Affidabilità nel modulo di protezione hardware gestito di Azure Key Vault

Il modulo di protezione hardware gestito di Azure Key Vault è un servizio cloud completamente gestito, a disponibilità elevata, a tenant singolo e conforme agli standard che consente di proteggere le chiavi crittografiche per le applicazioni cloud usando moduli di protezione hardware convalidati FIPS 140-3 di livello 3. Il modulo di protezione hardware gestito offre una gamma di funzionalità di affidabilità predefinite per garantire che le chiavi rimangano disponibili.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come il modulo di protezione hardware gestito sia resiliente a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, errori hardware e interruzioni dell'area. Descrive anche come usare i backup e il dominio di sicurezza per eseguire il ripristino da altri tipi di problemi, funzionalità di ripristino per impedire l'eliminazione accidentale ed evidenzia alcune informazioni chiave sul contratto di servizio del modulo di protezione hardware gestito.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Per i carichi di lavoro di produzione, è consigliabile:

  • Scaricare e archiviare in modo sicuro il dominio di sicurezza subito dopo il provisioning del modulo di protezione hardware gestito. Il dominio di sicurezza è necessario per il ripristino di emergenza.
  • Stabilire un quorum di più persone per il dominio di sicurezza con almeno tre titolari di chiave.
  • Abilitare la protezione dall'eliminazione per impedire l'eliminazione accidentale o dannosa.
  • Implementare backup regolari in un account di archiviazione di Azure e usare l'archiviazione con ridondanza geografica nelle aree supportate.
  • Per i carichi di lavoro cruciali che richiedono un contratto di servizio superiore, abilitare la replica in più aree.

Panoramica dell'architettura di affidabilità

Quando si utilizza un HSM gestito, si distribuisce un'istanza, che è anche chiamata pool.

Il Managed HSM è progettato per garantire alta disponibilità e durabilità tramite la sua architettura:

  • Isolamento a tenant singolo: ogni istanza del modulo di protezione hardware gestito è dedicata a un singolo cliente ed è costituita da un cluster di più partizioni HSM isolate dal punto di vista crittografico.

  • Partizioni con triplice ridondanza: un pool di moduli di protezione hardware gestito è costituito da tre partizioni HSM con carico bilanciato distribuite tra rack separati all'interno di un data center. Questa distribuzione offre ridondanza in caso di errori hardware e garantisce che la perdita di un singolo componente (ad esempio l'alimentatore o il commutatore di rete di un rack) non influisca su tutte le partizioni.

  • Confidential computing: ogni istanza del servizio viene eseguita in un ambiente di esecuzione attendibile (TEE) che usa enclave Intel SGX. Il personale Microsoft, inclusi quelli con accesso fisico ai server, non può accedere al materiale della chiave crittografica.

  • Correzione automatica: se un errore hardware o un altro problema influisce su una delle tre partizioni, il servizio ricompila automaticamente la partizione interessata sull'hardware integro senza alcun intervento del cliente e senza esporre segreti.

Per altre informazioni su come il modulo di protezione hardware gestito implementa queste funzionalità, vedere Sovranità, disponibilità, prestazioni e scalabilità delle chiavi nel modulo di protezione hardware gestito.

Dominio di sicurezza

Il dominio di sicurezza è un componente fondamentale per il ripristino di emergenza. Si tratta di un BLOB crittografato che contiene tutte le credenziali necessarie per ricompilare un'istanza del modulo di protezione hardware gestito da zero, tra cui 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.

Importante

Senza il dominio di sicurezza, il ripristino di emergenza non è possibile. Microsoft non è in grado di ripristinare il dominio di sicurezza e non può accedere alle chiavi senza di esso.

I domini di sicurezza sono una parte fondamentale della sicurezza e dell'affidabilità del modulo di protezione hardware gestito. È consigliabile seguire queste procedure consigliate:

  • Generare chiavi in modo sicuro: per gli ambienti di produzione, generare le coppie di chiavi RSA che proteggono il dominio di sicurezza in un ambiente con estensione air-gapped( ad esempio un modulo di protezione hardware locale o una workstation isolata).
  • Store offline: archiviare le chiavi di dominio di sicurezza nelle unità USB crittografate o in un'altra risorsa di archiviazione offline, con ogni condivisione chiave in un dispositivo separato in posizioni geografiche separate.
  • Stabilire un quorum di più persone: usare almeno tre titolari di chiavi per impedire a qualsiasi singola persona di avere accesso a tutte le chiavi quorum ed evitare una dipendenza da una singola persona.

Per altre informazioni, vedere Panoramica del dominio di sicurezza in HSM gestito.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Quando si usano i servizi di Azure che si integrano con il modulo di protezione hardware gestito, questi servizi gestiscono automaticamente gli errori temporanei.

Se si compilano applicazioni personalizzate che si integrano con HSM gestito, prendere in considerazione le procedure consigliate seguenti per gestire eventuali errori temporanei che potrebbero verificarsi:

  • Usare gli SDK forniti da Microsoft per Azure Key Vault, che includono meccanismi di ripetizione dei tentativi predefiniti. Gli SDK sono disponibili per .NET, Python e JavaScript.

  • Implementare la logica di ritentativo quando interagiscono direttamente con l'HSM gestito, inclusi i criteri di ritentativo con backoff esponenziale.

  • Ridurre il numero di dipendenze dirette su HSM gestito. Quando possibile, l'operazione di crittografia della cache consente di ridurre le richieste dirette al modulo di protezione hardware gestito. Per operazioni a chiave pubblica, ad esempio crittografia, wrapping e verifica, eseguire queste operazioni in locale memorizzando nella cache il materiale della chiave pubblica. L'esecuzione delle operazioni in locale riduce la dipendenza dal Managed HSM ed evita che errori temporanei possano interrompere queste operazioni.

Se utilizzi Managed HSM in scenari ad alto throughput, nota che Managed HSM non limita le operazioni di crittografia. Utilizza l'hardware del modulo di protezione hardware alla massima capacità. Ogni istanza del modulo di protezione hardware gestito ha tre partizioni. Durante le operazioni di manutenzione o riparazione, una partizione potrebbe non essere disponibile. Per la pianificazione della capacità, si supponga che siano disponibili due partizioni. Se è necessaria una velocità effettiva garantita, pianificare in base alla disponibilità di una partizione. Monitorare la metrica di disponibilità del Managed HSM per comprendere l'integrità del servizio.

Per ridimensionare la crittografia di grandi quantità di dati, usare una gerarchia di chiavi in cui solo la chiave di crittografia della chiave (KEK) viene archiviata in HSM gestito e usata per eseguire il wrapping delle chiavi di livello inferiore archiviate in un'altra posizione di archiviazione sicura delle chiavi.

Per indicazioni dettagliate sui benchmark delle prestazioni e sulla pianificazione della capacità, vedere Linee guida per il ridimensionamento del modulo di protezione hardware gestito di Azure.

Resilienza agli errori di partizione

Il modulo di protezione hardware gestito raggiunge la disponibilità elevata tramite l'architettura a triplice ridondanza, in cui ogni pool di moduli di protezione hardware è costituito da tre partizioni HSM distribuite tra rack server separati all'interno di un data center. Questa distribuzione a livello di rack fornisce ridondanza contro gli errori hardware localizzati.

Diagramma che mostra le tre partizioni di un pool di moduli di protezione hardware gestito, ognuna in un server fisico separato e in un rack server diverso.

Diagramma che mostra le tre partizioni di un pool di moduli di protezione hardware gestito, ognuna in un server fisico separato e in un rack server diverso.

Quando si verificano errori hardware o interruzioni localizzate, il modulo di protezione hardware gestito reindirizza automaticamente le richieste a partizioni integre e ricompila le partizioni interessate tramite un processo denominato correzione del servizio riservato. Le partizioni non riuscite vengono ricompilate automaticamente su hardware integro usando enclave TLS e Intel SGX attestati per proteggere i segreti durante il ripristino.

Cost

Non sono previsti costi aggiuntivi associati alla disponibilità elevata predefinita in HSM gestito. I prezzi si basano sul numero di pool di moduli di protezione hardware e sul numero di operazioni eseguite. Per altre informazioni, vedere prezzi di Azure Managed HSM.

Comportamento quando tutte le partizioni sono integre

Questa sezione descrive cosa aspettarsi quando i pool di moduli di protezione hardware gestiti sono operativi e non sono disponibili partizioni.

  • Routing del traffico: Il Managed HSM gestisce automaticamente il routing del traffico tra le sue tre partizioni. Durante le normali operazioni, le richieste vengono distribuite in modo trasparente tra partizioni.

  • Replica dei dati: tutti i dati, incluse chiavi, assegnazioni di ruolo e criteri di controllo di accesso, vengono replicati in modo sincrono in tutte e tre le partizioni. Ciò garantisce coerenza e disponibilità anche se una partizione non è più disponibile.

Comportamento durante un errore di partizione

Questa sezione descrive cosa aspettarsi quando una o più partizioni non sono più disponibili.

  • Rilevamento e risposta: il servizio HSM gestito è responsabile del rilevamento degli errori di partizione e della risposta automatica. Non è necessario eseguire alcuna azione durante un errore di partizione.

  • Richieste attive: durante un errore di partizione, le richieste in transito verso la partizione interessata potrebbero fallire e richiedere nuovi tentativi da parte delle applicazioni client. Per ridurre al minimo gli effetti delle interruzioni delle partizioni, le applicazioni client devono seguire le procedure di gestione degli errori temporanei.

  • Perdita di dati prevista: non è prevista alcuna perdita di dati durante un errore di partizione a causa della replica sincrona tra partizioni.

  • Tempo di inattività previsto: per le operazioni di lettura e la maggior parte delle operazioni di crittografia, è necessario che non siano previsti tempi di inattività minimi durante un errore di partizione. Le rimanenti partizioni integre continuano a gestire le richieste.

  • Reindirizzamento del traffico: il modulo di protezione hardware gestito reindirizza automaticamente il traffico dalla partizione interessata a partizioni integre senza richiedere alcun intervento del cliente.

Ripristino della partizione

Quando la partizione interessata viene ripristinata, Managed HSM ripristina automaticamente le operazioni attraverso la riparazione confidenziale del servizio. Questo processo:

  1. Crea una nuova istanza del servizio su hardware integro.
  2. Stabilisce una connessione TLS attestata con la partizione primaria.
  3. Scambia in modo sicuro le credenziali e il materiale crittografico.
  4. Sigilla i dati di servizio nella nuova CPU.

La piattaforma Azure gestisce completamente questo processo e non richiede alcun intervento del cliente.

Resilienza ai guasti delle zone di disponibilità

La disponibilità elevata del modulo di protezione hardware gestito si basa sulla distribuzione a livello di rack all'interno di un data center, non sulla distribuzione esplicita della zona di disponibilità. Ogni partizione viene eseguita in un server separato in un rack diverso, che protegge da errori a livello di rack, ad esempio alimentazione o commutatore di rete.

Se è necessario essere resilienti alle interruzioni a livello di data center o di disponibilità a livello di area, è consigliabile usare uno degli approcci per la resilienza agli errori a livello di area.

Resilienza agli errori a livello di area

Le risorse del modulo di protezione hardware gestito vengono distribuite in una singola area di Azure. Se l'area diventa non disponibile, anche il tuo HSM gestito non è disponibile. Esistono tuttavia approcci che è possibile usare per garantire la resilienza alle interruzioni dell'area.

Replica in più aree

Il modulo di protezione hardware gestito supporta la replica facoltativa in più aree, che consente di estendere un pool di moduli di protezione hardware gestito da un'area di Azure ( l'area primaria) a una seconda area di Azure (l'area estesa). Dopo aver configurato:

  • Entrambe le aree sono attive e in grado di gestire le richieste.
  • Il materiale chiave, i ruoli e le autorizzazioni vengono replicati automaticamente tra aree.
  • Le richieste vengono instradate all'area disponibile più vicina tramite Gestione traffico di Azure.
  • L'SLA combinato aumenta.

Requirements

  • Supporto per le aree: tutte le aree del modulo di protezione hardware gestito di Azure sono supportate come aree primarie. Non esiste alcuna dipendenza dalle associazioni di aree di Azure.

    HSM gestito non supporta tutte le regioni come regioni estese. Per altre informazioni, vedere Supporto per aree di Azure.

  • Numero massimo di aree: È possibile aggiungere un'area estesa per un massimo di due aree in totale.

Cost

La replica in più aree comporta una fatturazione aggiuntiva perché un secondo pool di moduli di protezione hardware viene utilizzato nell'area estesa. Per altre informazioni, vedere prezzi di Azure Managed HSM.

Configurare la replica in più aree

  • Aggiungere un'area estesa: Per informazioni dettagliate sull'aggiunta di un'area estesa a un'area primaria esistente, vedere Estendere un modulo di protezione hardware primario in un'area estesa.

    L'estensione di un modulo di protezione hardware gestito a un'altra area potrebbe richiedere fino a 30 minuti.

  • Rimuovere un'area estesa: Per informazioni dettagliate sulla rimozione di un'area estesa da un'area primaria esistente, vedere Rimuovere un'area estesa dal modulo di protezione hardware primario.

Comportamento quando tutte le aree sono integre

Quando la replica in più aree è abilitata ed entrambe le aree sono operative:

  • Routing del traffico: tutte le aree possono gestire le richieste. Gestione traffico di Azure instrada le richieste all'area con la prossimità geografica più vicina o la latenza più bassa.

    Se si usa il collegamento privato, configurare gli endpoint privati in entrambe le regioni per un routing ottimale durante il failover. Per altre informazioni, vedere Comportamento dei collegamenti privati con la replica in più aree.

  • Replica dei dati: tutte le modifiche apportate a chiavi, definizioni di ruolo e assegnazioni di ruolo vengono replicate in modo asincrono nell'area estesa entro sei minuti. Attendere sei minuti dopo aver creato o aggiornato una chiave prima di usarla nell'area estesa.

Comportamento durante un errore di area

Quando la replica in più aree è abilitata e si verifica un'interruzione di un'area:

  • Rilevamento e risposta: Gestione traffico di Azure rileva l'area non integra e instrada le richieste future all'area integra. I record DNS hanno una durata TTL di cinque secondi, anche se i client che memorizzano nella cache le ricerche DNS potrebbero riscontrare tempi di failover leggermente più lunghi.
  • Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli eventuali errori dell'area e configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.
  • Richieste attive: Le richieste in corso nell'area interessata potrebbero fallire e richiedere un nuovo tentativo.

  • Perdita di dati prevista: potrebbe verificarsi una perdita di dati per le modifiche apportate entro sei minuti prima dell'errore dell'area se tali modifiche non sono state completate.

  • Tempo di inattività previsto: Le operazioni di lettura e scrittura rimangono disponibili nella regione funzionante durante il failover.

    Le applicazioni client vicine all'area non integra potrebbero continuare a essere indirizzate a tale area fino a quando i record DNS non vengono aggiornati, ma questo aggiornamento avviene entro circa cinque secondi. Per ridurre al minimo il tempo di failover, i client devono evitare la memorizzazione nella cache delle ricerche DNS per più tempo rispetto al TTL del record DNS.

  • Reindirizzamento: Azure Traffic Manager reindirizza automaticamente le richieste alla regione operativa.

Ripristino della regione

Quando l'area interessata viene ripristinata, il modulo di protezione hardware gestito riprende automaticamente le operazioni. Il Traffic Manager avvia nuovamente l'instradamento delle richieste a entrambe le regioni in base alla prossimità.

Testare gli errori dell'area

HSM gestito gestisce completamente il routing del traffico, il failover e il failback per i guasti regionali, quindi non è necessario convalidare i processi di guasto regionale o fornire ulteriori input.

Soluzioni personalizzate in più aree per la resilienza

Se la replica in più aree non è adatta alle proprie esigenze, è possibile implementare il ripristino di emergenza manuale. Tale approccio richiede:

  • Il dominio di sicurezza dell'HSM di origine.
  • Chiavi private (almeno il numero di quorum) che crittografano il dominio di sicurezza.
  • Backup completo recente del modulo di protezione hardware dal modulo di protezione hardware di origine.

Per eseguire il ripristino di emergenza:

  1. Creare una nuova istanza di Managed HSM in un'area diversa.
  2. Attivare la modalità di ripristino del dominio di sicurezza e caricare il dominio di sicurezza.
  3. Eseguire un backup del nuovo modulo di protezione hardware (necessario prima del ripristino).
  4. Ripristinare il backup dal modulo di protezione hardware di origine.

Importante

Il nuovo HSM ha un nome diverso e un URI endpoint del servizio. È necessario aggiornare la configurazione dell'applicazione per usare il nuovo percorso.

Per procedure dettagliate di ripristino di emergenza, vedere Ripristino di emergenza del modulo di protezione hardware gestito.

Backup e ripristino

HSM gestito supporta il backup completo e il ripristino di tutte le chiavi, versioni, attributi, tag e assegnazioni di ruolo. I backup vengono archiviati in un account di archiviazione di Azure. Se l'area lo supporta, è consigliabile eseguire il backup del modulo di protezione hardware gestito in un account di archiviazione di Azure con GRS abilitato.

I backup vengono crittografati usando chiavi crittografiche associate al dominio di sicurezza del modulo di protezione hardware e possono essere ripristinati solo in un modulo di protezione hardware con lo stesso dominio di sicurezza.

Il modulo di protezione hardware gestito non supporta la pianificazione dei backup, ma è possibile creare un'utilità di pianificazione personalizzata usando un servizio come Funzioni di Azure o Automazione di Azure.

Mentre è in corso un backup, il modulo di protezione hardware potrebbe non funzionare a velocità effettiva completa perché alcune partizioni sono occupate nell'esecuzione dell'operazione di backup.

Per procedure dettagliate di backup e ripristino, vedere Backup completo e ripristino.

Resilienza all'eliminazione accidentale

Il modulo di protezione hardware gestito offre due funzionalità di ripristino chiave per impedire l'eliminazione accidentale o dannosa:

  • Eliminazione temporanea: quando si elimina un modulo di protezione hardware o una chiave, rimane recuperabile per un periodo di conservazione configurabile (da 7 a 90 giorni, predefinito 90 giorni). L'eliminazione temporanea è sempre abilitata e non può essere disabilitata.

    Note

    Le risorse del modulo di sicurezza hardware gestito che sono state eliminate temporaneamente continuano a essere fatturate fino a quando non vengono definitivamente rimosse.

  • Protezione contro l'eliminazione: quando abilitata, impedisce che il tuo HSM gestito e le sue chiavi vengano eliminati permanentemente fino alla fine del periodo di conservazione. La protezione dall'eliminazione non può essere disabilitata o sottoposta a override da nessuno, incluso Microsoft.

È consigliabile abilitare la protezione dall'eliminazione per gli ambienti di produzione. Per altre informazioni, vedere Eliminazione temporanea e eliminazione temporanea del modulo di protezione hardware gestito.

Resilienza alla manutenzione del servizio

Il modulo di protezione hardware gestito gestisce la manutenzione del servizio, inclusi gli aggiornamenti del firmware, l'applicazione di patch e la riparazione hardware, senza l'intervento del cliente. Durante la manutenzione:

  • Le partizioni potrebbero non essere temporaneamente disponibili durante l'applicazione degli aggiornamenti.
  • Almeno due di tre partizioni rimangono disponibili durante la manutenzione di routine.
  • Le applicazioni client devono implementare la logica di ripetizione dei tentativi per gestire brevi interruzioni.

Il processo di risanamento del servizio confidenziale garantisce che i segreti non sono mai esposti durante le operazioni di manutenzione.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere Accordi sul livello di servizio (SLA) per i servizi online.

Il modulo di protezione hardware gestito fornisce un contratto di servizio standard per le distribuzioni a singola area. Quando si abilita la replica in più aree, aumenta il contratto di servizio combinato per entrambe le aree.