次の方法で共有

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

    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 です。