Condividi tramite

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

  • Articolo

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, abilitare la chiave gestita dal cliente per gli account esistenti

Importante

Esaminare attentamente la sezione dei prerequisiti. Si tratta di considerazioni importanti.

Prerequisiti

Tutti i passaggi preliminari necessari durante la configurazione delle chiavi gestite dal cliente per i nuovi account sono applicabili per abilitare la chiave gestita dal cliente nell'account esistente. Fare riferimento ai passaggi qui

Nota

È importante notare che l'abilitazione della crittografia nell'account Azure Cosmos DB comporterà un piccolo sovraccarico per l'ID del documento, limitando le dimensioni massime dell'ID documento a 990 byte invece di 1024 byte. Se nell'account sono presenti documenti con ID superiori a 990 byte, il processo di crittografia avrà esito negativo finché tali documenti non verranno 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.

Passaggi per abilitare la chiave gestita dal cliente nell'account esistente

Per abilitare cmk in un account esistente, aggiornare l'account con un modello di Resource Manager impostando un identificatore di chiave dell'insieme di credenziali delle chiavi nella proprietà keyVaultKeyUri, proprio come quando si abilita CMK 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 cmk 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. Seguire il passaggio 1 al passaggio 5 e quindi seguire le istruzioni per abilitare la chiave gestita dal cliente nell'account esistente.

  1. Configurare l'identità gestita per l'account Cosmos Configurare le identità gestite con l'ID Microsoft Entra per l'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 l'insieme di credenziali delle chiavi come indicato nella documentazione qui

  4. Aggiungere i criteri di accesso nell'insieme di credenziali delle chiavi per l'identità predefinita impostata nel passaggio precedente

  5. Aggiornare l'account cosmos 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

  • Non è supportata l'abilitazione di CMK in account Azure Cosmos DB per Apache Cassandra esistenti.
  • L'abilitazione della chiave gestita dal cliente è disponibile solo a livello di account Cosmos DB e non a raccolte.
  • Non è supportata l'abilitazione di CMK per gli account esistenti abilitati per le visualizzazioni materializzate e per tutte le versioni ed elimina la modalità feed di modifiche.
  • Assicurarsi che l'account non disponga di 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 1024 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.

Monitorare lo stato di avanzamento della crittografia risultante

L'abilitazione della chiave gestita dal cliente su un account esistente è un'operazione asincrona che avvia un'attività in background che crittografa tutti i dati esistenti. Di conseguenza, la richiesta dell'API REST per abilitare la chiave gestita dal cliente fornisce nella risposta un URL "Azure-AsyncOperation". Il polling di questo URL con le richieste GET restituisce lo stato dell'operazione complessiva, che alla fine ha avuto 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 dell'interfaccia della riga di comando per abilitare cmk attende il completamento della crittografia dei dati.

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

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

Ciò si verifica quando il processo di analisi usa più UR rispetto a quelle di cui è stato effettuato il provisioning nella raccolta, generando un errore 429. Una soluzione per questo problema consiste nell'urtare temporaneamente le UR 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. Questo è consigliabile solo se si è certi che non ci siano ID di grandi dimensioni. Se durante la crittografia viene rilevato un ID di grandi dimensioni, il processo si arresterà fino a quando non viene risolto il 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 chiave gestita dal cliente è un'operazione asincrona e dipende dalla disponibilità di UR inutilizzate sufficienti. È consigliabile abilitare cmk durante le ore di minore attività e, se applicabile, è possibile aumentare le UR prima della mano, per velocizzare la crittografia. È anche una funzione diretta delle dimensioni dei dati.

Dobbiamo metterci tra parentesi per tempi 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 UR dopo l'attivazione della chiave gestita dal cliente?

È consigliabile attivare le UR 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 UR dopo l'attivazione della chiave gestita dal cliente.

Per consentire a un account 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 invertire la crittografia o disabilitare la crittografia dopo l'attivazione della chiave gestita dal cliente?

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.

È necessario eseguire il backup dei dati prima di abilitare la chiave gestita dal cliente?

L'abilitazione della chiave gestita dal cliente non comporta alcuna minaccia per la 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 nell'account abilitato per il ripristino temporizzato e viene ripristinato l'ora in cui cmk è stato disabilitato?

In questo caso la chiave gestita dal cliente è abilitata in modo esplicito nell'account di destinazione ripristinato per i motivi seguenti:

  • Una volta abilitata la chiave gestita dal cliente nell'account, non è possibile disabilitare la chiave gestita dal cliente.
  • Questo comportamento è in linea con la progettazione corrente del ripristino dell'account abilitato cmk 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'insieme di credenziali delle chiavi di Azure è valida, la crittografia viene avviata e il processo viene completato senza ulteriore controllo. 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.

Passaggi successivi