Abilitare la replica in più aree nel modulo di protezione hardware gestito di Azure
La replica in più aree consente nell’estendere un pool di moduli di protezione hardware gestito da un'area di Azure (denominata primaria) a un'altra area di Azure (denominata secondaria). Una volta configurate, entrambe le aree sono attive, in grado di gestire le richieste e, con la replica automatizzata, condividere lo stesso materiale chiave, ruoli e autorizzazioni. L'area disponibile più vicina all'applicazione riceve e soddisfa la richiesta, ottimizzando così la velocità effettiva e latenza di lettura. Anche se le interruzioni a livello di area sono rare, la replica in più aree migliora la disponibilità di chiavi crittografiche cruciali in caso di mancata disponibilità di un'area. Per altre informazioni sul contratto di servizio, vedere Contratto di servizio per il modulo di protezione hardware gestito di Azure Key Vault.
Architettura
Quando la replica in più aree è abilitata in un modulo di protezione hardware gestito, viene creato un secondo pool di moduli di protezione hardware gestiti con tre partizioni del modulo di protezione hardware con bilanciamento del carico nell'area secondaria. Quando le richieste vengono inviate all'endpoint DNS globale di Gestione traffico <hsm-name>.managedhsm.azure.net, l'area disponibile più vicina riceve e soddisfa la richiesta. Sebbene ogni area mantenga singolarmente la disponibilità elevata a livello di area a causa della distribuzione di moduli di protezione hardware nell'area, la gestione traffico garantisce che anche se tutte le partizioni di un modulo di protezione hardware gestito in un'area non sono disponibili a causa di una catastrofe, le richieste possono comunque essere gestite dal pool di moduli di protezione hardware gestiti secondario.
Latenza di replica
Qualsiasi operazione di scrittura nel modulo di protezione hardware gestito, ad esempio la creazione o l'aggiornamento di una chiave, la creazione o l'aggiornamento di una definizione di ruolo o la creazione o l'aggiornamento di un'assegnazione di ruolo, possono richiedere fino a 6 minuti prima che entrambe le aree vengano replicate completamente. All'interno di questa finestra non è garantito che il materiale scritto sia stato replicato tra le aree. Pertanto, è consigliabile attendere sei minuti tra la creazione o l'aggiornamento della chiave e l'uso della chiave per assicurarsi che il materiale della chiave sia stato completamente replicato tra aree. Lo stesso vale per le assegnazioni di ruolo e le definizioni di ruolo.
Comportamento di failover
Il failover si verifica quando una delle aree in un modulo di protezione hardware gestito in più aree diventa non disponibile a causa di un'interruzione e l'altra area inizia a gestire tutte le richieste. L'interruzione può essere limitata solo al pool di moduli di protezione hardware, all'intero servizio del modulo di protezione hardware gestito o all'intera area di Azure. Durante il failover, è possibile notare una modifica del comportamento a seconda dell'area interessata.
| Area interessata | Letture consentite | Scritture consentite |
|---|---|---|
| Secondario | Sì | Sì |
| Primario | Sì | Forse |
Se l'area secondaria non è più disponibile, le operazioni di lettura (ottieni chiave, chiavi elenco, tutte le operazioni di crittografia, elencare le assegnazioni di ruolo) sono disponibili se l'area primaria è attiva. Sono disponibili anche operazioni di scrittura (creazione e aggiornamento delle chiavi, creazione e aggiornamento delle assegnazioni di ruolo, creazione e aggiornamento delle definizioni di ruolo).
Se l'area primaria non è disponibile, le operazioni di lettura sono disponibili, ma le operazioni di scrittura potrebbero non essere disponibili, a seconda dell'ambito dell'interruzione.
Tempo di failover
In background, la risoluzione DNS gestisce il reindirizzamento delle richieste all'area primaria o secondaria.
Se entrambe le aree sono attive, Gestione traffico risolve le richieste in ingresso nella posizione con la prossimità geografica più vicina o la latenza di rete più bassa all'origine della richiesta. I record DNS sono configurati con un TTL predefinito di 5 secondi.
Se un'area segnala uno stato non integro a Gestione traffico, le richieste future vengono risolte nell'altra area, se disponibile. I client che memorizzano nella cache le ricerche DNS possono riscontrare tempi di failover prolungati. Tuttavia, una volta scadute le cache sul lato client, le richieste future devono essere instradate all'area disponibile.
Supporto dell'area di Azure
Le aree seguenti sono supportate come aree primarie (aree da cui è possibile replicare un pool di moduli di protezione hardware gestiti)
- Stati Uniti orientali
- Stati Uniti orientali 2
- Stati Uniti settentrionali
- Europa occidentale
- Stati Uniti occidentali
- Canada orientale
- Qatar centrale
- Asia orientale
- Asia sudorientale
- Regno Unito meridionale
- Stati Uniti centrali
- Giappone orientale
- Svizzera settentrionale
- Brasile meridionale
- Australia centrale
- India centrale
- Stati Uniti occidentali 3
- Canada centrale
- Australia orientale
- India meridionale
- Svezia centrale
- Sudafrica settentrionale
- Corea centrale
- Europa settentrionale
- Francia centrale
- Giappone occidentale
- Stati Uniti centro-meridionali
- Polonia Centrale
- Svizzera occidentale
- Australia meridionale
- India occidentale
- Emirati Arabi Uniti centrali
- Emirati Arabi Uniti settentrionali
- Stati Uniti occidentali 2
- Stati Uniti centro-occidentali
Nota
Stati Uniti centrali, Stati Uniti orientali, Stati Uniti centro-meridionali, Stati Uniti occidentali 2, Svizzera settentrionale, Europa occidentale, India centrale, Canada centrale, Canada orientale, Giappone occidentale, Qatar centrale, Polonia centrale e Stati Uniti occidentali non possono essere estesi come area secondaria in questo momento. Altre aree potrebbero non essere disponibili per l'estensione a causa di limitazioni di capacità nell'area.
Fatturazione
La replica in più aree nell'area secondaria comporta una fatturazione aggiuntiva (x2), perché viene usato un nuovo pool di moduli di protezione hardware nell'area secondaria. Per altre informazioni, vedere Prezzi del modulo di protezione hardware gestito di Azure.
Comportamento della funzione di eliminazione temporanea
La funzionalità di eliminazione temporanea del modulo di protezione hardware gestito consente il ripristino di moduli di protezione hardware eliminati e chiavi, tuttavia in uno scenario abilitato per la replica in più aree, esistono piccole differenze in cui il modulo di protezione hardware secondario deve essere eliminato prima di poter eseguire l'eliminazione temporanea nel modulo di protezione hardware primario. Inoltre, quando un database secondario viene eliminato, viene eliminato immediatamente e non passa a uno stato di eliminazione temporanea che arresta tutta la fatturazione per il database secondario. È sempre possibile estendersi a una nuova area come secondaria dal database primario, se necessario.
Comportamento del collegamento privato con la replica in più aree
La funzionalità collegamento privato di Azure consente di accedere al servizio del modulo di protezione hardware gestito tramite un endpoint privato nella rete virtuale. È necessario configurare l'endpoint privato nel modulo di protezione hardware gestito nell'area primaria esattamente come quando non si usa la funzionalità di replica in più aree. Per il modulo di protezione hardware gestito nell'area secondaria, è consigliabile creare un altro endpoint privato dopo che il modulo di protezione hardware gestito nell'area primaria viene replicato nel modulo di protezione hardware gestito nell'area secondaria. In questo modo le richieste client verranno reindirizzate al modulo di protezione hardware gestito più vicino alla posizione client.
Di seguito alcuni scenari con esempi: modulo di protezione hardware gestito in un'area primaria (Regno Unito meridionale) e un altro modulo di protezione hardware gestito in un'area secondaria (Stati Uniti centro-occidentali).
Quando entrambi i moduli di protezione hardware gestiti nelle aree primarie e secondarie sono operativi con endpoint privato abilitato, le richieste client vengono reindirizzate al modulo di protezione hardware gestito più vicino alla posizione client. Le richieste client passano all'endpoint privato dell'area più vicina e quindi indirizzate al modulo di protezione hardware gestito della stessa area da Gestione traffico.
Quando uno dei moduli di protezione hardware gestiti (Regno Unito meridionale, ad esempio) in uno scenario replicato in più aree non è disponibile con gli endpoint privati abilitati, le richieste client vengono reindirizzate al modulo di protezione hardware gestito disponibile (Stati Uniti centro-occidentali). Le richieste dei clienti provenienti dal Regno Unito meridionale verranno prima indirizzate all'endpoint privato del Regno Unito meridionale e quindi indirizzate al modulo di protezione hardware gestito degli Stati Uniti centro-occidentali dal gestore del traffico.
Moduli di protezione hardware gestiti in aree primarie e secondarie, ma solo un endpoint privato configurato in primario o secondario. Per consentire a un client di una rete virtuale diversa (VNET1) di connettersi a un modulo di protezione hardware gestito tramite un endpoint privato in una rete virtuale diversa (VNET2), richiede il peering reti virtuali tra le due reti virtuali. È possibile aggiungere un collegamento di rete virtuale per la zona DNS privata creata durante la creazione dell'endpoint privato.
Nel diagramma seguente, l'endpoint privato viene creato solo nell'area Regno Unito meridionale, mentre sono presenti due moduli di protezione hardware gestiti in esecuzione uno nel Regno Unito meridionale e l'altro nell'area Stati Uniti centro-occidentali. Le richieste provenienti da entrambi i client passano al modulo di protezione hardware gestito dal Regno Unito meridionale perché le richieste vengono instradate tramite l'endpoint privato e la posizione dell'endpoint privato in questo caso si trova nel Regno Unito meridionale.
Nel diagramma seguente, l'endpoint privato viene creato solo nell'area Regno Unito meridionale, solo il modulo di protezione hardware gestito nell'area Stati Uniti centro-occidentali è disponibile e il modulo di protezione hardware gestito nel Regno Unito meridionale non è disponibile. In questo caso, le richieste verranno reindirizzate al modulo di protezione hardware gestito degli Stati Uniti centro-occidentali attraverso l'endpoint privato nel Regno Unito meridionale perché Gestione traffico rileva che il modulo di protezione hardware gestito dal Regno Unito meridionale non è disponibile.
Comandi dell'interfaccia della riga di comando di Azure
Se si crea un nuovo pool di moduli di protezione hardware gestiti e quindi si estende a un database secondario, vedere queste istruzioni prima di eseguire l'estensione. Se si estende da un pool di moduli di protezione hardware gestiti già esistente, usare le istruzioni seguenti per creare un modulo di protezione hardware secondario in un'altra area.
Nota
Questi comandi richiedono l'interfaccia della riga di comando di Azure versione 2.48.1 o successiva. Per installare la versione più recente, vedere Come installare l'interfaccia della riga di comando di Azure.
Aggiungere un modulo di protezione hardware secondario in un'altra area
Per estendere un pool di moduli di protezione hardware gestito a un'altra area, eseguire il comando seguente che creerà automaticamente un secondo modulo di protezione hardware.
az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"
Nota
"ContosoMHSM" in questo esempio è il nome del pool del modulo di protezione hardware primario; "australiaeast" è l'area secondaria in cui si sta estendendo.
Rimuovere un modulo di protezione hardware secondario in un'altra area
Dopo aver rimosso un modulo di protezione hardware secondario, le partizioni del modulo di protezione hardware nell'altra area verranno eliminate. Tutti i database secondari devono essere eliminati prima che un modulo di protezione hardware gestito primario possa essere eliminato temporaneamente o rimosso definitivamente. È possibile eliminare solo i database secondari usando questo comando. Il database primario può essere eliminato solo usando i comandi di eliminazione temporanea e di rimozione definitiva
az keyvault region remove --hsm-name ContosoMHSM --region australiaeast
Elencare tutte le regioni
az keyvault region list --hsm-name ContosoMHSM