このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ暗号化転送について詳しく説明します。
CIO レベルの概要
- GDC では転送中のデータの信頼性、整合性、機密性を確保するために、さまざまなセキュリティ対策を採用しています。
- 確立される接続に応じて、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 によって認証されます。
- 整合性: ユーザーが送信したデータが変更されることなく宛先に到着すること、つまり不正な変更から保護されていることを確認します。
- 暗号化: 転送中のデータを判読不能にして機密性を維持します。暗号化とは、読み取り可能なデータ（平文）を読み取り不能（暗号テキスト）にするプロセスであり、その目的は平文へのアクセスをデータの所有者が許可したユーザーのみに限定することです。暗号化プロセスで使用されるアルゴリズムは公開されていますが、暗号テキストの復号に必要な鍵は非公開です。転送データの暗号化では、楕円曲線ベースのディフィーヘルマンなどの非対称鍵交換を使用して、データ暗号化に使用される共有対称鍵を確立することがよくあります。暗号化の詳細については、最新の暗号の概要をご覧ください。
暗号化は、複数の状態のデータを保護するために使用できます。
- 保存データの暗号化: 保存中のデータを暗号化することで、システム侵害やデータ漏洩からデータを保護します。保存データの暗号化には、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 ゲートウェイでホストされているマネージド サービスの場合、Cloud Service Mesh Ingress ゲートウェイを使用して、お客様のネットワークからのリクエストを受け入れます。Cloud Service Mesh Ingress Gateway は、受信 HTTP(S) のトラフィックをプロキシし、GDC マネージド サービス自体にトラフィックをルーティングしてロード バランシングします。別のファイアウォール レイヤは、侵入検知と侵入防止による DDoS 攻撃対策を提供します。この接続は、Cloud Service Mesh Ingress Gateway から GDC マネージド サービスのフロントエンドに対して認証され、暗号化されます。図 1 に、このインタラクションを接続 A として示します。
ほとんどの GDC API とマネージド サービスは、Cloud Service Mesh Ingress ゲートウェイでホストされています。ただし、一部のサービスは、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 ゲートウェイへの暗号化
現在、多くのシステムが HTTPS を使用してインターネット経由で通信しています。HTTPS は TLS 接続を使用してセキュリティを実現し、リクエストとレスポンスの信頼性、整合性、機密性を確保しています。HTTPS リクエストを受け入れるには、受信者が公開鍵/秘密鍵のペアと、サーバー認証用の認証局（CA）からの X.509 証明書を持っていなければなりません。鍵ペアと証明書は、受信者がリクエストの対象となるドメイン名を所有していることを証明することで、アプリケーション レイヤ（レイヤ 7）でユーザーのリクエストを認証するのに役立ちます。以下のサブセクションでは、TLS、BoringSSL、GDC 構成可能な認証局といった、ユーザーから Cloud Service Mesh Ingress ゲートウェイへの暗号化の要素について説明します。
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 ゲートウェイは、FIPS で承認されたアルゴリズムのみを適用して、セキュリティを強化します。
BoringSSL
BoringSSL は Google が維持管理する TLS プロトコルのオープンソース実装であり、OpenSSL から分岐したもので、OpenSSL とほぼインターフェース互換性があります。Google は OpenSSL から BoringSSL をフォークして OpenSSL を簡素化し、内部での使用と、Chromium および Android オープンソース プロジェクトのサポートを強化しました。BoringSSL のコアである BoringCrypto は、FIPS 140-2 レベル 1 の認定を受けています。
Cloud Service Mesh Ingress ゲートウェイの 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 ゲートウェイに実装され、BoringSSL 暗号ライブラリに実装されている暗号化
GDC で構成可能な認証局
TLS の一環として、サーバーは接続リクエストを受信したときに、ユーザーに対して自身の ID を証明する必要があります。この身元確認は TLS プロトコルで行われ、サーバーが要求された ID を含む証明書を提示することで実現されます。証明書にはサーバーの DNS ホスト名と公開鍵の両方が含まれます。提示された証明書は、接続をリクエストしたユーザーが信頼する発行元の認証局（CA）によって署名されます。つまり、サーバーへの接続をリクエストするユーザーは、ルート CA を信頼すればよいだけで、サーバーがどこからでもアクセスできるようにするには、ルート CA がすべてのクライアント デバイスに認識されている必要があります。クライアントのブラウザとデバイスは、クライアントが動作している環境に基づいて、信頼する一連のルート CA で構成されます。
GDC のルート CA は、デプロイされる環境と、その環境におけるお客様の要件によって異なります。
Cloud Service Mesh Ingress ゲートウェイからアプリケーション フロントエンド
2 つのケース:
- Cloud Service Mesh Ingress ゲートウェイが TLS を終端し、Cloud Service Mesh Istio 証明書を使用して mTLS を再暗号化する
- Ingress ゲートウェイから Istio サイドカー アプリケーション フロントエンドへの mTLS
- Cloud Service Mesh Ingress ゲートウェイは TLS を終端し、構成された CA を使用して TLS を別のサーバーに再暗号化します。
ストレージ トラフィックのネットワーク暗号化
GDC ファイルおよびブロック ストレージ システムでは、ストレージを使用するアプリケーションとストレージ サービスの間でトラフィックがルーティングされます。このデータは、IPsec を使用して転送中に認証および暗号化されます。ストレージ トラフィックのクライアントサイド暗号化は近日中に利用可能になります。IPSec トランスポート モードは、ストレージにアクセスする必要があるホストへのファイル トラフィックとブロック トラフィックの間で使用されます。認証は、オンザフライで生成され、GDC に安全に保存される事前共有キーによって行われます。IPSec SA が確立されると、IPSec トンネルを使用して情報が交換されます。パケットは、IPSec SA で指定された FIPS 準拠の暗号化を使用して暗号化および復号されます。
サービス間の認証、整合性、暗号化
GDC インフラストラクチャ内のアプリケーション レイヤ（レイヤ 7）では、Cloud Service Mesh Ingress Gateway からサービスへ、および GDC サービスから別の GDC サービスへの RPC 呼び出しの認証、整合性、暗号化に mTLS または TLS を使用します。GDC で実行される各サービスは、関連付けられた暗号認証情報を持つサービス アカウント ID として実行されます。Cloud Service Mesh を介して mTLS で通信する場合、GDC サービスはクライアント証明書を使用して他のサービスを認証します。Cloud Service Mesh は、内部認証局を使用してこれらの証明書を検証します。TLS 経由で通信する場合（GDC Kubernetes API サーバーなど）、GDC サービスは Kubernetes サービス アカウント トークンを使用してサービスを認証します。Kubernetes サービス アカウント トークンは、Kubernetes API サーバー トークン発行元の公開鍵を使用して検証されます。