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

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

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

プロキシ ロードバランサとバックエンド間の暗号化

一部のプロキシ ロードバランサ（表 1 を参照）の場合、Google は Google Cloud VPC ネットワーク内に存在するバックエンドへのトラフィックを自動的に暗号化します。これをネットワーク レベルの自動暗号化と呼びます。ネットワーク レベルの自動暗号化は、次のタイプのバックエンドとの通信にのみ適用されます。

  • インスタンス グループ
  • ゾーン NEG（GCE_VM_IP_PORT エンドポイント）

さらに、Google Cloud では、バックエンド サービスとの通信を暗号化する安全なプロトコル オプションを提供しています。

一部の Google Cloud ロードバランサでは、バックエンドに対するクライアントとして Google Front End（GFE）を使用しますが、他のロードバランサではオープンソースの Envoy プロキシを使用します。いずれの場合も、ロードバランサは、TLS 1.3 に対して RFC 8446 セクション 9.1 に記載されている暗号スイートをサポートしています。TLS 1.2 以前の場合、ロードバランサは COMPATIBLE SSL ポリシー プロファイルに関連付けられた暗号スイートをサポートします。

次の表に、バックエンドへのトラフィックを暗号化するプロキシ ロードバランサの概要を示します。

表 1. ロードバランサとバックエンド間の通信
プロキシ ロードバランサ プロキシ（クライアントからバックエンド） ネットワーク レベルの自動暗号化 バックエンド サービスのプロトコル オプション
グローバル外部アプリケーション ロードバランサ GFE（高度なルーティング機能のための Envoy ソフトウェアを使用） HTTP、HTTPS、HTTP/2
バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。
従来のアプリケーション ロードバランサ GFE HTTP、HTTPS、HTTP/2
バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。
リージョン外部アプリケーション ロードバランサ Envoy プロキシ HTTP、HTTPS、HTTP/2
バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。
リージョン内部アプリケーション ロードバランサ Envoy プロキシ HTTP、HTTPS、HTTP/2
バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。
クロスリージョン内部アプリケーション ロードバランサ Envoy プロキシ HTTP、HTTPS、HTTP/2
バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。
グローバル外部プロキシ ネットワーク ロードバランサ GFE（高度なルーティング機能のための Envoy ソフトウェアを使用） SSL または TCP
バックエンドへの転送中に監査可能な暗号化が必要な場合は、バックエンド サービス プロトコルに SSL を選択します。
従来のプロキシ ネットワーク ロードバランサ GFE SSL または TCP
バックエンドへの転送中に監査可能な暗号化が必要な場合は、バックエンド サービス プロトコルに SSL を選択します。
リージョン外部プロキシ ネットワーク ロードバランサ Envoy プロキシ TCP
リージョン内部プロキシ ネットワーク ロードバランサ Envoy プロキシ TCP
クロスリージョン内部プロキシ ネットワーク ロードバランサ Envoy プロキシ TCP
Cloud Service Mesh クライアントサイド プロキシ HTTPS と HTTP/2

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

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

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

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

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

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

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

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

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

  • インターネット NEG バックエンド対応の HTTPS ロードバランサを除き、ロードバランサはバックエンドへの接続に Server Name Indication（SNI）拡張機能を使用しません。

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

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

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

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

外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサは、Google の BoringCrypto ライブラリを使用します。FIPS 140-2 の詳細については、NIST 暗号モジュール検証プログラム証明書 #3678 をご覧ください。

内部ロードバランサは Google の BoringSSL ライブラリを使用します。FIPS 140-2 の詳細については、Envoy のドキュメントをご覧ください。Google は、FIPS 準拠モードで内部アプリケーション ロードバランサ用に Envoy プロキシを構築します。

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