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