次の方法で共有


SQL Server Linux コンテナーをセキュリティで保護する

適用対象: SQL Server - Linux

SQL Server 2017 (14.x) コンテナーは既定でルート ユーザーとして起動するため、セキュリティ上の問題が発生する可能性があります。 この記事では SQL Server Linux コンテナーを実行するときのセキュリティ オプションと、ルート以外のユーザーとして SQL Server コンテナーを構築する方法について説明します。

この記事の例では、Docker を使用していることを前提としていますが、Kubernetes などの他のコンテナー オーケストレーション ツールにも同じ原則を適用できます。

非ルート SQL Server 2017 コンテナーを作成して実行する

次の手順のようにして、mssql (非ルート) ユーザーとして起動する SQL Server 2017 (14.x) コンテナーを作成します。

注意

SQL Server 2019 (15.x) 以降のバージョンのコンテナーは自動的に非ルートとして起動するのに対し、SQL Server 2017 (14.x) のコンテナーは既定でルートとして起動します。 SQL Server コンテナーを非ルートとして実行する方法の詳細については、セキュリティの構成に関するページを参照してください。

  1. 非ルート SQL Server コンテナー用のサンプル Dockerfile をダウンロードし、dockerfile として保存します。

  2. dockerfile ディレクトリのコンテキストで次のコマンドを実行して、非ルート SQL Server コンテナーを作成します。

    cd <path to dockerfile>
    docker build -t 2017-latest-non-root .
    
  3. コンテナーを開始します。

    重要

    SA_PASSWORD 環境変数は非推奨です。 代わりに MSSQL_SA_PASSWORD を使用してください

    docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword@" --cap-add SYS_PTRACE --name sql1 -p 1433:1433 -d 2017-latest-non-root
    

    注意

    非ルート SQL Server コンテナーによってトラブルシューティング用のダンプが生成されるようにするには、--cap-add SYS_PTRACE フラグが必要です。

  4. コンテナーが非ルート ユーザーとして実行されていることを確認します。

    docker exec -it sql1 bash
    

    whoami を実行すると、コンテナーで実行されているユーザーが返されます。

    whoami
    

ホスト上で別の非ルート ユーザーとしてコンテナーを実行する

SQL Server コンテナーを別の非ルート ユーザーとして実行するには、-u フラグを docker run コマンドに追加します。 非ルート コンテナーには、非ルート ユーザーがアクセスできる /var/opt/mssql にボリュームがマウントされていない限り、root グループの一部として実行される必要がある制限があります。 root グループから非ルート ユーザーに対して追加のルート アクセス許可は付与されません。

UID 4000 を持つユーザーとして実行する

カスタム UID を使用して SQL Server を開始できます。 たとえば、次のコマンドでは UID 4000 を使用して SQL Server が開始されます。

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u 4000:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

警告

SQL Server コンテナーで mssqlroot などの名前付きユーザーが使われていることを確認します。そうでない場合、コンテナー内で sqlcmd を実行できません。 SQL Server コンテナーが名前付きユーザーとして実行されているかどうかは、コンテナー内で whoami を実行することで確認できます。

非ルート コンテナーをルート ユーザーとして実行する

必要に応じて、ルート以外のコンテナーをルート ユーザーとして実行できます。このようにすると、より高い特権があるため、ファイルに対するすべてのアクセス許可もコンテナーに自動的に付与されます。

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" -u 0:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

ご利用のホスト コンピューター上のユーザーとして実行する

次のコマンドを使用すれば、ホスト コンピューター上の既存のユーザーで SQL Server を開始できます。

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u $(id -u myusername):0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

別のユーザーおよびグループとして実行する

カスタムのユーザーおよびグループで SQL Server を開始できます。 この例では、マウントされたボリュームには、ホスト コンピューター上のユーザーまたはグループ用に構成されたアクセス許可があります。

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=MyStrongPassword" --cap-add SYS_PTRACE -u $(id -u myusername):$(id -g myusername) -v /path/to/mssql:/var/opt/mssql -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

非ルート コンテナーに対して永続的なストレージ アクセス許可を構成する

マウントされたボリューム上にあるデータベース ファイルへのアクセスを非ルート ユーザーに許可するには、コンテナーを実行するユーザーまたはグループが永続的なファイル ストレージに対して読み書きできるようにします。

次のコマンドを使用すれば、データベース ファイルの現在の所有権を取得できます。

ls -ll <database file dir>

永続化されたデータベース ファイルへのアクセス権が SQL Server にない場合は、次のいずれかのコマンドを実行します。

データベース ファイルへの読み取り/書き込みアクセス権をルート グループに付与する

非ルート SQL Server コンテナーがデータベース ファイルにアクセスできるように、次のディレクトリへのアクセス許可をルート グループに付与します。

chgrp -R 0 <database file dir>
chmod -R g=u <database file dir>

非ルート ユーザーをファイルの所有者として設定する

これは、既定の非ルート ユーザーとすることも、その他の任意の非ルート ユーザーを指定することもできます。 この例では、UID 10001 を非ルート ユーザーとして設定します。

chown -R 10001:0 <database file dir>

SQL Server Linux コンテナーへの接続を暗号化する

重要

SQL Server on Linux またはコンテナーに対して Active Directory 認証または暗号化オプション (Transparent Data Encryption (TDE) や SSL など) を構成する場合、フォルダー /var/opt/mssql/secrets の下に複数のファイル (keytab、証明書、マシン キーなど) が既定で作成されます。これらへのアクセスは、既定で mssqlroot のユーザーに制限されています。 SQL Server コンテナーの永続ストレージを構成する場合は、同じアクセス戦略を使用して、コンテナー内の /var/opt/mssql/secrets フォルダーにマップされたホストまたは共有ボリューム上のパスが確実に保護され、ホスト上の mssqlroot のユーザーのみがアクセスできるようにしてください。 このパス/フォルダーへのアクセスが侵害されると、悪意のあるユーザーがこれらの重要なファイルにアクセスできるようになり、暗号化階層や Active Directory の構成が侵害されます。

SQL Server Linux コンテナーへの接続を暗号化するには、以下の要件を持つ証明書が必要です。

SQL Server Linux コンテナーへの接続を暗号化する方法の例を次に示します。 ここでは、自己署名証明書を使用しますが、運用環境のシナリオでは使用しないでください。 このような環境では、代わりに CA 証明書を使用する必要があります。

  1. 自己署名証明書を作成します。これは、テスト環境と非運用環境のみに適しています。

    openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=sql1.contoso.com' -keyout /container/sql1/mssql.key -out /container/sql1/mssql.pem -days 365
    

    前のコード サンプルでは、sql1 は SQL コンテナーのホスト名であるため、このコンテナーに接続する場合、接続文字列で使用される名前は sql1.contoso.com,port になります。 上記のコマンドを実行する前に、フォルダー パス /container/sql1/ が既に存在していることも確認する必要があります。

  2. mssql.keymssql.pem のファイルに適切なアクセス許可を設定し、これらのファイルを SQL Server コンテナーにマウントするときにエラーが発生しないようにします。

    chmod 440 /container/sql1/mssql.pem
    chmod 440 /container/sql1/mssql.key
    
  3. 次に、以下の内容で mssql.conf ファイルを作成して、サーバーによって開始される暗号化を有効にします。 クライアントによって開始される暗号化の場合は、最後の行を forceencryption = 0 に変更します。

    [network]
    tlscert = /etc/ssl/certs/mssql.pem
    tlskey = /etc/ssl/private/mssql.key
    tlsprotocols = 1.2
    forceencryption = 1
    

    注意

    Linux ディストリビューションによっては、証明書とキーの格納先のパスは、それぞれ /etc/pki/tls/certs/ と /etc/pki/tls/private/ である可能性があります。 SQL Server コンテナーの mssql.conf を更新する前に、パスを確認してください。 mssql.conf に設定された場所は、コンテナー内の SQL Server で証明書とそのキーが検索される場所になります。 この場合、その場所は /etc/ssl/certs//etc/ssl/private/ になります。

    mssql.conf ファイルも、同じフォルダーの場所 /container/sql1/ の下に作成されます。 上記の手順を行うと、sql1 フォルダーに mssql.confmssql.keymssql.pem の 3 つのファイルが作成されます。

  4. 次のコマンドを使って、SQL Server コンテナーをデプロイします。

    docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=P@ssw0rd" -p 5434:1433 --name sql1 -h sql1 -v /container/sql1/mssql.conf:/var/opt/mssql/mssql.conf -v   /container/sql1/mssql.pem:/etc/ssl/certs/mssql.pem -v /container/sql1/mssql.key:/etc/ssl/private/mssql.key -d mcr.microsoft.com/mssql/server:2019-latest
    

    上のコマンドでは、mssql.confmssql.pemmssql.key ファイルをコンテナーにマウントし、コンテナー内の 1433 ポート (SQL Server の既定のポート) をホストの 5434 ポートにマップしました。

    注意

    RHEL 8 以降を使用している場合は、docker run の代わりに podman run コマンドを使用することもできます。

SQL Server on Linux コンテナーへの接続の暗号化を開始するには、「クライアントによって開始される暗号化」に記載されている「クライアント マシンへの証明書の登録」および「接続文字列の例」セクションに従ってください。

  • クイックスタートに従って、Docker 上で SQL Server 2017 (14.x) のコンテナー イメージを開始する
  • クイックスタートに従って、Docker 上で SQL Server 2019 (15.x) のコンテナー イメージを開始する
  • クイックスタートに従って、Docker 上で SQL Server 2022 (16.x) のコンテナー イメージを開始する