転送データの暗号化

これは 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 サービスとはみなされません1。たとえば、ユーザーが 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 による上記の接続の保護をサポートしています2。接続は 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 におけるデフォルトとオプションの保護3

このセクションの残りの部分では、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 SHA17
TLS 1.04     AES-256-CBC MD58
QUIC5     ChaCha20-Poly1305  
      3DES6  

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

Google の認証局

TLS の一環として、サーバーは接続リクエストを受信したときに、ユーザーに対して自身の ID を証明する必要があります。この ID 確認は TLS プロトコルで行われ、サーバーが要求された ID を含む証明書を提示することで成功します。証明書にはサーバーの DNS ホスト名と公開鍵の両方が含まれます。提示された証明書は、接続をリクエストしたユーザーが信頼する発行元の認証局（CA）によって署名されます9。つまり、サーバーへの接続をリクエストするユーザーは、ルート 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 週間ごとにローテーションされます。

以前サーバーに接続していたクライアントは、秘密のチケットキー10 を使用して、短縮された 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 間のすべてのトラフィックを認証します。この認証はセキュリティ トークンを介して行われ、侵害されたホストがネットワーク上のパケットを偽装するのを防止します。

認証の際、セキュリティ トークンは送信者と受信者に関する認証情報を含むトンネル ヘッダーにカプセル化されます。送信側のコントロール プレーン11 がトークンを設定し、受信側のホストがトークンを検証します。セキュリティ トークンはすべてのフローについて事前に生成されており、トークンキー（送信者の情報を含む）とホストのシークレットで構成されます。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-GCM12 が使用されています。ALTS 暗号化の詳細については、表 2 を参照してください。

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

表 2: ALTS での暗号化

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

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

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

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

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

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

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

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

次のステップ

脚注

1 パートナー ソリューションには、Cloud Launcher で提供されるソリューションと、Cloud Dataprep のようなパートナーとの共同開発によるプロダクトが含まれます。
2 この暗号化は無効にすることもできます（例: Google Cloud Storage バケットへの HTTP アクセスの場合など）。
3 レイヤ 7 で保護されていない VM - サービス間の通信も、レイヤ 3 とレイヤ 4 では保護されます。
4 Google は、TLS 1.0 を引き続き使用しているブラウザに対しては、このプロトコル バージョンをサポートしています。クレジット カード情報を処理する Google サイトでは、Payment Card Industry（PCI）コンプライアンスで TLS 1.0 の使用中止が義務付けられている 2018 年 7 月までに、TLS 1.0 のサポートを終了する予定です。
5 QUIC の詳細については、https://www.chromium.org/quic をご覧ください。
6、7、8 一部のレガシー オペレーティング システムとの後方互換性のため、Google は 3DES、SHA1、MD5 をサポートしています。
9 チェーン証明書の場合、CA は推移的に信頼されます。
10 これはセッション チケット RFC 5077 またはセッション ID RFC 5246 になります。
11 コントロール プレーンはネットワークの一部で、シグナリング トラフィックを伝送し、ルーティングを担当します。
12 以前は他のプロトコルが使用されていましたが、現在は使用が中止されました。こうした古いプロトコルを使用しているのはジョブの 1% 未満です。
13 Datagram TLS（DTLS）は傍受や改ざんを防止した通信を可能にすることで、データグラム ベースのアプリケーションのセキュリティを実現します