TLS セキュリティを使用してクライアントをデータベースに接続する

概要

クライアント アプリケーションとデータベース サーバー間の接続は、業界標準のトランスポート層セキュリティ (TLS) (以前は Secure Sockets Layer (SSL) と呼ばれる) を使用して常に暗号化されます。

Azure Database for PostgreSQL では、TLS 1.2 と 1.3 を使用した暗号化接続がサポートされています。 TLS 1.0 と TLS 1.1 を使用してトラフィックを暗号化しようとするすべての受信接続は拒否されます。

既定では、クライアントとサーバーの間にセキュリティで保護された接続が適用されます。 TLS の適用を無効にして、暗号化されたクライアント通信と暗号化されていないクライアント通信の両方を許可する場合は、サーバー パラメーター require_secure_transport を OFF に変更できます。 ssl_max_protocol_version サーバー パラメーターを設定して、TLS バージョンを設定することもできます。 TLS を 無効にすることを強くお勧めします 。

クライアント TLS の構成

既定では、PostgreSQL はサーバー証明書の検証を実行しません。 このため、クライアントが知らなくても、サーバー ID のスプーフィング (DNS レコードの変更やサーバー IP アドレスの引き継ぎなど) が可能です。 このようなスプーフィングを防ぐには、クライアントで TLS 証明書の検証を使用する必要があります。

TLS 用にクライアントを構成するための接続パラメーターは多数あります。 いくつかの重要な要素は次のとおりです。

• ssl: TLS を使用して接続します。 このプロパティには、それに関連付けられた値は必要ありません。 それが存在しているだけで、TLS 接続であることを示します。 将来のバージョンとの互換性を確保するために、 true 値をお勧めします。 このモードでは、TLS 接続を確立するときに、クライアント ドライバーがサーバーの ID を検証して中間者攻撃を防ぎます。

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

  sslmode	Explanation
  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/ されます。

信頼されたルート証明機関 (CA) をインストールする

ルート CA 証明書をダウンロードして変換する

信頼されたルート証明書にシステム証明書ストアを使用する Windows クライアントの場合、Windows は Windows Update を介して新しいルート CA 証明書を展開するため、アクションは必要ありません。

Java クライアント、VS Code 拡張機能、およびその他のクライアント ( PSQL、Perl、...など) がシステム ストアを使用していない場合、および Linux 上のクライアントの場合は、ルート CA 証明書をダウンロードして PEM ファイルに結合する必要があります。 少なくとも、次のルート CA 証明書が含まれます。

• Microsoft RSA Root CA 2017 (crt ファイル)
• DigiCert グローバル ルート G2 (pem ファイル)

Azure Database for PostgreSQL で使用されるルート CA に変更がある場合は、結合されたファイルに対する今後の更新の必要性を減らすために、すべての Azure ルート 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 証明書を更新するには、次の手順に従います。

1. java キーストア cacerts 確認して、必要な証明書が既に含まれているかどうかを確認します。 次のコマンドを使用して、Java キーストア内の証明書を一覧表示できます。

   keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt
   

   出力で確認できるように、必要な証明書がクライアントの Java キー ストアに存在しない場合は、次の手順に進む必要があります。

2. カスタム キーストアのバックアップ コピーを作成します。

3. 証明書ファイルをダウンロードし、参照できる場所にローカルに保存します。

4. 必要なすべてのルート 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 App Services の場合、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する場合、クライアント証明書の更新に関して 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 証明書を更新する

Windows 上の .NET (Npgsql) ユーザーの場合、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する場合は、 すべての ルート 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());
}

関連コンテンツ

• クライアント構成を検証し、接続エラーのトラブルシューティングを行う
• PostgreSQL のドキュメント。