Azure Database for PostgreSQL - フレキシブル サーバーとの TLS および SSL を使用した安全な接続

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

Azure Database for PostgreSQL フレキシブル サーバーでは、トランスポート層セキュリティ (TLS) を使用して、Azure Database for PostgreSQL フレキシブル サーバーへのクライアント アプリケーションの接続が強制されます。 TLS は、データベース サーバーとクライアント アプリケーションの間で、暗号化されたネットワーク接続を保証する業界標準のプロトコルです。 TLS は、Secure Sockets Layer (SSL) が更新されたプロトコルです。

TLS とは

Netscape Communications 製の TLS。 Secure Sockets Layer の show と has は定期的に置き換えられていますが、SSL または SSL/TLS という用語は依然として同じ意味で使用されることがあります。TLS は、TLS record show と TLS handshake show の 2 つの層で構成されています。 record show は関連付けのセキュリティを提供し、handshake show はサーバーと顧客がお互いを確認し、情報が取引される前に暗号化評価と暗号キーを調整する権限を与えます。

上記の図は、次の動作で構成される一般的な TLS 1.2 ハンドシェイク シーケンスを示しています。

1. クライアントは、まず ClientHello と呼ばれるメッセージを送信します。このメッセージは基本的に、クライアントがサポートする暗号スイートのセットと TLS 1.2 を介して通信する意思を表しています
2. それをサーバーが受信し、ServerHello で応答します。これは特定の暗号スイートを使用して、TLS 1.2 を介してクライアントと通信することに同意します
3. それに加えて、サーバーは、そのキー共有を送信します。 このキー共有の詳細は、選択された暗号スイートによって異なります。 注意すべき重要な詳細は、クライアントとサーバーが暗号化キーについて合意するには、お互いの部分を受け取るか、共有する必要があることです。
4. サーバーは、証明書 (CA による署名済み) と、キー共有を含む ClientHello と ServerHello の一部の署名を送信します。そのため、クライアントはそれらが本物であることがわかります。
5. クライアントが上記のデータを正常に受信し、次に独自のキー共有を生成したら、それをサーバーのキー共有と混合して、セッションの暗号化キーを生成します。
6. 最後のステップとして、クライアントはサーバーにキー共有を送信し、暗号化を有効にして、Finished メッセージ (これまでに行われた処理のトランスクリプトのハッシュ) を送信します。 サーバーも同じように、キー共有を混合してキーを取得し、独自の Finished メッセージを送信します。
7. このとき、アプリケーション データは接続上で暗号化して送信できます。

証明書チェーン

証明書チェーンは、SSL/TLS 証明書と証明機関 (CA) 証明書を含む証明書の順序指定済みリストです。これを使うと、受信側は送信者とすべての CA が信頼できることを確認できます。 チェーンまたはパスは SSL/TLS 証明書で始まり、チェーン内の各証明書はチェーン内の次の証明書によって識別されるエンティティによって署名されます。 チェーンは、ルート CA 証明書で終了します。 ルート CA 証明書は、常に証明機関 (CA) 自体によって署名されます。 チェーン内のすべての証明書の署名は、ルート CA 証明書まで検証する必要があります。 SSL/TLS 証明書とチェーン内のルート CA 証明書の間にある証明書は、中間証明書と呼ばれます。

TLS バージョン

米国の保健福祉省 (HHS) や国立標準技術研究所 (NIST) など、世界にはネットワーク セキュリティに関する TLS のガイドラインを維持する政府機関がいくつか存在します。 TLS が提供するセキュリティのレベルは、TLS プロトコルのバージョンとサポートされている暗号スイートによって最も大きな影響を受けます。 暗号スイートは、暗号、キー交換アルゴリズム、ハッシュ アルゴリズムなどの一連のアルゴリズムであり、これらをまとめて使って、セキュリティ保護された TLS 接続を確立します。 ほとんどの TLS クライアントとサーバーはそれらの代わりとなるものを複数サポートしています。そのため、これらは、セキュリティで保護された接続を確立するときにネゴシエートして、一般的な TLS バージョンと暗号スイートを選択する必要があります。

Azure Database for PostgreSQL では TLS バージョン 1.2 以降をサポートしています。 インターネット技術標準化委員会 (IETF) は RFC 8996 で、TLS 1.0 と TLS 1.1 を使用してはならないことを明記しています。 どちらのプロトコルも、2019 年末までに非推奨となりました。

TLS 1.0 や TLS 1.1 など、以前のバージョンの TLS プロトコルを使用する受信接続は、既定ではすべて拒否されます。

インターネット技術標準化委員会 (IETF) は、2018 年 8 月に RFC 8446 で TLS 1.3 仕様をリリースし、現在使用されている最も一般的で推奨される TLS バージョンです。 TLS 1.3 は、TLS 1.2 より高速で安全です。

証明書認証は、認証用の SSL クライアント証明書を使用して実行されます。 このシナリオでは、PostgreSQL サーバーは、提示されたクライアント証明書の CN (共通名) 属性を、要求されたデータベース ユーザーと比較します。 Azure Database for PostgreSQL フレキシブル サーバーでは、現時点で SSL 証明書ベースの認証をサポートしていません。

現在の TLS/SSL 接続の状態を確認するには、sslinfo 拡張機能を読み込み、ssl_is_used() 関数を呼び出して SSL が使用されているかどうかを確認します。 この関数は、接続で SSL を使用している場合は t を返し、それ以外の場合は f を返します。 また、次のクエリを使用して、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの SSL 使用状況に関するすべての情報をプロセス、クライアント、アプリケーション別に収集することもできます。

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

テストのため、openssl コマンドを直接使用することもできます。次に例を示します。

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

このコマンドは、TLS のバージョン、暗号など、多数の低レベルのプロトコル情報を出力します。 オプション -starttls postgres を使用する必要があります。それ以外の場合、このコマンドは SSL が使用されていないことを報告します。 このコマンドを使用するには、少なくとも OpenSSL 1.1.1 が必要です。

クライアントでの SSL の構成

既定では、PostgreSQL でサーバー証明書の検証は実行されません。 つまり、クライアントが知らなくても、(DNS レコードを変更したりサーバー IP アドレスを乗っ取ったりするなどして) サーバー ID をスプーフィングすることは可能です。 どの SSL オプションでも、暗号化とキー交換の形式のオーバーヘッドが発生する可能性があるため、パフォーマンスとセキュリティの間でトレードオフが生じます。 スプーフィングを防ぐには、クライアントで SSL 証明書の検証を使用する必要があります。 クライアントを SSL 用に構成するための接続パラメーターは多数あります。 私たちにとって重要なものは、次のようにごく一部です。

1. ssl。 SSL を使用して接続します。 このプロパティは値を関連付ける必要がありません。 単に存在するだけで、SSL 接続が指定されます。 ただし、将来のバージョンとの互換性のためには、値 "true" をお勧めします。 このモードでは、SSL 接続を確立すると、クライアント ドライバーがサーバーの ID を検証し、"中間者" 攻撃を防ぎます。 これは、サーバー証明書が信頼された機関によって署名されていること、および接続先のホストが証明書内のホスト名と同じであることを確認することによって行われます。
2. sslmode。 暗号化が必要で、暗号化できない場合に接続を失敗させたい場合は、sslmode=require を設定します。 これにより、サーバーがこのホストや IP アドレスの SSL 接続を受け入れるように構成され、サーバーがクライアント証明書を認識するようになります。 つまり、サーバーが SSL 接続を受け入れない場合、またはクライアント証明書が認識されない場合、接続は失敗します。 次の表に、この設定の値を示します。

使用される既定の sslmode モードは、libpq ベースのクライアント (psql など) と JDBC で異なります。 libpq ベースのクライアントは既定で prefer となり、JDBC クライアントは既定で verify-full となります。

3. sslcert、sslkey、sslrootcert。 これらのパラメーターは、クライアント証明書、PKCS-8 クライアント キー、ルート証明書の既定の場所をオーバーライドできます。 これらの既定値はそれぞれ /defaultdir/postgresql.crt、/defaultdir/postgresql.pk8、/defaultdir/root.crt です。defaultdir は、*nix システムでは ${user.home}/.postgresql/ で、Windows では %appdata%/postgresql/ です。

証明機関 (CA) は、証明書の発行を担う機関です。 信頼された証明機関は、ある人物が主張している人物であることを確認する権限を持つエンティティです。 このモデルを機能させるには、すべての参加者が信頼された CA のセットに同意する必要があります。 すべてのオペレーティング システムとほとんどの Web ブラウザーは、信頼された CA のセットが付属しています。

クライアントでの SSL/TLS 構成の詳細については、PostgreSQL のドキュメントを参照してください。

証明書のピン留めのシナリオでルート CA 証明書をダウンロードしてアプリケーション クライアントを更新する

証明書のピン留めのシナリオでクライアント アプリケーションを更新するために、次の URI から証明書をダウンロードできます。

• Microsoft RSA Root Certificate Authority 2017 https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt
• DigiCert Global Root G2 https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem
• DigiCert Global Root CA https://cacerts.digicert.com/DigiCertGlobalRootCA.crt

証明書をクライアント証明書ストアにインポートするには、証明書ファイルを上記の URI からダウンロードした後に、証明書の .crt ファイルを .pem 形式に変換する必要が生じる場合があります。 これらのファイル変換を行うために、次の例に示すように、OpenSSL ユーティリティを使用できます。

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

クライアント アプリケーションの証明書ストアを新しいルート CA 証明書で更新する方法の詳細については、こちらのハウツー ドキュメントに記載されています。

証明書のピン留めのシナリオの読み取りレプリカ

ルート CA の Microsoft RSA Root Certificate Authority 2017 への移行により、前に作成したプライマリ サーバーよりも新しいルート CA 証明書に、新しく作成されたレプリカを配置できます。 そのため、verify-ca と verify-full の sslmode 構成設定 (証明書のピン留め) を使用するクライアントの場合、中断された接続で 3 つのルート CA 証明書を受け入れる必要があります:

• Microsoft RSA Root Certificate Authority 2017 https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt
• DigiCert Global Root G2 https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem
• DigiCert Global Root CA https://cacerts.digicert.com/DigiCertGlobalRootCA.crt

証明書のピン留めシナリオで psql に接続し、クライアント証明書をテストする

次の例に示すように、クライアントの psql コマンド ラインを使用し、証明書のピン留めシナリオでサーバーへの接続をテストできます。

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

ssl と証明書のパラメータの詳細については、psql ドキュメントをご覧ください。

SSL/TLS 接続のテスト

クライアント アプリケーションから SSL 対応サーバーへのアクセスを試行する前に、psql 経由でアクセスできることを確認してください。 SSL 接続が確立されると、次のような出力が表示されます。

psql (14.5)SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)Type "help" for help.

sslinfo 拡張機能を読み込み、ssl_is_used() 関数を呼び出して SSL が使用されているかどうかを確認します。 この関数は、接続で SSL を使用している場合は t を返し、それ以外の場合は f を返します。

暗号スイート

暗号スイート は、暗号アルゴリズムのセットです。 TLS/SSL プロトコルは、暗号スイートのアルゴリズムを使用して、キーを作成し、情報を暗号化します。 暗号スイートは一見ランダムな情報の長い文字列として表示されますが、その文字列の各セグメントには重要な情報が含まれています。 一般に、このデータ文字列はいくつかの主要なコンポーネントで構成されます。

• プロトコル (つまり、TLS 1.2 または TLS 1.3)
• キー交換または合意アルゴリズム
• デジタル署名 (認証) アルゴリズム
• 一括暗号化アルゴリズム
• メッセージ認証コード アルゴリズム (MAC)

SSL/TLS のバージョンが異なると、サポートされる暗号スイートも異なります。 TLS 1.2 暗号スイートは TLS 1.3 接続とネゴシエートできず、その逆も同じです。 現時点で、Azure Database for PostgreSQL フレキシブル サーバーは、HIGH:!aNULL カテゴリに分類される TLS 1.2 プロトコル バージョンの暗号スイートを数多くサポートしています。

SSL/TLS 接続エラーのトラブルシューティング

1. SSL/TLS プロトコル バージョンの互換性のトラブルシューティングに関する最初のステップは、クライアントによる TLS 暗号化が行われた状態で Azure Database for PostgreSQL - フレキシブル サーバーにアクセスしようとしたときに表示されるエラー メッセージを特定することです。 アプリケーションとプラットフォームによっては、エラー メッセージが異なる場合がありますが、多くの場合、基になる問題を示しています。
2. SSL/TLS プロトコル バージョンの互換性を確認するには、データベース サーバーとアプリケーション クライアントの SSL/TLS 構成を確認して、互換性のあるバージョンと暗号スイートがサポートされていることを確認する必要があります。
3. データベース サーバーとクライアントの SSL/TLS バージョンと暗号スイートの間の不一致やギャップを分析し、特定のオプションの有効化または無効化、ソフトウェアのアップグレードまたはダウングレード、または証明書またはキーの変更によって解決を試みてください。 たとえば、セキュリティと互換性の要件によっては、サーバーまたはクライアントで特定の SSL/TLS バージョンを有効または無効にしなければならない場合があります。例として、安全ではなく非推奨と見なされている TLS 1.0 と TLS 1.1 を無効にし、より安全で新しい TLS 1.2 と TLS 1.3 を有効にするなどがあります。
4. Microsoft RSA Root Certificate Authority 2017 で発行された最新の証明書には、Digicert Global Root G2 CA によってクロス署名された中間証明書がチェーン内にあります。 一部の Postgres クライアント ライブラリでは、sslmode=verify-full または sslmode=verify-ca の設定を使っているときに、中間証明書とクロス署名されているルート CA 証明書で接続エラーが発生し、代替の信頼パスが生じる可能性があります。 これらの問題を回避するには、3 つの必要な証明書をすべてクライアント証明書ストアに追加するか、前に説明したように sslrootcert パラメーターを明示的に指定するか、PGSSLROOTCERT 環境変数を、既定値の %APPDATA%\postgresql\root.crt ではなく、Microsoft RSA Root Certificate Authority 2017 のルート CA 証明書があるローカル パスに設定します。

関連するコンテンツ

• Azure portal または Azure CLI でプライベート アクセス (VNet 統合) オプションを使って Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成する方法について説明します。
• Azure portal または Azure CLI でパブリック アクセス (許可された IP アドレス) オプションを使って Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成する方法について学習します。