Google Cloud の転送中の暗号化

このコンテンツの最終更新日は 2025 年 4 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。

Google では、インターネット上を流れるデータでも、Google のインフラストラクチャ内を移動するデータでも、Google のサーバーに保存されているデータでも、セキュリティ管理によってデータを保護しています。Google のセキュリティ戦略の中心にあるのは、保存データと転送中のデータ両方の認証、整合性、暗号化です。この論文では、インターネットから転送中のデータと Google のネットワーク内で転送中のデータを暗号化するためにGoogle Cloud を設計した方法について説明します。このドキュメントは、お客様のデータセンター ネットワークと Google のデータセンター ネットワーク間の相互接続を介して転送されるデータには適用されません。

転送中の暗号化では、Transport Layer Security（TLS）、BoringSSL、Application Layer Transport Security（ALTS）、PSP セキュリティ プロトコルなど、さまざまなテクノロジーを使用してデータを保護します。Google が提供するデフォルトの保護に加えて、IPsec、マネージド TLS 証明書、Cloud Service Mesh などの暗号化オプションを追加して、データをさらに保護できます。

このドキュメントは、 Google Cloudを現在ご利用中またはご検討中の CISO およびセキュリティ運用チームを対象としています。このドキュメントは、暗号化と暗号プリミティブについて基本的な知識があることを前提としています。

認証、完全性、暗号化

Google では、転送データの信頼性、整合性、プライバシーを確保するために、次のセキュリティ対策を採用しています。

  • 認証は、接続内のピア（人間またはプロセス）の ID を検証します。
  • 完全性により、送信したデータが移行元と移行先の間の転送中に変更されるのを防ぎます。
  • 暗号化では、暗号を使用して転送中のデータを判読不能にし、機密性を維持します。

転送データの暗号化は、エンドユーザーと Google Cloud の間、または 2 つのサービスの間を移動する通信データが傍受された場合でも、そのデータのセキュリティを確保します。転送中の暗号化では、エンドポイントを認証し、送信前にデータを暗号化します。受信者は、到着時にデータを復号し、転送中にデータが変更されていないことを確認します。

暗号化は広範なセキュリティ戦略の一部です。転送中の暗号化により、潜在的な攻撃者からデータを保護し、Google、顧客、エンドユーザーがネットワークの下位レイヤを信頼する必要がなくなります。 Google Cloud

トラフィックのルーティング方法

このセクションでは、リクエストがエンドユーザーから適切なGoogle Cloud サービスまたは顧客アプリケーションにどのように伝達されるか、およびサービス間でトラフィックがどのようにルーティングされるかを説明します。

Google Cloud サービスは、Google がお客様に提供するモジュール式クラウド サービスです。これには、コンピューティング、データ ストレージ、データ分析、ML などのサービスがあります。たとえば、Cloud Storage は Google Cloud サービスです。

顧客アプリケーションは Google Cloud でホストされるアプリケーションで、Google のお客様であるユーザーが、 Google Cloudサービスを利用して構築およびデプロイできます。Google Cloud でホストされている顧客アプリケーションやパートナー ソリューションは、 Google Cloud サービスとはみなされません。たとえば、Cloud Run、Google Kubernetes Engine、または Compute Engine の VM を使用して構築したアプリケーションは、顧客アプリケーションになります。

次の図は、エンドユーザーから Google へのトラフィック パス、Google のネットワーク内のパス、各接続のセキュリティを示しています。次のトラフィック パスが表示されます。

  • インターネット上のエンドユーザーから Google Cloud サービス（図の A）への通信
  • インターネット上のエンドユーザーからGoogle Cloud でホストされている顧客アプリケーションへの通信（図では B とラベル付けされています）
  • 仮想マシンから仮想マシン（図の C）
  • 仮想マシンから Google Front End（GFE）（図では D とラベル付け）
  • GFE から Google API とサービス（図の E）
  • Google Cloud サービスと Google Cloud サービスの間の認証（図では F とラベル付けされています）

Google のトラフィック パス。

エンドユーザーと Google の間の転送中の暗号化

以降のセクションでは、前の図に示されているエンドユーザーのルーティング リクエストについて詳しく説明します。

エンドユーザーから Google Cloud サービスへ

Cloud Storage や Compute Engine などのGoogle Cloud サービスは、お客様に提供され、Google の本番環境で実行されるクラウド サービスです。Google Cloud サービスは、Google Front End（GFE）という全世界に分散したシステムを利用して、世界中からのリクエストを受信します。GFE は、着信 HTTP(S)、TCP、TLS 接続のトラフィックを終端し、DDoS 攻撃対策を提供して、Google Cloud サービス自体へのトラフィックをルーティングおよび負荷分散します。GFE の拠点は全世界にあり、パスはユニキャストまたはエニーキャストを使用してアドバタイズされます。

GFE は、エンドユーザーからGoogle Cloud サービスへのトラフィックと、エンドユーザーから Google Cloud でホストされ、Cloud Load Balancing を使用する顧客アプリケーションへのトラフィックを Google のネットワーク経由でルーティングします。

クライアントが HTTPS、HTTP/2、HTTP/3 経由でサービスに送信するリクエストは、TLS で保護されます。 Google Cloud GFE の TLS は、Google が維持管理する TLS プロトコルのオープンソース実装である BoringSSL によって実装されています。BoringSSL のコアである BoringCrypto は、FIPS 140-3 レベル 1 の認定を受けています。

GFE は、前方秘匿性のキー ネゴシエーションなど、業界標準の暗号化パラメータをクライアントとネゴシエートします。古いクライアントや能力の低いクライアントの場合、GFE はクライアントが提供する最も強力なレガシー暗号プリミティブを選択します。

エンドユーザーから Google Cloudでホストされている顧客アプリケーションへの通信

直接接続またはロードバランサを使用して、インターネットから Google Cloud でホストされている顧客アプリケーションにエンドユーザー トラフィックを転送できます。トラフィックが直接ルーティングされる場合、トラフィックはアプリケーションをホストする VM サーバーの外部 IP アドレスにルーティングされます。

外部アプリケーション ロードバランサまたは外部プロキシ ネットワーク ロードバランサで TLS を使用して、 Google Cloudで実行されているアプリケーションに接続できます。レイヤ 7 ロードバランサを使用する場合、エンドユーザーとロードバランサ間の接続は、デフォルトで TLS を使用して暗号化されます（エンドユーザーのクライアント アプリケーションが TLS をサポートしている場合）。GFE は、セルフマネージドまたは Google マネージドの TLS 証明書を使用して、エンドユーザーからの TLS 接続を終端します。証明書のカスタマイズの詳細については、SSL 証明書の概要をご覧ください。ロードバランサと顧客アプリケーションをホストする VM 間の暗号化を有効にするには、ロードバランサからバックエンドへの暗号化をご覧ください。

相互 TLS（mTLS）を構成するには、相互 TLS の概要をご覧ください。GKE と Compute Engine のワークロードでは、Cloud Service Mesh を使用して、相互認証（クライアントとサーバー）に mTLS を使用し、管理する証明書を使用して転送中の通信を暗号化できます。

Firebase Hosting と Cloud Run カスタム ドメインでは、無料の自動 TLS 証明書を検討してください。Cloud Run のカスタム ドメインを使用すると、独自の SSL 証明書を提供し、HTTP Strict Transport Security（HSTS）ヘッダーを使用することもできます。

Google ネットワーク内の転送データの暗号化

Google Cloud は、このセクションに別途記載がない限り、Google のネットワーク内で転送中の顧客データを暗号化します。

Google の AI スーパーコンピュータ内の TPU または GPU を接続する超高性能の専用相互接続は、このドキュメントで説明するネットワークとは異なります。 Google Cloudでは、これらの超高性能インターコネクトは TPU の場合は ICI、GPU の場合は NVLink です。詳細については、TPU アーキテクチャと GPU マシンタイプをご覧ください。

外部 IP アドレスを使用して VM に接続するトラフィックは、Google のネットワークから離れます。これらの接続の暗号化は、お客様が構成する必要があります。

Google Cloud 仮想ネットワークの認証と暗号化

Google Cloudの仮想ネットワークは、VM 間のトラフィックを暗号化し、完全性を保護し、認証します。

同一の VPC 内、または Google Cloudの仮想ネットワーク内にあるピアリングされた VPC ネットワーク間でのプライベート IP トラフィックの暗号化は、ネットワーク層で行われます。

通信するホストのペアはそれぞれ、ALTS によって保護されたコントロール チャネルを使用してセッションキーを確立し、認証され、完全性が保護され、暗号化された通信を行います。セッションキーはこうしたホスト間の VM 間通信を暗号化するために使用され、定期的にローテーションされます。

VPC ネットワーク内の VM 間の接続、および Google の本番環境ネットワーク内におけるピアリングした VPC ネットワークは、完全性が保護され、暗号化されます。これらの接続には、お客様の VM 間の接続と、お客様と Cloud SQL などの Google マネージド VM との間の接続が含まれます。トラフィックのルーティング方法の図に、このインタラクションを示します（接続 C）。Google は内部 IP アドレスの使用に基づいて自動暗号化を有効にするため、外部 IP アドレスを使用する VM 間の接続は自動的に暗号化されません。

Google Cloudの仮想ネットワークは、VM 間のすべてのトラフィックを認証します。この認証はセキュリティ トークンを使用して行われ、侵害されたホストがネットワーク上のパケットを偽装するのを防止します。

セキュリティ トークンは、送信者と受信者に関する認証情報を含むトンネル ヘッダーにカプセル化されます。送信側のホストのコントロール プレーンがトークンを設定し、受信側のホストがトークンを検証します。セキュリティ トークンはすべてのフローについて事前に生成されており、トークン（送信者の情報を含む）とホストのシークレットで構成されます。

Google API とサービスへの接続

トラフィックの処理は、 Google Cloud サービスがホストされている場所によって異なります。

ほとんどの Google API とサービスは GFE でホストされます。VM から GFE へのトラフィックは外部 IP アドレスを使用して Google Cloud サービスにアクセスしますが、プライベート アクセスを構成すると、外部 IP アドレスの使用を回避できます。GFE からサービスへの接続は認証され、暗号化されます。

Cloud SQL などの一部のサービスは、Google マネージド VM インスタンスでホストされています。お客様の VM が外部 IP アドレスを使用して Google マネージド VM インスタンスでホストされているサービスにアクセスする場合、トラフィックは Google の本番環境ネットワークに留まりますが、外部 IP アドレスを使用しているため自動的に暗号化されません。詳細については、Google Cloud 仮想ネットワークの認証と暗号化をご覧ください。

ユーザーが Google Cloud サービスにリクエストを送信すると、Google ではウェブ（パブリック）認証局からの証明書を確認する HTTPS を使用して認証、完全性、暗号化を行い、転送中のデータを保護します。ユーザーが GFE に送信したデータは、TLS または QUIC を利用して転送中に暗号化されます。GFE はクライアントが何をサポートできるかに応じて、特定の暗号化プロトコルをクライアントとネゴシエートします。GFE は可能な限り、最新の暗号化プロトコルをネゴシエートします。

サービス間の認証、整合性、暗号化

Google のインフラストラクチャでは、GFE から Google Cloud サービスへの接続、および Google Cloud サービスから Google Cloud サービスへの接続の認証、整合性、暗号化に ALTS が使用されます。

ALTS では、認証にサービスベースの IDが使用されます。Google の本番環境で実行されているサービスには、サービスベースの ID をアサートする認証情報が発行されます。サービスが他のサービスとの間で RPC を送受信する場合、その認証情報を使用して認証を行います。ALTS は、これらの認証情報が Google の内部 CA によって発行されたことを確認します。Google の内部 CA は、Certificate Authority Service とは無関係の独立した認証局です。

ALTS は、Google の本番環境で実行されている GFE からサービスへ、およびサービス間で Google Cloud データを伝送するトラフィックに、暗号化と暗号の完全性保護を使用します。

ALTS は、GFE と Google Cloud サービス間のトラフィックにおいて、HTTP などの他のレイヤ 7 プロトコルを RPC メカニズムでカプセル化する際にも使用されています。この保護により、アプリケーション レイヤが分離され、ネットワーク パスのセキュリティに依存する必要がなくなります。

転送データの暗号化方法

以降のセクションでは、Google が転送中のデータを暗号化するために使用するテクノロジーの一部について説明します。

PSP を使用したネットワーク暗号化

PSP は、接続ごとのセキュリティを実現し、スマート ネットワーク インターフェース カード（SmartNIC）ハードウェアに暗号化をオフロードできるトランスポート独立プロトコルです。SmartNIC が利用可能な場合は、ALTS は PSP を使用してネットワーク全体の転送中データを暗号化します。

PSP は、大規模なデータセンター トラフィックの要件を満たすように設計されています。Google インフラストラクチャでは、PSP を使用して、データセンター内およびデータセンター間のトラフィックを暗号化しています。PSP は UDP などの非 TCP プロトコルもサポートし、接続ごとに一意の暗号鍵を使用します。

Application Layer Transport Security

ALTS は、Google が開発した相互認証および暗号化システムです。ALTS は、Google の本番環境で実行されているサービス間の転送中のデータに対して、認証、機密性、完全性を提供します。ALTS は次のプロトコルで構成されています。

  • ハンドシェイク プロトコル: クライアントが、楕円曲線と量子安全鍵交換を組み合わせたものを開始します。ハンドシェイクの最後に、関連するサービスは署名付き証明書を交換して検証し、共有トラフィック キーを計算することで、相互の ID を認証します。共有トラフィック鍵の導出にサポートされているアルゴリズムには、NIST ポスト量子アルゴリズム ML-KEM（FIPS 203）があります。詳細については、ポスト量子暗号をご覧ください。

  • レコード プロトコル: サービス間のデータは、共有トラフィック鍵を使用して転送時に暗号化されます。デフォルトでは、ALTS はすべてのトラフィックに AES-128-GCM 暗号化を使用します。Google の最下位レベルのストレージ システム内で転送されるデータは AES-256 暗号化を使用し、ALTS は AES メッセージ認証を提供します。ALTS の暗号化は、BoringSSL または PSP によって提供されます。この暗号化は、FIPS 140-2 レベル 1 または FIPS 140-3 レベル 1 で検証されています。

ALTS 証明書のルート署名鍵は、Google の内部 CA に保存されます。

次のステップ