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 がお客様に提供するモジュール式クラウド サービスです。これにはコンピューティング、データ ストレージ、データ分析、機械学習などのサービスがあります。たとえば、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 経由で Google Cloud サービスに送信するリクエストは、TLS で保護されます。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では、これらの超高性能インターコネクトは ICI（TPU の場合）または NVLink（GPU の場合）になります。詳細については、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 は次のプロトコルで構成されています。

  • handshake プロトコル: クライアントが、楕円曲線と量子安全鍵交換を組み合わせたものを開始します。handshake の最後に、関係するサービスが署名付きの証明書を交換して検証し、共有トラフィック キーを計算することで、相互の 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 に保存されます。

次のステップ