使用受證明機制控管的安全金鑰釋出，保護 Azure 虛擬機上的智慧財產權

本文描述了一種可重複使用的模式，用於保護敏感資產——例如專有的機器學習模型權重、授權資料集或秘密設定——這些資產必須在他人 Azure 訂閱內的虛擬機（VM）上執行。 擁有資產的一方（發行商）和擁有虛擬機運行的訂閱方（消費者）是不同的。 消費者擁有該虛擬機的完整 Azure 控制平面存取權，但不得能夠擷取該資產。

該模式將多項 Azure 文件化的特徵組成多層防禦。 其密碼編譯核心為來自 Azure Key Vault 的證明管制安全金鑰發行 (SKR)，並以可信啟動 vTPM 證明管制。 它 不 一定需要機密運算，但當威脅模型需要時，可作為選用層加入機密運算。

Note

Secure Key Release 是 Azure Key Vault Premium 與 Managed HSM 的資料平面功能。 它會根據金鑰的釋出原則驗證已簽署的 Microsoft Azure 證明（MAA）權杖，且不受運算類型影響。 機密虛擬機是這些令牌的常見來源，但並非必需——受信任的啟動虛擬機也會產生 MAA 令牌。 關於令牌要求，請參閱 Azure Key Vault 安全金鑰釋放政策文法。

情境與威脅模型

發佈者將基於虛擬機的工作負載分發到消費者的訂閱中（例如透過 Azure Marketplace 作為解決方案範本，或以共享映像檔形式）。 工作負載需要解密金鑰，才能在執行時解鎖出版商的資產。 該金鑰 必須只 授權給出版商真實且未經修改的影像——絕不可直接交給消費者，也絕不能授權給經過竄改或替換的影像。

這種模式防禦兩種截然不同的威脅方向。 明確命名它們才讓層次決定更清晰。

威脅方向 對手 能力 受以下機制防護
A — 消費者（虛擬機/訂閱擁有者） 訂閱擁有者擁有完整的 Azure RBAC 來管理已部署的資源 az vm run-command、自訂腳本擴充、作業系統磁碟快照與交換、序列主控台、透過 IMDS 進行管理身份令牌竊取——全部 皆無 SSH 第1–3層
B — 雲端供應商（主機/虛擬機監控器） 擁有主機層級存取虛擬機記憶體的操作員 從虛擬機外部讀取來賓記憶體 第四層（可選）

威脅方向 A是主要威脅 ，也是塑造架構的關鍵。 在基礎模式中，威脅方向 B 屬於明確接受的風險：該平台是受信任的，這與信任雲端供應商 hypervisor 的常見做法一致。 只有在 Hypervisor 本身必須視為不可信時（例如，要求必須進行記憶體加密的受管制工作負載），才新增 第 4 層。

何時加入機密運算（第四層）

機密運算並不是這個模式的替代方案——它是你選擇性地加裝在上面的 第四層 。 基礎模式（第1–3層）已在認證時限制金鑰釋放，保護資產免於消費者，並可在任何Gen2可信啟動SKU上以標準成本運行。 加入機密運算並不會改變模式的運作方式：SKR、強化映像和網路隔離都保持不變，釋出流程也完全相同。 唯一的差異在於：發佈原則是根據硬體 TEE 宣告來把關，而不是根據 vTPM 的測量式開機宣告；此外，工作負載是在機密虛擬機 SKU 上執行。 你可以獲得對威脅方向 B（主機/虛擬機監控器）的保護，並以高價交易 SKU、GPU 和區域範圍。

下表顯示了第四層新增了什麼以及成本——不是兩種模式之間的選擇：

考慮事項 基本模式（第 1–3 層，受信任啟動） 加入第四層（機密運算）
保護資產免受消費者侵害（威脅A） 是的 是的（未改變）
保護資產免受主機/虛擬機監控程式（威脅 B）的傷害 不（接受風險） 是的（記憶體加密）
證明管制金鑰發行 vTPM 測量開機宣告 硬體-TEE 宣告
GPU SKU 的可用性 所有第二世代SKU 僅限於機密的 GPU SKU 和配額
區域與 SKU 廣度 寬 更窄
相對成本 標準虛擬機定價 進階

從基礎圖案開始。 只有在你必須不信任虛擬機監控程式時才加入第四層——例如一個受規範且必須執行記憶體加密的工作負載——同時接受較窄的 SKU、GPU 和區域可用性，以及較高的費用。

圖案的元素

這個模式是一種縱深防禦的分層架構。 每一層防禦特定的威脅方向：第1至第3層防禦消費者（威脅方向A），選擇性第4層防禦主機（威脅方向B）。 受保護的資產位於核心，必須穿過每一層外圍層才能抵達。

保護資產的同心防禦層示意圖，以及每層防禦的威脅方向。

這些層可在靜態和使用中保護資產。 執行時，消費者的虛擬機與發布者的信任錨點互動如下：

消費者租戶與發佈者租戶之間執行時證明與金鑰釋放流程的示意圖。

第一層：檢測門控安全金鑰釋放（密碼門）

這一層是基礎。 受信任啟動 VM 會以安全開機和虛擬 TPM（vTPM）開機。 vTPM 會將啟動鏈測量並記錄到平台組態暫存器（PCRs）中，為實際開機的內容建立加密指紋。 來賓請求包含這些測量值的 MAA 權杖，例如 secureboot 宣告以及 x-ms-azurevm-attested-pcr-values.pcr0 到 pcr7。 接著它呼叫 金鑰保存庫 的/release端點並呈現該令牌。 金鑰保存庫 會驗證令牌的簽章，並將其與金鑰的釋放政策進行評估。 如果原則中的宣告相符，金鑰保存庫 就會釋出金鑰，並以 vTPM 的暫時性金鑰加以包裝，因此只有該已通過證明的虛擬機器才能將其解開。 如果兩者不相符，則該版本會傳回 AccessDenied。

它會阻擋什麼（威脅 A）：遭到竄改、被重新套用映像，或更換磁碟的虛擬機會量測出不同的 PCR 值，因此無法取得金鑰。 掛載在不同虛擬機上的作業系統磁碟快照也會失敗。

可信啟動虛擬機的代表性發布政策：

{
  "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>" }
      ]
    }
  ]
}

第二層：強化映像（保護解密資產）

第一層控制 鍵是否 被釋放;一旦資產在 Running Guest 中解密後，它就無法保護它。 強化映像檔以縮小訪客與控制平面的攻擊面：檔案系統完整性（例如 dm-verity）、唯讀根檔案系統、無 SSH 守護程序、無互動式登入，且無可執行操作員指令的訪客代理。

其可防範的內容（威脅 A）： 在客體內利用正在執行且已驗證的虛擬機——惡意程序、權限提升，以及透過作業系統層級漏洞從程序記憶體中擷取已解密的資產。

第三層：網路隔離（縮小表面）

限制虛擬機與信任錨點及資料的通訊方式。 使用私有端點管理 金鑰保存庫、儲存及任何登錄;私有路徑通往認證提供者;私有 DNS;且不必要地公開出口。 在交付機制支援的情況下（例如受控應用程式），拒絕指派也可以移除使用者對運算資源的 RBAC 權限，從而直接阻擋控制平面攻擊（run-command、磁碟操作、序列主控台、身分盜用）。 在以解決方案範本交付的模式下，客戶仍保有對已部署資源的 RBAC 控制權，因此無法使用控制平面強化；在此情況下，第 1 層和第 2 層承擔對威脅 A 的防禦：快照或遭替換的磁碟將無法通過證明（第 1 層），而經強化的映像（第 2 層）則可防止在來賓作業系統內擷取已解密的資產。

它所封鎖的內容 (威脅A)：減少控制平面與資料平面攻擊的暴露面，並防止來自已證明客體的資料外洩路徑。

第四層（可選）：機密運算（防禦威脅方向B）

以上所有東西都信任宿主。 如果你不信任虛擬機管理程式，就把工作負載放在機密虛擬機（AMD SEV-SNP 或 Intel TDX）上。 記憶體加密可防止主機讀取來賓記憶體，而 SKR 則在發行原則中，將宣告從 vTPM 的測量式開機宣告升級為硬體 TEE 宣告。 此層是 唯一 防禦威脅方向B的層。預設是關閉的，因為這樣會縮小 SKU、GPU 和區域的可用性，還會增加成本。

跨租用戶身分識別

出版者持有信任錨點——金鑰保存庫（或管理式 HSM）及認證提供者——位於出版商租戶中，且不在消費者的 RBAC 之外。 證明的 VM 會在取用者的租用戶中執行，且必須跨越該邊界呼叫 金鑰保存庫。 兩個平台限制排除了明顯的做法：

  • 受控身分識別只存在於一個租用戶中。 出版商的租戶不會辨識或發放代幣給存在於消費者租戶中的管理身份。
  • Azure RBAC 角色指派只能針對資源自身租戶中的身份，因此你無法在發佈者的 金鑰保存庫 上授予消費者的管理身份角色。

聯邦身份憑證（FIC）也無法直接彌補這個缺口：Entra ID 不允許 FIC 信任其他 Entra 租戶發行的代幣，因此發行商擁有的應用程式無法跨越邊界將消費者的管理身份聯合。

有效的模式將橋接身份—— 多租戶應用——置於消費者端：

  1. 取用者會在其租戶中註冊多租戶應用程式，並在其中設定一個 同一租戶 的 FIC，使其信任該 VM 的受控識別。 允許使用信任同一租用戶身分識別的 FIC。
  2. 發行者透過為該應用程式佈建服務主體，並在該金鑰上授與該主體 金鑰保存庫 Crypto Service Release User 角色，將該應用程式納入其自己的租用戶。 這個經過深思熟慮、針對個別消費者進行的上線步驟，正是發行者授與外部執行者其租用戶存取權的位置。
  3. 執行時，虛擬機的管理身份會從 IMDS 取得一個憑證，透過 FIC 交換以作為多租戶應用程式進行認證，並以請求主體中的 MAA 憑證呼叫 金鑰保存庫 /release 的端點。

Important

身份交換不是安全邊界。 由於消費者擁有多租戶應用程式的註冊權，消費者端管理員可以為其新增另一個憑證（例如用戶端秘密）並手動驅動此流程——因此身份層無法保證發布者能抵禦對抗性消費者。 真正的界線是 SKR + 證明 (第 1 層)：即使有有效的發佈者-租用戶權杖，金鑰保存庫 也拒絕發行金鑰，除非有效的 MAA 權杖符合發行原則，且只有發佈者真實且經過證明的映像才能產生。 身分層只負責將請求轉送到正確的保管庫。

逐步介紹

  1. 佈建信任錨點 (發行者租用戶)。 建立 金鑰保存庫 Premium 或 Managed HSM。 建立 一個可匯出 的 RSA-HSM 金鑰。 附加一個發行原則，用以釘選您的 MAA 授權單位和可信啟動宣告 (secureboot，已選取 x-ms-azurevm-attested-pcr-values.pcrN)。
  2. 確定預期的PCR數值。 先驗證一張已知良好的影像實例，然後從回傳的 MAA 代幣讀取 x-ms-azurevm-attested-pcr-values 。 將您的開機鏈結測量的 PCR 釘選為 — 通常為 pcr4 (開機載入程式/核心) 和 pcr7 (安全開機狀態)。
  3. 部署工作負載 (取用者租用戶)。 部署一台可信啟動（Gen2）虛擬機，執行已強化映像。 為其指派受控身分識別，並將該身分識別同盟至跨租用戶身分識別中所述、由取用者擁有的多租用戶應用程式；發佈者已在該金鑰上，將 金鑰保存庫 密碼編譯服務發行使用者角色授與該應用程式的服務主體。
  4. 執行時驗證並發布。 訪客取得 MAA 代幣，然後呼叫 POST /keys/{key-name}/release。 金鑰保存庫 會驗證並回傳包裹好的金鑰;訪客會在虛擬機內展開它。
  5. 驗證負面案例。 將發佈政策中釘選的 PCR 改為不匹配值（或啟動修改過的映像檔），並確認釋放回傳 AccessDenied。

關於可執行的程式碼，請參見 相關內容中的範例。

相關內容

  • 上次更新時間：