転送データの暗号化

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップの暗号化転送について説明します。

CIO レベルの概要

  • GDC では、転送中のデータの信頼性、整合性、機密性を確保するために、さまざまなセキュリティ対策を採用しています。
  • 確立される接続に応じて、GDC コンポーネントの転送中のデータにはデフォルトの保護が適用されます。たとえば、ユーザーと GDC Cloud Service Mesh Ingress ゲートウェイ間の通信は TLS を使用して保護されます。

はじめに

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

Google のセキュリティ戦略の中心にあるのは、保存データと転送中のデータ両方の認証、整合性、暗号化です。このドキュメントでは、Google Distributed Cloud air-gapped（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 マネージド サービスは、モジュール式のプライベート クラウド サービスです。これらのサービスには、コンピューティング、ストレージ、ML が含まれます。たとえば、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 上り（内向き）ゲートウェイでホストされます。ただし、一部のサービスは GDC が管理するレイヤ 4 ロードバランサで直接ホストされます。たとえば、DBS データベースは GDC 外部ロードバランサでホストされます。これらのサービスは、TLS を使用してアプリケーション レイヤで接続を認証して暗号化するように構成されています。図 1 にこのインタラクションを示します（接続 B）。

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

顧客ネットワークから GDC でホストされている顧客アプリケーションにトラフィックをルーティングする方法はいくつかあります。トラフィックのルーティング方法は、構成によって異なります。

お客様の API Gateway を介してお客様のアプリケーションを公開する

GDC は、顧客 API ゲートウェイを介した顧客アプリケーションの公開をサポートしています。お客様の 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 上り（内向き）ゲートウェイに送信したデータは、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 を分岐して 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 を証明する必要があります。この 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 Gateway から Istio Sidecar アプリケーション フロントエンドへの 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 からサービスへの RPC 呼び出し、および 1 つの GDC サービスから別の GDC サービスへの RPC 呼び出しの認証、整合性、暗号化に mTLS または TLS を使用します。GDC で実行される各サービスは、暗号認証情報の関連付けられたサービス アカウント ID として実行されます。Cloud Service Mesh を介して mTLS で通信する場合、GDC サービスはクライアント証明書を使用して他のサービスに対して認証を行います。Cloud Service Mesh は、内部認証局を使用してこれらの証明書を検証します。TLS 経由で通信する場合（GDC Kubernetes API サーバーなど）、GDC サービスは Kubernetes サービス アカウント トークンを使用してサービスに対する認証を行います。Kubernetes サービス アカウント トークンは、Kubernetes API サーバー トークン発行者の公開鍵を使用して検証されます。