Bescherm intellectueel eigendom op Azure-VM's met door attestatie beveiligde Secure Key Release

In dit artikel wordt een herbruikbaar patroon beschreven voor het beveiligen van een gevoelige asset, zoals eigen machine learning-modelgewichten, een gelicentieerde gegevensset of een geheime configuratie, die moeten worden uitgevoerd op een virtuele machine (VM) binnen het Azure-abonnement van iemand anders. De partij die eigenaar is van het activum (de uitgever) verschilt van de partij die eigenaar is van het abonnement waarop de VIRTUELE machine wordt uitgevoerd (de consument). De klant heeft volledige toegang tot het Azure-beheervlak van die VM, maar mag die asset niet kunnen extraheren.

Het patroon combineert verschillende gedocumenteerde Azure functies in verdedigingslagen. De cryptografische kern wordt gevormd door attestation-gated Secure Key Release (SKR) uit Azure Key Vault, afhankelijk van Trusted Launch-vTPM-attestatie. Er is geen Confidential Computing vereist, maar Confidential Computing kan worden toegevoegd als een optionele laag wanneer het bedreigingsmodel dit vereist.

Scenario en bedreigingsmodel

Een uitgever implementeert een op VM gebaseerde workload in het abonnement van een klant (bijvoorbeeld via Azure Marketplace als een oplossingssjabloon of als een gedeelde installatiekopie). De workload heeft een ontsleutelingssleutel nodig om de asset van de uitgever tijdens runtime te ontgrendelen. De sleutel mag alleen worden verstrekt aan de authentieke, ongewijzigde image van de uitgever — nooit rechtstreeks aan de consument en nooit aan een gemanipuleerde of vervangen image.

Het patroon verdedigt zich tegen twee verschillende bedreigingsrichtingen. Als u ze expliciet een naam geeft, worden de gelaagde beslissingen duidelijk.

Bedreigingsrichting A is de primaire bedreiging en de bedreiging die de architectuur vormt. In het basispatroon is bedreigingsrichting B een expliciet geaccepteerd risico: het platform wordt vertrouwd en komt overeen met de algemene houding van het vertrouwen van de hypervisor van de cloudprovider. Voeg Layer 4 alleen toe wanneer de hypervisor zelf niet mag worden vertrouwd (bijvoorbeeld een gereguleerde workload waarvoor geheugenversleuteling verplicht is).

Wanneer moet u Confidential Computing toevoegen (laag 4)

Confidential Computing is geen alternatief voor dit patroon. Dit is de optionele Laag 4 die u er bovenop toevoegt. Het basispatroon (lagen 1–3) maakt het vrijgeven van sleutels reeds afhankelijk van attestation, beschermt de asset tegen de afnemer en draait op elke Gen2 Trusted Launch-SKU tegen standaardtarief. Het toevoegen van vertrouwelijk computergebruik verandert niet hoe het patroon werkt: SKR, de beveiligde image en netwerkisolatie blijven allemaal hetzelfde en het releaseproces is identiek. De enige verschillen zijn dat het releasebeleid is gebaseerd op hardware-TEE-claims in plaats van op vTPM measured-boot-claims, en dat de workload wordt uitgevoerd op een confidentiale VM-SKU. U krijgt bescherming tegen bedreigingsrichting B (de host/hypervisor) en verhandelt SKU, GPU en regiobreedte tegen premiumkosten.

In de volgende tabel ziet u wat Laag 4 toevoegt en wat het kost, niet een keuze tussen twee patronen:

Begin met het basispatroon. Voeg laag 4 alleen toe wanneer u de hypervisor moet wantrouwen, bijvoorbeeld bij een gereguleerde workload waarvoor geheugenversleuteling verplicht is, waarbij u de beperktere beschikbaarheid van SKU's, GPU's en regio's en de hogere kosten accepteert.

De elementen van het patroon

Het patroon is een gelaagde verdedigingsopbouw. Elke laag verdedigt een specifieke bedreigingsrichting: Lagen 1-3 verdedigen tegen de consument (bedreigingsrichting A) en de optionele Laag 4 verdedigt zich tegen de host (bedreigingsrichting B). De beveiligde asset bevindt zich in de kern, alleen bereikbaar via elke omsluitende laag.

De lagen beschermen de asset in rust en in gebruik. Tijdens runtime communiceren de VM van de consument en de vertrouwensankers van de uitgever als volgt:

Laag 1: attestatiegestuurde veilige sleutlevrijgave (de cryptografische toegangspoort)

Deze laag is de basis. Een vertrouwde start-VM wordt opgestart met Beveiligd opstarten en een virtuele TPM (vTPM). De vTPM meet de opstartketen in PCR's (Platform Configuration Registers), waardoor een cryptografische vingerafdruk wordt gemaakt van precies wat is opgestart. De gast vraagt een MAA-token aan dat deze metingen bevat, zoals de secureboot-claim en x-ms-azurevm-attested-pcr-values.pcr0 tot en met pcr7. Vervolgens wordt het /release-eindpunt van Key Vault aangeroepen en wordt het token aangeboden. Key Vault valideert de handtekening van het token en evalueert deze op basis van het releasebeleid van de sleutel. Als de claims in het beleid overeenkomen, geeft Key Vault de sleutel vrij, verpakt met de tijdelijke sleutel van de vTPM, zodat alleen die geattesteerde VM deze kan uitpakken. Als ze niet overeenkomen, retourneert de release AccessDenied.

Wat het blokkeert (bedreiging A): Een VM waarmee is geknoeid, die opnieuw van een image is voorzien of waarvan de schijf is verwisseld, meet andere PCR's en kan de sleutel niet verkrijgen. Een momentopname van de besturingssysteemschijf die op een andere VM is gekoppeld, mislukt ook.

Een representatief releasebeleid voor een vertrouwde start-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>" }
      ]
    }
  ]
}

Laag 2: geharde image (bescherm het ontsleutelde bestand)

Laag 1 bepaalt of de sleutel wordt vrijgegeven; het beveiligt de asset niet zodra deze is ontsleuteld in de actieve gast. Behard de afbeelding om de kwetsbaarheid voor aanvallen op het gast- en besturingsvlak te verkleinen: bestandssysteemintegriteit (bijvoorbeeld dm-verity), een alleen-lezen hoofdbestandssysteem, geen SSH-daemon, geen interactieve aanmelding en geen in-guest agent waarmee door operator geleverde opdrachten kunnen worden uitgevoerd.

Wat wordt geblokkeerd (bedreiging A): In-guest exploitatie van een actieve, geteste VM: frauduleuze processen, escalatie van bevoegdheden, het extraheren van de ontsleutelde asset uit procesgeheugen via een beveiligingsprobleem op besturingssysteemniveau.

Laag 3: Netwerkisolatie (verklein het oppervlak)

Beperk hoe de VIRTUELE machine met de vertrouwensankers en -gegevens praat. Gebruik privé-eindpunten voor Key Vault, opslag en een register; een privépad naar de attestation-provider; privé-DNS en geen onnodig openbaar uitgaand verkeer. Waar het implementatiemechanisme dit ondersteunt - bijvoorbeeld een beheerde applicatie - kunnen weigeringstoewijzingen ook de RBAC-machtigingen van de consument voor de rekenresources wegnemen, waardoor control-plane-aanvallen (run-command, schijfbewerkingen, seriële console, identiteitsdiefstal) volledig worden geblokkeerd. Bij levering via een oplossingssjabloon behoudt de klant de RBAC over de geïmplementeerde resources, waardoor hardening van het beheervlak niet beschikbaar is; daar vormen laag 1 en laag 2 de verdediging tegen bedreiging A: een snapshot of verwisselde schijf doorstaat de attestation niet (laag 1), en de geharde image (laag 2) voorkomt extractie van het ontsleutelde asset binnen de guest-omgeving.

Wat wordt geblokkeerd (bedreiging A): Vermindert het blootgestelde oppervlak voor aanvallen op het besturingsvlak en het gegevensvlak en voorkomt exfiltratiepaden van de geteste gast.

Laag 4 (optioneel): Confidential Computing (verdedigt bedreigingsrichting B)

Alles hierboven vertrouwt de host. Als u de hypervisor niet kunt vertrouwen, voert u de workload uit op een vertrouwelijke VM (AMD SEV-SNP of Intel TDX). Geheugenversleuteling voorkomt dat de host het geheugen van de gast leest, en SKR zet in het releasebeleid claims voor gemeten opstarten via vTPM om naar hardware-TEE-claims. Deze laag is de enige laag die bedreigingsrichting B verdedigt. Deze functie is standaard uitgeschakeld omdat de beschikbaarheid van SKU, GPU en regio's wordt beperkt en kosten worden toegevoegd.

Tenantoverschrijdende identiteit

De uitgever beheert de vertrouwensankers — Key Vault (of Managed HSM) en de attestatieprovider — in de tenant van de uitgever, buiten de RBAC van de consument. De geattesteerde VM draait in de tenant van de klant en moet Key Vault over die tenantgrens heen aanroepen. Twee platformbeperkingen sluiten de voor de hand liggende benaderingen uit:

• Er bestaat een beheerde identiteit in precies één tenant. De tenant van de uitgever herkent of geeft tokens niet door aan een beheerde identiteit die zich in de tenant van de consument bevindt.
• Een Azure RBAC-roltoewijzing kan alleen gericht zijn op een identiteit in de eigen tenant van de resource, zodat u de beheerde identiteit van de consument niet kunt toewijzen aan de Key Vault van de uitgever.

Een federatieve identiteitsreferentie (FIC) kan de kloof ook niet rechtstreeks overbruggen: Entra ID staat niet toe dat een FIC tokens vertrouwt die zijn uitgegeven door een andere Entra-tenant, dus een toepassing van de uitgever kan de beheerde identiteit van de consument niet over die grens heen federeren.

Het patroon dat werkt, plaatst de overbruggingsidentiteit (een multitenant-toepassing) aan de kant van de consument:

1. De gebruiker registreert een multitenant-toepassing in zijn tenant en configureert daarop een same-tenant-FIC die de beheerde identiteit van de virtuele machine vertrouwt. Een FIC die een identiteit in dezelfde tenant vertrouwt, is toegestaan.
2. De publisher neemt die applicatie op in zijn eigen tenant door ervoor een service-principal te provisioneren en die service-principal de rol Key Vault Crypto Service Release User op de sleutel toe te kennen. Deze weloverwogen onboardingstap per gebruiker is het moment waarop de uitgever een externe partij toegang verleent tot de tenant.
3. Tijdens de runtime verkrijgt de beheerde identiteit van de VM een token van IMDS, wisselt dit via de FIC uit om zich te authenticeren als de multitenant-applicatie, en roept het /release-eindpunt van Key Vault aan met het MAA-token in de hoofdtekst van de aanvraag.

Walkthrough

1. Configureer de vertrouwensankers (tenant van de uitgever). Maak een Key Vault Premium of een Managed HSM. Maak een exporteerbare RSA-HSM sleutel. Voeg een releasebeleid toe waarmee uw MAA-autoriteit en de Trusted Launch-claims (secureboot, x-ms-azurevm-attested-pcr-values.pcrNgeselecteerd) worden vastgezet.
2. Bepaal de verwachte PCR-waarden. Attesteer één keer een geverifieerd goed exemplaar van uw image en lees x-ms-azurevm-attested-pcr-values in het geretourneerde MAA-token. Koppel de PCR's die door uw opstartketen worden gemeten—meestal pcr4 (bootloader/kernel) en pcr7 (Secure Boot-status).
3. Implementeer de workload (tenant van de consument). Implementeer een VM met Trusted Launch (Gen2) waarop de beveiligde installatiekopie wordt uitgevoerd. Geef deze een beheerde identiteit en federeer die identiteit met de multitenant-toepassing die eigendom is van de consument en wordt beschreven in Cross-tenant identity, waarvan de service-principal door de uitgever de rol Key Vault Crypto Service Release User voor de sleutel heeft gekregen.
4. Attesteer en geef vrij tijdens uitvoering. De gast verkrijgt een MAA-token en roept vervolgens aan POST /keys/{key-name}/release. Key Vault valideert en retourneert de verpakte sleutel; de gast pakt deze uit in de VIRTUELE machine.
5. Controleer het negatieve scenario. Wijzig een vastgezette PCR in het vrijgavebeleid in een niet-overeenkomende waarde (of start een gewijzigde installatiekopie op) en bevestig dat de vrijgave AccessDenied retourneert.

Zie de voorbeelden in Gerelateerde inhoud voor runnable code.

Verwante onderwerpen

• Grammatica van beleid voor veilige sleutelrelease van Azure Key Vault
• Sleutelrelease beveiligen met Azure Key Vault en Azure Confidential Computing
• Voorbeelden van secure Key Release-beleid
• Overzicht van Microsoft Azure Attestation
• Vertrouwde start voor virtuele Azure-machines
• workload-identiteitsfederatie
• Voorbeeld: cvm-securekey-release-app in Azure/confidential-computing-cvm-guest-attestation
• Voorbeeld: SKR-voorbeelden in Azure-Samples/confidential-computing