クライアント アプリケーションとデータベース サーバー間の接続では、常に業界標準のトランスポート層セキュリティ (TLS) (以前は Secure Sockets Layer (SSL) と呼ばれる暗号化が使用されます。
注
オープン ソースの PostgreSQL では、コマンド、変数、およびドキュメントで従来の名前 SSL を使用して、既存の実装が壊れないようにします。 この記事では、コマンド名と変数で SSL を使用するときに頭字語 TLS を使用します。
Azure Database for PostgreSQL では、TLS 1.2 と 1.3 を使用した暗号化接続がサポートされています。 サーバーは、TLS 1.0 と TLS 1.1 を使用してトラフィックを暗号化しようとするすべての受信接続を拒否します。
既定では、サーバーはクライアントとサーバーの間にセキュリティで保護された接続を強制します。 この強制を無効にし、暗号化されたクライアント通信と暗号化されていないクライアント通信の両方を許可するには、サーバー パラメーターの require_secure_transport を OFFに変更します。
ssl_max_protocol_version サーバー パラメーターを設定して、TLS バージョンを設定することもできます。
TLS を無効にしないでください。
Important
Microsoft は、中間 CA 証明書と結果の証明書チェーンを更新するために、Azure Database for PostgreSQL の TLS 証明書ローテーションを開始しました。 ルート CA は同じままです。
クライアント構成で TLS の推奨構成を使用している場合は、何も行う必要はありません。
証明書のローテーション スケジュール
- Azure リージョンの米国中西部、東アジア、英国南部では、2025 年 11 月 11 日に TLS 証明書のローテーションが開始されました。
- 2026 年 1 月 19 日以降、この証明書ローテーションは、Azure Government を含む残りの (中国を除く) リージョンまで拡張される予定です。
- 2026 年の春節 (旧正月) の後、中国のリージョンでは、 ルート CA の 1 つに変更を含む証明書ローテーションも行われます。
クライアント TLS の構成
既定では、PostgreSQL はサーバー証明書を検証しません。 この既定の動作により、クライアントはサーバー ID がスプーフィングされているかどうかを検出できません (たとえば、DNS レコードを変更したり、サーバー IP アドレスを引き継ぐ場合など)。 この種のスプーフィングを防ぐには、クライアントで TLS 証明書の検証を有効にします。
クライアント TLS セットアップ用に多数の接続パラメーターを構成できます。 重要な要素をいくつか次に示します。
ssl: TLS を使用して接続します。 このプロパティには値は必要ありません。 その存在は TLS 接続を指定します。 将来のバージョンとの互換性を確保するために、true値を使用します。 このモードでは、TLS 接続を確立すると、クライアント ドライバーは中間者攻撃を防ぐためにサーバーの ID を検証します。sslmode: 暗号化が必要な場合は、このパラメーターをrequireに設定し、暗号化できない場合は接続を失敗します。 この設定により、サーバーがこのホストまたは IP アドレスの TLS 接続を受け入れるように構成され、サーバーがクライアント証明書を認識します。 サーバーが TLS 接続を受け入れない場合、またはクライアント証明書が認識されない場合、接続は失敗します。 次の表に、この設定の値を示します。sslmodeExplanation disable暗号化は使用されません。 Azure Database for PostgreSQL には TLS 接続が必要であるため、この設定は使用しないでください。 allow暗号化は、サーバー設定で必要または適用される場合に使用されます。 Azure Database for PostgreSQL には TLS 接続が必要であるため、この設定は preferと同じです。prefer暗号化は、サーバー設定で許可されている場合に使用されます。 Azure Database for PostgreSQL には TLS 接続が必要です。 require暗号化が使用されます。 これにより、サーバーが TLS 接続を受け入れるように構成されます。 verify-ca暗号化が使用されます。 クライアントに格納されている信頼されたルート証明書に対してサーバー証明書を確認します。 verify-full暗号化が使用されます。 クライアントに格納されている証明書に対してサーバー証明書を確認します。 また、サーバー証明書が接続と同じホスト名を使用することも検証します。 プライベート DNS リゾルバーが別の名前を使用して Azure Database for PostgreSQL サーバーを参照する場合を除き、この設定を使用します。
既定の sslmode モードは、 libpq ベースのクライアント ( PSQL や JDBC など) によって異なります。 libpq ベースのクライアントは、既定で prefer。
JDBC クライアントは既定でverify-fullに設定されます。
-
sslcert、sslkey、およびsslrootcert: これらのパラメーターは、クライアント証明書、PKCS-8 クライアント キー、およびルート証明書の既定の場所をオーバーライドします。 既定では、/defaultdir/postgresql.crt、/defaultdir/postgresql.pk8、/defaultdir/root.crtで、defaultdirは Linux システムで${user.home}/.postgresql/され、Windows では%appdata%/postgresql/されます。
Important
一部の Postgres クライアント ライブラリでは、中間証明書をクロス署名するルート CA 証明書で sslmode=verify-full 設定を使用すると、接続に失敗することがあります。 この構成により、代替の信頼パスが作成されます。 この場合は、 sslrootcert パラメーターを明示的に指定します。 または、 PGSSLROOTCERT 環境変数を、microsoft RSA Root CA 2017 ルート CA 証明書が配置されているローカル パスに設定します(既定値の %APPDATA%\postgresql\root.crt)。
信頼されたルート証明機関 (CA) をインストールする
ルート CA 証明書をダウンロードして変換する
信頼されたルート証明書に対してシステム証明書ストアを使用する Windows クライアントの場合、Windows は Windows Update を介して新しいルート CA 証明書を展開するため、アクションは必要ありません。
Java クライアント、VS Code 拡張機能、およびシステム ストアを使用しないその他のクライアント ( PSQL、Perl など) と Linux 上のクライアントの場合:ルート CA 証明書をダウンロードして PEM ファイルに結合する必要があります。 少なくとも、次のルート CA 証明書を含めます。
注
中国リージョンおよびローテーション拡張機能をお持ちのお客様の場合: Digicert Global Root CA (pem ファイル) は引き続き有効です。を組み合わせた PEM ファイルに含めます。
すべての Azure ルート CA 証明書を含めて、Azure Database for PostgreSQL で使用されるルート CA に変更がある場合に、結合されたファイルに対する今後の更新の必要性を減らします。 Azure ルート CA 証明書の一覧については、 Azure 証明機関の詳細を参照してください。
証明書をクライアント証明書ストアにインポートするには、CRT 形式の証明書を PEM 形式に変換し、PEM ファイルを 1 つのファイルに連結することが必要になる場合があります。 OpenSSL X509 ユーティリティを使用して、CRT ファイルを PEM に変換できます。
openssl x509 -inform DER -in certificate-filename.crt -out certificate-filename.pem -outform PEM
ルート CA 証明書を 1 つの PEM ファイルに結合する
一部のクライアントでは、任意のテキスト エディターまたはコマンド ライン ツールを使用して、すべての PEM ファイルを 1 つのファイルに連結します。
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----
中国リージョンおよびローテーション拡張機能をお持ちのお客様の場合:
-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----
Java アプリケーションのルート CA 証明書を結合して更新する
カスタム Java アプリケーションでは、信頼された証明機関 (CA) 証明書を含む cacerts という既定のキーストアが使用されます。
cacerts証明書ファイルは、java.home\lib\securityのセキュリティ プロパティ ディレクトリに存在します。ここで、java.homeはランタイム環境ディレクトリ (SDK 内の jre ディレクトリ、または Java™ 2 ランタイム環境の最上位ディレクトリ) です。
PostgreSQL を使用してクライアント証明書のピン留めシナリオ用にクライアント ルート CA 証明書を更新するには、次の手順に従います。
cacertsJava キーストアを調べて、必要な証明書が既に含まれているかどうかを確認します。 次のコマンドを使用して、Java キーストア内の証明書を一覧表示できます。keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt必要な証明書がクライアントの Java キーストアに存在しない場合は、出力を確認できるので、次の手順に進みます。
カスタム キーストアのバックアップ コピーを作成します。
証明書ファイルをダウンロードし、参照できる場所にローカルに保存します。
必要なすべてのルート CA 証明書を含む結合 CA 証明書ストアを生成します。 次の例は、PostgreSQL Java ユーザーに DefaultJavaSSLFactory を使用する方法を示しています。
keytool -importcert -alias PostgreSQLServerCACert -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt keytool -importcert -alias PostgreSQLServerCACert2 -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password -noprompt ...
Azure App Services でルート CA 証明書を更新する
Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する Azure App Services の場合、クライアント証明書を更新するための 2 つのシナリオが考えられます。 シナリオは、Azure App Services にデプロイされたアプリケーションで SSL を使用する方法によって異なります。
- Azure Database for PostgreSQL フレキシブル サーバー インスタンスで変更が行われる前に、プラットフォーム レベルで新しい証明書を App Service に追加します。 アプリケーションの App Service プラットフォームに含まれている SSL 証明書を使用している場合、何もする必要はありません。 詳細については、 Azure App Service ドキュメントの「Azure App Service での TLS/SSL 証明書の追加と管理 」を参照してください。
- SSL 証明書ファイルへのパスをコードに明示的に含める場合は、新しい証明書をダウンロードし、それを使用するようにコードを更新する必要があります。
Azure Kubernetes Service (AKS) でクライアントを使用するときにルート CA 証明書を更新する
Azure Kubernetes Services (AKS) でホストされているアプリケーションを使用して Azure Database for PostgreSQL に接続しようとしている場合は、専用の顧客のホスト環境からのアクセスに似ています。 AKS ドキュメントの詳細な手順を参照してください。
Windows 上の .NET (Npgsql) ユーザーのルート CA 証明書を更新する
Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する Windows 上の .NET (Npgsql) ユーザーの場合は、 すべての ルート CA 証明書が、信頼されたルート証明機関の下の Windows 証明書ストアに含まれていることを確認します。 Windows Update では、標準の Azure ルート CA リストが保持されます。
推奨される構成に記載されている証明書が含まれていない場合は、不足している証明書をインポートします。
証明書の検証で TLS を使用する方法
データベース サービスに PostgreSQL を使用する一部のアプリケーション フレームワークでは、インストール時に TLS が既定で有効になりません。 Azure Database for PostgreSQL インスタンスは TLS 接続を強制しますが、アプリケーションが TLS 用に構成されていない場合、アプリケーションは失敗する可能性があります。 TLS 接続を有効にする方法については、アプリケーションのドキュメントを参照してください。
PSQLを使用して接続する
次の例は、 PSQL コマンド ライン インターフェイスを使用してサーバーに接続する方法を示しています。 TLS 証明書の検証を適用するには、 sslmode=verify-full または sslmode=verify-ca 接続文字列の設定を使用します。 ローカル証明書ファイルのパスを sslrootcert パラメーターに渡します。
psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"
TLS 接続をテストする
クライアント アプリケーションから TLS 対応サーバーにアクセスする前に、 PSQL経由でアクセスできることを確認してください。 TLS 接続を確立した場合は、次の例のような出力が表示されます。
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()関数を呼び出して、TLS が使用されているかどうかを判断することもできます。 接続で TLS が使用されている場合、この関数は t を返します。 それ以外の場合は、fを返します。
Java キー ストアの信頼できる証明書の一覧をプログラムで取得する
既定では、信頼された証明書は、クライアントの Java インストール フォルダー内にある cacerts という名前の特別なファイルに格納されます。
次の例では、 cacerts を読み取り、 KeyStore オブジェクトに読み込みます。
private KeyStore loadKeyStore() {
String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
String filename = System.getProperty("java.home") + relativeCacertsPath;
FileInputStream is = new FileInputStream(filename);
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
String password = "changeit";
keystore.load(is, password.toCharArray());
return keystore;
}
cacertsの既定のパスワードはchangeitですが、実際のクライアントでは異なる必要があります。 管理者は、Java のインストール直後にパスワードを変更することをお勧めします。
KeyStore オブジェクトを読み込むと、PKIXParameters クラスを使用して、存在する証明書を読み取ることができます。
public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
KeyStore keyStore = loadKeyStore();
PKIXParameters params = new PKIXParameters(keyStore);
Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
List<Certificate> certificates = trustAnchors.stream()
.map(TrustAnchor::getTrustedCert)
.collect(Collectors.toList());
assertFalse(certificates.isEmpty());
}