Azure Database for PostgreSQL では、すべてのクライアント接続でトランスポート層セキュリティ (TLS) を使用する必要があります。これは、データベース サーバーとクライアント アプリケーション間の通信を暗号化する業界標準のプロトコルです。 TLS は古い SSL プロトコルよりも優先され、TLS バージョン 1.2 と 1.3 のみがセキュリティで保護されたと認識されます。 TLS セキュリティの整合性は、次の 3 つの柱に依存します。
- TLS バージョン 1.2 または 1.3 のみを使用する。
- クライアントは、信頼されたルート CA によって開始された CA のチェーン内の証明機関 (CA) によって発行されたサーバーの TLS 証明書を検証します。
- サーバーとクライアントの間でセキュリティで保護されたサイファスイートを交渉する。
信頼されたルート証明書と証明書のローテーション
Important
Microsoft は、中間 CA 証明書と結果の証明書チェーンを更新するために、Azure Database for PostgreSQL の TLS 証明書ローテーションを開始しました。 ルート CA は同じままです。
クライアント構成で TLS の推奨構成を使用している場合は、何も行う必要はありません。
証明書のローテーション スケジュール
- Azure リージョンの米国中西部、東アジア、英国南部では、2025 年 11 月 11 日に TLS 証明書のローテーションが開始されました。
- 2026 年 1 月 19 日以降、この証明書ローテーションは、Azure Government を含む残りの (中国を除く) リージョンまで拡張される予定です。
- 2026 年の春節 (旧正月) の後、中国のリージョンでは、 ルート CA の 1 つに変更を含む証明書ローテーションも行われます。
Azure Database for PostgreSQL で使用されるルート CA
ルート CA は、証明書チェーンの最上位機関です。 現在、Azure Database for PostgreSQL では、次のルート CA によって固定された中間 CA (ICA) によって発行されたデュアル署名付き証明書が使用されています。
現在、中国リージョンでは次の CA が使用されています。
- Microsoft RSA Root CA 2017
- DigiCert グローバル ルート CA
- 春祭りの後 (中国の新年) 2026: DigicertグローバルルートG2. 新しいルート CA を信頼されたルート ストアに追加して、この変更を事前に準備します。
中間証明機関 (Intermediate Certificate Authority)
Azure Database for PostgreSQL では、中間 CA (ICA) を使用してサーバー証明書を発行します。 セキュリティを維持するために、Microsoft はこれらの ICA と発行するサーバー証明書を定期的にローテーションします。 これらのローテーションはルーチンであり、事前に発表されていません。
DigiCert Global Root CAの中間 CA の現在のローテーション (証明書のローテーションを参照) は 2023 年 11 月に開始され、2024 年第 1 四半期に完了する予定です。
推奨されるプラクティスに従った場合、この変更で環境を変更する必要はありません。
古い CA チェーン
信頼されたルート ストアで中間 CA またはサーバー証明書を使用しないでください。
DigiCert Global Root G2Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08- サーバー証明書
新しい CA チェーン
信頼されたルート ストアで中間 CA またはサーバー証明書を使用しないでください。
DigiCert Global Root G2Microsoft TLS RSA Root G2Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16- サーバー証明書
読み取りレプリカ
DigiCert グローバル ルート CA から DigiCert グローバル ルート G2 へのルート CA の移行は、すべてのリージョンで完了しているというわけではありません。 そのため、新しく作成された読み取りレプリカでは、プライマリ サーバーよりも新しいルート CA 証明書を使用できます。 読み取りレプリカの信頼ストアにDigiCert グローバル ルート CAを追加する必要があります。
証明書チェーン
証明書チェーンは、信頼された証明機関 (CA) によって発行された証明書の階層的なシーケンスです。 チェーンはルート CA から開始され、中間 CA (ICA) 証明書が発行されます。 ICA は、下位の ICA に対して証明書を発行できます。 チェーン内の最も低い ICA は、個々のサーバー証明書を発行します。 信頼のチェーンを確立するには、チェーン内の各証明書をルート CA 証明書まで検証します。
接続エラーの削減
推奨される TLS 構成を使用すると、証明書のローテーションや中間 CA の変更による接続エラーのリスクを軽減できます。 具体的には、中間 CA または個々のサーバー証明書を信頼しないようにします。 これらのプラクティスにより、Microsoft が証明書チェーンを更新するときに予期しない接続の問題が発生する可能性があります。
Important
Microsoft では、クライアント アプリケーションの準備に役立つルート CA の変更を事前に発表しています。 ただし、サーバー証明書のローテーションと中間 CA への変更はルーチンであり、発表されません。
注意事項
サポートされていない (クライアント) 構成を使用すると、予期しない接続エラーが発生します。
TLS の推奨される構成
最適な構成
-
ssl_min_protocol_versionサーバー パラメーターをTLSv1.3に設定して、最新の最も安全な TLS バージョンを適用します。 - PostgreSQL 接続の
sslmode=verify-allを使用して、完全な証明書とホスト名の検証を確認します。 プライベート エンドポイントまたは仮想ネットワーク統合を使用した DNS 構成によっては、verify-allできない場合があります。 そのため、代わりにverify-caを使用できます。 - 信頼されたルート ストアで、Azure ルート証明書の完全なセットを常に維持します。
適切な構成
-
ssl_min_protocol_versionサーバー パラメーターをTLSv1.3に設定します。 TLS 1.2 をサポートする必要がある場合は、最小バージョンを設定しないでください。 - PostgreSQL 接続の
sslmode=verify-allまたはsslmode=verify-caを使用して、完全または部分的な証明書検証を確認します。 - 信頼されたルート ストアに、Azure Database for PostgreSQL で現在使用されているルート CA 証明書が含まれていることを確認します。
サポートされていますが、推奨されていません
次の構成は使用しないでください。
-
require_secure_transportをOFFに設定し、クライアント側をsslmode=disableに設定して、TLS を無効にします。 - クライアント側の
sslmode設定disable、allow、prefer、またはrequireを使用して、アプリが中間者攻撃に対して脆弱になる可能性があります。
サポートされていない構成。使用しない
Azure PostgreSQL では、中間 CA の変更や個々のサーバー証明書のローテーションに関する変更はアナウンスされません。 そのため、 sslmode 設定を verify-ca または verify-allを使用する場合、次の構成はサポートされません。
- 信頼されたストアでの中間 CA 証明書の使用。
- 証明書のピン留めを使用する (信頼されたストア内の個々のサーバー証明書の使用など)。
注意事項
Microsoft が証明書チェーンの中間 CA を変更したり、サーバー証明書をローテーションしたりするたびに、アプリケーションは警告なしにデータベース サーバーに接続できません。
証明書のピン留めの問題
注
クライアント アプリケーションの接続文字列で sslmode=verify-full または sslmode=verify-ca 設定を使用しない場合、証明書のローテーションは影響を受けません。 そのため、このセクションの手順に従う必要はありません。
中間 CA の現在の証明書の変更など、証明書のローテーションが中断されるため、アプリケーションで証明書のピン留めを使用しないでください。 証明書ピン留めについて知らないのであれば、おそらく使用していないでしょう。 証明書のピン留めを確認するには:
- 信頼されたルート ストアにある証明書の一覧を生成します。
- Java アプリケーションのルート CA 証明書を結合して更新します。
- クライアント コンピューターで信頼されたルート ストアを開き、証明書の一覧をエクスポートします。
- 信頼されたルート ストアに中間 CA 証明書または個々の PostgreSQL サーバー証明書がある場合は、証明書のピン留めを使用しています。
- 証明書のピン留めを削除するには、信頼されたルート ストアからすべての証明書を削除し、 推奨されるルート CA 証明書を追加します。
これらの手順を実行しても中間証明書が原因で問題が発生する場合は、 Microsoft サポートにお問い合わせください。 タイトルに ICA Rotation 2026 を含めます。
TLS に関するその他の考慮事項
コア TLS 構成と証明書管理以外にも、Azure Database for PostgreSQL への暗号化された接続のセキュリティと動作に影響を与える要素がいくつかあります。 これらの考慮事項を理解することは、環境内の TLS 実装に関する情報に基づいた意思決定を行う際に役立ちます。
セキュリティで保護されていない TLS バージョンと保護された TLS バージョン
世界中のいくつかの政府機関は、ネットワーク セキュリティに関する TLS のガイドラインを維持しています。 米国では、これらの組織には、保健福祉省と国立標準技術研究所が含まれます。 TLS が提供するセキュリティのレベルは、TLS プロトコルのバージョンとサポートされている暗号スイートの影響を最も受ける。
Azure Database for PostgreSQL では、TLS バージョン 1.2 と 1.3 がサポートされています。 RFC 8996 では、インターネット エンジニアリング タスク フォース (IETF) は、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 1.2 よりも高速で安全であるため、推奨されるバージョンです。
お勧めしませんが、必要に応じて、Azure Database for PostgreSQL への接続に対して TLS を無効にすることができます。
require_secure_transport サーバー パラメーターをOFFに更新できます。
Important
最新バージョンの TLS 1.3 を使用して、データベース接続を暗号化します。 最小 TLS バージョンを指定するには、 ssl_min_protocol_version サーバー パラメーターを TLSv1.3 に設定します。
ssl_max_protocol_version サーバー パラメーターは設定しないでください。
暗号スイート
暗号スイートは、暗号、キー交換アルゴリズム、ハッシュ アルゴリズムを含む一連のアルゴリズムです。 TLS 証明書と TLS バージョンと共に使用して、セキュリティで保護された TLS 接続を確立します。 ほとんどの TLS クライアントとサーバーは、複数の暗号スイートと、場合によっては複数の TLS バージョンをサポートします。 接続の確立中に、クライアントとサーバーは 、ハンドシェイクを介して使用する TLS バージョンと暗号スイートをネゴシエートします。 このハンドシェイク中に、次の手順が実行されます。
- クライアントは、受け入れ可能な暗号スイートの一覧を送信します。
- サーバーは、一覧から最適な暗号スイートを選択し、選択内容をクライアントに通知します。
Azure Database for PostgreSQL では使用できない TLS 機能
現時点では、Azure Database for PostgreSQL では次の TLS 機能は実装されていません。
- 相互認証 (mTLS) を使用した TLS による TLS 証明書ベースのクライアント認証。
- カスタム サーバー証明書 (独自の TLS 証明書を持ち込む)。