Skydda immateriella rättigheter på virtuella Azure-datorer med Secure Key Release som styrs av attestering

I den här artikeln beskrivs ett återanvändbart mönster för att skydda en känslig tillgång, till exempel proprietära maskininlärningsmodellvikter, en licensierad datauppsättning eller en hemlig konfiguration, som måste köras på en virtuell dator (VM) i någon annans Azure prenumeration. Den part som äger tillgången ( utgivaren) skiljer sig från den part som äger prenumerationen där den virtuella datorn körs ( konsumenten). Konsumenten har fullständig Azure kontrollplansåtkomst till den virtuella datorn, men får inte kunna extrahera tillgången.

Mönstret kombinerar flera dokumenterade Azure-funktioner i flera skyddslager. Dess kryptografiska kärna är Secure Key Release (SKR) som styrs av attestering från Azure Key Vault, baserat på Trusted Launch-vTPM-attestering. Det kräver inte konfidentiell databehandling, även om konfidentiell databehandling kan läggas till som ett valfritt lager när hotmodellen kräver det.

Scenario och hotmodell

En utgivare distribuerar en VM-baserad arbetsbelastning till en konsuments prenumeration (till exempel via Azure Marketplace som en lösningsmall eller som en delad avbildning). Arbetsbelastningen behöver en dekrypteringsnyckel för att låsa upp utgivarens resurs under körning. Nyckeln får endast släppas till utgivarens äkta, oförändrade bild – aldrig till konsumenten direkt och aldrig till en manipulerad eller ersatt bild.

Mönstret försvarar mot två distinkta hotriktningar. Att namnge dem explicit är det som gör skiktningsbesluten tydliga.

Hotriktning A är det primära hotet och det som formar arkitekturen. I basmönstret är hotriktningen B en uttryckligen accepterad risk: plattformen är betrodd och matchar den gemensamma hållningen att lita på molnleverantörens hypervisor-program. Lägg bara till Layer 4 när man inte kan lita på själva hypervisorn (till exempel för en reglerad arbetslast som kräver minneskryptering).

När du ska lägga till konfidentiell databehandling (Lager 4)

Konfidentiell databehandling är inte ett alternativ till det här mönstret– det är det valfria Layer 4 som du lägger till ovanpå det. Grundmönstret (lager 1–3) villkorar redan utlämningen av nyckeln med attestering, skyddar resursen från konsumenten och körs på valfri Gen2 Trusted Launch SKU till standardkostnad. Att lägga till konfidentiell databehandling ändrar inte hur mönstret fungerar: SKR, den härdade avbildningen och nätverksisoleringen förblir desamma och versionsflödet är identiskt. De enda skillnaderna är att utgivningsprincipen baseras på maskinvarubaserade TEE-anspråk i stället för vTPM-anspråk för uppmätt uppstart, och att arbetsbelastningen körs på en konfidentiell VM-SKU. Du får skydd mot hotriktning B (värd/hypervisor) och handel med SKU, GPU och regionbredd till premiumkostnad.

I följande tabell visas vad Layer 4 lägger till och vad det kostar – inte ett val mellan två mönster:

Börja med basmönstret. Lägg till Layer 4 endast när du inte kan lita på hypervisorn – till exempel för en reglerad arbetsbelastning som kräver minneskryptering – och acceptera då den mer begränsade tillgängligheten för SKU:er, GPU:er och regioner samt den högre kostnaden.

Elementen i mönstret

Mönstret är ett lager av skydd på flera nivåer. Varje lager skyddar mot en specifik hotriktning: lager 1–3 skyddar mot konsumenten (hotriktning A), och det valfria lager 4 skyddar mot värden (hotriktning B). Den skyddade tillgången ligger i kärnan och kan endast nås via varje omslutande lager.

Lagren skyddar resursen i vila och under användning. Vid körning interagerar konsumentens virtuella dator och utgivarens förtroendeankare på följande sätt:

Lager 1: Attesteringsstyrd säker nyckelutlämning (den kryptografiska spärren)

Det här lagret är grunden. En betrodd virtuell startdator startar med säker start och en virtuell TPM (vTPM). vTPM mäter startkedjan i Plattformskonfigurationsregister (PCR) och skapar ett kryptografiskt fingeravtryck av exakt vad som startades. gästen begär en MAA-token som innehåller dessa mätvärden, såsom påståendet secureboot och x-ms-azurevm-attested-pcr-values.pcr0 till och med pcr7. Den anropar sedan Key Vault slutpunkt /release och visar token. Key Vault verifierar tokens signatur och utvärderar den mot nyckelns versionsprincip. Om policyns uppgifter överensstämmer frigör Key Vault nyckeln, krypterad med vTPM:ets tillfälliga nyckel, så att endast den attesterade virtuella datorn kan avkapsla den. Om de inte stämmer överens returnerar utgåvan AccessDenied.

Vad det blockerar (hot A): En manipulerad, omskapad eller diskbytad virtuell dator mäter olika PCR:er och kan inte hämta nyckeln. En ögonblicksbild av os-disken som monterats på en annan virtuell dator misslyckas också.

En representativ versionsprincip för en betrodd virtuell dator för start:

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

Lager 2: Härdad bild (skydda den dekrypterade tillgången)

Lager 1 avgör om nyckeln lämnas ut; det skyddar inte resursen när den har dekrypterats i den körande gästen. Härda avbildningen för att krympa attackytan på gäst- och kontrollplanet: filsystemintegritet (till exempel dm-verity), ett skrivskyddat rotfilsystem, ingen SSH-daemon, ingen interaktiv inloggning och ingen gästagent som kan köra kommandon som tillhandahålls av operatören.

Vad det blockerar (hot A): Exploatering inifrån gästen av en attesterad virtuell maskin som körs – skadliga processer, eskalering av privilegier, extrahering av den dekrypterade resursen från processminnet via en sårbarhet på operativsystemnivå.

Lager 3: Nätverksisolering (krympa ytan)

Begränsa hur den virtuella datorn pratar med förtroendeankare och data. Använd privata slutpunkter för Key Vault, lagring och alla register, en privat sökväg till attesteringsprovidern, privat DNS och ingen onödig offentlig utgående trafik. Om distributionsmekanismen stöder det – till exempel en hanterad applikation – kan nekande tilldelningar också ta bort konsumentens RBAC-behörigheter för beräkningsresurserna, vilket helt blockerar attacker mot kontrollplanet (run-command, diskoperationer, seriekonsol, identitetsstöld). Vid en leverans med lösningsmall behåller kunden RBAC över de driftsatta resurserna, så härdning av kontrollplanet är inte tillgänglig; där står lager 1 och 2 för skyddet mot hot A – en ögonblicksbild eller en utbytt disk klarar inte attesteringen (lager 1), och den härdade avbilden (lager 2) förhindrar extrahering av den dekrypterade tillgången inne i gästen.

Vad det blockerar (hot A): Minskar den exponerade ytan för både attacker mot kontrollplanet och dataplanet och förhindrar exfiltreringsvägar från den attesterade gästen.

Layer 4 (valfritt): Konfidentiell databehandling (försvarar hotriktning B)

Allt ovan förlitar sig på värddatorn. Om du inte kan lita på hypervisor-programmet kör du arbetsbelastningen på en konfidentiell virtuell dator (AMD SEV-SNP eller Intel TDX). Minneskryptering förhindrar att värdsystemet läser gästens minne, och SKR uppgraderas från vTPM-baserade anspråk för uppmätt start till maskinvarubaserade TEE-anspråk i versionspolicyn. Det här lagret är det enda lagret som försvarar hotriktningen B. Det är inaktiverat som standard eftersom det begränsar tillgängligheten för SKU, GPU och regioner och lägger till kostnader.

Identitet mellan klientorganisationer

Utgivaren har förtroendeankare – Key Vault (eller Hanterad HSM) och attesteringsprovidern – i utgivarens klientorganisation, utanför konsumentens RBAC. Den intygade virtuella datorn körs i konsumentens klientorganisation och måste anropa Key Vault över den gränsen. Två plattformsbegränsningar utesluter de uppenbara metoderna:

• Det finns en hanterad identitet i exakt en klientorganisation. Utgivarens klientorganisation känner inte igen eller utfärdar token till en hanterad identitet som finns i konsumentens klientorganisation.
• En Azure RBAC-rolltilldelning kan bara rikta in sig på en identitet i resursens egen klientorganisation, så du kan inte ge konsumentens hanterade identitet en roll i utgivarens Key Vault.

En federerad identitetsautentiseringsuppgift (FIC) kan inte heller överbrygga klyftan direkt: Entra ID tillåter inte att en FIC litar på token som utfärdats av en annan Entra-klientorganisation, så ett utgivarägt program kan inte federera konsumentens hanterade identitet över gränsen.

Mönstret som fungerar placerar bryggidentiteten – ett program med stöd för flera klientorganisationer – på konsumentsidan:

1. Konsumenten registrerar ett program med flera klienter i sin klientorganisation och konfigurerar en FIC för samma klientorganisation på den som litar på den virtuella datorns hanterade identitet. En FIC som litar på en identitet i samma klientorganisation tillåts.
2. utgivaren ansluter applikationen till sin egen klientorganisation genom att etablera ett tjänsthuvudnamn för den och tilldela detta tjänsthuvudnamn rollen Key Vault Crypto Service Release User för nyckeln. Det här avsiktliga onboardingsteget för varje konsument är det steg där utgivaren ger en extern aktör åtkomst till sin klientorganisation.
3. Vid körning hämtar den virtuella datorns hanterade identitet en token från IMDS, byter ut den via FIC för att autentisera som multitenantprogram och anropar Key Vault slutpunkt /release med MAA-token i begärandetexten.

Genomgång

1. Etablera förtroendeankare (utgivarens klientorganisation). Skapa ett Key Vault Premium eller en hanterad HSM. Skapa en exporterbar RSA-HSM nyckel. Bifoga en releasepolicy som låser din MAA-auktoritet och Trusted Launch-attesterna (secureboot, valda x-ms-azurevm-attested-pcr-values.pcrN).
2. Fastställa förväntade PCR-värden. Attestera en känd, betrodd instans av avbilden en gång och läs x-ms-azurevm-attested-pcr-values från den returnerade MAA-tokenen. Lås de PCR:er som din startkedja mäter i – vanligtvis pcr4 (starthanterare/kärna) och pcr7 (Secure Boot-status).
3. Distribuera arbetsbelastningen (konsumentklientorganisation). Driftsätt en virtuell dator med Trusted Launch (Gen2) som kör den härdade avbildningen. Ge den en hanterad identitet och federera den identiteten till det konsumentägda programmet med flera klientorganisationer som beskrivs i Identitet mellan klientorganisationer, vars tjänstens huvudnamn utgivaren har beviljat Key Vault Crypto Service Release User-behörigheten för nyckeln.
4. Attestera och släpp vid körning. Gästen hämtar en MAA-token och anropar sedan POST /keys/{key-name}/release. Key Vault validerar och returnerar den inpackade nyckeln; gästen packar upp den i den virtuella datorn.
5. Kontrollera det negativa fallet. Ändra en fastnålad PCR i utgivningspolicyn till ett värde som inte matchar (eller starta från en modifierad avbildning) och bekräfta att frisläppningen returnerar AccessDenied.

Körbar kod finns i exemplen i Relaterat innehåll.

Relaterat innehåll

• Grammatik för säker nyckelfrisättningsprincip i Azure Key Vault
• Säker nyckelversion med Azure Key Vault och Azure konfidentiell databehandling
• Exempel på principexempel för säker nyckelutgivning
• Översikt över Microsoft Azure Attestation
• Betrodd start för virtuella Azure-datorer
• Identitetsfederation för arbetsbelastning
• Exempel: cvm-securekey-release-app i Azure/confidential-computing-cvm-guest-attestation
• Exempel: SKR-exempel i Azure-Samples/confidential-computing