Megosztás a következőn keresztül:

Ügyfél által felügyelt kulcsok konfigurálása meglévő Azure Cosmos DB-fiókhoz az Azure Key Vaulttal

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: NoSQL MongoDB Gremlin Asztal

Az új Azure Cosmos DB-fiók létrehozásakor általánosan elérhető egy második titkosítási réteg engedélyezése inaktív adatokhoz ügyfél által felügyelt kulcsokkal . Természetes következő lépésként most már lehetőségünk van a CMK engedélyezésére a meglévő Azure Cosmos DB-fiókokon.

Ez a funkció nem igényel adatmigrálást egy új fiókba a CMK engedélyezéséhez. Segít az ügyfelek biztonságának és megfelelőségi helyzetének javításában.

A CMK engedélyezése elindít egy háttérbeli, aszinkron folyamatot a fiók összes meglévő adatának titkosításához, míg az új bejövő adatok titkosítása a megőrzése előtt történik. Nem kell megvárni, amíg az aszinkron művelet sikeres lesz. Az engedélyezési folyamat nem használt/tartalék kérelemegységeket használ fel, hogy az ne befolyásolja az olvasási/írási számítási feladatokat. A fiók titkosítása után erre a hivatkozásra kattintva megtekintheti a kapacitástervezést.

Első lépések a CMK engedélyezésével a meglévő fiókokon

Fontos

Tekintse át alaposan az előfeltételek szakaszt. Ezek fontos szempontok.

Előfeltételek

Az ügyfél által felügyelt kulcsok új fiókokhoz való konfigurálásához szükséges összes előfeltétel-lépés alkalmazható a CMK engedélyezéséhez a meglévő fiókon. Tekintse meg az itt leírt lépéseket

Feljegyzés

Fontos megjegyezni, hogy az Azure Cosmos DB-fiók titkosításának engedélyezése kis többletterhelést jelent a dokumentum azonosítójához, és a dokumentumazonosító maximális méretét 1024 bájt helyett 990 bájtra korlátozza. Ha a fiókjában 990 bájtnál nagyobb azonosítójú dokumentumok találhatók, a titkosítási folyamat mindaddig sikertelen lesz, amíg a dokumentumok nem törlődnek.

Annak ellenőrzéséhez, hogy a fiókja megfelelő-e, az itt található konzolalkalmazás használatával ellenőrizheti a fiókját. Győződjön meg arról, hogy az "sqlEndpoint" fióktulajdonság végpontját használja, a kiválasztott API-tól függetlenül.

Ha a migrálás során le szeretné tiltani a kiszolgálóoldali érvényesítést, forduljon az ügyfélszolgálathoz.

A CMK engedélyezésének lépései a meglévő fiókban

Ha egy meglévő fiókon szeretné engedélyezni a CMK-t, frissítse a fiókot egy ARM-sablonnal, amely egy Key Vault-kulcsazonosítót állít be a keyVaultKeyUri tulajdonságban – ugyanúgy, mint amikor a CMK-t egy új fiókon engedélyezi. Ez a lépés egy PATCH-hívás kiadásával végezhető el a következő hasznos adatokkal:

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

Ennek a PARANCSSOR-parancsnak a kimenete, amely lehetővé teszi a CMK várakozását az adatok titkosításának befejezésére.

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

A CMK engedélyezésének lépései a meglévő Azure Cosmos DB-fiókon folyamatos biztonsági mentéssel vagy elemzési tárfiókkal

Ha engedélyezni szeretné a CMK-t olyan meglévő fiókon, amelyen engedélyezve van a folyamatos biztonsági mentés és az időpont-visszaállítás, néhány további lépést kell követnünk. Kövesse az 1. lépést az 5. lépéshez, majd kövesse az utasításokat a CMK meglévő fiókon való engedélyezéséhez.

  1. Felügyelt identitás konfigurálása a Cosmos-fiókhoz Felügyelt identitások konfigurálása Az Azure Cosmos DB-fiók Microsoft Entra-azonosítójával

  2. A Cosmos-fiók frissítése az alapértelmezett identitás beállításához, hogy az előző lépésben hozzáadott felügyelt identitásra mutasson

    Rendszer által felügyelt identitás esetén:

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

    Felhasználó által felügyelt identitás esetén:

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

  3. A Keyvault konfigurálása az itt található dokumentációban leírtak szerint

  4. Hozzáférési szabályzat hozzáadása az előző lépésben beállított alapértelmezett identitás kulcsvaultjában

  5. A cosmos-fiók frissítése a keyvault uri beállításához. Ez a frissítés aktiválja a CMK-t a fiókon 

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

Ismert korlátozások

  • Nem támogatjuk a CMK engedélyezését a meglévő Azure Cosmos DB for Apache Cassandra-fiókokon.
  • A CMK engedélyezése csak Cosmos DB-fiók szintjén érhető el, gyűjteményekben nem.
  • Nem támogatjuk a CMK engedélyezését a materializált nézetekhez engedélyezett meglévő fiókokhoz, valamint az összes verzióhoz és törléshez.
  • A CMK engedélyezése előtt győződjön meg arról, hogy a fiók nem rendelkezik 990 bájtnál nagyobb méretű azonosítójú dokumentumokkal. Ha nem, akkor a titkosítás után a maximálisan támogatott 1024 bájtos korlát miatt hibaüzenet jelenik meg.
  • A meglévő adatok titkosítása során az olyan vezérlősík-műveletek, mint a "régió hozzáadása" le lesz tiltva. Ezek a műveletek feloldva vannak, és közvetlenül a titkosítás befejezése után használhatók.

Az eredményként kapott titkosítás állapotának figyelése

A CMK engedélyezése meglévő fiókon aszinkron művelet, amely elindít egy háttérfeladatot, amely minden meglévő adatot titkosít. Ezért a CMK engedélyezésére irányuló REST API-kérés válaszában egy "Azure-AsyncOperation" URL-címet biztosít. Ha GET-kérésekkel kérdezi le ezt az URL-címet, az a teljes művelet állapotát adja vissza, amely végül sikeres lesz. Ezt a mechanizmust ebben a cikkben részletesen ismertetjük.

A Cosmos DB-fiók továbbra is használható, és az adatok továbbra is írhatók anélkül, hogy megvárják az aszinkron művelet sikerességét. A CMK engedélyezésére szolgáló PARANCSSOR-parancs az adatok titkosításának befejezésére vár.

Ahhoz, hogy egy meglévő Cosmos DB-fiók használható legyen a CMK-hoz, vizsgálatot kell végezni annak érdekében, hogy a fiók ne rendelkezzen "Nagy azonosítókkal". A "nagy azonosító" olyan dokumentumazonosító, amely meghaladja a 990 karakter hosszúságot. Ez a vizsgálat kötelező a CMK-migráláshoz, és a Microsoft automatikusan elvégzi. A folyamat során hibaüzenet jelenhet meg.

HIBA: (InternalServerError) Váratlan hiba a CMK-migrálás dokumentumvizsgálata során. Please retry the operation.

Ez akkor fordul elő, ha a vizsgálati folyamat több kérelemegységet használ, mint a gyűjteményen kiépítettek, és 429-et eredményez. A probléma megoldására az lesz a megoldás, hogy ideiglenesen jelentősen megütik a kérelemegységeket. Másik lehetőségként használhatja az itt üzemeltetett konzolalkalmazást a gyűjtemények vizsgálatához.

Feljegyzés

Ha a migrálás során le szeretné tiltani a kiszolgálóoldali érvényesítést, forduljon az ügyfélszolgálathoz. Ez csak akkor ajánlott, ha biztos benne, hogy nincsenek nagy azonosítók. Ha a titkosítás során nagy azonosítóval találkozik, a folyamat a nagy azonosítójú dokumentum címzéséig leáll.

Ha további kérdései vannak, forduljon Microsoft ügyfélszolgálata.

GYIK

Milyen tényezőktől függ a titkosítási idő?

A CMK engedélyezése aszinkron művelet, és attól függ, hogy elegendő nem használt kérelemegység érhető el. Javasoljuk, hogy engedélyezze a CMK-t csúcsidőn kívül, és ha lehetséges, növelheti a kérelemegységeket a kéznél, hogy felgyorsítsa a titkosítást. Az adatméret közvetlen függvénye is.

Meg kell kapcsosnunk magunkat az állásidőhöz?

A CMK engedélyezése elindít egy háttérbeli, aszinkron folyamatot az összes adat titkosításához. Nem kell megvárni, amíg az aszinkron művelet sikeres lesz. Az Azure Cosmos DB-fiók olvasáshoz és íráshoz érhető el, és nincs szükség állásidőre.

Fel tudja pöccenni a ru-t, amint a CMK aktiválódott?

Javasoljuk, hogy a CMK aktiválása előtt pöccsen fel a kérelemegységek között. A CMK aktiválása után a rendszer blokkol néhány vezérlősík-műveletet a titkosítás befejezéséig. Ez a blokk megakadályozhatja, hogy a felhasználó növelje az RU-t a CMK aktiválása után.

Annak érdekében, hogy egy meglévő Cosmos DB-fiók használható legyen a CMK-hoz, a Microsoft automatikusan elvégzi a nagyméretű azonosítók vizsgálatát a korábban felsorolt ismert korlátozások egyikének kezelése érdekében. Ez a folyamat további kérelemegységeket is felhasznál, és érdemes jelentősen megnövelni a ru-k számát a 429-re vonatkozó hiba elkerülése érdekében.

Van mód a titkosítás megfordítására vagy a titkosítás letiltására a CMK aktiválása után?

Miután aktiválta a CMK-t használó adattitkosítási folyamatot, az nem állítható vissza.

Hatással lesz-e az adatok méretére és az olvasási/írási műveletekre a CMK-val való titkosítás engedélyezése a meglévő fiókban?

Ahogy várható volt, a CMK engedélyezésével kismértékben megnő az adatméret és a kérelemegységek száma a további titkosítási/visszafejtési feldolgozás érdekében.

Biztonsági másolatot kell készítenie az adatokról a CMK engedélyezése előtt?

A CMK engedélyezése nem jelent adatvesztést.

A régi biztonsági másolatok az időszakos biztonsági mentés részeként vannak titkosítva?

Szám A régi rendszeres biztonsági másolatok nincsenek titkosítva. A CMK engedélyezése után újonnan létrehozott biztonsági másolatok titkosítása.

Mi a folyamatos biztonsági mentéshez engedélyezett meglévő fiókok viselkedése?

Ha a CMK be van kapcsolva, a titkosítás a folyamatos biztonsági mentésekhez is be van kapcsolva. Ha a CMK be van kapcsolva, az összes visszaállított fiók engedélyezve lesz.

Mi a viselkedés, ha a CMK engedélyezve van a PITR-kompatibilis fiókban, és visszaállítjuk a fiókot arra az időre, amikor a CMK le lett tiltva?

Ebben az esetben a CMK kifejezetten engedélyezve van a visszaállított célfiókon a következő okok miatt:

  • Ha a CMK engedélyezve van a fiókban, nincs lehetőség a CMK letiltására.
  • Ez a viselkedés összhangban van a CMK-kompatibilis fiók rendszeres biztonsági mentéssel történő visszaállításának jelenlegi tervével

Mi történik, ha a felhasználó visszavonja a kulcsot, miközben a CMK migrálása folyamatban van?

A rendszer ellenőrzi a kulcs állapotát a CMK-titkosítás aktiválásakor. Ha az Azure Key Vaultban lévő kulcs jó állapotban van, a titkosítás elindul, és a folyamat további ellenőrzés nélkül befejeződik. A titkosítási folyamat akkor is sikeres, ha a kulcsot visszavonták, vagy az Azure Key Vaultot törölték vagy nem érhető el.

Engedélyezhetjük a CMK-titkosítást a meglévő éles fiókunkon?

Igen. Tekintse át alaposan az előfeltétel szakaszt. Javasoljuk, hogy először tesztelje az összes forgatókönyvet a nem termelési fiókokon, és ha már jól érzi magát, fontolja meg az éles fiókokat.

Következő lépések