Sovranità, disponibilità, prestazioni e scalabilità della chiave nel modulo di protezione hardware gestito

Articolo
04/10/2024

Le chiavi crittografiche sono la radice dell'attendibilità per la protezione dei sistemi informatici moderni, sia in locale che nel cloud. Pertanto, il controllo degli utenti con autorità su tali chiavi è fondamentale per la creazione di applicazioni sicure e conformi.

In Azure, la visione di come deve essere eseguita la gestione delle chiavi nel cloud ha il nome di sovranità della chiave. Per sovranità della chiave si intende che l'organizzazione di un cliente ha il controllo completo ed esclusivo su chi può accedere alle chiavi e modificare i criteri di gestione delle chiavi e sui servizi di Azure che usano tali chiavi. Una volta che il cliente ha preso queste decisioni, al personale Microsoft viene impedito, tramite mezzi tecnici, di modificare queste decisioni. Il codice del servizio di gestione delle chiavi esegue le decisioni del cliente fino a quando il cliente non comunica di fare diversamente e il personale Microsoft non può intervenire.

Allo stesso tempo, è nostra convinzione che ogni servizio nel cloud debba essere completamente gestito. Il servizio deve fornire le promesse fondamentali necessarie per la disponibilità, la resilienza, la sicurezza e il cloud, supportate dai contratti di servizio. Per distribuire un servizio gestito, Microsoft deve applicare patch ai server di gestione delle chiavi, aggiornare il firmware del modulo di protezione hardware (HSM), correggere gli errori hardware, eseguire il failover e altre operazioni con privilegi elevati. Come la maggior parte dei professionisti della sicurezza sa, negare a qualcuno con privilegi elevati o accesso fisico a un accesso di sistema ai dati all'interno di tale sistema è un problema difficile.

L’articolo illustra come è stato risolto questo problema nel servizio modulo di protezione hardware gestito di Azure Key Vault, offrendo ai clienti la sovranità completa e i contratti di servizio completamente gestiti usando la tecnologia di confidential computing abbinata ai moduli di protezione hardware.

Ambiente hardware del modulo di protezione hardware gestito

Il pool di moduli di protezione hardware gestiti di un cliente in qualsiasi area di Azure si trova in un data center Azure sicuro. Tre istanze vengono distribuite su più server. Ogni istanza viene distribuita in un rack diverso per garantire la ridondanza. Ogni server dispone di un adattatore per il modulo di protezione hardware Marvell LiquidSecurity convalidato FIPS 140-2 Livello 3 con più core crittografici. I core vengono usati per creare partizioni del modulo di protezione hardware completamente isolate, incluse credenziali completamente isolate, archiviazione dei dati e controllo di accesso.

La separazione fisica delle istanze all'interno del data center è fondamentale per garantire che la perdita di un singolo componente (ad esempio, il commutatore top-of-rack o un'unità di risparmio energetico in un rack) non possa influire su tutte le istanze di un pool. Questi server sono dedicati al team del modulo di protezione hardware di sicurezza di Azure. I server non vengono condivisi con altri team di Azure e non vengono distribuiti carichi di lavoro dei clienti su questi server. I controlli di accesso fisico, inclusi i rack bloccati, vengono usati per impedire l'accesso non autorizzato ai server. Questi controlli soddisfano FedRAMP-High, PCI, SOC 1/2/3, ISO 270x e altri standard di sicurezza e privacy e vengono regolarmente verificati in modo indipendente come parte del programma di conformità di Azure. I moduli di protezione hardware sono dotati di una sicurezza fisica avanzata, convalidata per soddisfare i requisiti FIPS 140-2 Livello 3. L'intero servizio del modulo di protezione hardware gestito è basato sulla piattaforma Azure sicura standard, tra cui avvio attendibile, che protegge da minacce persistenti avanzate.

Gli adattatori del modulo di protezione hardware possono supportare decine di partizioni del modulo di protezione hardware isolate. L'esecuzione su ogni server è un processo di controllo denominato Node Service. Il Node Service acquisisce la proprietà di ogni adattatore e installa le credenziali per il proprietario dell'adattatore, in questo caso Microsoft. Il modulo di protezione hardware è progettato in modo che la proprietà dell'adattatore non fornisca a Microsoft l'accesso ai dati archiviati nelle partizioni dei clienti. Consente solo a Microsoft di creare, ridimensionare ed eliminare le partizioni dei clienti. Supporta l'esecuzione di backup nascosti di qualsiasi partizione per il cliente. In un backup nascosto, il backup viene sottoposto a wrapping da una chiave fornita dal cliente che può essere ripristinata dal codice del servizio solo all'interno di un'istanza gestita del modulo di protezione hardware di proprietà del cliente e il cui contenuto non è leggibile da Microsoft.

Architettura di un pool di moduli di protezione hardware gestiti

La figura 1 mostra l'architettura di un pool di moduli di protezione hardware, costituita da tre macchine virtuali Linux, ognuna in esecuzione su un server HSM nel proprio rack del data center per supportare la disponibilità. I componenti importanti sono:

Il controller di infrastruttura del modulo di protezione hardware (HFC) è il piano di controllo per il servizio. Il HFC esegue l'applicazione automatica delle patch e le riparazioni per il pool.
Limite crittografico conforme a FIPS 140-2 Livello 3, esclusivo per ogni cliente, inclusi tre enclave riservati Intel Secure Guard Extensions (Intel SGX), ognuno connesso a un'istanza del modulo di protezione hardware. Le chiavi radice per questo limite vengono generate e archiviate nei tre moduli di protezione hardware. Come descritto più avanti in questo articolo, nessun utente associato a Microsoft ha accesso ai dati entro questo limite. Ha accesso solo il codice del servizio in esecuzione nell'enclave Intel SGX (incluso l'agente del Node Service), che agisce per conto del cliente.

Diagram of a Managed HSM pool that shows TEEs inside a customer cryptographic boundary and health maintenance operations outside the boundary.

Ambiente di esecuzione attendibile (TEE)

Un pool di moduli di protezione hardware gestiti è costituito da tre istanze del servizio. Ogni istanza del servizio viene implementata come ambiente di esecuzione attendibile (TEE) che usa funzionalità Intel SGX e Open Enclave SDK. L'esecuzione all'interno di un ambiente di esecuzione attendibile di Azure garantisce che nessun utente nella macchina virtuale (VM) che ospita il servizio o il server host della macchina virtuale abbia accesso a segreti, dati o partizione del modulo di protezione hardware. Ogni ambiente di esecuzione attendibile è dedicato a un cliente specifico ed esegue la gestione TLS, la gestione delle richieste e il controllo di accesso alla partizione del modulo di protezione hardware. Nessuna credenziale o chiavi di crittografia dei dati specifiche del cliente è presente in testo non crittografato all'esterno di questo ambiente di esecuzione attendibile, tranne che come parte del pacchetto del dominio di sicurezza. Tale pacchetto viene crittografato in una chiave fornita dal cliente e viene scaricato al momento della creazione del pool.

Gli ambienti di esecuzione attendibile comunicano tra loro usando l’archiviazione thread-local attestata. L’archiviazione thread-local attestata combina le funzionalità di attestazione remota della piattaforma Intel SGX con TLS 1.2. In questo modo, il codice del modulo di protezione hardware gestito nell'ambiente di protezione dei dati limita la comunicazione solo ad altro codice firmato dalla stessa chiave di firma del codice del servizio del modulo di protezione hardware gestito, per evitare attacchi man-in-the-middle. La chiave di firma del codice del servizio del modulo di protezione hardware gestito viene archiviato nel servizio di sicurezza e rilascio dei prodotti Microsoft (che viene usato anche per archiviare, ad esempio, la chiave di firma del codice di Windows). La chiave è controllata dal team del modulo di protezione hardware gestito. Come parte degli obblighi normativi e di conformità per la gestione delle modifiche, questa chiave non può essere usata da altri team Microsoft per la firma del codice.

I certificati TLS usati per la comunicazione da TEE a TEE vengono rilasciati automaticamente dal codice del servizio all'interno dell'ambiente di esecuzione attendibile. I certificati contengono un report della piattaforma generato dall'enclave Intel SGX sul server. Il report della piattaforma è firmato con chiavi derivate da chiavi fuse da Intel nella CPU quando viene prodotta. Il report identifica il codice caricato nell'enclave Intel SGX tramite la chiave di firma del codice e l'hash binario. Da questo report della piattaforma, le istanze del servizio possono determinare che un peer è firmato anche dalla chiave di firma del codice del servizio HSM gestito e, con alcuni entanglement di crittografia tramite il report della piattaforma, può anche determinare che la chiave di firma del certificato autocertificata deve essere stata generata anche all'interno dell'ambiente di esecuzione attendibile, per impedire la rappresentazione esterna.

Offrire contratti di servizio di disponibilità con controllo completo della chiave gestita dal cliente

Per garantire la disponibilità elevata, il servizio HFC crea tre pool nell'area di Azure selezionata dal cliente.

Creazione del pool di moduli di protezione hardware gestiti

Le proprietà a disponibilità elevata dei pool di moduli di protezione hardware gestiti provengono dalle istanze del modulo di protezione hardware gestite e con triplo ridondanza sempre sincronizzate (o, se si usa replica in più aree, dal mantenere sincronizzate tutte e sei le istanze). La creazione del pool viene gestita dal servizio HFC, che alloca i pool nell'hardware disponibile nell'area di Azure scelta dal cliente.

Quando viene richiesto un nuovo pool, il cluster HFC seleziona tre server in più rack con spazio disponibile sulle schede HSM e quindi inizia a creare il pool:

HFC indica agli agenti del servizio Node in ognuno dei tre ambienti di esecuzione attendibili di avviare una nuova istanza del codice del servizio usando un set di parametri. I parametri identificano il tenant Microsoft Entra del cliente, gli indirizzi IP della rete virtuale interna di tutte e tre le istanze e altre configurazioni del servizio. Una partizione viene assegnata in modo casuale come primaria.
Si avviano le tre istanze. Ogni istanza si connette a una partizione nella scheda HSM locale e quindi azzera e inizializza la partizione usando nomi utente e credenziali generati in modo casuale (per assicurarsi che la partizione non possa essere accessibile da un operatore umano o da un'altra istanza dell’ambiente di esecuzione attendibile).
L'istanza primaria crea un certificato radice del proprietario della partizione usando la chiave privata generata nel modulo di protezione hardware. Stabilisce la proprietà del pool firmando un certificato a livello di partizione per la partizione HSM usando questo certificato radice. Il database primario genera anche una chiave di crittografia dei dati, usata per proteggere tutti i dati dei clienti inattivi all'interno del servizio. Per il materiale della chiave, viene usato un doppio wrapping perché il modulo di protezione hardware protegge anche il materiale della chiave stesso.
I dati di proprietà vengono quindi sincronizzati con le due istanze secondarie. Ogni secondaria contatta il database primario usando TLS attestato. Il database primario condivide il certificato radice del proprietario della partizione con la chiave privata e la chiave di crittografia dei dati. I database secondari usano ora il certificato radice della partizione per rilasciare un certificato di partizione alle proprie partizioni del modulo di protezione hardware. Al termine, sono presenti partizioni del modulo di protezione hardware in tre server separati di proprietà dello stesso certificato radice della partizione.
Tramite il collegamento TLS attestato, la partizione del modulo di protezione hardware primario condivide con le repliche secondarie la chiave di wrapping dei dati generata (usata per crittografare i messaggi tra i tre moduli di protezione hardware) usando un'API sicura fornita dal fornitore del modulo di protezione hardware. Durante questo scambio, i moduli di protezione hardware confermano che hanno lo stesso certificato del proprietario della partizione e quindi usano uno schema Diffie-Hellman per crittografare i messaggi in modo che il codice del servizio Microsoft non possa leggerli. Tutto ciò che il codice del servizio può fare è il trasporto di BLOB opachi tra i moduli di protezione hardware.

A questo punto, tutte e tre le istanze sono pronte per essere esposte come pool nella rete virtuale del cliente. Condividono lo stesso certificato del proprietario della partizione e la stessa chiave privata, la stessa chiave di crittografia dei dati e una chiave di wrapping dei dati comune. Tuttavia, ogni istanza ha credenziali univoche per le partizioni del modulo di protezione hardware. I passaggi finali sono stati completati.
Ogni istanza genera una coppia di chiavi RSA e una richiesta di firma del certificato (CSR) per il certificato TLS pubblico. La richiesta CSR è firmata dal sistema PKI (Public Key Infrastructure) Microsoft usando una radice pubblica Microsoft e il certificato TLS risultante viene restituito all'istanza.
Tutte e tre le istanze ottengono la chiave di tenuta Intel SGX dalla CPU locale. La chiave viene generata usando la propria chiave univoca della CPU e la chiave di firma del codice dell’ambiente di esecuzione attendibile.
Il pool deriva una chiave del pool univoca dalle chiavi di chiusura Intel SGX, crittografa tutti i segreti usando questa chiave del pool e quindi scrive i BLOB crittografati su disco. Questi BLOB possono essere decrittografati solo tramite la firma del codice dalla stessa chiave di tenuta Intel SGX in esecuzione nella stessa CPU fisica. I segreti sono associati a tale istanza specifica.

Il processo di bootstrap sicuro è stato completato. Questo processo ha consentito sia la creazione di un pool di moduli di protezione hardware con triplo ridondanza sia la creazione di una garanzia crittografica della sovranità dei dati dei clienti.

Gestione dei contratti di servizio di disponibilità in fase di esecuzione tramite la correzione del servizio riservato

La storia di creazione del pool descritta in questo articolo può spiegare in che modo il servizio del modulo di protezione hardware gestito è in grado di offrire contratti di servizio a disponibilità elevata gestendo in modo sicuro i server sottostanti il servizio. Si supponga che un server, un adattatore del modulo di protezione hardware o persino l'alimentatore nel rack, non riesca. L'obiettivo del servizio del modulo di protezione hardware gestito è, senza alcun intervento del cliente o la possibilità di esporre segreti in testo non crittografato all'esterno dell'ambiente di esecuzione attendibile, per ripristinare il pool a tre istanze integre. Questo risultato viene ottenuto tramite la riparazione del servizio riservato.

Inizia con HFC che rileva i pool con istanze nel server non riuscito. HFC trova nuovi server integri all'interno dell'area del pool in cui distribuire le istanze di sostituzione. Avvia nuove istanze, che vengono quindi considerate esattamente come secondarie durante il passaggio di provisioning iniziale: inizializza il modulo di protezione hardware, trova i segreti primari, scambia i segreti in modo sicuro tramite TLS attestato, firma il modulo di protezione hardware nella gerarchia di proprietà e quindi chiude i dati del servizio alla nuova CPU. Il servizio è ora risanato, completamente automaticamente e completamente riservato.

Ripristino da un'emergenza tramite il dominio di sicurezza

Il dominio di sicurezza è un BLOB protetto che contiene tutte le credenziali necessarie per ricompilare la partizione del modulo di protezione hardware da zero: la chiave del proprietario della partizione, le credenziali della partizione, la chiave di wrapping dei dati e un backup iniziale del modulo di protezione hardware. Prima che il servizio diventi attivo, il cliente deve scaricare il dominio di sicurezza fornendo un set di chiavi di crittografia RSA per proteggerlo. I dati del dominio di sicurezza hanno origine negli ambienti di esecuzione attendibili e sono protetti da una chiave simmetrica generata e da un'implementazione dell'algoritmo di condivisione dei segreti di Shamir, che suddivide le condivisioni chiave tra le chiavi pubbliche RSA fornite dal cliente in base ai parametri quorum selezionati dal cliente. Durante questo processo, nessuna delle chiavi del servizio o delle credenziali viene mai esposta in testo non crittografato all'esterno del codice del servizio in esecuzione negli ambienti di esecuzione attendibili. Solo il cliente, presentando un quorum delle chiavi RSA all'ambiente di esecuzione attendibile, può decrittografare il dominio di sicurezza durante uno scenario di ripristino.

Il dominio di sicurezza è necessario solo quando, a causa di una catastrofe, un'intera area di Azure viene persa e Microsoft perde tutte e tre le istanze del pool contemporaneamente. Se una sola istanza, o anche due istanze, vengono perse, la riparazione del servizio riservato verrà ripristinata in modo silenzioso in tre istanze integre senza alcun intervento del cliente. Se l'intera area viene persa, perché le chiavi di tenuta Intel SGX sono univoche per ogni CPU, Microsoft non ha modo di recuperare le credenziali del modulo di protezione hardware e le chiavi del proprietario della partizione. Esistono solo all'interno del contesto delle istanze.

Nel caso estremamente improbabile che si verifichi questa catastrofe, il cliente può recuperare lo stato e i dati del pool precedenti creando un nuovo pool vuoto, inserendolo nel dominio di sicurezza e quindi presentando il quorum della chiave RSA per dimostrare la proprietà del dominio di sicurezza. Se un cliente ha abilitato la replica in più aree, la catastrofe ancora più improbabile di entrambe le aree che riscontrano un errore simultaneo dovrebbe verificarsi prima dell'intervento del cliente per ripristinare il pool dal dominio di sicurezza.

Controllo dell'accesso al servizio

Come descritto, il codice del servizio nell'ambiente di esecuzione attendibile è l'unica entità che ha accesso al modulo di protezione hardware stesso perché le credenziali necessarie non vengono fornite al cliente o a nessun altro utente. Al contrario, il pool del cliente è associato all'istanza di Microsoft Entra e viene usato per l'autenticazione e l'autorizzazione. Al provisioning iniziale, il cliente può scegliere un set iniziale di dipendenti per assegnare il ruolo di amministratore per il pool. Questi utenti e i dipendenti nel ruolo amministratore globale del tenant di Microsoft Entra del cliente possono impostare i criteri di controllo di accesso all'interno del pool. Tutti i criteri di controllo di accesso vengono archiviati dal servizio nello stesso database delle chiavi mascherate, che vengono anche crittografati. Solo il codice del servizio nell'ambiente del di esecuzione attendibile ha accesso a questi criteri di controllo di accesso.

Riepilogo

Il modulo di protezione hardware gestito elimina la necessità che i clienti facciano compromessi tra disponibilità e controllo sulle chiavi crittografiche usando una tecnologia di enclave riservata e basata su hardware all'avanguardia. Come descritto in questo articolo, in questa implementazione, nessun dipendente o rappresentante Microsoft può accedere al materiale della chiave gestita dal cliente o ai segreti correlati, anche con accesso fisico ai computer host del modulo di protezione hardware gestito e ai moduli di protezione hardware. Questa sicurezza ha permesso ai clienti di servizi finanziari, produzione, settore pubblico, difesa e altri verticali di accelerare le migrazioni al cloud con piena fiducia.