このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ環境での転送データの暗号化について詳しく説明します。
CIO レベルの概要
- GDC では、転送中のデータの信頼性、整合性、機密性を確保するために、さまざまなセキュリティ対策を採用しています。
- 確立される接続に応じて、GDC コンポーネントの転送中のデータにはデフォルトの保護が適用されます。たとえば、ユーザーと GDC Cloud Service Mesh Ingress Gateway 間の通信は TLS を使用して保護されます。
はじめに
多くの場合、セキュリティはクラウド プロバイダを選ぶ際の重要な決定要因となります。Google では、セキュリティを最重要事項と考えています。Google はデータ保護のためのたゆまぬ努力を続けており、それはネットワーク上を流れるデータでも、Google のインフラストラクチャ内を移動するデータでも、Google のサーバーに保存されているデータでも同様です。
Google のセキュリティ戦略の中心にあるのは、保存データと転送中のデータ両方の認証、整合性、暗号化です。この論文では、Google Distributed Cloud エアギャップ（GDC）での転送中のデータの暗号化に関するアプローチを説明します。
保存中のデータについては、保存データの暗号化をご覧ください。 Google のセキュリティ全体の概要については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。
対象: このドキュメントは、GDC を現在ご利用中またはご検討中の CISO およびセキュリティ運用チームを対象としています。
前提条件: 読者はこの概要の知識に加えて、暗号化および暗号プリミティブについても基本的な理解を有していることを前提とします。
認証、整合性、暗号化
GDC では、転送中のデータの信頼性、整合性、機密性を確保するために、さまざまなセキュリティ対策を採用しています。
- 認証: ネットワーク レイヤでデータの宛先を認証します。ソースは GDC マネージド AIS によって認証されます。
- 整合性: ユーザーが送信したデータが変更されることなく宛先に到着することを確認します。つまり、不正な変更から保護されます。
- 暗号化: 転送中のデータを判読不能にして機密性を維持します。暗号化とは、読み取り可能なデータ（平文）を読み取り不能（暗号テキスト）にするプロセスであり、その目的は平文へのアクセスをデータの所有者が許可したユーザーのみに限定することです。暗号化プロセスに使用されるアルゴリズムは公開されていますが、暗号テキストを解読するために必要な鍵は未公開になっています。転送データの暗号化では多くの場合、楕円曲線ベースの Diffie-Hellman 鍵のような非対称鍵交換を使用して、データ暗号化に利用する共有対称鍵を確立します。暗号化の詳細については、最新の暗号の概要をご覧ください。
暗号化は以下の複数の状態にあるデータの保護に使用できます。
- 保存データの暗号化: 保存中のデータを暗号化することで、システム侵害やデータ漏洩からデータを保護します。保存データの暗号化には、Advanced Encryption Standard（AES）がよく利用されます。
- 転送データの暗号化: データがユーザーのサイトとクラウド プロバイダの間または 2 つのサービスの間を移動する際に傍受された場合、そのデータを保護します。この保護は、送信前のデータ暗号化、各エンドポイントの認証、到着時の復号および改ざんの有無の検証により実現されます。たとえば、転送時のセキュリティを確保するための転送中のデータの暗号化には Transport Layer Security（TLS）が、メール メッセージのセキュリティ確保には Secure/Multipurpose Internet Mail Extensions（S/MIME）がよく使用されます。
暗号化は広範なセキュリティ戦略の一部です。転送中のデータを暗号化すると、次のような理由で、接続が確立され認証された後に潜在的な攻撃者からデータを保護できます。
- 一般に第三者によって提供されている、ネットワークの下位レイヤを信頼する必要がなくなる
- 攻撃される可能性のある範囲が縮小する
- 通信が傍受された場合に、攻撃者によるデータへのアクセスが防止される
適切な認証、整合性、暗号化を利用すると、悪意ある環境においても、ユーザー、デバイス、プロセスの間を移動するデータを保護できます。以降のセクションでは、転送中のデータの暗号化に対する GDC のアプローチと、それがどこで適用されているかを説明します。
GDC ネットワーク インフラストラクチャ
物理的境界
物理的境界は Google が管理しているまたは Google が管理を委託している物理スペースの障壁であり、そこでは Google が厳格なセキュリティ対策を講じることができます。この場所への物理的なアクセスは制限され、厳重にモニタリングおよび監査されています。ハードウェアにアクセスできるのは、承認されたごく一部の担当者のみです。これらの物理的境界内で転送中のデータは、通常、認証および暗号化されます。
GDC の物理的境界の内外を通過する通信については、転送中のデータを保護するために強力な認証と暗号化を採用しています。
トラフィックのルーティング方法
GDC での転送データの暗号化の仕組みを理解するには、トラフィックが GDC にルーティングされ、GDC を通過する方法を説明する必要があります。このセクションでは、リクエストがエンドユーザーから適切な GDC サービスまたは顧客アプリケーションにどのように伝達されるか、およびクロスサイト サービス間でトラフィックがどのようにルーティングされるかを説明します。
GDC マネージド サービス は、モジュラー型のプライベート クラウド サービスです。これにはコンピューティング、ストレージ、機械学習などのサービスがあります。たとえば、GDC オブジェクト ストレージは GDC マネージド サービスです。顧客アプリケーション は GDC でホストされるアプリケーションで、GDC のお客様であるユーザーが、GDC サービスを利用して構築およびデプロイできます。GDC でホストされている顧客アプリケーションやパートナー ソリューションは、GDC マネージド サービスとはみなされません。たとえば、GDC VM、Database Service、Vertex AI を使用して構築したアプリケーションは、顧客アプリケーションになります。
図 1 は、さまざまな種類のリクエストを示しています。図 1 はさまざまなネットワーク コンポーネントと、それぞれの接続に適用されるセキュリティとのインタラクションを示しています。
図 1: サイト間接続インフラストラクチャ
エンドユーザー（顧客ネットワーク）から GDC API とマネージド サービスへの通信
Cloud Service Mesh Ingress Gateway でホストされているマネージド サービスの場合、Cloud Service Mesh Ingress Gateway を使用して顧客ネットワークからのリクエストを受け入れます。Cloud Service Mesh Ingress Gateway は、着信する HTTP(S) のトラフィックをプロキシし、GDC マネージド サービス自体へのトラフィックをルーティングおよび負荷分散します。別のファイアウォール レイヤでは、侵入検知と防止による DDoS 攻撃対策が提供されます。この接続は、Cloud Service Mesh Ingress Gateway から GDC マネージド サービスのフロントエンドに対して認証され暗号化されます。図 1 では、このインタラクションは接続 A として示されています。
ほとんどの GDC API とマネージド サービスは、Cloud Service Mesh Ingress Gateway でホストされます。ただし、一部のサービスは GDC マネージド レイヤ 4 ロードバランサで直接ホストされます。たとえば、DBS データベースは GDC 外部ロードバランサでホストされます。これらのサービスは、TLS を使用してアプリケーション レイヤで接続を認証および暗号化するように構成されています。図 1 では、このインタラクションは接続 B として示されています。
エンドユーザー（顧客ネットワーク）から GDC でホストされている顧客アプリケーションへの通信
顧客ネットワークから GDC でホストされている顧客アプリケーションにトラフィックをルーティングする方法はいくつかあります。トラフィックのルーティング方法は、構成によって異なります。
顧客 API Gateway を介して顧客アプリケーションを公開する
GDC では、顧客 API Gateway を介して顧客アプリケーションを公開できます。顧客 API Gateway サービスを使用すると、ユーザーは必要に応じて API を開発、デプロイ、保護、管理、スケーリングできます。図 1 では、このインタラクションは接続 C として示されています。
顧客の外部ロードバランサを介してコンテナ化された顧客ワークロードを公開する
GDC では、外部ロードバランサを介して顧客が管理するコンテナ化されたワークロードを公開できます。GDC では、対応する担当者に上り（内向き）と下り（外向き）のポリシーを構成する機能を提供しています。 図 1 では、このインタラクションは接続 E として示されています。
仮想マシン ワークロードを公開する
GDC では、顧客が作成した仮想マシンをエンドユーザーに公開できます。GDC では、対応する担当者に上り（内向き）と下り（外向き）のポリシーを構成する機能を提供しています。図 1 では、このインタラクションは接続 F として示されています。
GDC クロスサイト インターコネクト サービス
あるマネージド サービスから別のマネージド サービスへのルーティングは、通常、GDC の物理的境界内で完全に実行されます。クロスサイト バックアップなどの場合、データは GDC の物理的境界外にルーティングされます。その場合、データはアプリケーション レイヤ（TLS など）で暗号化され、ネットワーク レイヤでも暗号化できます。 図 1 では、このインタラクションは接続 G として示されています。
仮想マシンから仮想マシンへの通信
GDC 内の VM 間の接続は、ネットワーク レベルで暗号化されません。適切な暗号化プロトコルまたは IPSec トンネルなどの特定のテクノロジーを使用してデータを暗号化するのは、お客様の責任です。
転送データをデフォルトで暗号化
GDC では転送中のデータに対し、デフォルトとユーザー構成の両方によるさまざまな暗号化方式を使用しています。使用される暗号化のタイプは、OSI レイヤ、サービスのタイプ、およびインフラストラクチャの物理コンポーネントによって異なります。このセクションでは、Google で転送中のデータを保護するために使用されるデフォルトの保護について説明します。
このセクションの残りの部分では、Google で転送中のデータを保護するために使用されるデフォルトの保護について説明します。
ユーザーから Cloud Service Mesh Ingress Gateway への暗号化
現在では、多くのシステムがインターネット経由での通信に HTTPS を使用しています。HTTPS は TLS 接続を使用してセキュリティを実現し、リクエストとレスポンスの信頼性、整合性、機密性を確保しています。HTTPS リクエストを受け入れるには、受信者が公開鍵/秘密鍵のペアと、サーバー認証用の認証局（CA）からの X.509 証明書を持っていなければなりません。この鍵ペアと証明書は、受信者がリクエスト対象のドメイン名を所有していることを証明するもので、アプリケーション レイヤ（レイヤ 7）でユーザーのリクエストを認証するのに役立ちます。以下のサブセクションでは、TLS、BoringSSL、GDC 構成可能な認証局といった、ユーザーから Cloud Service Mesh Ingress Gateway への暗号化の要素について説明します。
Transport Layer Security（TLS）
GDC サービスにリクエストを送信すると、信頼できる認証局からの証明書を使用して HTTPS で認証、整合性、暗号化を実現することで、転送中のデータが保護されます。ユーザーが GDC マネージド サービスの Cloud Service Mesh Ingress Gateway に送信したデータは、Transport Layer Security（TLS）を利用して転送中に暗号化されます。Cloud Service Mesh Ingress Gateway はクライアントが何をサポートできるかに応じて、特定の暗号化プロトコルをクライアントとネゴシエートします。 GDC Cloud Service Mesh Ingress Gateway は、より強力なセキュリティを提供するために、FIPS 承認済みのアルゴリズムのみを適用します。
BoringSSL
BoringSSL は Google が維持管理する、 TLS プロトコルのオープンソース実装であり、OpenSSL から分岐したもので、OpenSSL とほぼインターフェース互換性があります。Google は OpenSSL から BoringSSL を分岐することで、内部使用のためおよび Chromium と Android オープンソース プロジェクトのサポートを強化するために、 OpenSSL を簡略化しました。BoringSSL のコアである BoringCrypto は、FIPS 140-2 レベル 1 の認定を受けています。
Cloud Service Mesh Ingress Gateway の TLS は BoringSSL によって実装されています。表 1 は、GDC でクライアントとの通信の際にサポートされる暗号化プロトコルを示しています。
| プロトコル | 認証 | 鍵交換 | 暗号化 | ハッシュ関数 |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256（NIST secp256r1） | AES-256-GCM | SHA256 |
表 1: GDC サービス用に Cloud Service Mesh Ingress Gateway で実装され、BoringSSL 暗号ライブラリで実装される暗号化
GDC 構成可能な認証局
TLS の一環として、サーバーは接続リクエストを受信したときに、ユーザーに対して自身の ID を証明する必要があります。この ID 確認は TLS プロトコルで行われ、サーバーが要求された ID を含む証明書を提示することで成功します。証明書にはサーバーの DNS ホスト名と公開鍵の両方が含まれます。提示された証明書は、接続をリクエストしたユーザーが信頼する発行元の認証局（CA）によって署名されます。この結果、サーバーへの接続をリクエストしたユーザーは、ルート CA を信頼するだけで済みます。サーバーが普遍的なアクセスを許可するには、ルート CA がすべてのクライアント デバイスに知られている必要があります。クライアント ブラウザとデバイスは、クライアントが動作している環境に基づいて、信頼するルート CA のセットで構成されます。
GDC のルート CA は、デプロイ先の環境と、その環境の顧客の要件によって異なります。
Cloud Service Mesh Ingress Gateway からアプリケーション フロントエンドへの通信
次の 2 つのケースがあります。
- Cloud Service Mesh Ingress Gateway が TLS を終端し、Cloud Service Mesh Istio 証明書を使用して mTLS を再暗号化する
- Ingress Gateway から Istio Sidecar アプリケーション フロントエンドへの mTLS
- Cloud Service Mesh Ingress Gateway が TLS を終端し、構成された CA を使用して TLS を別のサーバーに再暗号化する。
ストレージ トラフィックのネットワーク暗号化
GDC ファイルとブロック ストレージ システムでは、ストレージを使用するアプリケーションとストレージ サービスの間でトラフィックがルーティングされます。そのデータは、IPSec を使用して転送中に認証および暗号化されます。ストレージ トラフィックのクライアントサイド暗号化は近日提供予定です。 IPSec トランスポート モードは、ファイルとブロックのトラフィックと、ストレージにアクセスする必要があるホストの間で使用されます。認証は、実行時に生成され、GDC に安全に保存される事前共有鍵によって行われます。IPSec SA が確立されると、IPSec トンネルを使用して情報が交換されます。パケットは、IPSec SA で指定された FIPS 準拠の暗号化を使用して暗号化および復号されます。
サービス間の認証、整合性、暗号化
GDC インフラストラクチャ内のアプリケーション レイヤ（レイヤ 7）では、Cloud Service Mesh Ingress Gateway からサービスへの RPC 呼び出し、およびある GDC サービスから別の GDC サービスへの RPC 呼び出しの認証、整合性、暗号化に mTLS または TLS を使用します。 GDC で動作する各サービスは、暗号認証情報の関連付けられたサービス アカウント ID として実行されています。Cloud Service Mesh を介して mTLS で通信する場合、GDC サービスはクライアント証明書を使用して他のサービスに対する認証を行います。Cloud Service Mesh はこうした証明書を、内部認証局を使用して検証します。TLS を介して通信する場合（GDC Kubernetes API サーバーなど）、GDC サービスは Kubernetes サービス アカウント トークンを使用してサービスに対する認証を行います。Kubernetes サービス アカウント トークンは、Kubernetes API サーバー トークン発行者の公開鍵を使用して検証されます。