すべての Trusted Cloud リージョンでの暗号化
VPC ネットワークとピアリングした VPC ネットワーク内の VM 間トラフィックはすべて暗号化されます。
プロキシ ロードバランサとバックエンド間の暗号化
一部のプロキシ ロードバランサ（表 1 を参照）の場合、Google は Trusted Cloud VPC ネットワーク内に存在するバックエンドへのトラフィックを自動的に暗号化します。これをネットワーク レベルの自動暗号化と呼びます。ネットワーク レベルの自動暗号化は、次のタイプのバックエンドとの通信にのみ適用されます。
- インスタンス グループ
- ゾーン NEG（
GCE_VM_IP_PORTエンドポイント）
さらに、 Trusted Cloud では、バックエンド サービスとの通信を暗号化する安全なプロトコル オプションを提供しています。
リージョン ロードバランサは、バックエンドへのクライアントとしてオープンソースの Envoy プロキシを使用します。ロードバランサは、TLS 1.3 に対して RFC 8446 セクション 9.1 に記載されている暗号スイートをサポートしています。TLS 1.2 以前の場合、ロードバランサは COMPATIBLE SSL ポリシー プロファイルに関連付けられた暗号スイートをサポートします。
次の表に、バックエンドへのトラフィックを暗号化するプロキシ ロードバランサの概要を示します。
| プロキシ ロードバランサ | プロキシ（クライアントからバックエンド） | ネットワーク レベルの自動暗号化 | バックエンド サービスのプロトコル オプション |
|---|---|---|---|
| リージョン外部アプリケーション ロードバランサ | Envoy プロキシ | HTTP、HTTPS、HTTP/2 バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。 |
|
| リージョン内部アプリケーション ロードバランサ | Envoy プロキシ | HTTP、HTTPS、HTTP/2 バックエンドへの転送中に監査可能な暗号化が必要な場合は、HTTPS または HTTP/2 を選択します。 |
|
| リージョン外部プロキシ ネットワーク ロードバランサ | Envoy プロキシ | TCP | |
| リージョン内部プロキシ ネットワーク ロードバランサ | Envoy プロキシ | TCP |
安全なバックエンド プロトコルのユースケース
次の場合は、バックエンド インスタンスとの接続にセキュアなプロトコルを使用することをおすすめします。
ロードバランサ（または Cloud Service Mesh）からバックエンド インスタンスへの接続で、監査可能な暗号化された接続が必要な場合。
ロードバランサが、Trusted Cloud の外部にあるバックエンド インスタンスに接続する場合（インターネット NEG 経由で）。インターネット NEG バックエンドへの通信は、公共のインターネットを通過する可能性があります。ロードバランサがインターネット NEG に接続する場合、公開 CA 署名済み証明書は検証要件を満たしている必要があります。
安全なバックエンド プロトコルの考慮事項
安全なバックエンド サービス プロトコルを使用する場合は、次の点に注意してください。
ロードバランサのバックエンド インスタンスまたはエンドポイントは、バックエンド サービスと同じプロトコルを使用してサービスを提供する必要があります。たとえば、バックエンド サービス プロトコルが HTTPS の場合、バックエンドは HTTPS サーバーである必要があります。
バックエンド サービス プロトコルが HTTP/2 の場合、バックエンドは TLS を使用する必要があります。構成手順については、バックエンド インスタンスまたはエンドポイントで実行されているソフトウェアのドキュメントをご覧ください。
HTTPS または SSL サーバーとして機能させるには、バックエンド インスタンスまたはエンドポイントに秘密鍵と証明書をインストールする必要があります。これらの証明書は、ロードバランサのフロントエンド SSL 証明書と一致する必要はありません。インストール手順については、バックエンド インスタンスまたはエンドポイントで実行されているソフトウェアのドキュメントをご覧ください。
インターネット NEG バックエンド対応の HTTPS ロードバランサを除き、ロードバランサはバックエンドへの接続に Server Name Indication（SNI）拡張機能を使用しません。
ロードバランサが Trusted Cloud内のバックエンドに接続すると、ロードバランサはバックエンドに存在するすべての証明書を受け入れます。この場合、ロードバランサは最小限の証明書検証のみを行います。
たとえば、次のような状況では証明書は有効として扱われます。
- 証明書が自己署名されている。
- 証明書が不明な認証局（CA）によって署名されている。
- 証明書の有効期限が切れているか、まだ有効になっていない。
CN属性とsubjectAlternativeName属性がHostヘッダーまたは DNS PTR レコードと一致しない。
RSA 証明書の場合、2025 年 4 月 28 日以降、ロードバランサは、X509v3 鍵使用拡張機能が存在し、デジタル署名パラメータと鍵暗号化パラメータの両方が含まれている RSA 証明書のみを受け入れます。詳細については、関連する 2025 年 1 月 24 日のリリースノートをご覧ください。
安全なフロントエンド プロトコル
ターゲット HTTPS またはターゲット SSL プロキシを構成の一部に使用すると、Trusted Cloud で安全なフロントエンド プロトコルを使用できます。
外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサは、Google の BoringCrypto ライブラリを使用します。FIPS 140-2 の詳細については、NIST 暗号モジュール検証プログラム証明書 #3678 をご覧ください。
内部ロードバランサは Google の BoringSSL ライブラリを使用します。FIPS 140-2 の詳細については、Envoy のドキュメントをご覧ください。Google は、FIPS 準拠モードで内部アプリケーション ロードバランサ用に Envoy プロキシを構築します。