azure-confidential-computing

Azure Confidential Computing

Confidential computing は、データ保護の第 3 の柱である 使用中のデータ を保護し、保存中および転送中の暗号化を補完します。Azure Confidential Computing は、ハードウェアベースの Trusted Execution Environments（TEE） を使用するため、ワークロードはホスト（Microsoft を含む）が検査できない暗号化メモリ上で実行されます。また、秘密情報を解放する前に、リモートの依拠当事者に TEE の状態を証明するため、暗号技術による アテステーション を使用します。

使用する場面

• 各当事者が互いのデータを見ずに計算する必要がある、複数当事者によるデータコラボレーション（クリーンルーム、不正対策コンソーシアム、共同分析）。
• クラウド事業者によるアクセスからの隔離が必要な、規制対象のワークロード（防衛、一部の金融・医療関連のシナリオ）。
• モデルの重みやトレーニングデータが最重要資産となる、機密性の高い AI のトレーニング／推論。
• アテステーションの証拠を伴う、ハードウェアを基盤とした暗号処理。

通常の保存データ向け CMK（azure-key-vault）、汎用的なアプリの暗号化、または Azure 以外の TEE／Intel SGX のみを使用する設計には、このスキルを使用しないでください。

形態

形態	ハードウェア	最適な用途
Confidential VMs（DCasv5/ECasv5）	AMD SEV-SNP	VM 全体を TEE とする、Linux／Windows ワークロードのリフトアンドシフト
Confidential VMs（DCesv5/ECesv5）	Intel TDX	VM のトラストドメインの分離
AKS 上の Confidential containers	Kata Containers + AMD SEV-SNP	コンテナのワークロード、Pod ごとの TEE
Confidential GPU VMs（NCC H100 v5）	NVIDIA H100 + Intel TDX	機密性の高い AI のトレーニング／推論
App-enclave（Intel SGX、DCsv2/3）	Intel SGX	特定用途のエンクレーブ。従来型のパターンで、新規構築ではあまり一般的ではありません
Azure Confidential Ledger	ハードウェアで保護された追記専用の台帳	改ざんを検知できる監査ログ

アプローチ

1. 脅威モデルを検証します。 機密コンピューティングで保護できるのは、次の脅威です。

   • クラウド事業者（ホスト管理者）によるメモリの検査。
   • 同一ホスト上のテナントによるサイドチャネルからの読み取り（ハードウェアによる緩和の範囲内）。
   • メモリダンプと組み合わせたスナップショット／ディスクイメージの持ち出し。 アプリケーションのバグ、自社コードのサプライチェーン侵害、顧客側の内部関係者によるアクセスは保護されません。

2. 適切な形態を選びます。

   • 既存の VM ワークロードを、コードを変更せずに機密データを扱う用途へ移行する場合 → Confidential VM (SEV-SNP) が最も簡単です。
   • 機密レベルが混在する K8s クラスターの場合 → AKS 上の Confidential containers を使い、TEE が必要な Pod の範囲を限定します。
   • 機密 GPU（機密データを使った LLM のトレーニング／推論）の場合 → NCC H100 v5。
   • 秘密プロトコルを使ったマルチパーティ計算の場合 → SGX 対応のコードを使用します（VM 全体よりも細かい TEE が必要な場合に限ります）。

3. Microsoft Azure Attestation をセットアップします。 MAA サービスは、TEE の状態（CPU モデル、ファームウェアのバージョン、セキュリティ バージョン）を記述した署名付きのアテステーショントークンを発行します。 依拠当事者（アプリ、Key Vault）は、ワークロードを信頼する前にこれらのトークンを検証します。

4. 安全なキーリリース（SKR）を構成します。 Azure Key Vault Premium／Managed HSM は、検証済みの MAA トークンを 条件とするキーリリースポリシーに対応しています。ワークフローは次のとおりです。

   1. 機密ワークロードが MAA にアテステーションを要求します。
   2. ワークロードがトークンを Key Vault に提示します。
   3. Key Vault が、構成済みのポリシー（許可された TEE の種類、ファームウェアのバージョン、所有者の ID）に照らしてトークンを検証します。
   4. TEE のメモリにキーがリリースされます。 これが「Microsoft でさえこのキーを読み取れず、適切なハードウェア上で実行されている適切なワークロードだけが使用できる」という仕組みの基盤です。

5. AKS 上の Confidential containers — Confidential Container アドオンを使用します。 アテステーションに対応する init コンテナーで Pod のセキュリティを構成し、Pod のアテステーション後に SKR を通じて機密シークレットを取得します。

6. 機密 AI のパターン。 よく使われる形態は次の 2 つです。

   • 機密推論：モデルの重みはディスク上で暗号化したまま保持し、TEE メモリに読み込みます。クライアントのトラフィックは TEE 内で終端します。独自モデルに使用します。
   • 機密トレーニング：トレーニングデータは暗号化してアップロードし、アテステーション済みのトレーニングジョブにのみキーをリリースします。トレーニング済みモデルの成果物はデータ所有者のキーで暗号化します。
   • マルチパーティの場合：各当事者のデータとモデルを個別の（または共有の）TEE に配置し、アテステーション済みの証拠がある場合にのみ出力をリリースします。

7. 高い完全性が求められる監査（規制当局向けログ、IoT の信頼性確保）には Confidential Ledger を使用します。スループットが高い汎用ロギングには使用しないでください。追記専用でブロックチェーンに基づくため、レイテンシが高くなります。

8. 運用します。 アテステーションの失敗（ファームウェアの差異、ハードウェアの更新）を監視します。 SKR ポリシーを定期的に見直し、時間の経過に伴ってセキュリティ バージョン番号の基準を引き上げます。

ガードレール

• 機密コンピューティングは万能ではありません。 アプリケーションのセキュリティ、サプライチェーンの衛生管理、ID 管理が引き続き最優先です。TEE はホスト事業者に対する保護を強化しますが、利用者自身からは保護しません。
• キーリリースポリシーには、セキュリティ バージョン番号の下限を必ず含めてください。 そうしないと、古い脆弱なファームウェアがアテステーションに合格し、キーを取得してしまいます。
• Confidential VM には通常の VM との機能差があります。 導入を確定する前に、スナップショット、バックアップ、ASR、カスタム拡張機能を検証してください。
• パフォーマンスへの影響は小さいものの、実際に発生します。 メモリ暗号化には数パーセントのコストがかかり、機密 GPU にはさらにオーバーヘッドがあります。ベンチマークを実施してください。
• AKS の機密コンテナーには、慎重なイメージ設計が必要です。 シークレットをイメージに含めず、SKR を使用してください。
• 対応が限られているリージョン／SKU があります。 機密 GPU と TDX-VM SKU は、すべての地域で利用できるわけではありません。リージョンごとに計画してください。
• Customer Key／CMK と機密コンピューティングを混同しないでください。 これらは異なる問題（保存データのキー管理と、実行時のメモリ保護）を解決します。
• アテステーションの証拠には有効期限があります。 トークンは失効するため、アプリに更新処理を組み込んでください。

よくあるアンチパターン

• 「イメージにシークレットをハードコードした Confidential VM」 — TEE が保護するのは実行時のメモリであり、イメージではありません。SKR を使用してください。
• 「ファームウェアの下限を設定せず、あらゆる AMD SEV-SNP を許可する SKR ポリシー」 — 脆弱なファームウェアも受け入れてしまい、セキュリティモデルが損なわれます。
• 「単なる『セキュリティ強化』の選択肢としての Confidential container」 — 脅威モデル上のメリットに見合わない運用の複雑さが生じます。明確に機密性の高いワークロードに限定してください。
• 「追記専用ログストアとしての Confidential ledger」 — 想定されるスループットのクラスが異なります。高い完全性が求められる、低ボリュームの規制対応や監査用チェーンに使用してください。
• 「SGX のみを前提とした設計を、VM 全体を使うユースケースに無理に適用する」 — コードの書き換えコストが発生します。Confidential VM を使用してください。
• 「テストせずに Confidential VM でスナップショットと復元を行う」 — ワークフローによっては、アテステーション済み状態の要件を維持できない場合があります。テストしてください。
• 「Confidential Computing を『CMK より強力な暗号化』として宣伝する」 — これは異なる制御カテゴリです。正確に伝えてください。

プロンプトの例

• 4 行の銀行が暗号化データを提出し、アテステーションを条件とするキーのリリースによって Confidential GPU VM で共同モデルをトレーニングする、複数当事者による不正検知コンソーシアムを設計してください。
• 規制対象の Linux ワークロードを Confidential VM（SEV-SNP）にリフトアンドシフトし、バックアップと DR の検証も行ってください。
• Confidential AKS クラスターについて、TEE が必要なポッド、ポッドごとのシークレットに SKR を接続する方法、アテステーションのフローを説明してください。
• ファームウェアの下限を条件とする Confidential VM のアテステーションに基づく SKR ポリシーを使用して、Key Vault Managed HSM を構成してください。
• ワークロードの構成に応じて、Confidential VM（SEV-SNP）と（TDX）を比較してください。
• Confidential GPU H100 上で独自の LLM を使った機密性の高い推論を設計してください。
• データ主権の要件に対して、Customer Key と Confidential Computing のどちらを選ぶべきか判断してください。

Microsoft Learn

• Confidential computing の概要：https://learn.microsoft.com/azure/confidential-computing/overview
• Confidential VM：https://learn.microsoft.com/azure/confidential-computing/confidential-vm-overview
• AMD SEV-SNP CVM：https://learn.microsoft.com/azure/confidential-computing/virtual-machine-solutions-amd
• Intel TDX CVM：https://learn.microsoft.com/azure/confidential-computing/tdx-confidential-vm-overview
• AKS 上の Confidential container：https://learn.microsoft.com/azure/confidential-computing/confidential-containers-on-aks-preview
• Confidential GPU（NCC H100 v5）：https://learn.microsoft.com/azure/confidential-computing/confidential-vm-overview#confidential-vms-with-gpu
• Microsoft Azure Attestation：https://learn.microsoft.com/azure/attestation/overview
• Secure key release：https://learn.microsoft.com/azure/key-vault/keys/policy-grammar
• Confidential Ledger：https://learn.microsoft.com/azure/confidential-ledger/overview
• Confidential AI のシナリオ：https://learn.microsoft.com/azure/confidential-computing/confidential-ai