構成証明ゲートセキュリティキーリリースを使用してAzure VM の知的財産を保護する

この記事では、機密性の高い資産 (独自の機械学習モデルの重み、ライセンスされたデータセット、シークレット構成など) を保護するための再利用可能なパターンについて説明します。このパターンは、他のユーザーのAzure サブスクリプション内の仮想マシン (VM) 上で実行する必要があります。資産 ( パブリッシャー) を所有するパーティは、VM が実行されているサブスクリプション ( コンシューマー) を所有するパーティとは異なります。コンシューマーは、その VM への完全なAzureコントロールプレーンアクセスを持ちますが、資産を抽出することはできません。

このパターンは、文書化された複数のAzure機能を多層防御に組み合わせたものになっています。その暗号コアは、Azure Key Vault からの構成証明によって制御される Secure Key Release (SKR) であり、その条件となるのは Trusted Launch の vTPM 構成証明です。コンフィデンシャルコンピューティングは必要 ありません が、Confidential Computing は、脅威モデルが要求する場合にオプションレイヤーとして追加できます。

Note

セキュリティで保護されたキーリリースは、Azure Key Vault Premium と Managed HSM のデータプレーン機能です。これは、コンピューティングの種類に関係なく、キーのリリースポリシーに対して署名された Microsoft Azure Attestation (MAA) トークンを検証します。機密 VM はこれらのトークンの一般的なソースですが、必須ではありません。信頼された起動 VM では MAA トークンも生成されます。トークンの要件については、セキュリティで保護されたキーリリースポリシーの文法Azure Key Vault参照してください。

シナリオと脅威モデル

パブリッシャーは、VM ベースのワークロードをコンシューマーのサブスクリプションに配布します（たとえば、Azure Marketplace を通じてソリューションテンプレートまたは共有イメージとして）。ワークロードには、実行時にパブリッシャーの資産のロックを解除するための復号化キーが必要です。キーは、パブリッシャーの真正で未変更のイメージにのみ提供しなければなりません。コンシューマーに直接提供してはならず、改ざんまたは置換されたイメージに提供してはなりません。

このパターンは、2 つの異なる脅威の方向から防御します。これらの名前を明示的に指定すると、階層化の決定が明確になります。

脅威の方向	敵対者	能力	～によって保護されています
A — コンシューマー (VM/サブスクリプション所有者)	デプロイされたリソースに対する完全なAzure RBAC を持つサブスクリプション所有者	`az vm run-command`、カスタムスクリプト拡張機能、OS ディスクのスナップショットとスワップ、シリアルコンソール、IMDS 経由のマネージド ID トークンの盗難-すべて SSH なし	レイヤー 1 ~ 3
B — クラウドプロバイダー (ホスト/ハイパーバイザー)	VM メモリへのホストレベルのアクセス権を持つオペレーター	VM の外部からのゲストメモリの読み取り	レイヤー 4 (省略可能)

脅威の方向 A は主要な脅威 であり、アーキテクチャを形作る脅威です。基本パターンでは、脅威の方向 B は明示的に受け入れられたリスクです。プラットフォームは信頼されており、クラウドプロバイダーのハイパーバイザーを信頼する一般的な姿勢と一致します。ハイパーバイザー自体を信頼できない場合にのみ Layer 4 を追加します（たとえば、メモリ暗号化が必須の規制要件のあるワークロードの場合）。

コンフィデンシャルコンピューティングを追加するタイミング (レイヤー 4)

コンフィデンシャルコンピューティングは、このパターンの代替手段ではありません。これは、その上に追加するオプションの レイヤー 4 です。ベースパターン (レイヤー 1～3) では、既に構成証明を条件としてキーリリースを制御し、利用者からアセットを保護し、標準コストであらゆる Gen2 Trusted Launch SKU 上で動作します。コンフィデンシャルコンピューティングを追加しても、パターンの動作は変わりません。SKR、強化されたイメージ、ネットワーク分離はすべて同じままであり、リリースフローは同じです。唯一の違いは、リリースポリシーが vTPM の measured boot クレームではなくハードウェア TEE クレームを条件とすることと、ワークロードが機密 VM SKU 上で実行されることです。脅威の方向 B (ホスト/ハイパーバイザー) に対する保護を取得し、SKU、GPU、リージョンの幅を Premium コストで取引します。

次の表は、レイヤー 4 の追加内容とコストを示しています。2 つのパターンの選択ではありません。

Consideration	基本パターン（レイヤー 1～3、Trusted Launch）	レイヤー 4 の追加 (コンフィデンシャルコンピューティング)
コンシューマーから資産を保護する (脅威 A)	はい	はい (変更なし)
ホスト/ハイパーバイザーから資産を保護します (脅威 B)	いいえ (許容されるリスク)	はい (メモリ暗号化)
構成証明によって制御される鍵のリリース	vTPM 測定ブートのクレーム	Hardware-TEE の主張
GPU SKU の可用性	すべての Gen2 SKU	機密性の高い GPU SKU とクォータに限定
リージョンと SKU の幅	幅広い	より狭い
相対コスト	Standard VM の価格	Premium

基本パターンから始めます。レイヤー 4 を追加するのは、ハイパーバイザーに不信感を抱く必要がある場合 (たとえば、メモリ暗号化を義務付ける規制されたワークロードなど)、より狭い SKU、GPU、リージョンの可用性と Premium コストを受け入れる場合のみです。

パターンの要素

このパターンは多層防御スタックです。各レイヤーは特定の脅威の方向を防御します。レイヤー 1 ~ 3 はコンシューマー (脅威の方向 A) に対して防御し、オプションのレイヤー 4 はホスト (脅威の方向 B) に対して防御します。保護された資産はコアに配置され、外側のすべてのレイヤーを介してのみ到達可能です。

レイヤーは、保存時および使用時のアセットを保護します。実行時に、コンシューマーの VM とパブリッシャーのトラストアンカーは、次のように対話します。

コンシューマーテナントとパブリッシャーテナントの間のランタイム構成証明とキーリリースフローの図。

レイヤー 1: 構成証明で制御される安全な鍵の解放（暗号学的ゲート）

このレイヤーが基礎です。セキュアブートと仮想 TPM (vTPM) を使用して、トラステッド起動 VM が起動します。 vTPM は、ブートチェーンをプラットフォーム構成レジスタ (PCR) に測定し、起動された内容を正確に暗号化フィンガープリントを作成します。ゲストは、secureboot クレームや pcr7 から x-ms-azurevm-attested-pcr-values.pcr0 までなど、これらの測定値を含む MAA トークンを要求します。その後、Key Vaultの/release エンドポイントを呼び出し、トークンを提示します。 Key Vaultはトークンの署名を検証し、キーのリリースポリシーに対して評価します。ポリシーの要求が一致する場合、Key Vaultは vTPM のエフェメラルキーにラップされたキーを解放し、構成証明された VM のみがラップを解除できるようにします。一致しない場合、リリースは AccessDeniedを返します。

ブロックするもの (脅威 A): 改ざんされた VM、再イメージ化された VM、またはディスクスワップされた VM は、異なる PCR を測定し、キーを取得できません。別の VM にマウントされている OS ディスクのスナップショットも失敗します。

信頼された起動 VM の代表的なリリースポリシー:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

レイヤー 2: 強化されたイメージ (復号化された資産を保護する)

レイヤー 1 では、キーが解放 されるかどうかを 制御します。実行中のゲストで復号化されると、資産は保護されません。イメージを強化して、ゲスト内およびコントロールプレーン内の攻撃対象領域を縮小します。ファイルシステムの整合性 (dm-verity など)、読み取り専用ルートファイルシステム、SSH デーモンなし、対話型ログインなし、およびオペレーターが指定したコマンドを実行できるゲスト内エージェントがありません。

ブロックするもの (脅威 A): 実行中の構成証明済み VM (不正なプロセス、特権エスカレーション、OS レベルの脆弱性を介してプロセスメモリから復号化された資産を抽出する) のゲスト内悪用。

レイヤー 3: ネットワーク分離 (サーフェスを縮小)

VM がトラストアンカーとデータと通信する方法を制限します。 Key Vault、ストレージ、レジストリにはプライベートエンドポイントを使用し、構成証明プロバイダーへのプライベートパスとプライベート DNS を使用して、不要なパブリックエグレスを発生させないでください。配信メカニズムでサポートされている場合 (マネージドアプリケーションなど) 拒否割り当てでは、コンピューティングリソースに対するコンシューマーの RBAC を取り除き、コントロールプレーン攻撃 (run-command、ディスク操作、シリアルコンソール、ID 盗難) を完全にブロックすることもできます。ソリューションテンプレート配信では、コンシューマーはデプロイされたリソースに対して RBAC を保持するため、コントロールプレーンのセキュリティ強化は使用できません。そこで、レイヤー 1 とレイヤー 2 は、脅威 A に対する防御を実行します。スナップショットまたはスワップされたディスクは構成証明に失敗し (レイヤー 1)、強化されたイメージ (レイヤー 2) は、復号化されたゲスト内資産の抽出を防ぎます。

防ぐもの (脅威 A): コントロールプレーン攻撃とデータプレーン攻撃の両方に対する攻撃面を縮小し、検証済みゲストからのデータ流出経路を防ぎます。

レイヤー 4 (省略可能): コンフィデンシャルコンピューティング (脅威の方向 B を防御)

上記のすべてがホストを信頼します。ハイパーバイザーを信頼できない場合は、Confidential VM (AMD SEV-SNP または Intel TDX) でワークロードを実行します。メモリ暗号化を使用すると、ホストはゲストメモリを読み取りなくなり、SKR は vTPM メジャーブート要求からリリースポリシーのハードウェア TEE 要求にアップグレードされます。このレイヤーは、脅威の方向 B を防御する唯一のレイヤーです。SKU、GPU、リージョンの可用性が縮小され、コストが追加されるため、既定ではオフになっています。

テナント間 ID

発行元は、コンシューマーの RBAC の管理外にある 発行元のテナント内で、信頼アンカーである Key Vault (または Managed HSM) と構成証明プロバイダーを保有しています。構成証明済みの VM は コンシューマーの テナントで実行され、その境界をまたいで Key Vault を呼び出す必要があります。 2 つのプラットフォーム制約によって、明確なアプローチが除外されます。

マネージド ID は、1 つのテナントに存在します。発行元のテナントは、コンシューマーのテナントに存在するマネージド ID を認識したり、トークンを発行したりしません。
Azure RBAC ロールの割り当ては、リソース独自のテナント内の ID のみを対象とできるため、コンシューマーのマネージド ID にパブリッシャーのKey Vaultのロールを付与することはできません。

フェデレーション ID 資格情報 (FIC) は、ギャップを直接埋めることはできません。Entra IDは、FIC が別の Entra テナントによって発行されたトークンを信頼することを許可しないため、発行元所有のアプリケーションは境界を越えてコンシューマーのマネージド ID をフェデレーションできません。

動作するパターンでは、ブリッジング ID ( マルチテナントアプリケーション) がコンシューマー側に配置されます。

コンシューマーは、テナントにマルチテナントアプリケーションを登録し、VM のマネージド ID を信頼する同じテナント FIC を構成します。同じテナント内の ID を信頼する FIC が許可されます。
パブリッシャーは、そのアプリケーションのサービスプリンシパルをプロビジョニングし、そのプリンシパルにキーに対する Key Vault Crypto Service Release User ロールを付与することで、そのアプリケーションを独自のテナントにオンボードします。コンシューマーごとのこの意図的なオンボーディング手順では、発行元が外部アクターにテナントへのアクセスを許可します。
実行時に、VM のマネージド ID は IMDS からトークンを取得し、FIC を介して交換してマルチテナントアプリケーションとして認証し、要求本文で MAA トークンを使用してKey Vaultの/release エンドポイントを呼び出します。

Important

ID 交換はセキュリティ境界ではありません。コンシューマーはマルチテナントアプリケーションの登録を所有しているため、コンシューマー側の管理者は別の資格情報 (クライアントシークレットなど) を追加し、このフローを手動で実行できます。そのため、ID 層によって、敵対的なコンシューマーに対する保証は発行元に与えなくなります。実際の境界は SKR + 構成証明 (レイヤー 1) です。有効な発行元テナントトークンであっても、有効な MAA トークンがリリースポリシーを満たしていない限り、Key Vaultはキーの解放を拒否し、発行元の本物の構成証明されたイメージのみがキーを生成できます。 ID レイヤーは、リクエストを適切なボールトに振り分けるだけです。

Walkthrough

トラストアンカー (パブリッシャーテナント) をプロビジョニングします。 Key Vault Premium または Managed HSM を作成します。 エクスポート可能な RSA-HSM キーを作成します。 MAA 機関と Trusted Launch クレーム（x-ms-azurevm-attested-pcr-values.pcrN、選択した）をピン留めする securebootをアタッチします。
予想される PCR 値を決定します。 イメージの既知の適切なインスタンスを 1 回証明し、返された MAA トークンから x-ms-azurevm-attested-pcr-values を読み取ります。ブートチェーンで測定される PCR、一般的には pcr4（ブートローダー/カーネル）と pcr7（Secure Boot の状態）をピン留めしてください。
ワークロード (コンシューマーテナント) をデプロイします。 強化されたイメージを実行する信頼された起動 (Gen2) VM をデプロイします。マネージド ID を付与し、その ID を、Cross-tenant identity で説明されているコンシューマー所有のマルチテナントアプリケーションにフェデレーションします。このアプリケーションは、パブリッシャーがそのキーに対して Key Vault Crypto Service Release User ロールを付与したサービスプリンシパルを持ちます。
実行時に構成証明とリリースを行います。 ゲストは MAA トークンを取得し、 POST /keys/{key-name}/releaseを呼び出します。 Key Vaultラップされたキーを検証して返します。ゲストは VM 内でラップを解除します。
負のケースを確認します。 リリースポリシーのピン留めされた PCR を一致しない値に変更 (または変更されたイメージを起動) し、リリースが AccessDenied返されたことを確認します。

実行可能なコードについては、「関連コンテンツ」のサンプルを参照してください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-10-01