Confidential Computing

解決する課題

データの暗号化は「保存中（at rest）」と「転送中（in transit）」が一般的ですが、処理のためにメモリへ展開した瞬間（使用中, in use）は平文になります。Confidential Computing は、この最後の空白を CPU のハードウェアで埋めます。

• 機密データを処理する間も、メモリ上で平文にしたくない
• クラウド事業者の管理者や、同じ物理ホストに同居する他テナントからメモリの中身を覗かれたくない
• 規制業種（金融・医療・公共）で、事業者を信頼の対象から外した（事業者非信頼）構成を取りたい
• 複数組織でデータを共有して計算したいが、生データは互いに見せたくない（協調分析・クリーンルーム）

主要概念と用語

• Confidential Computing: 使用中（メモリ上）のデータを CPU のハードウェアで暗号化・隔離する技術の総称
• TEE（Trusted Execution Environment, 信頼実行環境）: コードとデータを保護された領域で実行する仕組み。Google Cloud では VM 単位の保護が中心
• Confidential VM: メモリ暗号化を有効にした VM。多くのワークロードをコード改変なしでそのまま動かせる
• メモリ暗号化: VM ごとに固有の鍵で物理メモリを暗号化。鍵は CPU 内で管理され、ハイパーバイザやホスト OS からは平文を読めない
• AMD SEV / SEV-SNP: AMD CPU のメモリ暗号化機能。SEV-SNP は改ざん防止（完全性保護）を追加した世代
• Intel TDX: Intel CPU の Trust Domain Extensions。VM 単位の TEE を提供する別系統の実装
• リモート構成証明（Remote Attestation）: 「本当に保護された TEE 上で、想定どおりのコードが動いているか」を暗号的に検証する仕組み
• Confidential GKE / Confidential Space: コンテナノードを丸ごと Confidential VM 化する構成や、複数当事者の協調計算に特化した実行環境

仕様・制限・クォータ

• 位置づけ: 既定の保存時暗号化に使用中の暗号化を上乗せする機能。基盤の暗号化を置き換えるものではない
• 対応マシン: Confidential VM は特定の CPU プラットフォーム（AMD SEV／SEV-SNP、Intel TDX 系）に対応するマシンシリーズで有効化する。利用可能なシリーズ・リージョンは公式参照
• 有効化方法: 多くは VM 作成時に Confidential を有効化するフラグを立てるだけ。アプリのコード変更は基本的に不要
• 対応サービス: 単体 VM のほか、Confidential GKE Node（ノードを Confidential VM 化）や Confidential Space（協調計算向け）などへ展開できる
• 制約: 利用できるマシンシリーズ・リージョン・一部機能（ライブマイグレーション等）に制限が伴う場合がある。世代や CPU 種別で挙動が異なるため、要件は最新の公式ドキュメントで確認する
• クォータ: 対応 VM の vCPU 数などは通常の Compute クォータの枠内で管理される。具体値は変動するため公式参照

内部の仕組み

中核は CPU によるメモリ暗号化です。VM ごとに固有の暗号鍵が CPU 内のハードウェアで生成・管理され、その VM のメモリ内容は物理メモリに書き込まれる時点で暗号化されます。鍵は CPU の外（ハイパーバイザ、ホスト OS、物理メモリのダンプ）には平文で出ません。

• ハイパーバイザやホスト管理者は VM をスケジュールし管理できますが、メモリの平文は読めない。これにより「事業者を信頼しない」前提の構成が可能になります
• SEV-SNP や TDX の世代では、メモリ暗号化に加えて**完全性保護（改ざん検知）**が加わり、悪意あるホストによるメモリ書き換えやリプレイを検知できます
• リモート構成証明では、TEE が「自分は本物のハードウェア上の保護領域で、これこれのコード・設定で起動した」という署名付きの証拠を生成します。検証側はこの証拠を確認してから、初めて鍵やデータを渡します
• 鍵は CPU・ファームウェアと結びつくため、保護領域の外へ持ち出された瞬間にデータは復元できなくなります

設計パターン / ベストプラクティス

• 既存ワークロードの底上げ: まずは機密度の高い VM を Confidential VM に置き換える。コード変更が不要なため移行コストが小さい
• GKE への展開: コンテナ基盤は Confidential GKE Node でノードごと保護し、Pod 側の改修を避ける
• 協調分析・クリーンルーム: 複数当事者がデータを持ち寄って計算する用途は Confidential Space を使い、リモート構成証明で承認されたコードにだけデータを開示する
• 鍵連携: 構成証明の検証を通った TEE にのみ Cloud KMS の鍵アクセスを許可し、「正しい環境で動くコードだけが復号できる」状態を作る
• 完全性が要件なら世代を選ぶ: 改ざん検知まで求めるなら SEV-SNP / TDX 世代を選定する

運用・監視

• VM の作成・変更や Confidential 設定の有効化は Cloud Audit Logs に記録される。設定が意図せず外れていないかを監査する
• 一部の機能（例: ライブマイグレーションや特定のマシン操作）に制約が出ることがあるため、可用性設計に織り込む
• リモート構成証明を運用に組み込む場合は、検証ロジックと許可するコード測定値（ハッシュ）の管理・更新フローを用意する
• 対応マシンシリーズやリージョンの可用性に依存するため、移行前に対象リージョンでの提供状況を確認する
• 性能影響はワークロード依存。メモリ集約的な処理では事前にベンチマークを取る

コスト

Confidential VM の有効化自体に追加料金がかかる場合があり、加えて対応マシンシリーズの通常の Compute 料金が基本コストになります。Confidential GKE や Confidential Space も土台は対応 VM の費用です。

セキュリティ

• 脅威モデルを正しく理解する: 守るのは主に「使用中メモリの機密性・完全性」と「事業者・同居テナントからの隔離」。アプリ自身のバグや認証不備までは守らない
• 既定の保存時暗号化・転送時暗号化と組み合わせて初めて全行程が保護される。Confidential 単体で十分とみなさない
• リモート構成証明を信頼の起点にし、想定どおりの TEE・コードでのみデータ・鍵を解禁する
• 完全性（改ざん検知）が要件なら SEV-SNP / TDX 世代を選び、メモリ暗号化のみの世代と混同しない
• 構成証明の検証や鍵アクセスの権限は IAM で最小権限に絞り、誰が保護環境へデータを渡せるかを統制する

関連サービス・比較

最も近い関連は Cloud KMS です。Cloud KMS が「鍵で保存中・転送中データを守る」のに対し、Confidential Computing は「ハードウェアで使用中データを守る」もので、役割が補完関係にあります。AWS で近い位置づけは Nitro Enclaves（隔離された実行環境）です。

ハンズオン / CLI例

# AMD SEV ベースの Confidential VM を作成（メモリ暗号化を有効化）
gcloud compute instances create my-confidential-vm \
  --zone asia-northeast1-b \
  --machine-type n2d-standard-2 \
  --confidential-compute \
  --maintenance-policy TERMINATE \
  --image-family ubuntu-2204-lts \
  --image-project ubuntu-os-cloud

# SEV-SNP（完全性保護つき世代）を明示して作成する例
gcloud compute instances create my-snp-vm \
  --zone asia-northeast1-b \
  --machine-type n2d-standard-2 \
  --confidential-compute-type SEV_SNP \
  --maintenance-policy TERMINATE \
  --image-family ubuntu-2204-lts \
  --image-project ubuntu-os-cloud

# Confidential 設定が有効になっているか確認
gcloud compute instances describe my-confidential-vm \
  --zone asia-northeast1-b \
  --format "value(confidentialInstanceConfig)"

# Confidential ノードを使う GKE クラスタを作成
gcloud container clusters create conf-cluster \
  --region asia-northeast1 \
  --enable-confidential-nodes \
  --machine-type n2d-standard-2