Azure Database for PostgreSQL フレキシブルサーバーでの TLS と SSL を使用したセキュリティで保護された接続

2024-11-12

適用対象: 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 ハンドシェイクシーケンスを示しています。

クライアントは、まず ClientHello と呼ばれるメッセージを送信します。このメッセージは基本的に、クライアントがサポートする暗号スイートのセットと TLS 1.2 を介して通信する意思を表しています。
サーバーがメッセージを受信し、ServerHello で応答します。そして、特定の暗号スイートを使用して、TLS 1.2 を介してクライアントと通信することに同意します
サーバーは、そのキー共有も送信します。このキー共有の詳細は、選択された暗号スイートによって異なります。クライアントとサーバーが暗号化キーについて合意するには、お互いの一部を受け取るか、共有する必要があります。
サーバーは、証明書 (証明機関 [CA] によって署名された) と、ClientHello と ServerHelloの部分に対する署名を送信します。キー共有も含まれます。この方法で、クライアントはそのサーバーが本物であることを識別します。
クライアントがデータを正常に受信し、独自のキー共有を生成したら、それをサーバーのキー共有と組み合わせて、セッションの暗号化キーを生成します。
クライアントはサーバーにキー共有を送信し、暗号化を有効にして、Finished メッセージを送信します。このメッセージは、これまでに発生した内容のトランスクリプトのハッシュです。サーバーも同じ処理を行います。キー共有を組み合わせてキーを取得し、独自の Finished メッセージを送信します。
これで、アプリケーションデータを接続上で暗号化して送信できます。

証明書チェーン

証明書チェーンは、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 より高速で安全です。

注

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 証明書。

注

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

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

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

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

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

証明書のピン留めのシナリオでルート 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-fullsslmode 構成設定 (証明書のピン留め) を使用するクライアントの場合、中断された接続で次の 3 つのルート 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 接続 (プロトコル: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)「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 接続エラーをトラブルシューティングする

TLS/SSL プロトコルバージョンの互換性のトラブルシューティングに関する最初のステップは、クライアントによる TLS 暗号化が行われた状態で Azure Database for PostgreSQL フレキシブルサーバーにアクセスしようとしたときに表示されるエラーメッセージを特定することです。アプリケーションとプラットフォームによっては、エラーメッセージが異なる場合があります。多くの場合、基になる問題を示しています。
TLS/SSL プロトコルバージョンの互換性を確認するには、データベースサーバーとアプリケーションクライアントの TLS/SSL 構成を確認して、互換性のあるバージョンと暗号スイートがサポートされていることを確認します。
データベースサーバーとクライアント間の TLS/SSL バージョンや暗号スイートに関する不一致やギャップを分析します。特定のオプションを有効または無効にする、ソフトウェアをアップグレードまたはダウングレードする、証明書やキーを変更するなどの解決策を試してみてください。たとえば、セキュリティと互換性の要件に応じて、サーバーまたはクライアントで特定の TLS/SSL バージョンを有効または無効にする必要がある場合があります。具体的には、セキュリティで保護されておらず非推奨と見なされる TLS 1.0 と TLS 1.1 を無効にし、より安全でモダンな TLS 1.2 と TLS 1.3 を有効にする必要がある場合があります。
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 フレキシブルサーバーを作成する方法について学習します。

次の方法で共有

Azure Database for PostgreSQL フレキシブル サーバーでの TLS と SSL を使用したセキュリティで保護された接続