Konfigurace klíčů spravovaných zákazníkem pro stávající účet služby Azure Cosmos DB pomocí služby Azure Key Vault
PLATÍ PRO: NoSQL MongoDB Skřítek Stůl
Povolení druhé vrstvy šifrování neaktivních uložených dat pomocí klíčů spravovaných zákazníkem při vytváření nového účtu služby Azure Cosmos DB je už nějakou dobu obecně dostupné. Jako přirozený další krok teď máme možnost povolit CMK u stávajících účtů Azure Cosmos DB.
Tato funkce eliminuje potřebu migrace dat do nového účtu, aby bylo možné povolit CMK. Pomáhá zlepšit stav zabezpečení a dodržování předpisů zákazníků.
Povolení CMK spustí proces na pozadí, asynchronní proces pro šifrování všech existujících dat v účtu, zatímco nová příchozí data se před zachováním zašifrují. Není nutné čekat, až asynchronní operace proběhne úspěšně. Proces povolení spotřebovává nepoužívané/náhradní jednotky RU, aby to nemělo vliv na úlohy čtení a zápisu. Po zašifrování účtu můžete odkazovat na tento odkaz pro plánování kapacity.
Začněte tím, že u stávajících účtů povolíte CMK.
Důležité
Důkladně si projděte část s požadavky. Jedná se o důležité aspekty.
Požadavky
Všechny požadované kroky potřebné při konfiguraci klíčů spravovaných zákazníkem pro nové účty platí pro povolení klíče CMK ve vašem stávajícím účtu. Projděte si zde uvedené kroky .
Poznámka:
Je důležité si uvědomit, že povolení šifrování účtu služby Azure Cosmos DB přidá k ID dokumentu malou režii, což omezuje maximální velikost ID dokumentu na 990 bajtů místo 1024 bajtů. Pokud má váš účet nějaké dokumenty s ID většími než 990 bajtů, proces šifrování se nezdaří, dokud tyto dokumenty nebudou odstraněny.
Pokud chcete ověřit, jestli váš účet vyhovuje, můžete k prohledávání účtu použít zadanou konzolovou aplikaci hostované tady . Ujistěte se, že používáte koncový bod z vlastnosti účtu sqlEndpoint bez ohledu na vybrané rozhraní API.
Pokud chcete během migrace zakázat ověřování na straně serveru, obraťte se na podporu.
Postup povolení CMK u stávajícího účtu
Pokud chcete povolit CMK u existujícího účtu, aktualizujte účet nastavením šablony ARM identifikátor klíče služby Key Vault ve vlastnosti keyVaultKeyUri – stejně jako při povolování klíče CMK u nového účtu. Tento krok lze provést vydáním volání PATCH s následující datovou částí:
{
"properties": {
"keyVaultKeyUri": "<key-vault-key-uri>"
}
}
Výstup tohoto příkazu rozhraní příkazového řádku pro povolení cmk čeká na dokončení šifrování dat.
az cosmosdb update --name "testaccount" --resource-group "testrg" --key-uri "https://keyvaultname.vault.azure.net/keys/key1"
Postup povolení CMK u existujícího účtu služby Azure Cosmos DB s účtem průběžného zálohování nebo analytického úložiště
Pokud chcete povolit CMK u existujícího účtu, který má povolené průběžné zálohování a obnovení k určitému bodu v čase, musíme provést několik dalších kroků. Postupujte podle kroku 1 ke kroku 5 a pak podle pokynů povolte CMK u existujícího účtu.
Konfigurace spravované identity pro váš účet cosmos DB – Konfigurace spravovaných identit pomocí Id Microsoft Entra pro účet služby Azure Cosmos DB
Aktualizace účtu cosmos za účelem nastavení výchozí identity tak, aby odkazovat na spravovanou identitu přidanou v předchozím kroku
Pro systémovou spravovanou identitu:
az cosmosdb update--resource-group $resourceGroupName --name $accountName --default-identity "SystemAssignedIdentity"
Pro identitu spravovanou uživatelem:
az cosmosdb update -n $sourceAccountName -g $resourceGroupName --default-identity "UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-00000000/resourcegroups/MyRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyID"
Tady nakonfigurujte keyvault podle dokumentace .
Přidání zásad přístupu do služby keyvault pro výchozí identitu nastavenou v předchozím kroku
Aktualizujte účet cosmos tak, aby nastavoval identifikátor URI služby KeyVault. Tato aktualizace aktivuje cmk u účtu.
az cosmosdb update --name $accountName --resource-group $resourceGroupName --key-uri $keyVaultKeyURI
Známá omezení
- Nepodporujeme povolení CMK u existujících účtů Azure Cosmos DB pro Apache Cassandra.
- Povolení CMK je k dispozici pouze na úrovni účtu služby Cosmos DB, a ne v kolekcích.
- Nepodporujeme povolení CMK u existujících účtů, které jsou povolené pro materializovaná zobrazení a všechny verze a odstraní režim kanálu změn.
- Než povolíte CMK, ujistěte se, že účet nesmí obsahovat dokumenty s velkými ID většími než 990 bajtů. Pokud ne, zobrazí se chyba kvůli maximálnímu podporovanému limitu 1024 bajtů po šifrování.
- Během šifrování existujících dat se zablokují akce řídicí roviny, jako je přidání oblasti. Tyto akce jsou odblokované a je možné je použít hned po dokončení šifrování.
Monitorování průběhu výsledného šifrování
Povolení CMK u existujícího účtu je asynchronní operace, která spouští úlohu na pozadí, která šifruje všechna existující data. Požadavek rozhraní REST API na povolení CMK v odpovědi na adresu URL Azure-AsyncOperation. Dotazování na tuto adresu URL s požadavky GET vrátí stav celkové operace, která nakonec proběhne úspěšně. Tento mechanismus je plně popsaný v tomto článku.
Účet Cosmos DB se může dál používat a data se můžou dál zapisovat, aniž by čekala na úspěšné asynchronní operace. Příkaz rozhraní příkazového řádku pro povolení cmk čeká na dokončení šifrování dat.
Aby se stávající účet Cosmos DB mohl používat pro CMK, je potřeba provést kontrolu, aby se zajistilo, že účet nemá velké ID. Velké ID je ID dokumentu, které přesahuje délku 990 znaků. Tato kontrola je povinná pro migraci CMK a microsoft ji provádí automaticky. Během tohoto procesu se může zobrazit chyba.
CHYBA: (InternalServerError) Při kontrole migrace CMK do dokumentu došlo k neočekávané chybě. Opakujte operaci.
K tomu dochází v případě, že proces kontroly používá více JEDNOTek RU, než které jsou zřízené v kolekci, což vyvolá chybu 429. Řešením tohoto problému bude dočasně narazit na počet RU. Případně můžete použít poskytnutou konzolovou aplikaci hostované zde , abyste mohli skenovat jejich kolekce.
Poznámka:
Pokud chcete během migrace zakázat ověřování na straně serveru, obraťte se na podporu. To je vhodné pouze v případě, že jste si jisti, že neexistují žádná velká ID. Pokud během šifrování dojde k velkému ID, proces se zastaví, dokud nebude vyřešen dokument Velké ID.
Pokud máte další otázky, kontaktujte podpora Microsoftu.
Nejčastější dotazy
Jaké jsou faktory, na kterých závisí doba šifrování?
Povolení CMK je asynchronní operace a závisí na tom, že je k dispozici dostatek nevyužitých RU. Doporučujeme povolit CMK v době mimo špičku a pokud je to možné, můžete zvýšit počet RU před rukou, aby se urychlilo šifrování. Jedná se také o přímou funkci velikosti dat.
Potřebujeme se závorkou prostoje?
Povolení cmk spustí pozadí, asynchronní proces pro šifrování všech dat. Není nutné čekat, až asynchronní operace proběhne úspěšně. Účet služby Azure Cosmos DB je k dispozici pro čtení a zápisy a není potřeba prostoje.
Můžete po aktivaci CMK narazit na RU?
Před aktivací CMK se doporučuje navýšit jednotky RU. Po aktivaci CMK se některé operace řídicí roviny zablokují, dokud se šifrování nedokončí. Tento blok může uživateli zabránit ve zvýšení počtu RU po aktivaci klíče CMK.
Aby mohl stávající účet Cosmos DB používat cmK, je kontrola velkého ID povinná automaticky microsoftem vyřešit jedno ze známých omezení uvedených výše. Tento proces také spotřebovává další RU a je vhodné výrazně navýšit počet RU, aby se zabránilo chybě 429.
Existuje způsob, jak po aktivaci klíče CMK vrátit šifrování zpět nebo zakázat šifrování?
Po aktivaci procesu šifrování dat pomocí klíče CMK se nedá vrátit zpět.
Bude povolení šifrování pomocí klíče CMK u existujícího účtu mít vliv na velikost dat a čtení a zápisy?
Jak byste očekávali, povolením CMK dojde k mírnému zvýšení velikosti dat a RU, aby se přizpůsobilo dodatečnému zpracování šifrování a dešifrování.
Měli byste zálohovat data před povolením CMK?
Povolení CMK nepředstavuje žádnou hrozbu ztráty dat.
Jsou staré zálohy pořízené jako součást pravidelného zálohování šifrované?
Ne. Staré pravidelné zálohy nejsou šifrované. Nově vygenerované zálohy po zašifrování klíče CMK.
Jaké je chování stávajících účtů, které jsou povolené pro průběžné zálohování?
Když je klíč CMK zapnutý, šifrování je zapnuté i pro průběžné zálohování. Jakmile je cmk zapnutý, budou všechny obnovené účty v budoucnu povolené cmk.
Jaké je chování, pokud je v účtu s povoleným obnovením k určitému bodu v čase, kdy byl cmK zakázaný, povolíme cmk a účet obnovíme?
V takovém případě je klíč CMK explicitně povolený pro obnovený cílový účet z následujících důvodů:
- Po povolení CMK v účtu není k dispozici žádná možnost zakázat CMK.
- Toto chování je v souladu s aktuálním návrhem obnovení účtu s podporou CMK s pravidelným zálohováním.
Co se stane, když uživatel odvolá klíč, když migrace CMK probíhá?
Stav klíče se kontroluje při aktivaci šifrování CMK. Pokud je klíč ve službě Azure Key Vault v dobrém stavu, šifrování se spustí a proces se dokončí bez další kontroly. I když je klíč odvolán nebo je trezor klíčů Azure odstraněný nebo nedostupný, proces šifrování proběhne úspěšně.
Můžeme povolit šifrování CMK u stávajícího produkčního účtu?
Ano. Důkladně si projděte část s požadavky. Doporučujeme nejprve otestovat všechny scénáře na neprodukčních účtech a jakmile budete mít přehled o produkčních účtech.
Další kroky
- Přečtěte si další informace o šifrování dat ve službě Azure Cosmos DB.
- Můžete se rozhodnout přidat druhou vrstvu šifrování s vlastními klíči. Další informace najdete v článku o klíčích spravovaných zákazníkem.
- Další informace o certifikacích Microsoftu najdete v Centru zabezpečení Azure.