転送データの暗号化

これは Google が暗号化によってどのようにデータを保護しているかに関する 3 番目のホワイトペーパーです。このホワイトペーパーでは、Google Cloud と Google Workspace での転送データの暗号化について詳しく説明します。

Google ではすべての Google プロダクトで、顧客データを高度に保護するとともに、セキュリティ保護の方式についても可能な限り透明性を確保するよう努めています。

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

CIO レベルの概要

Google では転送データの信頼性、整合性、プライバシーを確保するために、さまざまなセキュリティ対策を採用しています。
このホワイトペーパーで説明するユースケースでは、Google または Google の代理者が管理していない物理的境界の外側を転送中のデータが移動する場合、Google は 1 つ以上のネットワークレイヤでそのデータを暗号化し、認証します。VPC ネットワークとピアリングした VPC ネットワーク内の VM 間トラフィックはすべて暗号化されます。
確立される接続に応じて、転送中のデータにはデフォルトの保護が適用されます。たとえば、ユーザーと Google Front End（GFE）間の通信は TLS を使用して保護されます。
WAN 経由でのデータの暗号化について追加要件がある Google Cloud のお客様は、データがユーザーからアプリケーション、または仮想マシンから仮想マシンへと移動する際に、追加の保護を実装できます。こうした保護には、IPSec トンネル、Gmail S/MIME、マネージド SSL 証明書、Istio などがあります。
Google は業界と積極的に協力して、誰もがどこからでも転送中のデータの暗号化を利用できるように努めています。Google には Certificate Transparency（証明書の透明性）、Chrome API、セキュアな SMTP など、転送中のデータの暗号化の利用とインターネット上でのデータセキュリティを促進する複数のオープンソースプロジェクトがあります。
Google は今後も引き続き、転送データの暗号化における業界リーダーの地位を維持していきたいと考えています。この目的のため、Google は暗号化技術の開発と改善に向けてリソースを投入しています。この分野における Google の努力は、Key Transparency やポスト量子暗号の分野における革新にも表れています。

はじめに

多くの場合、セキュリティはパブリッククラウドプロバイダを選ぶ際の重要な決定要因となります。Google では、セキュリティを最重要事項と考えています。Google はデータ保護のためのたゆまぬ努力を続けており、それはインターネット上を流れるデータでも、Google のインフラストラクチャ内を移動するデータでも、Google のサーバーに保存されているデータでも同様です。

Google のセキュリティ戦略の中心にあるのは、保存データと転送中のデータ両方の認証、整合性、暗号化です。このドキュメントでは、Google Cloud での転送中のデータの暗号化に関するアプローチを説明します。

保存データについては、Google Cloud Platform での保存データの暗号化をご覧ください。Google のセキュリティ全体の概要については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

対象: このドキュメントは、Google Cloud を現在ご利用中またはご検討中の CISO およびセキュリティ運用チームを対象としています。

前提条件: 読者はこの概要の知識に加えて、暗号化および暗号プリミティブについても基本的な理解を有していることを前提とします。

認証、整合性、暗号化

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

認証: データソース（人間またはプロセス）と宛先を検証します。
整合性: ユーザーが送信したデータが変更されることなく宛先に到着することを確認します。
暗号化: 転送中のデータを判読不能にして機密性を維持します。暗号化とは、読み取り可能なデータ（平文）を読み取り不能（暗号テキスト）にするプロセスであり、その目的は平文へのアクセスをデータの所有者が許可したユーザーのみに限定することです。暗号化プロセスに使用されるアルゴリズムは公開されていますが、暗号テキストを解読するために必要な鍵は未公開になっています。転送データの暗号化では多くの場合、楕円曲線ベースの Diffie-Hellman 鍵のような非対称鍵交換を使用して、データ暗号化に利用する共有対称鍵を確立します。暗号化の詳細については、最新の暗号の概要をご覧ください。

暗号化は以下の 3 種類の状態にあるデータの保護に使用できます。

保存データの暗号化: 保存中のデータを暗号化することで、システム侵害やデータ漏洩からデータを保護します。保存データの暗号化には、Advanced Encryption Standard（AES）がよく利用されます。
転送データの暗号化: データがユーザーのサイトとクラウドプロバイダの間または 2 つのサービスの間を移動する際に傍受された場合、そのデータを保護します。この保護は、送信前のデータ暗号化、各エンドポイントの認証、到着時のデータの復号、データが変更されていないことの検証により実現されます。たとえば、転送時のセキュリティを確保するための転送データの暗号化には Transport Layer Security（TLS）が、メールメッセージのセキュリティ確保には Secure/Multipurpose Internet Mail Extensions（S/MIME）がよく使用されます。
使用中の暗号化: 処理中にデータを暗号化することで、メモリ内のデータを侵害やデータ漏洩から保護します。詳細については、Confidential Computing をご覧ください。

暗号化は広範なセキュリティ戦略の一部です。転送中の暗号化によって次の対抗策を実現し、接続の確立と認証が行われた後の潜在的な攻撃からデータを保護します。

一般に第三者によって提供されている、ネットワークの下位レイヤを信頼する必要がなくなる
攻撃される可能性のある範囲が縮小する
通信が傍受された場合に、攻撃者によるデータへのアクセスが防止される

適切な認証、整合性、暗号化を行えば、好ましくない環境においても、ユーザー、デバイス、プロセスの間を移動するデータを保護できます。以降のセクションでは、転送中のデータの暗号化に対する Google のアプローチと、それがどこで適用されているかを説明します。

Google のネットワークインフラストラクチャ

物理的境界

物理的境界は Google が管理しているまたは Google が管理を委託している物理スペースの障壁であり、そこでは Google が厳格なセキュリティ対策を講じることができます。この場所への物理的なアクセスは制限され、厳重にモニタリングされています。ハードウェアにアクセスできるのは、Google のごく一部の社員のみです。これらの物理的境界内で転送されるデータは通常認証されますが、デフォルトでは暗号化されないことがあります。

インターネットが世界的に広がっているため、Google の WAN 内のファイバーリンクや、Google が管理しているまたは Google が管理を委託している物理的境界の外で、この同じ物理的セキュリティ制御を施行することはできません。このため Google は、物理的な信頼境界の外で自動的にさらなる保護を追加しています。こうした保護には、Google の物理的境界外のすべてのトラフィックでの転送データの暗号化が含まれます。

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

Google における転送データの暗号化の仕組みを完全に理解するには、トラフィックがインターネット内をどのようにルーティングされるかも知っておく必要があります。このセクションでは、リクエストがエンドユーザーから適切な Google Cloud サービスまたは顧客アプリケーションにどのように伝達されるか、およびサービス間でトラフィックがどのようにルーティングされるかを説明します。

Google Cloud サービスは、Google がお客様に提供するモジュール式クラウドサービスです。これにはコンピューティング、データストレージ、データ分析、ML などのサービスがあります。たとえば、Cloud Storage は Google Cloud サービスです。顧客アプリケーションは Google Cloud でホストされるアプリケーションで、Google のお客様であるユーザーが、Google Cloud サービスを利用して構築およびデプロイできます。Google Cloud でホストされている顧客アプリケーションやパートナーソリューションは、Google Cloud サービスとはみなされません¹。たとえば、ユーザーが Google App Engine、Google Kubernetes Engine、または Google Compute Engine の VM を使用して構築したアプリケーションは、顧客アプリケーションになります。

図 1 は、以下に説明する 5 種類のルーティングリクエストを示したものです。この図はさまざまなネットワークコンポーネントと、それぞれの接続に適用されるセキュリティとのインタラクションを示しています。

エンドユーザー（インターネット）から Google Cloud サービスへの通信

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

GFE は Google Cloud サービスへのトラフィックのプロキシとして機能し、ユーザーリクエストを Google のネットワークバックボーンを介して Google Cloud サービスにルーティングします。この接続は、Google が管理しているまたは Google のために管理されている物理的境界を離れるときに、GFE から Google Cloud サービスのフロントエンドまたは顧客アプリケーションに対して認証され暗号化されます。図 1 にこのインタラクションを示します（接続 A）。

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

インターネットからのトラフィックを、Google Cloud でホストしている顧客アプリケーションにルーティングする方法はいくつかあります。トラフィックのルーティング方法は、以下に説明するように、構成によって異なります。図 1 にこのインタラクションを示します（接続 B）。

外部アプリケーションロードバランサまたは外部プロキシネットワークロードバランサ（SSL プロキシを使用）を使用する場合は、ロードバランサからバックエンドへの暗号化をご覧ください。

仮想マシンから仮想マシンへの通信

VPC ネットワーク内の VM 間の接続、および Google の本番環境ネットワーク内におけるピアリングした VPC ネットワークは、認証され、暗号化されます。これには、お客様の VM 間の接続と、お客様と Cloud SQL などの Google マネージド VM との間の接続が含まれます。図 1 にこのインタラクションを示します（接続 C）。外部 IP アドレスを使用する VM 間の接続は暗号化されないことにご注意ください。

Google API とサービスへの接続

トラフィックの処理は、Google Cloud サービスのロケーションによって異なります。

ほとんどの Google API とサービスは Google Front End（GFE）にホストされます。ただし、一部のサービスは Google が管理するインスタンスにホストされます。たとえば、プライベートサービスアクセスと限定公開クラスタの GKE マスターは、Google が管理するインスタンスにホストされます。

限定公開の Google アクセスを使用すると、外部 IP アドレスを持たない VM でも、サポートされている Google API とサービス（App Engine にホストされている顧客アプリケーションなど）にアクセスできます。Google API とサービスへのアクセスの詳細については、サービスのプライベートアクセスオプションをご覧ください。
Compute Engine VM インスタンスが別の Compute Engine VM インスタンスの外部 IP アドレスに接続した場合、トラフィックは Google の本番環境ネットワークに留まりますが、外部 IP アドレスを使用しているため暗号化されません。Compute Engine VM インスタンスの外部 IP アドレスに接続する Google の本番環境ネットワーク外のシステムでは、インターネット経由でトラフィックがルーティングされます。

図 1 は外部パス（ラベルは接続 D）を示しています。この種のルーティングリクエストの一般的なケースとしては、次のものがあります。
- Compute Engine VM から Google Cloud Storage へ
- Compute Engine VM から Machine Learning API へ

VM から GFE への接続について、Google Cloud サービスはデフォルトで TLS による上記の接続の保護をサポートしています²。接続は GFE からサービスまで認証され、接続が物理的境界を離れる場合には暗号化が行われます。これらのデフォルトの保護に加えて、エンベロープ暗号化を適用できます。詳細については、データの暗号化をご覧ください。

Google Cloud サービスから Google Cloud サービスへの通信

ある本番環境サービスから別の本番環境サービスへのルーティングは、Google のネットワークバックボーン上で行われ、場合によっては Google が管理しているまたは Google が管理を委託している物理的境界の外にトラフィックをルーティングしなければならないことがあります。図 1 にこのインタラクションを示します（接続 E）。この種のトラフィックの一例は、Google Cloud Functions をトリガーする Google Cloud Storage イベントです。本番環境サービス間の接続は、物理的境界を離れる場合は暗号化され、認証は物理的境界内で行われます。

ユーザーは、ALTS による暗号化を使用して、物理的境界を超えて Google Cloud サービスにルーティングされます。

図 1: VPC ネットワークにおけるデフォルトの保護と、オーバーレイオプションによる保護

デフォルトでの転送データの暗号化

Google では転送中のデータに対し、デフォルトとユーザー構成の両方によるさまざまな暗号化方式を使用しています。使用される暗号化のタイプは、OSI レイヤ、サービスのタイプ、およびインフラストラクチャの物理コンポーネントによって異なります。下の図 2 と図 3 は、Google Cloud でレイヤ 3、4、7 のために用意されているオプションとデフォルトの保護を示しています。

レイヤ 3 と 4 の暗号化オプションには、VM へのデータトラフィックと境界間のデータトラフィックが含まれます。

図 2: Google Cloud 全体のレイヤ 3 および 4 におけるデフォルトとオプションの保護

レイヤ 7 の暗号化オプションには、VM 間で転送中のデータと Google Front End に転送中のデータに関するオプションも含まれます。

図 3: Google Cloud 全体のレイヤ 7 におけるデフォルトとオプションの保護³

このセクションの残りの部分では、Google で転送中のデータを保護するために使用されるデフォルトの保護について説明します。

ユーザーから Google Front End への通信の暗号化

現在では、多くのシステムがインターネット経由での通信に HTTPS を使用しています。HTTPS は TLS 接続を使用してセキュリティを実現し、リクエストとレスポンスの信頼性、整合性、プライバシーを確保しています。HTTPS リクエストを受け入れるには、受信者が公開鍵/秘密鍵のペアと、サーバー認証用の認証局（CA）からの X.509 証明書を持っていなければなりません。この鍵ペアと証明書は、受信者がリクエスト対象のドメイン名を所有していることを証明するもので、アプリケーションレイヤ（レイヤ 7）でユーザーのリクエストを保護するのに役立ちます。以下のサブセクションでは、TLS、BoringSSL、Google の認証局といった、ユーザーから GFE への暗号化の要素について説明します。顧客のパスがすべて GFE を経由するわけではありません。GFE は特に、ユーザーから Google Cloud サービスへのトラフィックと、ユーザーから Google Cloud 上でホストされている顧客アプリケーション（Google Cloud Load Balancing を使用）へのトラフィックに使用されます。

Transport Layer Security（TLS）

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

GFE のスケールされた TLS 暗号化は、エンドユーザーと Google との通信に適用されるだけでなく、TLS 上での API と Google 間の通信（Google Cloud を含む）も容易にします。さらに Google の TLS 暗号化は、Gmail で外部メールサーバーとメールを交換するためにも使用されています（詳細は Gmail での TLS 要件をご覧ください）。

Google は TLS の採用とその実装強化の両面で業界をリードしており、その目的を遂行するために TLS のセキュリティ機能の多くをデフォルトで有効にしています。たとえば 2011 年以降は、TLS 実装で前方秘匿性を使用しています。前方秘匿性により、接続を保護する鍵は永続化されなくなるため、1 つのメッセージを傍受して読み取った攻撃者が以前のメッセージを読み取ることはできません。

BoringSSL

BoringSSL は Google が維持管理する TLS プロトコルのオープンソース実装であり、OpenSSL から分岐したもので、OpenSSL とほぼインターフェース互換性があります。Google が OpenSSL から BoringSSL を分岐して OpenSSL を簡略化したのは、内部使用のため、そして Chromium と Android オープンソースプロジェクトのサポートを強化するためでした。BoringSSL のコアである BoringCrypto は、FIPS 140-2 レベル 1 の認定を受けています。

GFE の TLS は BoringSSL によって実装されています。表 1 は、GFE でクライアントとの通信の際にサポートされる暗号化プロトコルを示しています。

プロトコル	認証	鍵交換	暗号化	ハッシュ関数
TLS 1.3	RSA 2048	Curve25519	AES-128-GCM	SHA384
TLS 1.2	ECDSA P-256	P-256（NIST secp256r1）	AES-256-GCM	SHA256
TLS 1.1			AES-128-CBC	SHA1⁷
TLS 1.0⁴			AES-256-CBC	MD5⁸
QUIC⁵			ChaCha20-Poly1305
			3DES⁶

表 1: Google Front End で Google Cloud サービス用に実装され、BoringSSL 暗号ライブラリで実装される暗号化

Google の認証局

TLS の一環として、サーバーは接続リクエストを受信したときに、ユーザーに対して自身の ID を証明する必要があります。この ID 確認は TLS プロトコルで行われ、サーバーが要求された ID を含む証明書を提示することで成功します。証明書にはサーバーの DNS ホスト名と公開鍵の両方が含まれます。提示された証明書は、接続をリクエストしたユーザーが信頼する発行元の認証局（CA）によって署名されます⁹。つまり、サーバーへの接続をリクエストするユーザーは、ルート CA を信頼すればよいだけで、サーバーがどこからでもアクセスできるようにするには、ルート CA が世界中のクライアントデバイスに知られている必要があります。現在、ほとんどのブラウザや他の TLS クライアント実装には、「ルートストア」で信頼性のある CA として独自のルート CA のセットが構成されています。

Google ではこれまで、独自の発行元 CA を運用し、それを使用して Google ドメインの証明書に署名していました。ただし、独自のルート CA は運用していませんでした。現在 Google の CA 証明書は、DigiCert や以前 GlobalSign が運営していたルート（「GS Root R2」と「GS Root R4」）を含む、普遍的に分散した複数のルート CA によって相互署名されています。

Google は 2017 年 6 月、今後は Google 所有のルート CA を使用していくことを発表しました。長期的には、遍在的に分散したルート CA を運用し、そこで Google ドメインおよびお客様の証明書を発行することを計画しています。

ルート鍵の移行と鍵のローテーション

新しいルート CA に移行する際は、すべてのブラウザとデバイスにその証明書の信頼を埋め込む必要があり、これには長い時間がかかるため、ルート CA の鍵は頻繁には変更されません。そのため、現在 Google では独自のルート CA を運用しているものの、移行期間中は今後も引き続き複数の第三者のルート CA に依存して、独自の CA に移行するまでの間、レガシーデバイスの認証を行う予定です。

新しいルート CA キーを作成するには、キーセレモニーを行う必要があります。Google は、このセレモニーには 6 名の許可された担当者のうち最低 3 名が物理的に集まり、金庫に保管されたハードウェアキーを使用することを義務づけています。このメンバーは電磁干渉から保護された専用の部屋に集まり、エアギャップ式のハードウェアセキュリティモジュール（HSM）を使用して、一連の鍵と証明書を生成します。この専用の部屋は Google データセンター内の安全な場所にあります。プロセスを計画どおりに進めるため、物理的なセキュリティ対策、カメラ、他の人による観察などという追加的な管理も行われます。セレモニーが成功した場合、生成された証明書は発行者名、公開鍵、署名を除いて、サンプル証明書と同一になります。結果として得られたルート CA 証明書は、ブラウザおよびデバイスのルートプログラムに送信され組み込まれます。このプロセスは、鍵が 10 年以上その信頼性を維持できるよう、関連する秘密鍵のプライバシーとセキュリティが十分に理解されるように設計されています。

前述のように、CA は秘密鍵を使用して証明書に署名し、署名された証明書は、ユーザーセッションの一環として TLS handshake を開始するときに ID を証明します。サーバー証明書は中間 CA で署名されます。中間 CA の作成方法は、ルート CA の作成と同様です。中間 CA の証明書は TLS セッションの一部として配布されるため、新しい中間 CA に移行するほうが容易です。この配布方法により、CA オペレータはルート CA 鍵のマテリアルをオフライン状態に保つこともできます。

TLS セッションのセキュリティは、サーバーのキーがどれだけ安全に保護されているかによって異なります。キー侵害のリスクをさらに軽減するため、Google の TLS 証明書の有効期間は約 3 か月に制限されており、証明書は約 2 週間ごとにローテーションされます。

以前サーバーに接続していたクライアントは、秘密のチケットキー¹⁰ を使用して、短縮された TLS handshake で以前のセッションを再開できるため、このチケットは攻撃者にとって非常に貴重となります。Google ではチケットキーを少なくとも 1 日に 1 回ローテーションし、3 日ごとにすべてのプロパティでキーを期限切れにしています。セッションキーチケットのローテーションの詳細については、TLS 暗号ショートカットのセキュリティ損害の測定を参照してください。

Google Front End からアプリケーションのフロントエンドへの通信

トラフィックのルーティング方法で説明したように、ユーザーが接続する GFE が、目的のサービスとそれに関連するアプリケーションフロントエンドとは異なる物理的境界内に位置する場合があります。この場合、ユーザーのリクエストおよび他のレイヤ 7 プロトコル（HTTP など）は、TLS によって保護されるか、Application Layer Transport Security（ALTS）を使用して保護された RPC にカプセル化されます（サービス間の認証、整合性、暗号化を参照）。この RPC は認証され、暗号化されます。

Google Cloud サービスでは、RPC は ALTS で保護されます。Google Cloud でホストされている顧客アプリケーションの場合は、トラフィックが Google Front End 経由でルーティングされると（Google Cloud Load Balancer を使用している場合など）、VM へのトラフィックは次のセクションで説明する Google Cloud の仮想ネットワーク暗号化を使用して保護されます。

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

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

Google は Galois Counter Mode（GCM）の Advanced Encryption Standard（AES）を 128 ビット鍵（AES-128-GCM）とともに使用して、ネットワークレイヤの暗号化を実装しています。通信するホストのペアはそれぞれ、ALTS によって保護されたコントロールチャネルを介してセッションキーを確立し、認証され暗号化された通信を行います。セッションキーはこうしたホスト間のすべての VM 間通信を暗号化するために使用され、定期的にローテーションされます。

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

認証の際、セキュリティトークンは送信者と受信者に関する認証情報を含むトンネルヘッダーにカプセル化されます。送信側のコントロールプレーン¹¹ がトークンを設定し、受信側のホストがトークンを検証します。セキュリティトークンはすべてのフローについて事前に生成されており、トークンキー（送信者の情報を含む）とホストのシークレットで構成されます。Google が管理しているまたは Google が管理を委託している物理的境界のすべての送信元 / 受信者ペアについて、それぞれ 1 つのシークレットが存在します。

図 4 は、トークンキー、ホストシークレット、セキュリティトークンの作成方法を示しています。

セキュリティトークンのコンポーネント部分には、トークンキー、ホストシークレット、さらにそれらの依存関係を含めることができます。

図 4: セキュリティトークン

物理的境界のシークレットは 128 ビットの擬似乱数であり、ホストシークレットはそこから HMAC-SHA1 を導出することで得られます。物理的境界のシークレットは、一対の物理的境界のネットワークコントロールプレーン間のハンドシェイクによってネゴシエートされ、数時間ごとに再ネゴシエートされます。個々の VM 間認証に使用されるセキュリティトークンは、これらの情報および他の入力情報から得られる HMAC であり、特定の送信側と受信側のペアについてネゴシエートされます。

仮想マシンから Google Front End への通信の暗号化

VM から GFE へのトラフィックは外部 IP を使用して Google サービスにアクセスしますが、限定公開アクセス機能を構成すると、リクエストに Google 専用の IP アドレスを使用できます。

デフォルトでは、VM から GFE への TLS トラフィックがサポートされています。接続は他の外部接続と同じ方法で行われます。TLS の詳細については、Transport Layer Security（TLS）をご覧ください。

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

Google のインフラストラクチャ内のアプリケーションレイヤ（レイヤ 7）では、Google の Application Layer Transport Security（ALTS）を使用して、GFE からサービスへ、およびサービスからサービスへの Google RPC コールの認証、整合性、暗号化を実現しています。

ALTS ではサービスアカウントを使用して認証が行われます。Google のインフラストラクチャで稼働するサービスは、すべてサービスアカウント ID として実行され、それぞれの ID には暗号認証情報が関連付けられています。サービスが他のサービスとの間で RPC を送受信する場合、その認証情報を使用して認証を行います。ALTS はこうした認証情報を、内部認証局を使用して検証します。

Google が管理しているまたは Google が管理を委託している物理的境界内では、ALTS が「認証と整合性」モードで RPC の認証と整合性を確認します。これらの物理的境界外の WAN を経由するトラフィックについては、ALTS はインフラストラクチャ RPC トラフィックの暗号化を、「認証、整合性、プライバシー」モードで自動的に実施します。現在、Google Cloud サービスを含む Google サービスへのすべてのトラフィックには、この同じ保護が適用されています。

ALTS はまた、Google Front End からアプリケーションフロントエンドに移動するトラフィックにおいて、HTTP などの他のレイヤ 7 プロトコルをインフラストラクチャ RPC メカニズムによりカプセル化するために使用されています。この保護によってアプリケーションレイヤが隔離され、ネットワークパスのセキュリティに依存する必要がなくなります。

セキュリティインフラストラクチャサービスは、Google が管理しているまたは Google が管理を委託している物理的境界内であっても、「認証、整合性、プライバシー」モードでのみ ALTS 通信の送受信を行うように構成できます。その一例が、キーストアです。キーストアは、Google のインフラストラクチャに保存されているデータを保護するための暗号鍵を保管し、管理します。

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

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

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

PSP の詳しい使用方法については、大規模な PSP 暗号ハードウェアオフロードがオープンソースにをご覧ください。

ALTS プロトコル

ALTS には相互 TLS に似た安全な handshake プロトコルがあります。ALTS を使用して通信しようとする 2 つのサービスは、機密情報を送信する前に、この handshake プロトコルを使用して通信パラメータを認証およびネゴシエートします。このプロトコルは以下の 2 つのステップによるプロセスになります。

ステップ 1: handshake クライアントが Curve25519 を使用して、サーバーとの楕円曲線 Diffie Hellman（ECDH）handshake を開始します。クライアントとサーバーはそれぞれ、証明書の一部として認定済みの ECDH 公開パラメータを有しており、それが Diffie Hellman 鍵交換の際に使用されます。handshake の結果、クライアントとサーバーで利用可能な共通のトラフィック鍵が生成されます。証明書のピア ID はアプリケーションレイヤに配置され、認可の決定に使用されます。
ステップ 2: 暗号化の記録 ステップ 1 で得られた共通トラフィック鍵を使用して、クライアントからサーバーにデータが安全に送信されます。ALTS の暗号化は、BoringSSL とその他の暗号化ライブラリを使用して実装されます。暗号化は AES-128-GCM が最も一般的ですが、整合性は AES-GCM の GMAC によって実現されます。

次の図は、ALTS handshake の詳細を示しています。新しい実装ではプロセスヘルパーが handshake を行いますが、アプリケーションによって直接行われる場合もあります。

クライアントアプリは、handshake サービスとはプロセスヘルパーを介してやり取りし、サーバーアプリとは鍵交換を介してやり取りします。

図 5: ALTS handshake

サービス間の認証、整合性、暗号化セクションの冒頭で説明したように、ALTS はサービスアカウントを使用して認証を行い、Google のインフラストラクチャ上で稼働する各サービスは、関連する暗号認証情報を持つサービス ID として実行されています。ALTS handshake の際、プロセスヘルパーは各クライアント / サーバーのペアが通信で使用する秘密鍵とそれに対応する証明書にアクセスします。秘密鍵とそれに対応する証明書（署名付きのプロトコルバッファ）は、サービスのサービスアカウント ID に対してプロビジョニングされています。

ALTS 証明書。ALTS 証明書にはいくつかの種類があります。

マシン証明書: 特定のマシンのコアサービスに ID を提供します。これは約 6 時間ごとにローテーションされます。
ユーザー証明書: コードを開発する Google エンジニアのエンドユーザー ID を提供します。これは約 20 時間ごとにローテーションされます。
Borg ジョブ証明書: Google のインフラストラクチャ内で実行されているジョブに ID を提供します。これは約 48 時間ごとにローテーションされます。

ルート認証書署名鍵は、Google の内部認証局（CA）に保管されています。これは Google の外部 CA とは無関係の独立した認証局です。

ALTS での暗号化

ALTS の暗号化は使用するマシンに応じて、さまざまなアルゴリズムを利用して実装できます。たとえば、大半のサービスでは AES-128-GCM¹² が使用されています。ALTS 暗号化の詳細については、表 2 を参照してください。

マシン	使用されるメッセージ暗号化法
最も一般的	AES-128-GCM
Sandy Bridge 以前	AES-128-VCM	GMAC の代わりに VMAC が使用されており、こうした古いマシンでは若干効率性が改善します。

表 2: ALTS での暗号化

ほとんどの Google サービスでは、ALTS か、ALTS を使用する RPC カプセル化が使用されます。ALTS が使用されない場合は、その他の保護が適用されます。例:

一部の低レベルのマシン管理およびブートストラップサービスでは、SSH を使用します。
一部の低レベルのインフラストラクチャロギングサービスでは TLS または Datagram TLS（DTLS）を使用します¹³。
非 TCP トランスポートを使用する一部のサービスは、Google が管理しているまたは Google が管理を委託している物理的境界内にある場合、他の暗号プロトコルまたはネットワークレベルの保護を使用します。

VM と Google Cloud Platform サービスの間の通信では、ALTS ではなく TLS を使用して、Google Front End との通信が行われます。こうした通信については、仮想マシンから Google Front End への通信の暗号化で説明します。

転送データの他の暗号化オプションの構成

Google Cloud とデータセンターの間で転送するデータ、または Google Cloud でホストされているアプリケーションとユーザーデバイス間で転送されるデータに対して、保護機能を構成できます。

データセンターを Google Cloud に接続する場合は、次の点を考慮してください。

外部アプリケーションロードバランサまたは外部プロキシネットワークロードバランサで TLS を使用して、クラウドサービスに接続します。GFE は、お客様がプロビジョニングして管理している SSL 証明書を使用して、ユーザーからの TLS 接続を終端します。証明書のカスタマイズの詳細については、SSL 証明書の概要をご覧ください。
Cloud VPN を使用して IPSec トンネルを作成するか、Cloud Interconnect を使用してオンプレミスネットワークを Virtual Private Cloud ネットワークに安全に接続します。詳細については、ネットワーク接続プロダクトの選択をご覧ください。

Google Cloud で実行されているアプリケーションにユーザーデバイスを接続する場合は、次の点を考慮してください。

使用する SSL 証明書を構成することで、GFE の TLS サポートを使用します。たとえば、アプリケーションで TLS セッションを終了させることができます。
Firebase Hosting と App Engine の両方のカスタムドメインで使用できる無料の自動 SSL 証明書を検討してください。App Engine のカスタムドメインを使用すると、独自の SSL 証明書を提供し、HTTP Strict Transport Security（HSTS）ヘッダーを使用することもできます。
GKE と Compute Engine のワークロードでは、GKE Enterprise のサービスメッシュを使用して認証に mTLS を使用できます。これにより、すべての TCP 通信が転送時に暗号化されます。

Google Workspace を使用している場合は、送信メールに対して S/MIME を有効にするように Gmail を構成し、コンテンツと添付ファイルのコンプライアンスポリシーを設定します。また、受信メールと送信メールにルーティングルールを作成します。

転送データの暗号化の研究とイノベーション

Google は長年にわたり、インターネット上での転送データの暗号化の利用を促進するため、いくつかのオープンソースプロジェクトやその他の取り組みに参加してきました。

たとえば、次のようなことに取り組んできました。

Certificate Transparency（CT、証明書の透明性）は、CA が未承認の証明書や不正な証明書を発行した場合に、サイト運営者とドメイン所有者がそれを検出できるようにするために開始した取り組みです。
年次の HTTPS 透明性レポートでは、Google Cloud を含むすべてのプロパティの転送中データを 100% 暗号化するという目標の進捗状況が示されます。
量子コンピュータ攻撃から TLS 接続を保護するため、楕円曲線とポスト量子（CECPQ2）アルゴリズムの組み合わせを開発しました。

最近の取り組みの詳細については、セキュリティ研究コミュニティとの連携をご覧ください。

次のステップ

セキュリティのベストプラクティスなど、Google Cloud のセキュリティに関する一般的な情報については、Google Cloud ウェブサイトのセキュリティセクションをご覧ください。
Google Cloud のコンプライアンスとそれに関連する認証については、Google Cloud ウェブサイトのコンプライアンスをご覧ください。このセクションには Google の公開 SOC3 監査レポートも掲載されています。
転送中のデータを保護するベストプラクティスについては、エンタープライズ基盤のブループリントと Google Cloud アーキテクチャフレームワーク: セキュリティ、プライバシー、コンプライアンス、転送データの暗号化に関する規制要件を満たす方法を決めるをご覧ください。

脚注

¹ パートナーソリューションには、Cloud Launcher で提供されるソリューションと、Cloud Dataprep のようなパートナーとの共同開発によるプロダクトが含まれます。

² この暗号化は無効にすることもできます（例: Google Cloud Storage バケットへの HTTP アクセスの場合など）。

³ レイヤ 7 で保護されていない VM - サービス間の通信も、レイヤ 3 とレイヤ 4 では保護されます。

⁴ Google は、TLS 1.0 を引き続き使用しているブラウザに対しては、このプロトコルバージョンをサポートしています。クレジットカード情報を処理する Google サイトでは、Payment Card Industry（PCI）コンプライアンスで TLS 1.0 の使用中止が義務付けられている 2018 年 7 月までに、TLS 1.0 のサポートを終了する予定です。

⁵ QUIC の詳細については、https://www.chromium.org/quic をご覧ください。

^6、7、8 一部のレガシーオペレーティングシステムとの後方互換性のため、Google は 3DES、SHA1、MD5 をサポートしています。

⁹ チェーン証明書の場合、CA は推移的に信頼されます。

¹⁰ これはセッションチケット RFC 5077 またはセッション ID RFC 5246 になります。

¹¹ コントロールプレーンはネットワークの一部で、シグナリングトラフィックを伝送し、ルーティングを担当します。

¹² 以前は他のプロトコルが使用されていましたが、現在は使用が中止されました。こうした古いプロトコルを使用しているのはジョブの 1% 未満です。

¹³ Datagram TLS（DTLS）は傍受や改ざんを防止した通信を可能にすることで、データグラムベースのアプリケーションのセキュリティを実現します