Condividi tramite

Configurare le chiavi gestite dal cliente per l'account Azure Cosmos DB esistente con Azure Key Vault

SI APPLICA A: NoSQL MongoDB Gremlin Tabella

L'abilitazione di un secondo livello di crittografia per i dati inattivi tramite chiavi gestite dal cliente durante la creazione di un nuovo account Azure Cosmos DB è disponibile a livello generale per un certo periodo di tempo. Come passaggio successivo naturale, è ora possibile abilitare la chiave gestita dal cliente negli account Azure Cosmos DB esistenti.

Questa funzionalità elimina la necessità di eseguire la migrazione dei dati a un nuovo account per abilitare la chiave gestita dal cliente. Consente di migliorare il comportamento di sicurezza e conformità dei clienti.

L'abilitazione della chiave gestita dal cliente avvia un processo asincrono in background per crittografare tutti i dati esistenti nell'account, mentre i nuovi dati in ingresso vengono crittografati prima della persistenza. Non è necessario attendere che l'operazione asincrona abbia esito positivo. Il processo di abilitazione usa UR inutilizzate/di riserva in modo che non influisca sui carichi di lavoro di lettura/scrittura. È possibile fare riferimento a questo collegamento per la pianificazione della capacità dopo la crittografia dell'account.

Per iniziare, abilita CMK sui tuoi account esistenti.

Importante

Esaminare attentamente la sezione dei prerequisiti. Questi prerequisiti sono considerazioni importanti.

Prerequisiti

Tutti i passaggi preliminari necessari durante la configurazione delle chiavi gestite dal cliente (CMK) per i nuovi account si applicano anche per abilitare le CMK nel tuo account esistente. Fare riferimento ai passaggi qui

Nota

È importante notare che l'abilitazione della crittografia nell'account Azure Cosmos DB comporta un piccolo sovraccarico per l'ID del documento, limitando le dimensioni massime dell'ID documento a 990 byte invece di 1.024 byte. Se l'account contiene documenti con ID superiori a 990 byte, il processo di crittografia non riesce fino a quando tali documenti non vengono eliminati.

Per verificare se l'account è conforme, è possibile usare l'applicazione console fornita ospitata qui per analizzare l'account. Assicurarsi di usare l'endpoint dalla proprietà dell'account "sqlEndpoint", indipendentemente dall'API selezionata.

Se si vuole disabilitare la convalida lato server per questa operazione durante la migrazione, contattare il supporto tecnico.

Istruzioni per abilitare CMK nell'account esistente

Per abilitare la chiave gestita dal cliente in un account esistente, aggiornare l'account con un modello di Resource Manager impostando un ID chiave di Key Vault nella proprietà keyVaultKeyUri, proprio come si farebbe quando si abilita la chiave gestita dal cliente in un nuovo account. Questo passaggio può essere eseguito eseguendo una chiamata PATCH con il payload seguente:

    {
        "properties": {
        "keyVaultKeyUri": "<key-vault-key-uri>"
        }
    }

L'output di questo comando dell'interfaccia della riga di comando per abilitare la chiave gestita dal cliente attende il completamento della crittografia dei dati.

    az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"

Procedura per abilitare la chiave gestita dal cliente nell'account Azure Cosmos DB esistente con backup continuo o account dell'archivio analitico

Per abilitare cmk nell'account esistente con backup continuo e ripristino temporizzato abilitato, è necessario seguire alcuni passaggi aggiuntivi. Segui i passaggi dal passaggio 1 al passaggio 5 e poi segui le istruzioni per abilitare CMK sull'account esistente.

  1. Configurare l'identità gestita per l'account Cosmos DB Configurare le identità gestite con Microsoft Entra ID per il tuo account Azure Cosmos DB

  2. Aggiornare l'account Cosmos per impostare l'identità predefinita in modo che punti all'identità gestita aggiunta nel passaggio precedente

    Per Identità gestita dal sistema:

    az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"

    Per Identità gestita dall'utente:

    az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"

  3. Configurare KeyVault come descritto nella documentazione qui

  4. Aggiungere criterio di accesso nel keyvault per l'identità predefinita impostata nel passaggio precedente

  5. Aggiornare l'account di Cosmos DB per impostare l'URI dell'insieme di credenziali delle chiavi. Questo aggiornamento attiva l'abilitazione della chiave gestita dal cliente nell'account 

    az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI 

Limitazioni note

  • L'abilitazione della chiave gestita dal cliente negli account di Azure Cosmos DB for Apache Cassandra non è supportata.
  • L'abilitazione della chiave gestita dal cliente è disponibile solo a livello di account di Cosmos DB e non a livello di raccolte.
  • Assicurarsi che l'account non abbia documenti con ID di grandi dimensioni superiori a 990 byte prima di abilitare la chiave gestita dal cliente. In caso contrario, si riceverà un errore a causa del limite massimo supportato di 1.024 byte dopo la crittografia.
  • Durante la crittografia dei dati esistenti, le azioni del piano di controllo come "aggiungi area" vengono bloccate. Queste azioni vengono sbloccate e possono essere usate subito dopo il completamento della crittografia.
  • L'abilitazione di CMK per gli account Azure Cosmos DB esistenti con Ricerca vettoriale abilitata non è supportata.

Monitorare lo stato di avanzamento della crittografia risultante

L'abilitazione della CMK su un account esistente è un'operazione asincrona che avvia un processo in background che crittografa tutti i dati esistenti. Di conseguenza, la richiesta all'API REST per abilitare la CMK fornisce nella sua risposta un URL "Azure-AsyncOperation". Il polling di questo URL con richieste GET restituisce lo stato dell'operazione complessiva, che alla fine ha esito positivo. Questo meccanismo è descritto in modo completo in questo articolo.

L'account Cosmos DB può continuare a essere usato e i dati possono continuare a essere scritti senza attendere che l'operazione asincrona abbia esito positivo. Il comando CLI per abilitare CMK attende il completamento della crittografia dei dati.

Per consentire a un account di Cosmos DB esistente di usare la chiave gestita dal cliente, è necessario eseguire un'analisi per assicurarsi che l'account non abbia "ID di grandi dimensioni". Un "ID di grandi dimensioni" è un ID documento con lunghezza superiore a 990 caratteri. Questa analisi è obbligatoria per la migrazione CMK e viene eseguita automaticamente da Microsoft. Durante questo processo, è possibile che venga visualizzato un errore.

ERRORE: (InternalServerError) Errore imprevisto durante l'analisi dei documenti per la migrazione della chiave gestita dal cliente. Ripetere l'operazione.

Questo errore si verifica quando il processo di analisi usa più unità richiesta (UR) rispetto a quelle di cui è stato effettuato il provisioning nella raccolta, generando un errore 429. Una soluzione per questo problema consiste nell'aumentare temporaneamente le unità richiesta in modo significativo. In alternativa, è possibile usare l'applicazione console fornita ospitata qui per analizzare le raccolte.

Nota

Se si vuole disabilitare la convalida lato server per questa operazione durante la migrazione, contattare il supporto tecnico. La disabilitazione della convalida è consigliabile solo se si è certi che non siano presenti ID di grandi dimensioni. Se durante la crittografia viene rilevato un ID di grandi dimensioni, il processo si arresta fino a quando non viene risolto il problema relativo all'ID documento di grandi dimensioni.

Per altre domande, contattare supporto tecnico Microsoft.

Domande frequenti

Quali sono i fattori da cui dipende il tempo di crittografia?

L'abilitazione della CMK è un'operazione asincrona e dipende dalla disponibilità di sufficienti UR inutilizzate. È consigliabile abilitare la chiave gestita dal cliente durante le ore di minore attività e, se applicabile, è possibile aumentare le unità richiesta in precedenza, per velocizzare la crittografia. È anche una funzione diretta delle dimensioni dei dati.

Dobbiamo prepararci per un periodo di inattività?

L'abilitazione della chiave gestita dal cliente avvia un processo asincrono in background per crittografare tutti i dati. Non è necessario attendere che l'operazione asincrona abbia esito positivo. L'account Azure Cosmos DB è disponibile per le operazioni di lettura e scrittura e non è necessario un tempo di inattività.

È possibile aumentare le unità richiesta dopo l'attivazione della chiave gestita dal cliente?

È consigliabile aumentare le unità richiesta prima di attivare la chiave gestita dal cliente. Dopo l'attivazione della chiave gestita dal cliente, alcune operazioni del piano di controllo vengono bloccate fino al completamento della crittografia. Questo blocco può impedire all'utente di aumentare le RUs una volta attivato il CMK.

Per consentire a un account di Cosmos DB esistente di usare la chiave gestita dal cliente, un'analisi di ID di grandi dimensioni viene eseguita automaticamente da Microsoft per risolvere una delle limitazioni note elencate in precedenza. Questo processo usa anche UR aggiuntive ed è consigliabile aumentare significativamente le UR per evitare l'errore 429.

È possibile annullare la crittografia o disabilitarla dopo l'attivazione della chiave di crittografia gestita dal cliente (CMK)?

Una volta attivato il processo di crittografia dei dati tramite cmk, non può essere ripristinato.

L'abilitazione della crittografia tramite cmk nell'account esistente avrà un impatto sulle dimensioni dei dati e sulle operazioni di lettura/scrittura?

Come ci si aspetta, abilitando cmk c'è un lieve aumento delle dimensioni dei dati e delle UR per supportare l'elaborazione aggiuntiva di crittografia/decrittografia.

Dovresti eseguire il backup dei dati prima di abilitare la CMK?

L'abilitazione della chiave gestita dal cliente non comporta alcuna minaccia di perdita di dati.

I backup precedenti vengono eseguiti come parte di backup periodici crittografati?

No. I backup periodici precedenti non vengono crittografati. I backup appena generati dopo l'abilitazione della chiave gestita dal cliente sono crittografati.

Qual è il comportamento degli account esistenti abilitati per il backup continuo?

Quando cmk è attivato, la crittografia viene attivata anche per i backup continui. Dopo l'attivazione della chiave gestita dal cliente, tutti gli account ripristinati in futuro saranno abilitati per la chiave gestita dal cliente.

Qual è il comportamento se CMK è abilitato su un account con PITR attivato e ripristiniamo l'account al momento in cui CMK era disabilitato?

In questo caso, CMK è abilitato in modo esplicito nell'account di destinazione ripristinato per i motivi seguenti.

  • Una volta abilitato CMK nell'account, non è possibile disabilitare CMK.
  • Questo comportamento è allineato alla progettazione corrente del ripristino dell'account abilitato per la chiave gestita dal cliente con backup periodico

Cosa accade quando l'utente revoca la chiave mentre è in corso la migrazione della chiave cmk?

Lo stato della chiave viene controllato quando viene attivata la crittografia cmk. Se la chiave nell'Azure Key Vault è in regola, la crittografia viene avviata e il processo viene completato senza ulteriori verifiche. Anche se la chiave viene revocata o l'insieme di credenziali delle chiavi di Azure viene eliminato o non disponibile, il processo di crittografia ha esito positivo.

È possibile abilitare la crittografia cmk nell'account di produzione esistente?

Sì. Esaminare attentamente la sezione dei prerequisiti. È consigliabile testare prima tutti gli scenari sugli account non di produzione e, una volta che si è a proprio agio, è possibile prendere in considerazione gli account di produzione.

Come si esegue la migrazione di un account Azure Cosmos DB a un tenant diverso?

Se l'account Cosmos DB ha abilitato le Customer Managed Keys, è possibile eseguire la migrazione dell'account solo se si tratta di un account di chiave gestita dal cliente tra tenant. Per altre informazioni, vedere la guida sulla configurazione di chiavi gestite dal cliente tra tenant per l'account Azure Cosmos DB con Azure Key Vault.

Avvertimento

Dopo la migrazione, è fondamentale mantenere l'account di Azure Cosmos DB e Azure Key Vault in tenant separati per mantenere la relazione originale tra i tenant. Assicurarsi che la chiave del Key Vault rimanga in posizione fino al completamento della migrazione dell'account Cosmos DB.

Passaggi successivi

  • Last updated on