Questo articolo risponde ad alcune delle domande più comuni sull'attestazione di Microsoft Azure.
Se il problema di Azure non viene risolto in questo articolo, è anche possibile inviare una richiesta di supporto ad Azure nella pagina del supporto tecnico di Azure.
Che cos'è Trusted Hardware Identity Management (THIM) e il relativo ruolo nell'attestazione dell'enclave
Trusted Hardware Identity Management (THIM) recupera la baseline di sicurezza di Azure per i nodi di Azure Confidential Computing (ACC) da Intel e memorizza nella cache i dati. Le informazioni memorizzate nella cache verranno poi usate dall'attestazione di Azure nella convalida degli ambienti di esecuzione attendibili (Trusted Execution Environments, TEE).
THIM è consigliato per i seguenti motivi:
- Offre disponibilità elevata
- Riduce le dipendenze nei servizi ospitati esternamente e nella connettività Internet.
- Recupera periodicamente le versioni più recenti di certificati Intel, CRL, informazioni TCB (Trusted Computing Base) e l'identità dell'enclave tra virgolette dei nodi ACC di Intel. Il servizio conferma quindi che la baseline di sicurezza di Azure come riferimento dell'attestazione di Azure durante la convalida degli ambienti TEE, riducendo notevolmente gli errori di attestazione dovuti all'invalidamento o alla revoca dei certificati Intel
Attestazione SGX supportata da attestazione di Azure in ambienti non Azure
Nr. L'attestazione di Azure dipende dalla baseline di sicurezza indicata da Trusted Hardware Identity Management (THIM) per convalidare gli ambienti TEE. Il servizio THIM è attualmente progettato per supportare solo nodi di Confidential computing di Azure.
Quali convalide attestazione di Azure eseguire per l'attestazione di enclave SGX
Durante il processo di attestazione SGX, attestazione di Azure esegue le convalide seguenti:
- Convalida se la radice attendibile dell'offerta di enclave firmata appartiene a Intel
- Convalida se l'offerta T edizione Enterprise soddisfa la baseline di sicurezza di Azure come definito da Trusted Hardware Identity Management (THIM)
- Se il cliente ha creato un provider di attestazione e ha configurato un criterio personalizzato, oltre alle convalide precedenti, attestazione di Azure valuta l'offerta T edizione Enterprise rispetto ai criteri di attestazione. Usando i criteri di attestazione, i clienti possono definire regole di autorizzazione per il T edizione Enterprise e dettare anche le regole di rilascio per generare il token di attestazione
Come un verificatore può ottenere la garanzia per l'attestazione SGX supportata da attestazione di Azure
In generale, per i modelli di attestazione con Intel come radice di attendibilità, il client dell'attestazione parla con le API dell'enclave per recuperare la prova dell'enclave. Le API dell'enclave chiamano internamente il servizio di memorizzazione nella cache Intel PCK per recuperare i certificati Intel del nodo da attestare. I certificati vengono usati per firmare la prova dell'enclave generando in tal modo documentazione e materiale aggiuntivo attestabili da remoto.
Lo stesso processo può essere implementato per l'attestazione di Azure. Tuttavia, per sfruttare i vantaggi offerti da Trusted Hardware Identity Management (THIM), dopo l'installazione della macchina virtuale di Confidential computing di Azure, è consigliabile installare la libreria DCAP di Azure. In base all'accordo con Intel, quando viene installata la libreria DCAP di Azure, le richieste per la generazione di prove dell'enclave vengono reindirizzate dal servizio di memorizzazione nella cache Intel PCK a THIM. La libreria DCAP di Azure è supportata negli ambienti che si basano su Windows e Linux.
Come passare a attestazione di Azure da altri modelli di attestazione SGX
- Dopo aver installato la macchina virtuale Confidential computing di Azure, installare la libreria DCAP di Azure (Windows/Linux) per sfruttare i vantaggi offerti da Trusted Hardware Identity Management (THIM).
- È necessario creare un client di attestazione remoto che possa recuperare la prova dell'enclave e inviare richieste all'attestazione di Azure. Per i riferimenti, vedere gli esempi di codice
- Le richieste di attestazione possono essere inviate all'endpoint dell'API REST di provider predefiniti o di provider di attestazione personalizzati
- Nella versione dell'API 2018-09-01-preview , il client deve inviare il token di accesso di Microsoft Entra insieme all'evidenza all'endpoint dell'API di attestazione SGX. Il token di accesso Microsoft Entra non è un parametro obbligatorio per eseguire l'attestazione SGX nella versione dell'API 2020-10-01
Come può la relying party verificare l'integrità del token di attestazione e verificare che attestazione di Azure sia in esecuzione all'interno di un enclave
Il token di attestazione generato dall'attestazione di Azure viene firmato usando un certificato autofirmato. I certificati di firma vengono esposti mediante un endpoint di metadati OpenID. La relying party può recuperare i certificati di firma da questo endpoint ed eseguire la verifica della firma del token di attestazione. Il certificato di firma include anche l'offerta SGX del T edizione Enterprise all'interno della quale viene eseguita attestazione di Azure. Se la relying party preferisce anche verificare se attestazione di Azure è in esecuzione all'interno di un enclave SGX valido, l'offerta SGX può essere recuperata dal certificato di firma e convalidata localmente. Per altre informazioni, vedere esempi di codice
Quanto tempo è valido un token di attestazione?
Il tempo di validità del token di attestazione è di 8 ore. Attualmente non è disponibile alcun provisioning per personalizzare il valore.
Come identificare il certificato da usare per la verifica della firma dall'endpoint dei metadati OpenID
I certificati multipli esposti nell'endpoint dei metadati OpenID corrispondono a casi d'uso diversi (ad esempio, l'attestazione SGX) supportati dall'attestazione di Azure. In base agli standard specificati da RFC 7515, il certificato con ID chiave (kid) corrispondente al parametro kid nell'intestazione del token di attestazione deve essere usato per la verifica della firma. Se non viene trovato alcun valore di kid corrispondente, si provano tutti i certificati esposti dall'endpoint dei metadati OpenID.
È possibile che la relying party convida i segreti con gli ambienti di esecuzione attendibili convalidati (T edizione Enterprise)
Al momento della creazione di prove T edizione Enterprise, il codice in esecuzione all'interno del T edizione Enterprise può includere informazioni arbitrarie nell'evidenza. Ad esempio, il T edizione Enterprise può creare una o più coppie di chiavi asimmetriche, serializzare i componenti di chiave pubblica di queste coppie di chiavi come stringa JSON JWKS e includere la stringa JSON JWKS nella T edizione Enterprise evidenza come citazione RunTimeData { citazione, stringa JSON JWKS }. attestazione di Azure controlla se l'hash SHA256 di RuntimeData corrisponde ai 32 byte inferiori dell'attributo "dati del report" dell'offerta. Dopo aver valutato l'evidenza T edizione Enterprise, attestazione di Azure genera JWT con JWKS disponibile come attestazione denominata "keys" nell'attestazione "x-ms-runtime". RunTimeData può essere usato ulteriormente dalla relying party per stabilire un canale sicuro e trasmettere in modo sicuro i dati al T edizione Enterprise.
Dove attestazione di Azure archivia i dati dei clienti?
attestazione di Azure archivia i dati dei clienti inattivi, durante l'elaborazione e la replica per scopi BCDR all'interno dell'area geografica in cui il cliente distribuisce l'istanza del servizio.