Azure Attestation

解決する課題

• クラウド上で動くワークロードが、本当に改ざんされていない正規の環境で動いているか確認したい
• 機密コンピューティング（Confidential Computing）の TEE 内で動くコードの完全性を、外部から証明したい
• 秘密鍵やシークレットを 信頼できると確認できた環境にだけ渡したい（リリース条件を付けたい）
• VM の起動チェーン（ブート）が 既知の正しい状態であることを TPM の測定値で検証したい

主要概念と用語

• アテステーション（Attestation / 遠隔検証）: ある環境が「自分はこういう状態だ」という証拠を提示し、信頼できる第三者がそれを検証して真正性を判定する仕組み。Azure Attestation はその**検証側（Verifier）**を担う
• TEE（Trusted Execution Environment）: CPU が提供する保護された実行領域。中のコードとデータは OS やハイパーバイザーからも保護される。代表例が Intel SGX と AMD SEV-SNP
• 証跡（Evidence / Quote）: TEE や TPM がハードウェアの秘密で署名して出力する測定値の塊。中で動くコードのハッシュ（MRENCLAVE など）や環境の構成情報を含む
• アテステーションポリシー: 「どの条件を満たせば信頼すると判定するか」をユーザーが記述するルール。署名者・コードのハッシュ・許容するセキュリティバージョンなどを条件にできる
• アテステーショントークン: 検証結果を表す 署名付き JWT。証跡が示す主張（claims）を含み、Azure Attestation の鍵で署名される。リライングパーティ（依存側）はこのトークンを検証して判定を信頼する
• アテステーションプロバイダー: 検証エンドポイントとポリシーを束ねるリソース単位。リージョンごとに作成し、URI を持つ
• TPM アテステーション: 仮想 / 物理マシンの **TPM（Trusted Platform Module）**が記録したブート測定値を検証し、起動チェーンの完全性を確認する用途

仕様・制限・クォータ

• 主な検証対象は Intel SGX エンクレーブ、AMD SEV-SNP（機密 VM）、TPM ベースのブート測定の3系統
• 既定（Default）プロバイダー がリージョン単位で用意され、共有ポリシーで使える。カスタムプロバイダーを作れば、独自ポリシーや独自署名鍵を持てる
• ポリシーには AAD（Microsoft Entra ID）モードと、分離（Isolated）モードがある。分離モードではポリシー更新にポリシー署名証明書を要求でき、管理者の権限濫用に対しても堅牢にできる
• アテステーショントークンの署名鍵は Azure 側が管理し、JWKS エンドポイント経由で公開鍵を取得して検証する
• 各操作にはスループット上限（スロットリング）があり、超過時は制限がかかるため、頻繁な再検証はトークンの有効期間内でキャッシュするのが前提
• 利用可能リージョンや具体的な上限値は変動しうるため、最新の公式ドキュメントで確認する

内部の仕組み

検証の流れは「証跡の提示 → 真正性の検証 → ポリシー評価 → トークン発行」という4段です。ワークロードはまず TEE や TPM にハードウェア署名付きの証跡を生成させ、それを Azure Attestation のエンドポイントへ送ります。Azure Attestation は証跡の署名チェーン（ハードウェアベンダーのルートまで）を検証して本物のハードウェアが出したものだと確認し、続けてユーザー定義のポリシーを評価します。条件を満たせば、証跡の主張を含む**署名付き JWT（アテステーショントークン）**を返します。

• 依存側（リライングパーティ）は、受け取ったトークンを Azure Attestation の公開鍵で検証し、claims（コードのハッシュ・SVN など）を見て後続処理を許可する
• Azure Attestation 自身も SGX エンクレーブ内で動作し、検証ロジックの完全性を自分自身のアテステーションで担保する設計になっている
• Key Vault の **Secure Key Release（SKR）**と組み合わせると、「アテステーションに合格した環境にだけ鍵を解放する」リリース条件を構成できる
• すべての検証は証跡のハードウェア署名に依拠するため、ソフトウェアだけでは偽造できない信頼の根（Root of Trust）になる

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

• 鍵のリリース条件にアテステーションを使う: Key Vault の SKR で「正規の TEE であると検証できた場合のみ鍵を解放」とし、シークレットを信頼できる環境に限定して渡す
• ポリシーをコード（IaC）で管理し、許可するコードハッシュ・署名者・最小 SVN を明示してレビュー可能にする
• 分離（Isolated）モードを本番で採用し、ポリシー更新に署名証明書を要求して、管理者単独でのポリシー緩和を防ぐ
• トークンの有効期間内はキャッシュして、毎回の再検証によるスロットリングを避ける
• 依存側は必ず JWKS でトークン署名を検証し、claims の値（コードの同一性・SVN の下限）まで確認してから信頼する

運用・監視

• アテステーションプロバイダーの操作を Azure Monitor の診断設定で Log Analytics 等へ送り、検証要求と失敗を可視化する
• ポリシー変更を監査し、いつ・誰が条件を緩めたかを追跡する（分離モードなら署名で裏付ける）
• 検証失敗が増えたら、ハードウェアのセキュリティパッチ適用で SVN が上がった結果ポリシーの下限に抵触していないかを確認する
• 公開鍵（JWKS）のローテーションに依存側が追従できているか、トークン検証エラーの監視で担保する
• 依存側のトークン検証エラーは、有効期限切れ・署名鍵の不一致・claims 不足の順に切り分ける

コスト

検証操作（アテステーション要求）の回数に応じた従量課金が基本で、既定プロバイダーの利用やプロバイダー作成自体に大きな固定費はかからない考え方です。コストを抑える鍵は、有効期間内のトークンを再利用して検証回数を増やしすぎないことです。具体的な単価や無料枠の有無は変動するため、最新の料金ページで確認してください。

セキュリティ

• 信頼の根が ハードウェア（CPU / TPM）の証跡にあるため、ソフトウェア単独では偽装できない
• 分離モード + ポリシー署名証明書で、管理者であってもポリシーを勝手に緩められない構成にできる
• Secure Key Release と組み合わせ、検証に合格した環境にだけシークレットを解放する最小権限を実現
• アテステーショントークンは短命な署名付き JWTであり、依存側での厳格な検証（署名・有効期限・claims）が前提
• Azure Attestation 自体が SGX エンクレーブ内で動作し、検証サービス側の完全性も担保される

関連サービス・比較

Azure Attestation は単体で動くより、**Key Vault（Secure Key Release）**や機密コンピューティングと組み合わせて価値が出ます。役割としては、AWS で Nitro Enclaves の証跡を検証してから KMS が鍵を解放する流れに近い位置づけです。

ハンズオン / CLI例

# 機密コンピューティング用の拡張機能を追加（初回のみ）
az extension add --name confidentialledger

# カスタムのアテステーションプロバイダーを作成
az attestation create \
  --name demo-attest-prov \
  --resource-group demo-rg \
  --location japaneast

# プロバイダーの既定 URI（依存側がトークン検証に使う）を確認
az attestation show \
  --name demo-attest-prov \
  --resource-group demo-rg \
  --query attestUri -o tsv

# SGX 用のアテステーションポリシーを取得（既定値の確認）
az attestation policy show \
  --name demo-attest-prov \
  --resource-group demo-rg \
  --attestation-type SGX-OpenEnclave