Attestazione di Microsoft Azure

  • Articolo

Attestazione di Microsoft Azure è una soluzione unificata che consente di verificare in remoto l'attendibilità di una piattaforma e l'integrità dei file binari in esecuzione al suo interno. Il servizio supporta l'attestazione delle piattaforme supportate da TPM (Trusted Platform Module) insieme alla possibilità di attestare lo stato degli ambienti di esecuzione attendibile (TEE), ad esempio gli enclavi di Intel® Software Guard Extensions (SGX), gli enclavi con sicurezza basata su virtualizzazione (VBS), Trusted Platform Module (TPM), Avvio attendibile per le VM di Azure e le macchine virtuali riservate di Azure.

L'attestazione è un processo per dimostrare che siano state create istanze corrette dei binari software in una piattaforma attendibile. Le relying party remote possono quindi avere la certezza che solo tale software previsto venga eseguito su hardware attendibile. Attestazione di Azure è un servizio e framework unificato rivolto ai clienti per l'attestazione.

Attestazione di Azure rende disponibili paradigmi di sicurezza all'avanguardia, ad esempio il confidential computing di Azure e la protezione delle reti perimetrali intelligenti. I clienti chiedono di avere la possibilità di verificare in modo indipendente la posizione di un computer, la postura di una macchina virtuale (VM) in tale computer e l'ambiente in cui sono in esecuzione le enclavi nella VM. Attestazione di Azure risponde a queste e a molte altre richieste dei clienti.

Attestazione di Azure riceve evidenze dalle entità di calcolo, le converte in un set di attestazioni, le convalida in base a criteri configurabili e genera prove crittografiche per le applicazioni basate su attestazioni (ad esempio, relying party e autorità di controllo).

Attestazione di Azure supporta sia l'attestazione della piattaforma sia l'attestazione guest di macchine virtuali riservate (CVM) basate su AMD SEV-SNP. L'attestazione della piattaforma basata su Attestazione di Azure avviene automaticamente durante il percorso di avvio critico delle CVM, senza che sia necessaria alcuna azione da parte del cliente. Per altre informazioni sull'attestazione guest, vedere Annuncio della disponibilità generale dell'attestazione guest per le macchine virtuali riservate.

Casi d'uso

Attestazione di Azure fornisce servizi di attestazione completi per più ambienti e casi d'uso distinti.

Attestazione AMD SEV-SNP in macchine virtuali riservate

Le macchine virtuali riservate (CVM) di Azure si basano su processori AMD con tecnologia SEV-SNP. Le CVM offrono l'opzione di crittografia del disco del sistema operativo della macchina virtuale con chiavi gestite dalla piattaforma o chiavi gestite dal cliente e associa le chiavi di crittografia del disco al TPM della macchina virtuale. All'avvio di una CVM, il report SNP contenente le misurazioni del firmware della macchina virtuale guest viene inviato ad Attestazione di Azure. Il servizio convalida le misurazioni e genera un token di attestazione usato per rilasciare chiavi da HSM gestito o Azure Key Vault. Queste chiavi vengono usate per decrittografare lo stato vTPM della macchina virtuale guest, sbloccare il disco del sistema operativo e avviare la CVM. Il processo di attestazione e rilascio della chiave viene eseguito automaticamente a ogni avvio della CVM, solo in caso di attestazione corretta dell'hardware.

Attestazione AMD SEV-SNP in contenitori riservati

I contenitori riservati di Azure si basano su processori AMD con tecnologia SEV-SNP. I contenitori riservati, ospitati in Istanze di Azure Container e in Servizio Azure Kubernetes (in anteprima) offrono la possibilità di eseguire gruppi di contenitori in un ambiente di esecuzione attendibile protetto da SEV-SNP che isola tale gruppo di contenitori dal piano di controllo di gestione dei contenitori e da altri contenitori in esecuzione. L'attestazione nei contenitori riservati comporta il recupero del report di attestazione hardware AMD direttamente dal processore. Questa operazione può essere eseguita con il contenitore sidecar SKR o compilata direttamente nella logica dell'applicazione. Il report hardware può quindi essere scambiato con Attestazione di Azure e un HSM gestito o Azure Key Vault (AKV) Premium per recuperare i segreti. È anche possibile specificare il report hardware nel sistema dell'insieme di credenziali delle chiavi in base alle esigenze.

Attestazione di avvio attendibile

I clienti di Azure possono prevenire le infezioni di tipo bootkit e rootkit abilitando l'avvio attendibile per le macchine virtuali. Quando la macchina virtuale funziona con l'avvio protetto e vTPM è abilitato con l'estensione di attestazione guest installata, le misurazioni vTPM vengono inviate periodicamente ad Attestazione di Azure per il monitoraggio dell'integrità dell'avvio. Un errore di attestazione indica un potenziale malware, che viene mostrato ai clienti tramite gli avvisi e i consigli di Microsoft Defender per il cloud.

Attestazione TPM

L'attestazione basata su TPM (Trusted Platform Module) è fondamentale per fornire una prova dello stato di una piattaforma. Un TPM funge da radice di attendibilità e coprocessore di sicurezza per garantire la validità crittografica delle misurazioni (prova). I dispositivi dotati di TPM possono basarsi sull'attestazione per dimostrare che l'integrità dell'avvio non viene compromessa e rilevare l'abilitazione dello stato della funzionalità durante l'avvio.

Le applicazioni client possono essere progettate per sfruttare i vantaggi dell'attestazione TPM delegando attività sensibili in termini di sicurezza solo dopo che una piattaforma è stata convalidata come sicura. Tali applicazioni possono quindi usare Attestazione di Azure per stabilire periodicamente la relazione di trust nella piattaforma e la relativa capacità di accedere a dati sensibili.

Attestazione di enclavi SGX

Intel® Software Guard Extensions (SGX) fa riferimento all'isolamento di livello hardware, supportato in determinati modelli di CPU Intel. SGX consente l'esecuzione del codice in raggruppamenti purificati noti come enclavi SGX. Le autorizzazioni per l'accesso e la memoria vengono quindi gestite dall'hardware per garantire una superficie di attacco minima con isolamento appropriato.

Le applicazioni client possono essere progettate per sfruttare le enclavi SGX delegando le attività sensibili alla sicurezza da eseguire al loro interno. Tali applicazioni possono quindi usare Attestazione di Azure per stabilire periodicamente la relazione di trust nell'enclave e la relativa capacità di accedere a dati sensibili.

I processori Intel® Xeon® scalabili supportano solo soluzioni di attestazione basate su ECDSA per l'attestazione remota di enclavi SGX. Usando il modello di attestazione basato su ECDSA, Attestazione di Azure supporta la convalida dei processori Intel® Xeon® E3 e delle piattaforme server basate su processori Intel® Xeon® scalabili.

Nota

Per eseguire l'attestazione di piattaforme server basate su processori Intel® Xeon® scalabili con Attestazione di Azure, gli utenti devono installare Azure DCAP 1.10.0 o versioni successive.

Attestazione di enclavi aperti

Open Enclave (OE) è una raccolta di librerie destinate alla creazione di una singola astrazione unificata per enclavi che consente agli sviluppatori di creare applicazioni basate su TEE. Offre un modello di app sicuro universale che riduce al minimo le specifiche della piattaforma. Microsoft lo considera come un primo passo essenziale per la democratizzazione di tecnologie di enclave basate su hardware, ad esempio SGX, e l'aumento della loro diffusione in Azure.

OE standardizza i requisiti specifici per la verifica dell'evidenza di un'enclave. Per questo motivo, OE si qualifica come consumer di attestazione perfettamente idoneo per Attestazione di Azure.

Attestazione di Azure viene eseguita in un ambiente TEE

Attestazione di Azure è fondamentale per gli scenari di confidential computing ed esegue le azioni seguenti:

  • Verifica se l'evidenza dell'enclave è valida.
  • Valuta l'evidenza dell'enclave rispetto a criteri definiti dal cliente.
  • Gestisce e archivia criteri specifici del tenant.
  • Genera e firma un token usato dalle relying party per interagire con l'enclave.

Per garantire l'operatività di Microsoft al di fuori della TCB (Trusted Computing Base), le operazioni critiche di Attestazione di Azure, ad esempio la convalida delle offerte, la generazione di token, la valutazione dei criteri e la firma di token, vengono spostate in un enclave SGX.

Perché usare Attestazione di Azure

Attestazione di Azure rappresenta la scelta ideale per l'attestazione di ambienti TEE, perché offre i vantaggi seguenti:

  • Framework unificato per l'attestazione di più ambienti, ad esempio TPM ed enclavi SGX e VBS.
  • Consente la creazione di provider di attestazione personalizzati e la configurazione di criteri per limitare la generazione di token.
  • Protegge i dati durante l'uso con l'implementazione in un enclave SGX o in una macchina virtuale riservata basata su AMD SEV-SNP.
  • Servizi a disponibilità elevata

Come creare attendibilità con Attestazione di Azure

  1. Verificare se il token di attestazione viene generato da Attestazione di Azure - Il token di attestazione generato da Attestazione di Azure viene firmato usando un certificato autofirmato. L'URL dei certificati di firma viene esposto tramite un endpoint di metadati OpenID. La relying party può recuperare i certificati di firma ed eseguire la verifica della firma del token di attestazione. Vedere gli esempi di codice per altre informazioni
  2. Verificare se Attestazione di Azure è in esecuzione in un enclave SGX - I certificati di firma del token includono l'offerta SGX dell'ambiente TEE in cui viene eseguita Attestazione di Azure. Nel caso in cui la relying party preferisca verificare se Attestazione di Azure è in esecuzione in un enclave SGX valido, l'offerta SGX può essere recuperata dal certificato di firma e convalidata in locale. Vedere gli esempi di codice per altre informazioni
  3. Convalidare l'associazione dell'offerta SGX di Attestazione di Azure con la chiave che ha firmato il token di attestazione - La relying party può verificare se l'hash della chiave pubblica che ha firmato il token di attestazione corrisponde al campo dati del report dell'offerta SGX di Attestazione di Azure. Vedere gli esempi di codice per altre informazioni
  4. Verificare se le misurazioni del codice di Attestazione di Azure corrispondono ai valori pubblicati di Azure - L'offerta SGX incorporata nei certificati di firma del token di attestazione include misurazioni di codice di Attestazione di Azure, ad esempio MRSIGNER. Nel caso in cui la relying party voglia verificare se l'offerta SGX appartiene ad Attestazione di Azure in esecuzione in Azure, il valore MRSIGNER può essere recuperato dall'offerta SGX nel certificato di firma del token di attestazione e confrontato con il valore fornito dal team di Attestazione di Azure. Se si vuole eseguire questa convalida, inviare una richiesta nella pagina del supporto tecnico di Azure. Il team di Attestazione di Azure contatterà l'utente qualora vengano pianificate rotazioni di MRSIGNER.

Si prevede che mrsigner di Attestazione di Azure cambi con la rotazione dei certificati di firma del codice. Il team di Attestazione di Azure si attiene al seguente programma di implementazione per ogni rotazione di mrsigner:

i. Il team di Attestazione di Azure invia una notifica relativa al nuovo valore MRSIGNER con un periodo di tolleranza di due mesi per poter apportare modifiche al codice pertinenti

ii. Al termine del periodo di tolleranza di due mesi, Attestazione di Azure inizia a usare il nuovo valore MRSIGNER

iii. Tre mesi dopo la data di notifica, Attestazione di Azure cessa di usare il vecchio valore MRSIGNER

Supporto di continuità aziendale e ripristino di emergenza

Il servizio di continuità aziendale e ripristino di emergenza (BCDR) per Attestazione di Azure consente di ridurre le interruzioni dei servizi derivanti da problemi significativi di disponibilità o da eventi di emergenza in un'area.

I cluster distribuiti in due aree operano in modo indipendente in circostanze normali. Nel caso di errori o interruzioni in un'area, si verifica quanto segue:

  • Il BCDR di Attestazione di Azure fornisce un failover continuo in cui i clienti non devono eseguire altri interventi per il ripristino.
  • Il servizio Gestione traffico di Azure per l'area rileverà che il probe di integrità è danneggiato e sposterà l'endpoint in un'area abbinata.
  • Le connessioni esistenti non funzioneranno e riceveranno un errore interno del server o problemi di timeout.
  • Tutte le operazioni del piano di controllo verranno bloccate. I clienti non potranno creare provider di attestazioni nell'area primaria.
  • Tutte le operazioni del piano dati, incluse le chiamate di attestazione e la configurazione dei criteri, verranno gestite dall'area secondaria. I clienti possono continuare a lavorare alle operazioni del piano dati con l'URI originale corrispondente all'area primaria.

Passaggi successivi