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 コンテナーを非ルートとして実行する方法の詳細については、セキュリティの構成に関するページを参照してください。
非ルート SQL Server コンテナー用のサンプル Dockerfile をダウンロードし、
dockerfile
として保存します。dockerfile ディレクトリのコンテキストで次のコマンドを実行して、非ルート SQL Server コンテナーを作成します。
cd <path to dockerfile> docker build -t 2017-latest-non-root .
コンテナーを開始します。
重要
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
フラグが必要です。コンテナーが非ルート ユーザーとして実行されていることを確認します。
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 コンテナーで mssql
や root
などの名前付きユーザーが使われていることを確認します。そうでない場合、コンテナー内で 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、証明書、マシン キーなど) が既定で作成されます。これらへのアクセスは、既定で mssql
と root
のユーザーに制限されています。 SQL Server コンテナーの永続ストレージを構成する場合は、同じアクセス戦略を使用して、コンテナー内の /var/opt/mssql/secrets
フォルダーにマップされたホストまたは共有ボリューム上のパスが確実に保護され、ホスト上の mssql
と root
のユーザーのみがアクセスできるようにしてください。 このパス/フォルダーへのアクセスが侵害されると、悪意のあるユーザーがこれらの重要なファイルにアクセスできるようになり、暗号化階層や Active Directory の構成が侵害されます。
SQL Server Linux コンテナーへの接続を暗号化するには、以下の要件を持つ証明書が必要です。
SQL Server Linux コンテナーへの接続を暗号化する方法の例を次に示します。 ここでは、自己署名証明書を使用しますが、運用環境のシナリオでは使用しないでください。 このような環境では、代わりに CA 証明書を使用する必要があります。
自己署名証明書を作成します。これは、テスト環境と非運用環境のみに適しています。
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/
が既に存在していることも確認する必要があります。mssql.key
とmssql.pem
のファイルに適切なアクセス許可を設定し、これらのファイルを SQL Server コンテナーにマウントするときにエラーが発生しないようにします。chmod 440 /container/sql1/mssql.pem chmod 440 /container/sql1/mssql.key
次に、以下の内容で
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.conf
、mssql.key
、mssql.pem
の 3 つのファイルが作成されます。次のコマンドを使って、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.conf
、mssql.pem
、mssql.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) のコンテナー イメージを開始する