Proteggi la proprietà intellettuale sulle VM di Azure con il rilascio sicuro delle chiavi attivato tramite attestazione

Questo articolo descrive un modello riutilizzabile per proteggere un asset sensibile, ad esempio i pesi dei modelli di Machine Learning proprietari, un set di dati concesso in licenza o una configurazione segreta, che deve essere eseguita in una macchina virtuale (VM) all'interno della sottoscrizione Azure di un altro utente. Il soggetto che possiede la risorsa (il publisher) è diverso dal soggetto che possiede la sottoscrizione in cui viene eseguita la VM (il consumer). Il cliente ha pieno accesso al control plane di Azure per quella macchina virtuale, eppure non deve poter estrarre la risorsa.

Il modello combina diverse funzionalità di Azure documentate in livelli di difesa. Il suo nucleo crittografico è il rilascio sicuro delle chiavi (SKR) vincolato all’attestazione di Azure Key Vault, basato sull’attestazione vTPM di Trusted Launch. Non richiede l’elaborazione riservata, anche se l’elaborazione riservata può essere aggiunta come livello opzionale quando il modello di minaccia lo richiede.

Annotazioni

Secure Key Release è una funzionalità del piano dati di Azure Key Vault Premium e di Managed HSM. Verifica un token Microsoft attestazione di Azure (MAA) firmato in base ai criteri di rilascio di una chiave, indipendentemente dal tipo di elaborazione. Le macchine virtuali riservate sono un'origine comune di questi token, ma non sono necessarie: anche le macchine virtuali di avvio attendibile producono token MAA. Per i requisiti dei token, vedere Azure Key Vault grammatica dei criteri di rilascio delle chiavi sicure.

Scenario e modello di minaccia

Un editore distribuisce un carico di lavoro basato su VM nella sottoscrizione di un cliente, ad esempio tramite Azure Marketplace come modello di soluzione o come immagine condivisa. Il carico di lavoro richiede una chiave di decrittografia per sbloccare l'asset dell'editore in fase di esecuzione. La chiave deve essere rilasciata solo all'immagine originale e non modificata dell'editore, mai direttamente al consumer e mai a un'immagine manomessa o sostituita.

Il modello si difende da due direzioni di minaccia distinte. Denominarle in modo esplicito è ciò che rende chiare le decisioni di sovrapposizione.

Direzione delle minacce Avversario Capacità Protetto da
A — il consumatore (proprietario della VM/sottoscrizione) Proprietario della sottoscrizione con Azure RBAC completo sulle risorse distribuite az vm run-command, estensioni di script personalizzate, snapshot del disco del sistema operativo e scambio, console seriale, furto di token di identità gestita tramite IMDS, tutto senza SSH Livelli da 1 a 3
B : provider di servizi cloud (host/hypervisor) Operatore con accesso a livello di host alla memoria della macchina virtuale Lettura della memoria guest dall'esterno della macchina virtuale Livello 4 (facoltativo)

La direzione delle minacce A è la minaccia principale e quella che modella l'architettura. Nel modello di base, la direzione delle minacce B è un rischio accettato in modo esplicito: la piattaforma è attendibile, che corrisponde al comportamento comune di attendibilità dell'hypervisor del provider di servizi cloud. Aggiungere il livello 4 solo quando l'hypervisor stesso deve essere disfidato (ad esempio, un carico di lavoro regolamentato che impone la crittografia della memoria).

Quando aggiungere confidential computing (livello 4)

Confidential Computing non è un'alternativa a questo modello, ma è il livello 4 facoltativo aggiunto. Lo schema di base (livelli 1–3) subordina già il rilascio della chiave all'attestazione, protegge la risorsa dall'utilizzatore e funziona con qualsiasi SKU Gen2 di Trusted Launch a costo standard. L'aggiunta di Confidential Computing non cambia il funzionamento del modello: SKR, l'immagine con protezione avanzata e l'isolamento della rete rimangono invariati e il flusso di rilascio è identico. Le uniche differenze sono che la policy di rilascio si basa sulle attestazioni hardware TEE anziché sulle attestazioni di avvio misurato del vTPM e che il carico di lavoro viene eseguito su uno SKU di VM confidenziale. Si ottiene protezione contro il vettore di minaccia B (l'host/hypervisor), rinunciando in parte ad ampiezza di scelta in termini di SKU, GPU e copertura geografica, a un costo più elevato.

La tabella seguente illustra gli elementi aggiunti al livello 4 e i costi, non una scelta tra due modelli:

Consideration Modello di base (livelli 1–3, Trusted Launch) Con il livello 4 aggiunto (Confidential Computing)
Protegge la risorsa dal consumatore (minaccia A) Yes Sì (non modificato)
Protegge l'asset dall'host/hypervisor (minaccia B) No (rischio accettato) Sì (crittografia della memoria)
Rilascio della chiave subordinato all'attestazione Attestazioni vTPM di avvio misurato dichiarazioni Hardware-TEE
Disponibilità dello SKU GPU Tutti gli SKU gen2 Limitato agli SKU e alle quote riservate della GPU
Ampiezza dell'area e dello SKU Ampio Più stretto
Costo relativo Prezzi standard delle macchine virtuali Premium

Iniziare con il modello di base. Scegli il livello 4 solo quando non ci si può fidare dell'hypervisor, ad esempio per un workload regolamentato che richiede la crittografia della memoria, accettando la disponibilità più limitata di SKU, GPU e regioni e il costo più elevato.

Gli elementi del modello

Lo schema è uno stack di difesa in profondità. Ogni livello difende una direzione di minaccia specifica: i livelli 1-3 si difendono contro il consumer (direzione della minaccia A) e il livello 4 facoltativo si difende contro l'host (direzione della minaccia B). La risorsa protetta si trova al centro, raggiungibile solo attraverso tutti gli strati che la circondano.

flowchart TB
    threatA["Threat direction A<br/>Consumer / VM and subscription owner<br/>run-command, disk snapshot and swap,<br/>serial console, managed-identity theft"]
    threatB["Threat direction B<br/>Host / hypervisor<br/>reads guest memory"]

    subgraph L4 ["Layer 4 (optional) — Confidential Computing: host memory encryption"]
        subgraph L3 ["Layer 3 — Network isolation: private endpoints, no public egress, deny assignments"]
            subgraph L2 ["Layer 2 — Hardened image: dm-verity, read-only root, no SSH or agent"]
                subgraph L1 ["Layer 1 — Attestation-gated SKR: vTPM measured-boot claims gate key release"]
                    asset["Protected asset<br/>released key, then decrypted weights"]
                end
            end
        end
    end

    threatA -. "defended by Layers 1–3" .-> asset
    threatB -. "defended only by Layer 4" .-> asset
    style L4 stroke-dasharray: 5 5

I livelli proteggono l'asset sia a riposo sia in uso. In fase di esecuzione, la macchina virtuale del consumer e i trust anchor dell'editore interagiscono come segue:

flowchart TB
    subgraph consumer ["Consumer tenant (untrusted operator)"]
        vm["Trusted Launch VM<br/>Secure Boot + vTPM<br/>Hardened image"]
    end
    subgraph publisher ["Publisher tenant (holds the trust anchors)"]
        maa["Microsoft Azure Attestation"]
        akv["Key Vault Premium / Managed HSM<br/>exportable key + release policy"]
    end
    vm -->|"1. Attestation request (vTPM evidence)"| maa
    maa -->|"2. Signed MAA token (secureboot, PCR claims)"| vm
    vm -->|"3. POST /keys/{key}/release (MAA token)"| akv
    akv -->|"4. Key wrapped to vTPM ephemeral key, or AccessDenied"| vm
    linkStyle default stroke-width:2px

Livello 1: Rilascio della chiave protetta vincolato all'attestazione (barriera crittografica)

Questo livello è la base. Una VM Trusted Launch si avvia con Secure Boot e un TPM virtuale (vTPM). Il vTPM misura la catena di avvio nei registri di configurazione della piattaforma (PCR), creando un'impronta crittografica di ciò che è stato effettivamente avviato. L'ospite richiede un token MAA che includa queste misure, come l'asserzione secureboot e da x-ms-azurevm-attested-pcr-values.pcr0 a pcr7. Chiama quindi l'endpoint di /release Key Vault e presenta il token. Key Vault convalida la firma del token e la valuta in base ai criteri di rilascio della chiave. Se le attestazioni del criterio corrispondono, Key Vault rilascia la chiave, sottoposta al wrapping con la chiave effimera del vTPM, in modo che solo quella VM attestata possa decrittografarla. Se non corrispondono, la versione restituisce AccessDenied.

Cosa blocca (minaccia A): Una macchina virtuale manomessa, di cui è stata ricreata l’immagine o con disco sostituito misura valori PCR diversi e non può ottenere la chiave. Anche uno snapshot del disco del sistema operativo montato in una macchina virtuale diversa ha esito negativo.

Criteri di rilascio rappresentativi per una macchina virtuale di avvio attendibile:

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

Livello 2: immagine con protezione avanzata (proteggere l'asset decrittografato)

Il livello 1 controlla se la chiave viene rilasciata; non protegge la risorsa una volta decifrata nel guest in esecuzione. Rafforzare la sicurezza dell'immagine per ridurre la superficie di attacco all'interno del guest e del piano di controllo: integrità del filesystem (ad esempio, dm-verity), un filesystem root di sola lettura, nessun demone SSH, nessun accesso interattivo e nessun agente nel guest in grado di eseguire comandi forniti dall'operatore.

Cosa blocca (minaccia A): Sfruttamento guest di una macchina virtuale in esecuzione e con attestazione: processi non autorizzati, escalation dei privilegi, estrazione dell'asset decrittografato dalla memoria del processo tramite una vulnerabilità a livello di sistema operativo.

Livello 3: Isolamento della rete (ridurre la superficie di attacco)

Limitare il modo in cui la macchina virtuale comunica con le ancore di attendibilità e i dati. Utilizzare endpoint privati per Key Vault, l'archiviazione e qualsiasi registro; un percorso privato verso il provider di attestazione; DNS privato; e nessun traffico in uscita pubblico non necessario. Laddove il meccanismo di distribuzione lo supporti, ad esempio un'applicazione gestita, le assegnazioni di rifiuto possono anche revocare il controllo RBAC dell'utente sulle risorse di calcolo, bloccando del tutto gli attacchi al piano di controllo (run-command, operazioni sul disco, console seriale, furto d'identità). In una distribuzione basata su un modello di soluzione, il cliente mantiene il controllo degli accessi basato sui ruoli (RBAC) sulle risorse distribuite, quindi l'irrobustimento del piano di controllo non è disponibile; in questo caso, i livelli 1 e 2 forniscono la difesa contro la minaccia A: uno snapshot o un disco sostituito non supera l'attestazione (livello 1) e l'immagine irrobustita (livello 2) impedisce l'estrazione dell'asset decrittografato all'interno del guest.

Cosa blocca (minaccia A): Riduce la superficie esposta per gli attacchi del piano di controllo e del piano dati e impedisce percorsi di esfiltrazione dal guest attestato.

Livello 4 (facoltativo): Confidential Computing (difende la direzione delle minacce B)

Tutto quanto sopra si fida dell'host. Se non è possibile considerare attendibile l'hypervisor, eseguire il carico di lavoro in una macchina virtuale riservata (AMD SEV-SNP o Intel TDX). La crittografia della memoria impedisce all'host di leggere la memoria guest e SKR passa dalle asserzioni di avvio misurato del vTPM alle asserzioni hardware TEE nel criterio di rilascio. Questo livello è l'unico livello che difende la direzione delle minacce B. È disattivato per impostazione predefinita perché restringe la disponibilità di SKU, GPU e area geografica e aggiunge costi.

Identità tra tenant

L'editore detiene le ancore di attendibilità, ovvero Key Vault (o HSM gestito) e il provider di attestazione, nel tenant dell'editore, al di fuori dell'RBAC del consumer. La VM attestata è in esecuzione nel tenant del cliente e deve accedere a Key Vault attraverso tale confine. Due vincoli della piattaforma escludono gli approcci più ovvi:

  • Un'identità gestita esiste in un solo tenant. Il tenant dell'editore non riconoscerà né rilascerà token a un'identità gestita che si trova nel tenant del cliente.
  • Un'assegnazione di ruolo di Azure RBAC può avere come destinazione solo un'identità nel tenant della risorsa stessa, quindi non è possibile concedere all'identità gestita del consumer un ruolo sul Key Vault del publisher.

Una credenziale di identità federata (FIC) non può colmare direttamente il divario: Entra ID non consente a un FIC di considerare attendibili i token emessi da un altro tenant Entra, quindi un'applicazione di proprietà dell'editore non può federate l'identità gestita del consumer oltre il limite.

Lo schema che funziona colloca l'identità di collegamento, ovvero un'applicazione multi-tenant, sul lato del consumer:

  1. Il consumer registra un'applicazione multi-tenant nel proprio tenant e configura un FIC nello stesso tenant che considera attendibile l'identità gestita della VM. È consentito un FIC che considera attendibile un'identità dello stesso tenant.
  2. L'editore esegue l'onboarding di tale applicazione nel proprio tenant effettuando il provisioning di un'entità servizio e assegnando a tale entità servizio il ruolo Utente del rilascio del servizio di crittografia di Key Vault per la chiave. Questo passaggio deliberato di onboarding per singolo consumer è la fase in cui l'editore concede a un attore esterno l'accesso al proprio tenant.
  3. In fase di esecuzione, l'identità gestita della macchina virtuale ottiene un token da IMDS, lo scambia tramite FIC per autenticarsi come applicazione multi-tenant e chiama l'endpoint /release di Key Vault con il token MAA nel corpo della richiesta.

Importante

Lo scambio di identità non è il limite di sicurezza. Poiché il cliente possiede la registrazione dell'applicazione multi-tenant, un amministratore lato cliente può aggiungervi un'altra credenziale (per esempio, un segreto client) ed eseguire manualmente questo flusso, quindi il livello di identità non offre all'editore alcuna garanzia nei confronti di un cliente malevolo. La vera barriera è SKR + attestazione (livello 1): anche con un token valido del tenant dell’editore, Key Vault si rifiuta di rilasciare la chiave a meno che un token MAA valido non soddisfi i criteri di rilascio, e solo l’autentica immagine attestata dell’editore può generarne uno. Il livello di identità indirizza solo la richiesta al vault corretto.

Walkthrough

  1. Effettuare il provisioning dei trust anchor (tenant dell'editore). Crea un Key Vault Premium o un Managed HSM. Creare una chiave RSA-HSM esportabile . Collegare un criterio di rilascio che fissa l'autorità di certificazione MAA e le attestazioni di avvio attendibile (secureboot, x-ms-azurevm-attested-pcr-values.pcrN selezionato).
  2. Determinare i valori PCR previsti. Attesta una volta sola un'istanza della tua immagine nota come affidabile e leggi x-ms-azurevm-attested-pcr-values dal token MAA restituito. Aggiungere i PCR misurati dalla catena di avvio, in genere pcr4 (caricatore di avvio/kernel) e pcr7 (stato di avvio sicuro).
  3. Distribuire il carico di lavoro (tenant consumer). Distribuisci una macchina virtuale Trusted Launch (Gen2) basata sull'immagine hardenizzata. Assegna un'identità gestita e federa tale identità all'applicazione multi-tenant di proprietà del consumer descritta in Identità tra tenant, il cui service principal ha ricevuto dall'editore il ruolo Key Vault Crypto Service Release User per la chiave.
  4. Verificare e rilasciare in fase di esecuzione. Il guest ottiene un token MAA, quindi chiama POST /keys/{key-name}/release. Key Vault valida e restituisce la chiave sottoposta a wrapping; il guest esegue l’unwrapping all’interno della VM.
  5. Verificare il caso negativo. Modificare un PCR vincolato nei criteri di rilascio impostandolo su un valore non corrispondente (oppure avviare un'immagine modificata) e verificare che il rilascio restituisca AccessDenied.

Per il codice eseguibile, vedere gli esempi in Contenuto correlato.

Contenuti correlati

  • Last updated on