SQL Server-on-Linux への接続を暗号化する
適用対象: SQL Server - Linux
SQL Server on Linux では、トランスポート層セキュリティ (TLS) を使用して、クライアント アプリケーションと SQL Server インスタンス間のネットワークで送信されるデータを暗号化できます。 SQL Server では、Windows と Linux の両方で同じ TLS プロトコルがサポートされています。TLS 1.2、1.1、および 1.0。 ただし、TLS を構成する手順は、SQL Server が実行されているオペレーティング システムに固有です。
証明書の要件
証明書が次の要件に従っていることを確認します。
現在のシステム時刻が証明書の
Valid from
プロパティから証明書のValid to
プロパティまでの範囲であること。証明書がサーバー認証に使用されていること。
Server Authentication (1.3.6.1.5.5.7.3.1)
を指定するには、証明書のEnhanced Key Usage
プロパティが必要です。証明書が
AT_KEYEXCHANGE
のKeySpec
オプションを使用して作成する必要があります。 通常、証明書のキー使用法プロパティ (KEY_USAGE
) には、キーの暗号化 (CERT_KEY_ENCIPHERMENT_KEY_USAGE
) も含まれます。証明書の
Subject
プロパティで、共通名 (CN) がサーバー コンピューターのホスト名または完全修飾ドメイン名 (FQDN) と同一であることを示す必要があります。Note
ワイルドカード証明書がサポートされます。
使用する OpenSSL ライブラリの構成 (省略可能)
暗号化でどの libcrypto.so
ライブラリと libssl.so
ライブラリを使用するかを参照するシンボリック リンクを /opt/mssql/lib/
ディレクトリに作成できます。 これは、システムで提供されている OpenSSL の既定以外の特定のバージョンを使用するように SQL Server に指示する場合に便利です。 これらのシンボリック リンクが存在しない場合、SQL Server は既定で構成された OpenSSL ライブラリをシステムに読み込みます。
これらのシンボリック リンクには libcrypto.so
と libssl.so
いう名前を付け、/opt/mssql/lib/
ディレクトリに配置する必要があります。
Note
Let's Encrypt を使用して証明書を生成する例については、ブログ記事「 Linux Azure VM 上の SQL Server と Azure AI 検索を使用して Azure のデータの機能をロックしないを参照してください。
概要
クライアント アプリケーションから SQL Server への接続を暗号化するために TLS が使用されます。 正しく構成されると、TLS によって、クライアントとサーバー間の通信に対して、プライバシーとデータ整合性の両方が提供されます。 TLS 接続は、クライアント側で開始することもサーバー側で開始することもできます。
次のセクションでは、クライアントによって開始される暗号化の設定について説明します。
証明書の生成
/CN
は、SQL Server ホストの完全修飾ドメイン名と一致する必要があります。
注意事項
この例では、自己署名証明書を使用します。 自己署名証明書は運用シナリオでは使用しないでください。 CA 証明書を使用する必要があります。
証明書と秘密キーを保存するフォルダーが、mssql
ユーザーまたはグループによってアクセス可能であり、権限が 700
(drwx-----
) に設定されていることを確認してください。 フォルダーは、権限セットを 700
(drwx------
) に設定し、mssql
ユーザーまたはグループが所有する、またはアクセス許可を 755
(drwxr-xr-x
) に設定し、他のユーザーが所有していても mssql
ユーザー グループがアクセスできるよう手動で作成することができます。 たとえば、次のサンプルに示すように、パス /var/opt/mssql/
の下にある sslcert
というフォルダーを作成し、ファイルに対するアクセス許可を 600
に設定して証明書と秘密キーを保存できます。
openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=mssql.contoso.com' -keyout mssql.key -out mssql.pem -days 365
sudo chown mssql:mssql mssql.pem mssql.key
sudo chmod 600 mssql.pem mssql.key
#Saving the certificate to the certs folder under /etc/ssl/ which has the following permission 755(drwxr-xr-x)
sudo mv mssql.pem /etc/ssl/certs/ drwxr-xr-x
#Saving the private key to the private folder under /etc/ssl/ with permissions set to 755(drwxr-xr-x)
sudo mv mssql.key /etc/ssl/private/
SQL Server を構成する
systemctl stop mssql-server
sudo cat /var/opt/mssql/mssql.conf
sudo /opt/mssql/bin/mssql-conf set network.tlscert /etc/ssl/certs/mssql.pem
sudo /opt/mssql/bin/mssql-conf set network.tlskey /etc/ssl/private/mssql.key
sudo /opt/mssql/bin/mssql-conf set network.tlsprotocols 1.2
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl restart mssql-server
クライアント コンピューター (Windows、Linux、または macOS) に証明書を登録する
CA の署名入り証明書を使用する場合は、ユーザー証明書ではなく、証明機関 (CA) 証明書をクライアント コンピューターにコピーする必要があります。
自己署名証明書を使用している場合は、各ディストリビューションの次のフォルダーに
.pem
ファイルをコピーし、それらを有効にするコマンドを実行します。Ubuntu: 証明書を
/usr/share/ca-certificates/
にコピーし、その拡張子を.crt
に変更し、dpkg-reconfigure ca-certificates
を使用してシステム CA 証明書として有効にします。RHEL: 証明書を
/etc/pki/ca-trust/source/anchors/
にコピーし、update-ca-trust
を使用してシステム CA 証明書として有効にします。SUSE: 証明書を
/usr/share/pki/trust/anchors/
にコピーし、update-ca-certificates
を使用してシステム CA 証明書として有効にします。Windows: [現在のユーザー] > [信頼されたルート証明機関] > [証明書] で、
.pem
ファイルを証明書としてインポートします。macOS:
証明書を
/usr/local/etc/openssl/certs
にコピーします。次のコマンドを実行して、ハッシュ値を取得します。
/usr/local/Cellar/openssl/1.0.2l/openssl x509 -hash -in mssql.pem -noout
証明書の名前を値に変更します。 (例:
mv mssql.pem dc2dd900.0
)。dc2dd900.0
が/usr/local/etc/openssl/certs
に入力されていることを確認します。
接続文字列の例
注意事項
常に強力なパスワードを使用してください。 詳細については、「 Password Policy」をご参照ください。
SQL Server Management Studio
sqlcmd
sqlcmd -S <sqlhostname> -N -U sa -P '<password>'
ADO.NET
"Encrypt=True; TrustServerCertificate=False;"
ODBC
"Encrypt=Yes; TrustServerCertificate=no;"
JDBC
"encrypt=true; trustServerCertificate=false;"
一般的な接続エラー
エラー メッセージ | Fix |
---|---|
The certificate chain was issued by an authority that is not trusted. |
このエラーは、TLS ハンドシェイク中に SQL Server によって提示された証明書の署名をクライアントで検証できない場合に発生します。 クライアントで SQL Server 証明書が直接信頼されているか、SQL Server 証明書に署名した CA が信頼されていることを確認します。 |
The target principal name is incorrect. |
SQL Server の証明書の [共通名] フィールドと、クライアントの接続文字列に指定されているサーバー名が一致していることを確認します。 |
An existing connection was forcibly closed by the remote host. |
このエラーは、SQL Server によって要求されている TLS プロトコルのバージョンがクライアントでサポートされていない場合に発生する可能性があります。 たとえば、TLS 1.2 を要求するように SQL Server が構成されている場合は、クライアントでも TLS 1.2 プロトコルがサポートされていることを確認します。 |
Ubuntu 20.04 およびその他の最新の Linux ディストリビューション リリース
症状:
Linux インスタンスの SQL Server が、112 ビット未満のセキュリティを使用する署名アルゴリズムで作成された証明書 (例: MD5、SHA-1) を読み込むとき、次の例のような接続エラーが発生することがあります。
サーバーとの接続は正常に確立されましたが、ログイン プロセスでエラーが発生しました。 (プロバイダー: SSL プロバイダー、エラー: 0 - 既存の接続がリモート ホストによって強制的に閉じられました。)(Microsoft SQL Server、エラー: 10054)
このエラーは、Ubuntu 20.04 以降で、OpenSSL セキュリティ レベル 2 が既定で有効になっているために発生します。 セキュリティ レベル 2 では、112 ビット未満のセキュリティでの TLS 接続の確立は禁止されています。
解決方法
最低でも 112 ビットのセキュリティを使用する署名アルゴリズムを使用して証明書をインストールしてください。 この要件を満たす署名アルゴリズムは、SHA-224、SHA-256、SHA-384、および SHA-512 です。