Azure Confidential Computing

解決する課題

• 保管時・転送時だけでなく、使用中（メモリ上で処理中）のデータも暗号化して守りたい
• クラウド事業者やホストの管理者・ハイパーバイザーからも、処理中の機密データを見られたくない
• 複数の組織が互いに生データを見せずに、同じ計算（共同分析・機械学習）を行いたい
• 規制の厳しい業種（金融・医療・公共）で、コードとデータが想定どおりの環境で動いている証拠を残したい

主要概念と用語

• 信頼実行環境（TEE / Trusted Execution Environment）: CPU がハードウェアで隔離・暗号化する保護領域。中で動くコードとデータは、ホスト OS・ハイパーバイザー・他のプロセスから読めない
• 使用中の暗号化（Encryption-in-use）: 保管時・転送時に加えて、メモリ上で処理している最中のデータも暗号化したまま扱う考え方。Confidential Computing の中心的な価値
• 機密 VM（Confidential VM）: VM 全体のメモリを TEE で保護する方式。既存アプリをほぼそのまま載せ替えられる。AMD SEV-SNP や Intel TDX といった CPU 機能を利用する
• アプリケーション・エンクレーブ（Application Enclave）: アプリ内の一部だけを TEE に隔離する方式。Intel SGX が代表で、保護範囲は狭いが攻撃面を最小化できる
• 信頼コンピューティングベース（TCB / Trusted Computing Base）: セキュリティを成立させるために信頼する必要があるハード・ソフトの集合。Confidential Computing は TCB を CPU とエンクレーブ内コードへ縮小する
• リモート構成証明（アテステーション）: TEE が「正しいハードで・改ざんされていないコードを」動かしている証明を、暗号署名つきで外部に提示する仕組み。Microsoft Azure Attestation（MAA）が検証役を担う
• 機密コンテナ（Confidential Containers）: AKS や Container Apps 上で、Pod やコンテナを TEE 内で動かす方式

仕様・制限・クォータ

• 対応 VM サイズが限定される: 機密 VM やエンクレーブ対応は、特定の VM シリーズ（DC / EC 系列など）でのみ提供される。利用できるリージョンも限られる
• すべての処理が高速とは限らない: メモリ暗号化やエンクレーブ出入りのオーバーヘッドがあり、ワークロードによっては性能影響が出る
• アプリ改修の有無は方式で異なる: 機密 VM は既存 OS・アプリをほぼそのまま動かせる。アプリケーション・エンクレーブ（SGX）は、保護領域を切り出すためのSDK 対応・コード改修が前提
• GPU を使う機密推論・学習は対応構成が限定的で、提供範囲・世代が随時拡大している段階
• 機密 VM のOS イメージは対応イメージを使う必要があり、ゲスト側の構成証明や暗号化ディスクと組み合わせて運用する

内部の仕組み

Confidential Computing の核心は、CPU がハードウェアレベルでメモリを暗号化・隔離する点にあります。TEE の中で動くコードとデータは、CPU 内部で復号され処理されますが、物理メモリ上では暗号化されたままです。ホスト OS・ハイパーバイザー・クラウド管理者・同居する他テナントは、たとえ物理メモリを覗いても暗号文しか得られません。

• 機密 VM では、VM のメモリ全体が CPU の鍵で暗号化され、ハイパーバイザーからメモリ内容が隔離される。鍵は CPU が管理し、ホスト側に露出しない
• エンクレーブ方式 では、アプリが指定した一部のメモリ領域だけが保護され、その外（OS を含む）からはアクセスできない
• リモート構成証明 の流れは、まず TEE が自身のハード正当性とロード済みコードの計測値（ハッシュ）を含む証拠を生成し、それを Microsoft Azure Attestation などの検証サービスが検証する。検証に通って初めて、外部の鍵管理（Key Vault / Managed HSM）から復号鍵やシークレットを解放する設計にできる
• これにより「想定どおりの環境でだけ機密データを使わせる」という制御が成立する

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

• 移行容易性を優先するなら機密 VM、攻撃面の最小化を優先するならアプリケーション・エンクレーブを選ぶ
• アテステーションを鍵解放の前提条件にする。構成証明に通った TEE にのみ、Key Vault / Managed HSM から復号鍵を渡す設計にする
• **複数組織の共同計算（クリーンルーム的な用途）**では、各社が生データを出さずに TEE 内へ持ち込み、結果だけを共有する
• 機密性が必要な処理だけを TEE に載せ、性能影響の大きい一般処理は通常環境に置いて切り分ける
• 対応リージョン・VM サイズの可用性を設計初期に確認し、リージョン制約を前提に冗長構成を組む
• イメージや測定値（コードのハッシュ）をIaC で固定し、構成証明で検証する基準値を再現可能にする

運用・監視

• アテステーションの成否を監視し、検証失敗（想定外の測定値・古いファームウェア）を異常として検知する
• 機密 VM・エンクレーブ対応 VM の稼働リージョン・SKU の可用性を運用前提として管理する
• **TCB の更新（CPU ファームウェア / マイクロコード）**に追従する。測定値が変わると構成証明の基準値も更新が要る点に注意する
• 鍵管理（Key Vault / Managed HSM）のアクセスログと構成証明イベントを突き合わせ、鍵解放の正当性を監査する
• 性能要件があるワークロードは、TEE のオーバーヘッドを実測し、通常 VM との比較でキャパシティを見積もる

コスト

機密 VM・エンクレーブ対応 VM は、同等の通常 VM に比べて単価が高めになる傾向があります。Confidential Computing 機能そのものへの上乗せというより、対応する専用ハードウェア世代の VM 価格として現れます。アテステーション（Microsoft Azure Attestation）や鍵管理（Key Vault / Managed HSM）は別途のサービス費用がかかります。機密性が必要な処理だけを TEE に載せ、それ以外を通常環境に置く切り分けが、コスト最適化の基本です。

セキュリティ

• 使用中のデータまで暗号化でき、保管時・転送時と合わせて「データのライフサイクル全体」を保護できる
• クラウド管理者・ホスト OS・ハイパーバイザーからの隔離により、内部脅威やインフラ層の侵害に対する防御面が広がる
• TCB を CPU とエンクレーブ内コードへ縮小し、信頼すべき対象を小さくする（特にエンクレーブ方式）
• リモート構成証明で、改ざんされていない想定どおりの環境であることを暗号的に検証できる
• 鍵解放をアテステーション結果に紐づければ、不正な環境にはデータが渡らない統制を作れる

関連サービス・比較

機密データの保護という点で Azure Key Vault / Managed HSM と補完関係にあります。Key Vault は鍵そのものを安全に保管・操作し、Confidential Computing は**鍵を使ってデータを処理する瞬間（使用中）**を保護します。両者を組み合わせると、保管・転送・使用のすべての段階で機密性を担保できます。

ハンズオン / CLI例

# 利用可能なリージョンの機密 VM 対応サイズを確認（DC 系列の例）
az vm list-sizes --location japaneast --query "[?contains(name, 'DC')].name" -o table

# 機密 VM を作成（メモリ全体を TEE で保護する SecurityType を指定）
az vm create \
  --resource-group demo-rg \
  --name demo-cvm \
  --size Standard_DC2as_v5 \
  --image "Canonical:0001-com-ubuntu-confidential-vm-jammy:22_04-lts-cvm:latest" \
  --security-type ConfidentialVM \
  --os-disk-security-encryption-type VMGuestStateOnly \
  --enable-vtpm true \
  --enable-secure-boot true \
  --admin-username azureuser \
  --generate-ssh-keys