Dela via

Konfigurera kundhanterade nycklar för ditt befintliga Azure Cosmos DB-konto med Azure Key Vault

  • Artikel

GÄLLER FÖR: NoSQL MongoDB Gremlin Bord

Att aktivera ett andra krypteringslager för vilande data med hjälp av kundhanterade nycklar när du skapar ett nytt Azure Cosmos DB-konto har varit allmänt tillgängligt under en tid nu. Som ett naturligt nästa steg har vi nu möjlighet att aktivera CMK på befintliga Azure Cosmos DB-konton.

Den här funktionen eliminerar behovet av datamigrering till ett nytt konto för att aktivera CMK. Det hjälper till att förbättra kundernas säkerhets- och efterlevnadsstatus.

Att aktivera CMK startar en bakgrund, asynkron process för att kryptera alla befintliga data i kontot, medan nya inkommande data krypteras innan de bevaras. Du behöver inte vänta tills den asynkrona åtgärden lyckas. Aktiveringsprocessen förbrukar oanvända/extra RU:er så att den inte påverkar dina läs-/skrivarbetsbelastningar. Du kan se den här länken för kapacitetsplanering när ditt konto har krypterats.

Kom igång genom att aktivera CMK på dina befintliga konton

Viktigt!

Gå igenom avsnittet om förhandskrav noggrant. Detta är viktiga överväganden.

Förutsättningar

Alla nödvändiga steg som krävs när du konfigurerar kundhanterade nycklar för nya konton gäller för att aktivera CMK på ditt befintliga konto. Se stegen här

Kommentar

Det är viktigt att observera att om du aktiverar kryptering på ditt Azure Cosmos DB-konto läggs en liten kostnad till dokumentets ID, vilket begränsar den maximala storleken på dokument-ID:t till 990 byte i stället för 1 024 byte. Om ditt konto har dokument med ID:t som är större än 990 byte misslyckas krypteringsprocessen tills dokumenten har tagits bort.

För att kontrollera om ditt konto är kompatibelt kan du använda det angivna konsolprogrammet som finns här för att genomsöka ditt konto. Kontrollera att du använder slutpunkten från kontoegenskapen "sqlEndpoint", oavsett vilket API som valts.

Om du vill inaktivera verifiering på serversidan för detta under migreringen kontaktar du supporten.

Steg för att aktivera CMK på ditt befintliga konto

Om du vill aktivera CMK för ett befintligt konto uppdaterar du kontot med en ARM-mall som anger en Key Vault-nyckelidentifierare i egenskapen keyVaultKeyUri – precis som när du aktiverar CMK för ett nytt konto. Det här steget kan göras genom att utfärda ett PATCH-anrop med följande nyttolast:

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

Utdata från det här CLI-kommandot för att aktivera CMK väntar på att krypteringen av data ska slutföras.

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

Steg för att aktivera CMK för ditt befintliga Azure Cosmos DB-konto med ett konto för kontinuerlig säkerhetskopiering eller analysarkiv

För att aktivera CMK på ett befintligt konto som har kontinuerlig säkerhetskopiering och återställning till tidpunkt är aktiverat måste vi följa några extra steg. Följ steg 1 till steg 5 och följ sedan anvisningarna för att aktivera CMK för ett befintligt konto.

  1. Konfigurera hanterad identitet till ditt Cosmos-konto Konfigurera hanterade identiteter med Microsoft Entra-ID för ditt Azure Cosmos DB-konto

  2. Uppdatera Cosmos-kontot så att standardidentiteten pekar på hanterad identitet som lades till i föregående steg

    För systemhanterad identitet:

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

    För Användarhanterad identitet :

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

  3. Konfigurera Keyvault enligt dokumentationen här

  4. Lägg till åtkomstprincip i nyckelvalvet för standardidentiteten som anges i föregående steg

  5. Uppdatera Cosmos-kontot för att ange keyvault-uri. Den här uppdateringen utlöser aktivering av CMK på kontot 

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

Kända begränsningar

  • Vi stöder inte aktivering av CMK på befintliga Azure Cosmos DB för Apache Cassandra-konton.
  • Aktivering av CMK är endast tillgängligt på Cosmos DB-kontonivå och inte på samlingar.
  • Vi stöder inte aktivering av CMK på befintliga konton som är aktiverade för materialiserade vyer och alla versioner och tar bort ändringsflödesläget.
  • Se till att kontot inte får ha dokument med stora ID:er som är större än 990 byte innan du aktiverar CMK. Annars får du ett fel på grund av maxgränsen på 1 024 byte efter kryptering.
  • Under kryptering av befintliga data blockeras kontrollplansåtgärder som "lägg till region". Dessa åtgärder avblockeras och kan användas direkt när krypteringen är klar.

Övervaka förloppet för den resulterande krypteringen

Att aktivera CMK på ett befintligt konto är en asynkron åtgärd som startar en bakgrundsaktivitet som krypterar alla befintliga data. Därför tillhandahåller REST API-begäran om att aktivera CMK i sitt svar en "Azure-AsyncOperation"-URL. Avsökning av den här URL:en med GET-begäranden returnerar statusen för den övergripande åtgärden, som slutligen lyckas. Den här mekanismen beskrivs fullständigt i den här artikeln.

Cosmos DB-kontot kan fortsätta att användas och data kan fortsätta att skrivas utan att vänta på att den asynkrona åtgärden ska lyckas. CLI-kommandot för att aktivera CMK väntar på att krypteringen av data ska slutföras.

För att ett befintligt Cosmos DB-konto ska kunna användas i CMK måste en genomsökning göras för att säkerställa att kontot inte har "stora ID:er". Ett "stort ID" är ett dokument-ID som överskrider 990 tecken. Den här genomsökningen är obligatorisk för CMK-migreringen och görs automatiskt av Microsoft. Under den här processen kan det uppstå ett fel.

FEL: (InternalServerError) Oväntat fel vid dokumentsökning efter CMK-migrering. Försök att utföra åtgärden igen.

Detta inträffar när genomsökningsprocessen använder fler RU:er än de som har etablerats i samlingen, vilket utlöser ett 429-fel. En lösning på det här problemet är att tillfälligt öka sina RU:er avsevärt. Du kan också använda det angivna konsolprogrammet som finns här för att genomsöka deras samlingar.

Kommentar

Om du vill inaktivera verifiering på serversidan för detta under migreringen kontaktar du supporten. Detta rekommenderas endast om du är säker på att det inte finns några stora ID:n. Om stort ID påträffas under krypteringen stoppas processen tills det stora ID-dokumentet har åtgärdats.

Kontakta Microsoft Support om du har fler frågor.

Vanliga frågor och svar

Vilka faktorer beror krypteringstiden på?

Att aktivera CMK är en asynkron åtgärd och beror på att tillräckligt många oanvända RU:er är tillgängliga. Vi föreslår att du aktiverar CMK under låg belastning och om tillämpligt kan du öka RU:er före hand för att påskynda krypteringen. Det är också en direkt funktion av datastorlek.

Behöver vi förbereda oss för stilleståndstid?

Om du aktiverar CMK startas en asynkron bakgrundsprocess för att kryptera alla data. Du behöver inte vänta tills den asynkrona åtgärden lyckas. Azure Cosmos DB-kontot är tillgängligt för läsningar och skrivningar och det finns inget behov av stilleståndstid.

Kan du stöta upp RU:erna när CMK har utlösts?

Det rekommenderas att öka ru:erna innan du utlöser CMK. När CMK har utlösts blockeras vissa kontrollplansåtgärder tills krypteringen är klar. Det här blocket kan hindra användaren från att öka RU:erna när CMK utlöses.

För att tillåta att ett befintligt Cosmos DB-konto används för CMK görs en stor ID-genomsökning obligatoriskt av Microsoft automatiskt för att åtgärda en av de kända begränsningar som angavs tidigare. Den här processen förbrukar också ytterligare RU:er och det är en bra idé att öka RU:ernas avsevärt för att undvika fel 429.

Finns det något sätt att vända krypteringen eller inaktivera kryptering när du har utlöst CMK?

När datakrypteringsprocessen med CMK har utlösts kan den inte återställas.

Kommer aktivering av kryptering med hjälp av CMK på ett befintligt konto att påverka datastorleken och läsa/skriva?

Som förväntat ökar datastorleken och RU:erna något genom att aktivera CMK för extra kryptering/dekryptering.

Bör du säkerhetskopiera data innan du aktiverar CMK?

Att aktivera CMK utgör inget hot om dataförlust.

Krypteras gamla säkerhetskopior som en del av periodisk säkerhetskopiering?

Nej. Gamla periodiska säkerhetskopior krypteras inte. Nyligen genererade säkerhetskopior efter att CMK aktiverats har krypterats.

Vad är beteendet för befintliga konton som är aktiverade för kontinuerlig säkerhetskopiering?

När CMK är aktiverat aktiveras även krypteringen för kontinuerliga säkerhetskopieringar. När CMK är aktiverat är alla återställde konton framöver CMK aktiverade.

Vad är beteendet om CMK är aktiverat på ETT PITR-aktiverat konto och vi återställer kontot till den tidpunkt då CMK inaktiverades?

I det här fallet är CMK uttryckligen aktiverat på det återställde målkontot av följande skäl:

  • När CMK har aktiverats för kontot finns det inget alternativ för att inaktivera CMK.
  • Det här beteendet är i linje med den aktuella utformningen av återställning av CMK-aktiverat konto med regelbunden säkerhetskopiering

Vad händer när användaren återkallar nyckeln medan CMK-migreringen pågår?

Nyckelns tillstånd kontrolleras när CMK-kryptering utlöses. Om nyckeln i Azure Key Vault är i gott skick startas krypteringen och processen slutförs utan ytterligare kontroll. Även om nyckeln har återkallats eller Om Azure-nyckelvalvet har tagits bort eller inte är tillgängligt lyckas krypteringsprocessen.

Kan vi aktivera CMK-kryptering på vårt befintliga produktionskonto?

Ja. Gå igenom förutsättningsavsnittet noggrant. Vi rekommenderar att du testar alla scenarier först på icke-produktionskonton och när du är bekväm kan du överväga produktionskonton.

Nästa steg