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 とは

TLS は Netscape の SSL プロトコルから作成され、段階的に置き換えられてきました。 SSL または TLS/SSL という用語は、引き続き同じ意味で使用されています。 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. これで、アプリケーション データを接続上で暗号化して送信できます。

証明書チェーン

証明書チェーンは、TLS/SSL 証明書と CA 証明書を含む証明書の順序指定済みリストです。 これにより受信者は、送信者とすべての CA が信頼できることを確認できます。 チェーンまたはパスは、TLS/SSL 証明書から始まります。 チェーン内の各証明書はチェーン内の次の証明書によって識別されるエンティティによって署名されます。

チェーンは、ルート CA 証明書で終了します。 この証明書は、常に CA 自体によって署名されます。 チェーン内のすべての証明書の署名は、ルート CA 証明書まで検証する必要があります。

TLS/SSL 証明書とチェーン内のルート CA 証明書の間にある証明書は、中間証明書と呼ばれます。

TLS バージョン

世界中のいくつかの政府機関は、ネットワーク セキュリティに関する 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 1.3 が現在使用されている最も一般的で推奨される TLS バージョンです。 TLS 1.3 は、TLS 1.2 より高速で安全です。

Note

SSL と TLS の証明書により、接続が最先端の暗号化プロトコルで保護されていることが証明されます。 通信中の接続を暗号化することで、転送中のデータへの不正アクセスを防ぐことができます。 最新バージョンの TLS を使用して、Azure Database for PostgreSQL - フレキシブル サーバーへの接続を暗号化することを強くお勧めします。

推奨はされませんが、必要であれば、Azure Database for PostgreSQL - フレキシブル サーバーへの接続で TLS/SSL を無効にできます。 require_secure_transport サーバー パラメーターを OFF に更新できます。 ssl_min_protocol_version および ssl_max_protocol_version サーバー パラメーターを設定して、TLS バージョンを設定することもできます。

証明書認証は、認証用の SSL クライアント証明書を使用して実行されます。 このシナリオでは、PostgreSQL サーバーは、提示されたクライアント証明書の共通名 (CN) 属性を、要求されたデータベース ユーザーと比較します。

現在、Azure Database for PostgreSQL - フレキシブル サーバーは、次をサポートしていません。

• SSL 証明書ベースの認証。
• カスタム SSL/TLS 証明書。

Note

Microsoft は、Azure Database for PostgreSQL - フレキシブル サーバーなど、さまざまな Azure サービスに対してルート CA の変更を行いました。 詳細については、「Azure TLS 証明書の変更」と、「クライアントで 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 が必要です。

クライアントから Azure Database for PostgreSQL - フレキシブル サーバーへの接続保護のために、最新の最も安全な TLS バージョンを適用するには、ssl_min_protocol_version を 1.3 に設定します。 その設定では、Azure Database for PostgreSQL フレキシブル サーバーに接続するクライアントは、セキュリティで保護された方法で通信するために、このバージョンのプロトコルのみを使う必要があります。 以前のクライアントは、このバージョンをサポートしていないため、サーバーと通信できない可能性があります。

クライアントで SSL を構成する

既定では、PostgreSQL でサーバー証明書の検証は実行されません。 このため、クライアントに認識されずに、サーバー ID をスプーフィングすることは可能です (たとえば、DNS レコードを変更する、またはサーバー IP アドレスを乗っ取るなど)。 どの SSL オプションでも、暗号化とキー交換の形式のオーバーヘッドが発生する可能性があるため、パフォーマンスとセキュリティの間でトレードオフが生じます。

スプーフィングを防ぐには、クライアントで SSL 証明書の検証を使用する必要があります。

クライアントを SSL 用に構成するための接続パラメーターは多数あります。 重要な点をいくつか以下に示します。

• ssl: SSL を使用して接続します。 このプロパティは値を関連付ける必要がありません。 単に存在するだけで、SSL 接続が指定されます。 将来のバージョンとの互換性を確保するために、値 true をお勧めします。 このモードでは、SSL 接続を確立すると、クライアント ドライバーがサーバーの ID を検証し、中間者攻撃を防ぎます。 これは、サーバー証明書が信頼された機関によって署名されていること、および接続先のホストが証明書内のホスト名と同じであることを確認することによって行われます。

• sslmode: 暗号化を必須とし、暗号化できない場合に接続を失敗させたい場合は、sslmode=require を設定します。 この設定により、サーバーがこのホストや IP アドレスの SSL 接続を受け入れるように構成され、サーバーがクライアント証明書を認識するようになります。 サーバーが SSL 接続を受け入れない場合、またはクライアント証明書が認識されない場合、接続は失敗します。 次の表に、この設定の値の一覧を示します。

  SSL モード	説明
  disable	暗号化は使用されません。
  allow	暗号化は、サーバー設定で必要とされるか、強制される場合に使用されます。
  prefer	暗号化は、サーバー設定で許可されている場合に使用されます。
  require	暗号化が使用されます。 これにより、サーバーがこのホストや IP アドレスの SSL 接続を受け入れるように構成され、サーバーがクライアント証明書を認識するようになります。
  verify-ca	暗号化が使用されます。 クライアントに格納されている証明書に対してサーバー証明書の署名を検証します。
  verify-full	暗号化が使用されます。 クライアントに格納されている証明書に対してサーバー証明書の署名とホスト名を検証します。

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

• 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 のセットが付属しています。

verify-ca と verify-full sslmode 構成設定を使用することは、証明書のピン留めとも呼ばれます。 このケースでは、PostgreSQL サーバー上のルート CA 証明書で証明書の署名のほか、さらにホスト名をクライアント上の証明書と突き合わせる必要があります。

CA の PostgreSQL サーバー証明書が変更または期限切れになったときに、クライアントに保存されている証明書の定期的な更新が必要になる場合があります。 CA をピン留めしているかどうかを判別するには、証明書のピン留めと Azure サービスに関するページを参照してください

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

verify-ca と verify-full sslmode の構成設定 (つまり、証明書のピン留め) を使用するクライアントの場合、クライアント証明書ストアに次の "3 つ" のルート CA 証明書をデプロイする必要があります。

• DigiCert Global Root G2 と Microsoft RSA Root CA 2017 ルート CA 証明書。これはサービスが Digicert から Microsoft CA に移行するためです。
• Digicert Global Root CA。これはレガシとの互換性のためです。

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

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

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• DigiCert グローバル ルート CA

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

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

クライアント アプリケーションの証明書ストアを新しいルート CA 証明書で更新する方法については、アプリケーション クライアントのクライアント TLS 証明書の更新に関するページに記載されています。

重要

一部の Postgres クライアント ライブラリでは、sslmode=verify-full 設定を使用しているときに、中間証明書とクロス署名されているルート CA 証明書で接続エラーが発生する可能性があります。 その結果、代替の信頼パスが必要になります。 この場合は、sslrootcert パラメーターを明示的に指定することをお勧めします。 または、PGSSLROOTCERT 環境変数を、%APPDATA%\postgresql\root.crt の既定値から Microsoft RSA Root CA 2017 ルート CA 証明書が配置されているローカル パスに設定します。

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

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

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• DigiCert グローバル ルート CA

現在、Azure Database for PostgreSQL - フレキシブル サーバーでは、証明書ベースの認証をサポートしていません。

証明書のピン留めシナリオで 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 ドキュメントをご覧ください。

TLS/SSL 接続をテストする

クライアント アプリケーションから 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)

TLS/SSL のバージョンが異なると、サポートされる暗号スイートも異なります。 TLS 1.2 暗号スイートは TLS 1.3 接続とネゴシエートできず、その逆も同じです。

現時点で、Azure Database for PostgreSQL - フレキシブル サーバーは、HIGH:!aNULL カテゴリに分類される TLS 1.2 プロトコル バージョンの暗号スイートを数多くサポートしています。

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

1. TLS/SSL プロトコル バージョンの互換性のトラブルシューティングに関する最初のステップは、クライアントによる TLS 暗号化が行われた状態で Azure Database for PostgreSQL フレキシブル サーバーにアクセスしようとしたときに表示されるエラー メッセージを特定することです。 アプリケーションとプラットフォームによっては、エラー メッセージが異なる場合があります。 多くの場合、基になる問題を示しています。

2. TLS/SSL プロトコル バージョンの互換性を確認するには、データベース サーバーとアプリケーション クライアントの TLS/SSL 構成を確認して、互換性のあるバージョンと暗号スイートがサポートされていることを確認します。

3. データベース サーバーとクライアント間の TLS/SSL バージョンや暗号スイートに関する不一致やギャップを分析します。 特定のオプションを有効または無効にする、ソフトウェアをアップグレードまたはダウングレードする、証明書やキーを変更するなどの解決策を試してみてください。 たとえば、セキュリティと互換性の要件に応じて、サーバーまたはクライアントで特定の TLS/SSL バージョンを有効または無効にする必要がある場合があります。 具体的には、セキュリティで保護されておらず非推奨と見なされる TLS 1.0 と TLS 1.1 を無効にし、より安全でモダンな TLS 1.2 と TLS 1.3 を有効にする必要がある場合があります。

4. Microsoft RSA Root CA 2017 で発行された最新の証明書には、Digicert Global Root G2 CA によってクロス署名された中間証明書がチェーン内にあります。 一部の Postgres クライアント ライブラリでは、sslmode=verify-full または sslmode=verify-ca の設定を使用しているときに、中間証明書とクロス署名されているルート CA 証明書で接続エラーが発生する可能性があります。 その結果、代替の信頼パスが必要になります。

   これらの問題を回避するには、3 つの必要な証明書をすべてクライアント証明書ストアに追加するか、sslrootcert パラメーターを明示的に指定します。 または、PGSSLROOTCERT 環境変数を、%APPDATA%\postgresql\root.crt の既定値から Microsoft RSA Root CA 2017 ルート CA 証明書が配置されているローカル パスに設定します。

関連するコンテンツ

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