ロードバランサからバックエンドへの暗号化

すべての Google Cloud リージョンでの暗号化

VPC ネットワークとピアリングした VPC ネットワーク内の VM 間トラフィックはすべて暗号化されます。これには、物理的な境界内の VM 間トラフィック(クラスタ内トラフィック)も含まれます。

GFE とバックエンドの間の暗号化

次の種類のロードバランサの場合、Google Front End(GFE)と Google Cloud VPC ネットワーク内バックエンドの間のトラフィックは自動的に暗号化されます。

  • HTTP(S) ロード バランシング
  • TCP プロキシ負荷分散
  • SSL プロキシ負荷分散

安全なバックエンド プロトコルのオプション

バックエンド サービスを作成する際には、バックエンド サービス プロトコルを選択します。次のバックエンド サービス プロトコルは、バックエンドへの安全な接続性を提供します。

  • HTTP(S) 負荷分散の場合: HTTPS と HTTP/2
  • 内部 HTTP(S) 負荷分散の場合: HTTPS と HTTP/2
  • SSL プロキシ負荷分散の場合: SSL
  • Traffic Director の場合: HTTPS と HTTP/2

HTTP(S) 負荷分散または SSL プロキシ負荷分散が安全なプロトコルを使用してバックエンドに接続する場合、GFE は HTTPS または SSL クライアントになります。内部 HTTP(S) 負荷分散が安全なプロトコルを使用してバックエンドに接続する場合、Envoy プロキシは HTTPS クライアントになります。

Traffic Director を使用して構成されたクライアント側プロキシが安全なバックエンド サービス プロトコルを使用してバックエンドに接続する場合、クライアント側プロキシは SSL または HTTPS クライアントになります。

安全なバックエンド プロトコルのユースケース

次の場合は、バックエンド インスタンスとの接続にセキュアなプロトコルを使用することをおすすめします。

  • ロードバランサ(または Traffic Director)からバックエンド インスタンスへの接続で、監査可能な暗号化された接続が必要な場合。

  • ロードバランサが、Google Cloud の外部にあるバックエンド インスタンスに接続する場合(インターネット NEG 経由で)。インターネット NEG バックエンドへの通信は、公共のインターネットを通過する可能性があります。ロードバランサがインターネット NEG に接続する場合、公開 CA 署名済み証明書は検証要件を満たしている必要があります。

安全なバックエンド プロトコルの考慮事項

安全なバックエンド サービス プロトコルを使用する場合は、次の点に注意してください。

  • ロードバランサのバックエンド インスタンスまたはエンドポイントは、バックエンド サービスと同じプロトコルを使用してサービスを提供する必要があります。たとえば、バックエンド サービス プロトコルが HTTPS の場合、バックエンドは HTTPS サーバーである必要があります。

  • バックエンド サービス プロトコルが HTTP/2 の場合、バックエンドは TLS を使用する必要があります。構成手順については、バックエンド インスタンスまたはエンドポイントで実行されているソフトウェアのドキュメントをご覧ください。

  • HTTPS または SSL サーバーとして機能させるには、バックエンド インスタンスまたはエンドポイントに秘密鍵と証明書をインストールする必要があります。これらの証明書は、ロードバランサのフロントエンド SSL 証明書と一致する必要はありません。インストール手順については、バックエンド インスタンスまたはエンドポイントで実行されているソフトウェアのドキュメントをご覧ください。

  • GFE は、バックエンドへの TLS セッションを開始する際に、Server Name Indication(SNI)拡張機能を使用しません。

  • GFE が Google Cloud 内のバックエンドに接続すると、GFE はバックエンドに存在するすべての証明書を受け入れます。GFE は証明書の検証を行いません。たとえば、次のような状況では証明書は有効として扱われます。

    • 証明書が自己署名されている。
    • 証明書が不明な認証局(CA)によって署名されている。
    • 証明書の有効期限が切れているか、まだ有効になっていない。
    • CN 属性と subjectAlternativeName 属性が Host ヘッダーまたは DNS PTR レコードと一致しない。

安全なフロントエンド プロトコル

ターゲット HTTPS またはターゲット SSL プロキシを構成の一部に使用すると、Google Cloud で安全なフロントエンド プロトコルを使用できます。

HTTP(S) 負荷分散と SSL プロキシ負荷分散は Google の BoringCrypto ライブラリを使用します。FIPS 140-2 の詳細については、NIST 暗号モジュール検証プログラム証明書 #3678 をご覧ください。

内部 HTTP(S) 負荷分散は、Google の BoringSSL ライブラリを使用します。FIPS 140-2 の詳細については、Envoy のドキュメントをご覧ください。Google は、FIPS 準拠モードで内部 HTTP(S) 負荷分散のための Envoy プロキシを構築します。

Traffic Director は、FIPS 準拠モードで構築された Envoy プロキシをサポートしています。