Eseguire la migrazione dei carichi di lavoro dalle chiavi esterne per la gestione delle chiavi esterne di Managed HSM (anteprima)

Importante

La gestione esterna delle chiavi di Managed HSM è in anteprima. Le funzionalità di anteprima vengono rese disponibili all'utente in base alla condizione che si accettano le condizioni supplementari per l'utilizzo. Alcuni aspetti di questa funzionalità potrebbero cambiare prima della disponibilità generale.

Questo articolo descrive come passare un carico di lavoro di Azure da una chiave esterna nella gestione delle chiavi esterne di Managed HSM a una chiave di Managed HSM (o a una chiave esterna diversa). È destinato agli operatori del modulo di protezione hardware gestito che pianificano o eseguono questo tipo di transizione.

La migrazione delle chiavi non è supportata — la migrazione del carico di lavoro sì

Nella gestione delle chiavi esterne, lo stato di una chiave come chiave esterna o come chiave HSM gestita non è modificabile per progettazione: una volta creato un riferimento alla chiave in entrambe le modalità, tale modalità è fissa per la durata di tale chiave. La gestione delle chiavi esterne blocca le transizioni in entrambe le direzioni dell'API. Di conseguenza:

  • Non è possibile convertire una chiave esterna esistente in una chiave del modulo di protezione hardware gestito.
  • Non è possibile convertire una chiave HSM gestita esistente in una chiave esterna.
  • Non è possibile trasferire materiale crittografico tra due diversi HSM esterni tramite Managed HSM. Il trasferimento di materiale di chiavi tra HSM è un'operazione del fornitore dell'HSM che avviene al di fuori di Azure.

Questa decisione di progettazione è stata adottata per prevenire violazioni accidentali delle policy: se l'URI della stessa chiave potesse fare riferimento, in un dato momento, a materiale di chiave esterno e, in un altro, a materiale di chiave di HSM gestito, i clienti e i revisori non potrebbero più stabilire dove una determinata chiave sia stata archiviata nel tempo. Rendendo immutabile questa distinzione per ciascuna chiave, la gestione esterna delle chiavi mantiene un quadro univoco relativo a criteri e conformità per uno specifico URI di chiave per tutto il suo ciclo di vita.

Al contrario, si esegue la migrazione del carico di lavoro a una nuova chiave. Questo è lo stesso schema che Azure Key Vault usa per qualsiasi transizione delle chiavi tra confini. Per informazioni generali, vedere Eseguire la migrazione dei carichi di lavoro chiave. Il resto di questo articolo applica tale modello alla gestione delle chiavi esterne.

Importante

L'URI chiave della chiave di origine non viene preservato. La chiave di destinazione ha un nuovo URI della chiave e ogni servizio Azure che ha utilizzato la chiave precedente deve essere riconfigurato per usare il nuovo URI della chiave. Pianificare di conseguenza.

Quando eseguire la migrazione di un carico di lavoro da una chiave esterna

Motivi comuni per passare un carico di lavoro da una chiave esterna a una chiave HSM gestita:

  • Stai dismettendo il tuo HSM esterno o ponendo fine a una partnership esterna per la gestione delle chiavi.
  • Un requisito normativo o sovranità che originariamente imponeva il controllo fisico della chiave al di fuori dell'infrastruttura Microsoft non si applica più.
  • Hai bisogno di una latenza inferiore o vuoi che le tue chiavi siano coperte dallo SLA di Managed HSM.
  • Sono necessarie operazioni di crittografia che la gestione delle chiavi esterne non supporta, ad esempio, , signverifyencrypt, decrypt, Secure Key Release (SKR) o scenari di avvio di VM riservate( CVM).

È anche possibile usare lo stesso modello di migrazione del carico di lavoro per passare da una chiave esterna a un'altra, ad esempio quando si modificano i fornitori del modulo di protezione hardware. La procedura è identica, ad eccezione del fatto che la chiave di destinazione è un altro riferimento di chiave esterna anziché una chiave HSM gestita.

Pianificare la migrazione

Completa i seguenti passaggi di preparazione prima di avviare il cutover.

Identificare tutti i consumer downstream. Controllare i log di diagnostica di Monitoraggio di Azure per verificare la presenza di attività recenti wrapKey e unwrapKey rispetto alla chiave di origine. Ogni servizio Azure che usa questa chiave per la crittografia dei dati archiviati costituisce una dipendenza per la migrazione. Coordinare con i proprietari del servizio: ogni servizio deve essere riconfigurato in modo che punti al nuovo URI della chiave e i passaggi di riconfigurazione siano specifici del servizio.

Verificare l'algoritmo e la compatibilità delle dimensioni delle chiavi. La chiave di destinazione deve usare un algoritmo supportato dal servizio di Azure di utilizzo. Se si passa da una chiave RSA esterna a una chiave RSA HSM gestita, mantenere la stessa lunghezza del bit per evitare differenze di comportamento nel servizio di utilizzo. Le chiavi esterne AES-256 (oct, 256) corrispondono alle chiavi AES-256 di HSM gestito.

Mantenere la chiave di origine per l'accesso al backup. Non eliminare o disabilitare la chiave esterna sorgente durante il cutover. I backup e le snapshot meno recenti dei dati del servizio consumer sono ancora crittografati con chiavi di crittografia dei dati (DEK) incapsulate dalla chiave di origine. Finché tali backup non escono dal periodo di conservazione o non vengono nuovamente crittografati con la nuova chiave, la chiave sorgente deve rimanere accessibile per la decrittografia.

Procedura di migrazione

Seguire questa sequenza per eseguire la migrazione di un carico di lavoro da una chiave di origine a una chiave di destinazione. La stessa sequenza si applica se la destinazione è una chiave del modulo di protezione hardware gestito o un'altra chiave esterna.

  1. Creare la chiave di destinazione. Crea una nuova chiave nel tuo HSM gestito. Per informazioni dettagliate sulla creazione di chiavi, vedere Ciclo di vita della chiave esterna in Gestione chiavi esterne del modulo di protezione hardware gestito:

    Prendere nota del nuovo URI della chiave: configurare i servizi di Azure downstream per l'uso di questo URI.

  2. Concedere al carico di lavoro l'accesso alla chiave di destinazione. Assegnare l'identità gestita del servizio Azure che usa la risorsa al ruolo RBAC locale di HSM gestito appropriato (in genere Managed HSM Crypto User o un ruolo equivalente specifico del servizio). Per i passaggi per l'assegnazione dei ruoli, vedi Controllo di accesso di HSM gestito.

  3. Riconfigurare ogni servizio Azure downstream per usare la chiave di destinazione. Questo passaggio è specifico del servizio; seguire la documentazione per ogni servizio che utilizza la chiave di origine. Ad esempio, vedere i passaggi di riconfigurazione Archiviazione di Azure cmk. La maggior parte dei servizi Azure che supportano le chiavi gestite dal cliente (CMK) crittografano automaticamente nuovamente i DEK attivi con la nuova chiave poco dopo il completamento della riconfigurazione.

  4. Verificare che la nuova chiave sia in uso. Verificare nel pannello del portale del servizio di uso o nell'interfaccia della riga di comando che il nuovo URI della chiave sia ora il CMK attivo. Controllare i log di diagnostica di Monitoraggio di Azure per l'attività di wrapKey e unwrapKey relativa al nuovo URI della chiave. Eseguire una scrittura/lettura di test sul carico di lavoro protetto per verificare che la crittografia funzioni end-to-end.

  5. Mantenere la chiave di origine per l'accesso al backup. Mantenere attiva la chiave esterna di origine e mantenere operativo il proxy EKM e il modulo di protezione hardware esterno, purché sia necessario eseguire il ripristino dai backup eseguiti durante l'attivazione della chiave di origine. La chiave sorgente non viene usata per le nuove operazioni di wrapping dopo il cutover, ma è ancora necessaria per eseguire l'unwrapping dei DEK storici durante un ripristino.

  6. Rimuovere la chiave di origine quando nessun dato protetto dipende da esso. Quando tutti i backup crittografati con la chiave di origine hanno superato il periodo di conservazione previsto (o sono stati ricrittografati con la chiave di destinazione), è possibile dismettere la chiave di origine. Vedi Dismettere la chiave esterna di origine.

Verificare la chiave di destinazione

Prima di disattivare l'origine, verificare che la chiave di destinazione funzioni senza problemi:

  1. Verificare nel servizio di utilizzo Azure che il nuovo URI della chiave sia la chiave gestita dal cliente attivo.
  2. Verificare nei log di diagnostica di Monitoraggio di Azure che l'attività di wrapKey e unwrapKey si sia spostata nel nuovo URI della chiave e che non vengano registrati errori.
  3. Eseguire un test di scrittura/lettura o un test di crittografia specifico del servizio ( ad esempio, scrivere un nuovo BLOB in un account di archiviazione protetto con chiave gestita da cmk, quindi leggerlo di nuovo) e verificare che abbia esito positivo.
  4. Verificare che le letture cronologiche, incluse le letture dai dati scritti prima del cutover, abbiano esito positivo. La maggior parte dei servizi esegue nuovamente il wrapping dei DEK in background dopo una modifica della CMK (chiave gestita dal cliente), ma la chiave di origine potrebbe comunque essere usata transitoriamente fino al completamento dell’operazione.

Se uno di questi controlli ha esito negativo, la chiave di origine rimane intatta. È possibile eseguire di nuovo il rollback del servizio di uso riconfigurandolo in modo che punti nuovamente all'URI della chiave di origine.

Dismettere la chiave esterna di origine

Avvertimento

La rimozione della chiave esterna di origine è irreversibile. Qualsiasi dato ancora crittografato con una DEK protetta dalla chiave di origine, e non ancora ricrittografato con la chiave di destinazione, diventa definitivamente irrecuperabile una volta che la chiave di origine non è più disponibile. Verificare che nessun backup, snapshot o replica dipendano dalla chiave di origine prima di procedere.

Disattivare la chiave sorgente solo dopo aver confermato:

  • La chiave di destinazione è pienamente operativa su tutti i consumer.
  • Tutti i backup, gli snapshot e le repliche hanno superato la finestra di conservazione o sono stati crittografati nuovamente nella chiave di destinazione.
  • Nessuna operazione di wrapping o unwrapping attiva o in sospeso fa riferimento alla chiave di origine (verificarlo esaminando i log di diagnostica di Monitoraggio di Azure per l'URI della chiave di origine nell'arco di un intervallo rappresentativo).

Per rimuovere le autorizzazioni:

  1. Eliminare, e facoltativamente rimuovere definitivamente, il riferimento della chiave HSM gestita per la chiave esterna di origine usando az keyvault key delete e az keyvault key purge.
  2. Eliminare il materiale della chiave crittografica nell'HSM esterno usando gli strumenti del fornitore dell'HSM.

Elementi non supportati

  • Il tipo di chiave non è modificabile. La gestione delle chiavi esterne blocca le transizioni tra chiavi HSM esterne e gestite in entrambe le direzioni dell'API. Non esiste alcuna conversione sul posto in entrambe le direzioni. Entrambe le transizioni richiedono la migrazione del carico di lavoro a una nuova chiave.
  • Esportazione della chiave. Azure Key Vault e Managed HSM non consentono l'esportazione del materiale delle chiavi. Non esiste alcun percorso per estrarre una chiave esterna (o una chiave del modulo di protezione hardware gestito) e importarla altrove.
  • Trasferimento del materiale della chiave tra HSM tramite HSM gestito. Lo spostamento del materiale delle chiavi tra due HSM esterni diversi è un'operazione del fornitore dell'HSM che avviene al di fuori di Azure. L'HSM gestito non è coinvolto.
  • Migrazione multi-area di una chiave esterna per la gestione delle chiavi. La migrazione delle chiavi tra aree geografiche segue le pratiche standard di Managed HSM tra aree geografiche e non è specifica della gestione delle chiavi esterne. Vedere Eseguire la migrazione dei carichi di lavoro chiave.