Confidential Space のセキュリティの概要

このドキュメントでは、Confidential Space のセキュリティ管理と、さまざまな脅威を低減するためのシステム設計について説明します。Confidential Space は、当事者がデータの機密性と所有権を保持しながら、機密データ(規制対象データや個人情報(PII)など)をワークロードと共有できるように設計されています。Confidential Space を使用すると、ワークロードとそのデータの元の所有者にのみデータが表示されるように切り分けることができます。

Confidential Space は、ワークロード オペレーターと信頼関係を確立できない場合や、機密データを作成した元の当事者と信頼関係を構築できない場合に使用できます。たとえば、金融機関は Confidential Space を使用して相互に協力することで、不正行為の特定やマネーロンダリング活動の分析を行うことができます。Confidential Space では、顧客 ID を非公開にしながら、顧客データセット全体を分析できます。

Confidential Space システムのコンポーネント

Confidential Space は、承認済みのワークロードにのみシークレットをリリースするように設計された高信頼実行環境(TEE)を使用します。構成証明プロセスと強化された OS イメージにより、ワークロードとそれによって処理されるデータを信頼できないオペレーターから保護します。

Confidential Space システムには次の 3 つのコア コンポーネントがあります。

  • ワークロード: 強化された OS を含み、クラウドベースの TEE で実行されるコンテナ化されたイメージ。ハードウェア分離とリモート構成証明を提供する TEE として Confidential Computing を使用します。
  • 構成証明サービス: OpenID Connect(OIDC)トークン プロバイダ。このサービスを使用して、TEE の構成証明クォートを検証し、認証トークンをリリースします。認証トークンにはワークロードの識別属性が含まれています。
  • 保護されたリソース: Cloud Key Management Service 鍵や Cloud Storage バケットなどのマネージド クラウド リソース。リソースは、承認されたフェデレーション ID トークンへのアクセスを許可する許可ポリシーによって保護されています。中間のステップで Workload Identity プールを使用して、OIDC トークンを IAM で使用可能なフェデレーション ID トークンに変換します。

このシステムでは、承認されたワークロードにのみ、保護されたリソースへのアクセスを許可できます。また、Confidential Space は、構成証明の前後における検査や改ざんからワークロードを保護します。

Confidential Space システムには次の 3 つの当事者が存在します。

  • ワークロード作成者。保護されたリソースにアクセスできるアプリケーションを含むコンテナ化されたイメージを作成します。この作成者は、データや結果にアクセスできません。また、データや結果へのアクセスを制御することもできません。
  • ワークロード オペレーター。Google Cloud プロジェクトでワークロードを実行します。通常、オペレーターにはプロジェクトに対する完全な管理者権限が付与されています。オペレーターは、Compute Engine インスタンス、ディスク、ネットワーク ルールなどの Google Cloud リソースを管理できます。また、これらのリソースを操作する Google Cloud API を使用できます。オペレーターはデータや結果にアクセスできません。コードまたは実行環境に影響を及ぼすことも、変更を加えることもできません。オペレーターは、データや結果へのアクセスを制御することはできません。
  • 保護されたリソースを所有しているリソース オーナー(またはデータの共同編集者)。リソース オーナーは自身のデータにアクセスし、そのデータに対する権限を設定して、結果にアクセスできます。他のリソース オーナーのデータにアクセスしたり、そのコードを自身で変更することはできません。

Confidential Space では、ワークロード作成者、ワークロード オペレーター、リソース オーナーが分離され、当事者同士が相互に信頼されていない信頼モデルを構築できます。

次の図は、システム コンポーネントと当事者を表しています。ワークロードは、保護されたリソースとは別のプロジェクトに配置されています。

Confidential Space のシステムとコンポーネント。

安全なデータ処理の例

Confidential Space では、ユーザーのプライバシーを保護しながらデータを共有できます。次の表に 3 つのユースケースを示します。

ユースケース 実施例
関数型暗号モデル 関数型暗号モデルの例。Alice は、データセット全体を公開することなく、機密データの結果を Bob と共有したいと考えています。Alice はデータセットを暗号化し、自身のプロジェクトの Cloud KMS でデータ暗号鍵(DEK)を保護します。Alice は、ワークロードを実装するプログラムを作成し、そのバイナリを Bob と共有します。Alice は、プログラムが DEK にアクセスできるように KMS を構成します。ワークロードは Bob の Confidential Space で実行され、Alice のデータセットを復号して処理し、結果を Bob の Cloud Storage に書き込みます。
マルチパーティ計算 マルチパーティ計算の例。Alice と Bob は、入力データセットの機密性を保持しつつ、結果を相互に共有したいと考えています。関数暗号モデルの場合と同様に、Alice と Bob はそれぞれのデータセットを暗号化し、自分のプロジェクトの Cloud KMS インスタンス内で DEK を保護します。結果を確定するプログラムを共同で作成し、Confidential Space で実行します。Alice と Bob は、プログラムが DEK にアクセスできるように KMS を構成します。このプログラムは、両方のデータセットを読み取って処理し、その結果を共有の Cloud Storage バケットに書き込みます。
鍵の共有 より複雑なスキームでは、鍵共有の概念が使用されます。鍵の共有は Alice、Bob、他のオーナーに分割された秘密鍵で、各自の知っている情報によって、暗号化されたデータベースへのアクセスが許可されないようにするものです。このスキームでは、信頼が複数のオーナーに分割されています。秘密鍵は、制限付きの TEE でのみ、承認済みのワークロードによって組み立てられます。

これらの例で、暗号化されたデータセットにアクセスして、処理できるのはワークロードだけです。Confidential Space では、自身が所有していないデータに対して未監査のオペレーションは実行できません。データのオーナーがデータの使用方法とデータを処理できるワークロードを制御します。

ワークロードの整合性と機密性を保護する

ワークロードを信頼できないワークロード オペレーターから保護するため、Confidential Space には以下のセキュリティ制御が実装されています。

  • 構成証明プロセス。ワークロード イメージや TEE の変更を検出します。この制御により、構成証明前のワークロードの整合性が保護されます。
  • 強化されたベースイメージ。攻撃対象領域を縮小し、ワークロード オペレーターがランタイムにインスタンスにアクセスしたり、不正に使用することを防ぎます。この制御により、構成証明後のワークロードの整合性と機密性が保護されます。これらのセキュリティ制御の組み合わせにより、ワークロード、そのシークレット、ワークロードによって処理されるデータを保護します。

構成証明プロセス

構成証明プロセスは、Shielded VM のメジャード ブートと拡張ランタイムの測定値に基づいて行われます。このプロセスでは、仮想トラステッド プラットフォーム モジュール(vTPM)デバイスの保護された拡張専用レジスタでブート シーケンスの測定値をキャプチャします。

アーリーブート コンポーネント、読み込まれたカーネル、コンテナ イメージが測定の対象となります。また、インスタンスが Confidential VMs であることを示すフラグなどの環境プロパティも対象となります。vTPM は、構成証明サービスで信頼されている構成証明鍵を使用して、これらの測定値に署名(または引用)します。

次の図は、Confidential Space システムのコンポーネントと、各コンポーネントが構成証明プロセスに参加する方法を示しています。

構成証明プロセスのシステム コンポーネントと当事者。

構成証明プロセスは次のコンポーネントに依存します。

  • ゲスト ファームウェア: Google Cloud の信頼できる部分である不変のコンポーネント。
  • 証明済み Confidential Space イメージ: 接続されたブートディスクから読み取られる Container-Optimized OS に基づく強化されたイメージ。
  • 初期ブート コンポーネント: vTPM とやり取りしてブート コンポーネントを測定し、プラットフォーム構成レジスタ(PCR)に記録するブートローダーとカーネル。
  • ランチャー: イメージ リポジトリからワークロード バイナリをダウンロードし、コンテナとその構成を測定して PCR に記録するコンポーネント。ランチャーは、インスタンスのメタデータ サーバーから構成を読み取ります。

  • 構成証明処理コード: PCR クォートを準備し、vTPM のクォート、構成証明鍵、完全なイベントログを返すコード。

  • 構成証明サービス: クォートの検証、イベントログのリプレイ、OIDC トークンの発行を行い、ワークロード アクセス ポリシーの属性を含むトークンを返すサービス。

強化されたイメージ

Confidential Space イメージは単一目的の最小限の OS です。イメージがコンテナ ランチャーを実行し、コンテナ ランチャーが単一のコンテナを起動します。Confidential Space イメージは、Container-Optimized OS の既存のセキュリティ強化機能に基づいて構築され、次のメリットが追加されています。

  • 暗号化されたディスク パーティションと整合性の保護: Confidential Space イメージには次のパーティションが含まれます。
    • root-fs パーティションと、ランチャー バイナリを含む OEM パーティション。これらのパーティションは不変で、dm-verity によって保護されます。
    • ダウンロードされたワークロード バイナリを格納する、書き込み可能な一時パーティション。dm-crypt はこのパーティションを暗号化し、整合性を保護します。
    • RAM にマッピングされる tmp-fs パーティション。Confidential VM TEE では VM のメモリが暗号化されます。また、swap-fs システムは無効になっています。これにより、正しく構成されていないオペレーティング システムによってディスクにデータが保存されるのを防ぎます。
  • 証明済みの暗号化されたネットワーク接続: ランチャーは、TLS を使用して構成証明サービスを認証し、その通信リンクを保護します。
  • さまざまなブート測定: カーネル コマンドライン引数、root-fsdm-verity 構成、ワークロード バイナリなどを測定します。
  • リモート アクセスとクラウド固有のツールの無効化: sshd や OS Login などのツールが対象になります。

  • 状態遷移の軽減: たとえば、ランチャーは 1 つのコンテナを実行してから終了します。

脅威モデルと緩和策

このセクションでは、Confidential Space が緩和する脅威モデルと、Confidential Space によって生じる新たなリスクについて説明します。

次の攻撃はこのドキュメントの対象外です。

  • ソフトウェア サプライ チェーン攻撃。これは、ゲストの Unified Extensible Firmware Interface(UEFI)ファームウェア、Confidential Space イメージのブートローダーとカーネル、コンテナ ランタイム、ワークロードのサードパーティの依存関係が対象となります。データオーナーは、リソース オーナーが許可ポリシーでリソースを共有する前に、コンテナ イメージを確認して監査していることを前提としています。
  • VM エスケープなどの Google Cloud への攻撃。

発生する可能性のある攻撃

Confidential Space は、次の 3 つの攻撃を防ぐように設計されています。

  • 悪意のあるワークロード オペレーター: 悪意のあるワークロード オペレーターは、ディスク コンテンツの変更、ネットワーク接続の傍受、ランタイムでの TEE の不正使用を試みる可能性があります。悪意のあるオペレーターは、攻撃対象領域を拡大したり、ランタイム環境を制限する可能性があります。たとえば、悪意のあるオペレーターがシリアル コンソールを追加して、新しい攻撃経路を発生させる可能性があります。また、悪意のあるオペレーターがゲストのメモリサイズの制限、ディスク容量の変更、ファイアウォール ルールの変更など、リソースを制限する可能性もがあります。これらの制約により、I/O エラーがトリガーされ、十分にテストされていないエラーケースが発生する可能性があります。
  • 悪意のある構成証明クライアント: この攻撃者は構成証明サービスに接続して、正しく署名されたイベントログ メッセージを送信します。
  • 悪意のあるリソース オーナー: 悪意のあるリソース オーナーは、ワークロードによって使用される暗号化されたデータセットを完全に制御できます。この攻撃者は、不正な形式の入力や偏ったデータの提供、ワークロードの脆弱性の解析、プライバシー管理の回避を試みる可能性があります。

攻撃対象

次の表に、攻撃者が利用する攻撃対象領域を示します。

攻撃者 ターゲット 攻撃対象 リスク
ワークロード オペレーター TEE、ワークロード ディスク読み取り

ディスクから読み取られたすべてのものが攻撃者の制御下に置かれます。

マルチライター永続ディスクやダイナミック ディスク アタッチメントなどのサービスが悪用され、ディスク コンテンツが動的に変更される可能性があります。

ワークロード オペレーター TEE、ワークロード ディスク書き込み ディスクに書き込まれたものがすべて攻撃者に漏洩します。ディスク スナップショットインポート機能をご覧ください。
ワークロード オペレーター TEE、ワークロード メタデータ サーバー メタデータ サーバーから読み取られたインスタンス属性(起動スクリプトや環境変数など)が攻撃者の制御下に置かれます。
ワークロード オペレーター TEE、ワークロード ネットワーク イメージ リポジトリまたは構成証明サービスに対する外部ネットワーク接続が傍受される可能性があります。この攻撃は、一般公開の Cloud Router インスタンスを含むプライベート VPC を介して行われます。
構成証明クライアント 構成証明サービス イベントログと構成証明メッセージ 構成証明サービスには、暗号を多用する複雑なロジックがあり、防御を重視して技術することは困難です。
リソース オーナー ワークロード 暗号化されたデータセット

攻撃者がワークロードの入力データセットを汚染させる可能性があります。暗号化されたデータが必ずしも信頼できるデータとは限りません。

Google Cloud インフラストラクチャ

Google Cloud には、Compute Engine ハイパーバイザ、Confidential VM の vTPM、ゲスト UEFI ファームウェア、ホストされた構成証明サービスが含まれています。vTPM や OIDC 署名鍵などの機密性の高い鍵マテリアルは、安全に保護されるように設計されています。

Google のインフラストラクチャは、お客様のデータを他のお客様やユーザーのデータから論理的に分離するように設計されています。同じ物理サーバーに保存されている場合も同様です。サポート担当者とエンジニアに対する管理者権限は制限され、監査されています。また、お客様に対して透明性が維持されています。さらに、Confidential VMs のインライン メモリ暗号化によりインスタンス メモリの機密性を保護します。インライン メモリ暗号化により、直接的な検査や偶発的なメモリロギング(カーネル クラッシュログ)が無効になります。プラットフォームの保護について詳しくは、Google セキュリティの概要をご覧ください。

脅威と軽減策

整合性保護機能を備えた暗号化されたファイル システムは、ディスク攻撃のリスクを緩和するように設計されています。コードは、ディスクから読み取られた後に測定され、データがディスクから再度読み取られることはありません。シークレットがディスクやシリアル コンソールなどの外部デバイスに暗号化されずに開示されることはありません。

エンドツーエンドの認証済みチャネルを使用することで、ネットワーク攻撃のリスクを緩和できます。SSH などの外部ネットワーク アクセスはイメージで無効になっています。構成証明プロトコルは、ブート シーケンスとメタデータ サーバーから読み取られる構成を保護します。最後に、Confidential Space ワークロードでは、偏りのあるデータセットから生じるリスクを緩和するため、差分プライバシー制御を使用することが想定されています。

次の表に、脅威とその緩和策を示します。

メジャード ブート プロセスへの攻撃

次の表は、メジャード ブート プロセスに関連する潜在的な脅威と緩和策を示しています。

脅威 緩和策 緩和策の実装

攻撃者が、メジャード ブートをサポートしていない古いファームウェアで Shielded VM を起動する。

成功した場合、攻撃者は任意の測定値を再生し、リモート構成証明を回避する可能性があります。

この脅威は、Google Cloud コントロール プレーンによって緩和されます。

Confidential Space は、vTPM デバイスと最新の UEFI ファームウェアを追加します。また、Confidential Space を使用するとメジャード ブートが有効になり、その後、メジャード ブートは無効にできません。

Google Cloud インフラストラクチャ内

攻撃者が、ゲストの物理メモリにある UEFI ファームウェアを上書きし、ゲストを再起動して vTPM のレジスタをリセットして、変更されたファームウェアを実行する。

成功した場合、攻撃者は任意の測定値を再生し、リモート構成証明を回避する可能性があります。

この脅威はハイパーバイザによって緩和されます。ゲストの再起動時に、ハイパーバイザは UEFI ファームウェアのクリーンコピーをゲストメモリに読み込みます。ゲストメモリの以前の変更は破棄されます。さらに、ゲストの再起動は、vTPM をリセットする唯一のイベントとなります。 Google Cloud 内、Confidential Computing の有効化
攻撃者が未測定の構成ファイルを変更し、プログラムの実行に悪影響を及ぼす。

この脅威は構成証明プロセスによって緩和されます。すべての実行可能バイナリとそれぞれの構成ファイルは、実行前に完全に測定されます。

特に、セキュアブート変数、grub 構成、カーネル コマンドライン引数が測定されます。

セキュリティ審査により、構成証明プロセスで測定値の欠落がないことが確認されています。

Confidential Space イメージ内
攻撃者が、初期ブート コンポーネントでメモリ破損の脆弱性をトリガーし、コードを実行する。

アーリーブート コンポーネントは C 言語で記述されています。これらのコンポーネントは、信頼できないユーザーデータを処理し、メモリ破損の問題に対して脆弱な可能性があります。最近の例については、BootHole をご覧ください。

このリスクは、構成証明プロセスで緩和されます。初期ブート コンポーネントは、処理する前にユーザー制御データを測定する必要があります。BootHole 攻撃では、変更された grub.cfg を使用してコードを実行し、セキュアブートを無効にします。

ただし、Confidential Space システムでは、grub.cfg 測定値が想定の構成と一致しないため、構成証明を通過することはありません。

関連するリスクは、複雑なファイル システムのロジックが原因で発生します。Sequotaia などの過去の脆弱性から、ファイル システム ドライバが複雑なデータ構造を処理すると、メモリ破損の問題に対して脆弱になる場合があることが判明しています。

このリスクは、ブロックレベルの dm-veritydm-crypt 整合性保護を使用して、自動マウントを無効にすることで緩和されます。

Confidential Space イメージ内
攻撃者が、読み取りと実行が行われてから読み取りと測定が行われるまでに、ディスク上の初期ブートバイナリを変更する(ディスク TOCTOU)。

アーリーブート コンポーネントはベアメタル マシン向けに構築されているため、クラウドの動的環境を想定していない場合があります。ブート コンポーネントは、実行中にディスクの内容が変更されないことを前提としている場合がありますが、クラウド環境では、これは適切な前提とは言えません。

このリスクは、防御プログラミングを使用することで緩和されます。ディスクの内容は、読み取り、測定、実行パターンを使用して 1 回だけ読み取られます。

Confidential Space イメージのセキュリティ審査では、UEFI、ShimGNU GRUB などの初期ブート コンポーネントにおける TOCTOU の問題は特定されませんでした。

Confidential Space イメージ内
攻撃者が、カーネルの読み込み後に、ディスク上のデバイス ドライバとユーザーモード サービスを変更する。

この脅威は、整合性保護を使用したルート ファイル システムで緩和されます。

Confidential Space イメージの Root-fs は、dm-verity によって整合性が保護されます。構成(root-hash)はカーネル コマンド引数で渡され、構成証明サービスによって測定および証明されます。

Confidential Space イメージ内

コンテナ ランチャーへの攻撃

次の表に、ランチャーに関連する潜在的な脅威と緩和策を示します。

脅威 緩和策 緩和策の実装
攻撃者が、ランチャーまたはイメージ リポジトリのネットワーク接続を傍受する。

イメージ リポジトリへの接続は、認証済みの暗号化された TLS 接続によって保護されます。

攻撃者がイメージの URL を変更して、ワークロードのバイナリを制御する可能性があります。ただし、これらの操作は構成証明ログに反映されます。

イメージ リポジトリは、アクセスリストを使用した制御を行わないため、イメージには誰でもアクセスできることが想定されます。ワークロード コンテナ イメージにシークレットが含まれないようにする必要があります。

Confidential Space イメージ内
攻撃者が、ディスク上のワークロード イメージをダウンロードして測定した後、そのイメージを変更する。

この脅威は、暗号化され、整合性が保護される書き込み可能なパーティションによって緩和されます。

ワークロード イメージとその一時データは、ブートごとの一時的な鍵を使用して dm-crypt によって保護されます。

dm-crypt ディスク暗号化プロセスではロールバック攻撃が可能なため、攻撃者はディスク コンテンツを以前に暗号化された暗号テキストやタグに置き換えることができます。このような攻撃は、Confidential Space の設定で非常に複雑な攻撃であるとみなされます。

Confidential Space イメージ内
攻撃者が、メタデータ サーバーでランチャー構成を変更し、イメージ リポジトリの URL を制御する。 構成証明プロセスで、非認証イメージを読み込む安全でない構成が検出されます。 構成証明サービス内

構成証明サービスへの攻撃

次の表は、構成証明サービスへの潜在的な脅威と緩和策を示しています。

脅威 緩和策 緩和策の実装
攻撃者が、ランチャーまたは構成証明サービスのネットワーク接続を傍受し、シークレット トークンを読み取る。

この脅威は、暗号化された暗号化された TLS 接続を設定することで緩和されます。この接続により、トークンがパッシブな盗聴から保護されます。

攻撃者には TLS 鍵がないため、攻撃者がサービスになりすますことはできません。成功しても、攻撃者は有効な OIDC トークンを作成できません。

クライアント ID は構成証明プロトコルによって保証されているため、攻撃者は有効なクライアントになりすますことができません。

ワークロードと構成証明サービス間のネットワーク内。
攻撃者が、解析の不一致を悪用して、構成証明プロセスでの変更が検出されないようにする。

この脅威は、測定イベントログがシリアル化されて、解析と処理が行われる構成証明サービスに送信されたことが原因で発生することがあります。

解析の不一致は、サービスとランタイム OS がログのセマンティクス上で一致しない場合に発生します。

たとえば、cmdline フィールドにカンマ区切りの引数リストがある場合、a=1, b=2 c='3,d=e' のような文字列(値の部分文字列の ,d)は、カーネルとサービスで異なる方法で解析されます。

このリスクは、OS の動作を正しく反映する解析エンジンを設定することで緩和できます。特に、cmdline は文字列として処理されるため、Key-Value ペアに分割されません。

Confidential Space イメージ内
攻撃者が、すべてのサービス リソースを使用してサービス拒否(DoS)攻撃を実行し、サービスをダウンさせる。他の Confidential Space ユーザーのサービスが中断されます。

この信頼性のリスクは、必要なときにレプリケートとスケールアウトをすぐに実行できる分散型の弾力性のあるサービスを使用することで緩和されます。

コードを使用することで、悪意のあるクライアントによるリソースの大量消費を阻止できます。

ワークロード内

ワークロードへの攻撃

次の表に、ワークロードに関連する潜在的な脅威と緩和策を示します。

脅威 緩和策 緩和策の実装
攻撃者が、書き込み可能なパーティションからランタイム シークレットを読み取る。

この脅威は暗号化されたファイル システムで緩和されます。書き込み可能なファイル システムは、dm-crypt を使用してマウントします。スワップは無効化されており、メモリの内容はディスクにページングされません。

多層防御の手法として、OIDC トークンにスコープを設定し、有効期間を短くします。

Confidential Space イメージ内
攻撃者がシリアル コンソールからランタイム シークレットを読み取る。 認証情報とトークンはシリアル コンソールに出力されないため、この脅威は Confidential Space イメージを使用することで緩和されます。また、Cloud Logging も無効化されています。 Confidential Space イメージ内
攻撃者が、OSLogin パッケージを使用して承認済みの SSH 認証鍵を更新し、実行中のインスタンスに接続する。 sshd を含むデフォルトの systemd サービスがマスクされるため、この脅威は Confidential Space イメージを使用することで緩和されます。 Confidential Space イメージ内
攻撃者が、メタデータ サーバーの起動スクリプト(ゲスト エージェントによって自動的に読み込まれるスクリプト)を更新する。 ゲスト エージェント パッケージが無効になっているため、Confidential Space イメージを使用することでこの脅威は緩和されます。 Confidential Space イメージ内
攻撃者が、OS Config エージェントを使用して不正なパッケージを VM に push する。 OS Config エージェントが無効になっているため、この脅威は Confidential Space イメージを使用することで緩和されます。 Confidential Space イメージ内
攻撃者が、不正な形式および暗号化されたデータセットをワークロードに渡す。 この脅威は、ワークロード内に防御解析コードを実装することで緩和されます。 ワークロード内
攻撃者が、偏ったデータセットや汚染されたデータセットをワークロードに渡し、他の当事者からデータセットに関する情報を取得しようと試みる。 この脅威は、ワークロードに差分プライバシー管理を実装することで緩和されます。 ワークロード内

セキュリティ テスト

Confidential Space には、Google の包括的なセキュリティ審査プロセスが実施されています。このセキュリティ審査プロセスでは、次のテストと監査が行われています。

  • ネガティブ フローのエンドツーエンドの統合テスト

    これらのテストにより、コードが予期せぬ TEE 環境で実行された場合や、変更されたワークロード コンテナを起動した場合など、不正な測定に対する構成証明の失敗を検証しました。

  • メジャード ブート プロセスの手動監査

    この審査では、欠落した測定値の特定と、2 回読み取りのバグに重点を置きました。テストでは、セキュリティのベスト プラクティスを念頭に置いてコードが作成された場合と、障害発生時にコードが終了(シャットダウン)する場合を検証しました。

  • Confidential Space イメージとランチャー ロジックのビルドプロセスに対する手動監査

    この審査では、パッケージの削除と攻撃対象領域の削減に重点を置きました。

  • 構成証明サービスの手動監査

    この審査では、正しい構成証明プロトコルの実装と解析の問題の回避に重点を置きました。

  • サイバーセキュリティの専門家による暗号審査

    この審査では、構成証明プロトコル、ファイル システムの暗号化、整合性ソリューションに重点を置きました。

  • プライバシーの専門家によるプライバシー審査

    この審査では、Google が作成したワークロードにおける差分プライバシー管理に重点を置きました。

  • 継続的なファズテスト

    これらのテストでは、vTPM や構成証明サービスなどのセキュリティの重要な要素を網羅しています。

外部のペネトレーション テスト組織である NCC Group がシステムに対する侵入テストを実施しました。NCC は、安全なコンピューティング プラットフォームとして Confidential Space を認定しました。

次のステップ