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

Ügyféloldali titkosítás használata az Azure Cosmos DB-hez készült Always Encrypteddel

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Fontos

A titkosítási csomagok 1.0-s kiadásával egy kompatibilitástörő változást vezetünk be. Ha korábbi verziókkal hozott létre adattitkosítási kulcsokat és titkosítást engedélyező tárolókat, az ügyfélkód 1.0-s csomagokra való migrálása után újra létre kell hoznia az adatbázisokat és a tárolókat.

Az Always Encrypted egy olyan funkció, amely az Azure Cosmos DB-ben tárolt bizalmas adatok, például hitelkártyaszámok vagy nemzeti/regionális azonosító számok (például amerikai társadalombiztosítási számok) védelmére szolgál. Az Always Encrypted lehetővé teszi, hogy az ügyfelek titkosítsanak bizalmas adatokat az ügyfélalkalmazások között, és soha ne fedik fel a titkosítási kulcsokat az adatbázisban.

Az Always Encrypted ügyféloldali titkosítási képességeket biztosít az Azure Cosmos DB-hez. Az adatok ügyféloldali titkosítása a következő esetekben lehet szükséges:

  • Különleges bizalmassági jellemzőkkel rendelkező bizalmas adatok védelme: Az Always Encrypted lehetővé teszi az ügyfelek számára a bizalmas adatok alkalmazáson belüli titkosítását, és soha nem fedik fel az egyszerű szöveges adatokat vagy titkosítási kulcsokat az Azure Cosmos DB szolgáltatásban.
  • Tulajdonságonkénti hozzáférés-vezérlés megvalósítása: Mivel a titkosítást az Ön tulajdonában lévő és az Azure Key Vaultból kezelt kulcsok vezérlik, hozzáférési szabályzatokkal szabályozhatja, hogy az egyes ügyfelek mely bizalmas tulajdonságokhoz férhetnek hozzá.

Fogalmak

Az Azure Cosmos DB-hez készült Always Encrypted új fogalmakat vezet be, amelyek az ügyféloldali titkosítás konfigurálásában vesznek részt.

Titkosítási kulcsok

Adattitkosítási kulcsok

Az Always Encrypted használatakor az adatok titkosítva lesznek az előre létrehozandó adattitkosítási kulcsokkal (DEK). Ezek a DEK-k az Azure Cosmos DB szolgáltatásban vannak tárolva, és az adatbázis szintjén vannak definiálva, így a DEK több tároló között is megosztható. A DEK-k létrehozása ügyféloldalon történik az Azure Cosmos DB SDK használatával.

A következőket teheti:

  • Tulajdonságonként egy DEK létrehozása titkosításhoz, vagy
  • Több tulajdonság titkosításához használja ugyanazt a DEK-t.

Felhasználó által kezelt kulcsok

Mielőtt a DEK-k tárolása az Azure Cosmos DB-ben történik, egy ügyfél által felügyelt kulcs (CMK) burkolja őket. A DEK-k burkolásának és kibontásának szabályozásával a CMK-k hatékonyan szabályozhatják a megfelelő DEK-kkal titkosított adatokhoz való hozzáférést. A CMK-tároló bővíthetőként lett kialakítva, alapértelmezett implementációval, amely elvárja, hogy azOkat az Azure Key Vaultban tárolja.

Titkosítási kulcsok

Titkosítási szabályzat

Az indexelési szabályzathoz hasonlóan a titkosítási szabályzatok tárolószintű specifikációk, amelyek a JSON-tulajdonságok titkosításának módját írják le. Ezt a házirendet a tároló létrehozásakor kell megadni, és nem módosítható. Az aktuális kiadásban nem frissítheti a titkosítási szabályzatot.

Minden titkosítandó tulajdonság esetében a titkosítási szabályzat a következőket határozza meg:

  • A tulajdonság elérési útja a következő formában /property: . Jelenleg csak a legfelső szintű útvonalak támogatottak, beágyazott elérési utak, például /path/to/property nem támogatottak.
  • A tulajdonság titkosításához és visszafejtéséhez használandó DEK azonosítója.
  • Titkosítási típus. Ez lehet véletlenszerű vagy determinisztikus.
  • A tulajdonság titkosításához használandó titkosítási algoritmus. A megadott algoritmus felülbírálhatja a kulcs létrehozásakor definiált algoritmust, ha kompatibilisek.

Randomizált és determinisztikus titkosítás

Az Azure Cosmos DB szolgáltatás soha nem látja az Always Encrypted használatával titkosított tulajdonságok egyszerű szövegét. Azonban továbbra is támogat bizonyos lekérdezési képességeket a titkosított adatokon, a tulajdonsághoz használt titkosítási típustól függően. Az Always Encrypted a következő két titkosítási típust támogatja:

  • Determinisztikus titkosítás: Mindig ugyanazt a titkosított értéket hozza létre bármely egyszerű szöveges értékhez és titkosítási konfigurációhoz. A determinisztikus titkosítással a lekérdezések egyenlőségi szűrőket hajtanak végre a titkosított tulajdonságokon. Lehetővé teheti azonban, hogy a támadók a titkosított tulajdonság mintáinak vizsgálatával találják meg a titkosított értékekkel kapcsolatos információkat. Ez különösen igaz, ha a lehetséges titkosított értékek egy kis halmaza van, például Igaz/Hamis vagy Észak/Dél/Kelet/Nyugat régió.

  • Véletlenszerű titkosítás: Olyan módszert használ, amely kevésbé kiszámítható módon titkosítja az adatokat. A véletlenszerű titkosítás biztonságosabb, de megakadályozza, hogy a lekérdezések titkosított tulajdonságokra szűrjön.

Az Inicializálási vektor (IV) létrehozásával kapcsolatos további információkért lásd az Always Encrypted determinisztikus és véletlenszerű titkosítását.

Az Azure Key Vault beállítása

Az Always Encrypted használatának első lépése a CMK-k létrehozása az Azure Key Vaultban:

  1. Hozzon létre egy új Azure Key Vault-példányt, vagy keresse meg a meglévőt.
  2. Hozzon létre egy új kulcsot a Kulcsok szakaszban.
  3. A kulcs létrehozása után keresse meg az aktuális verziót, és másolja ki a teljes kulcsazonosítót:
    https://<my-key-vault>.vault.azure.net/keys/<key>/<version>. Ha kihagyja a kulcsverziót a kulcsazonosító végén, a rendszer a kulcs legújabb verzióját használja.

Ezután konfigurálnia kell, hogy az Azure Cosmos DB SDK hogyan fér hozzá az Azure Key Vault-példányhoz. Ez a hitelesítés Egy Microsoft Entra-identitáson keresztül történik. Valószínűleg egy Microsoft Entra-alkalmazás vagy egy felügyelt identitás identitását fogja használni proxyként az ügyfélkód és az Azure Key Vault-példány között, bár bármilyen identitás használható. A Microsoft Entra-identitás proxyként való használatához kövesse az alábbi lépéseket:

  1. Az Azure Key Vault-példányban keresse meg az Access-szabályzatok szakaszt, és adjon hozzá egy új szabályzatot:

    1. A kulcsengedélyekben válassza a Beolvasás, a Lista, a Kulcs kibontása, a Wrap Key, az Ellenőrzés és az Aláírás lehetőséget.
    2. Az Egyszerű kiválasztása területen keresse meg a Microsoft Entra-identitást.

A CMK védelme a véletlen törlés ellen

Annak érdekében, hogy a CMK véletlen törlése után ne veszítsen el hozzáférést a titkosított adatokhoz, javasoljuk, hogy állítson be két tulajdonságot az Azure Key Vault-példányon: Helyreállítható törlés és törlés elleni védelem.

Ha új Azure Key Vault-példányt hoz létre, engedélyezze ezeket a tulajdonságokat a létrehozás során:

Képernyőkép egy új Azure Key Vault-példány helyreállítható törlési és törlési védelmi tulajdonságairól.

Ha egy meglévő Azure Key Vault-példányt használ, az Azure Portal Tulajdonságok szakaszában ellenőrizheti, hogy engedélyezve vannak-e ezek a tulajdonságok. Ha ezen tulajdonságok bármelyike nincs engedélyezve, tekintse meg a "Helyreállítható törlés engedélyezése" és a "Törlés elleni védelem engedélyezése" című szakaszt az alábbi cikkek egyikében:

Az SDK inicializálása

Feljegyzés

Az Azure Cosmos DB-hez készült Always Encrypted jelenleg támogatott:

Az Always Encrypted használatához egy KeyResolver példányt az Azure Cosmos DB SDK-példányhoz kell csatolni. Ez a Azure.Security.KeyVault.Keys.Cryptography névtérben definiált osztály a CMK-okat futtató kulcstárolóval való interakcióra szolgál.

Az alábbi kódrészletek az DefaultAzureCredential osztály használatával kérik le az Azure Key Vault-példány elérésekor használni kívánt Microsoft Entra-identitást. Itt különböző típusú TokenCredential osztályok létrehozására találhat példákat.

Feljegyzés

Az osztályok eléréséhez TokenCredential szüksége lesz a további Azure.Identity-csomagra.

var tokenCredential = new DefaultAzureCredential();
var keyResolver = new KeyResolver(tokenCredential);
var client = new CosmosClient("<connection-string>")
    .WithEncryption(keyResolver, KeyEncryptionKeyResolverName.AzureKeyVault);

Adattitkosítási kulcs létrehozása

Ahhoz, hogy az adatok titkosíthatók legyenek egy tárolóban, létre kell hozni egy adattitkosítási kulcsot a szülőadatbázisban.

Új adattitkosítási kulcs létrehozása a metódus meghívásával és az CreateClientEncryptionKeyAsync átadással történik:

  • Sztringazonosító, amely egyedileg azonosítja az adatbázisban lévő kulcsot.
  • A kulccsal használni kívánt titkosítási algoritmus. Jelenleg csak egy algoritmus támogatott.
  • Az Azure Key Vaultban tárolt CMK kulcsazonosítója. Ez a paraméter egy általános EncryptionKeyWrapMetadata objektumban lesz átadva, ahol:
    • Ez type határozza meg a kulcsfeloldó típusát (például az Azure Key Vaultot).
    • Bármilyen name felhasználóbarát név lehet.
    • A value kulcsazonosítónak kell lennie.

    Fontos

    A kulcs létrehozása után keresse meg az aktuális verziót, és másolja ki a teljes kulcsazonosítót: https://<my-key-vault>.vault.azure.net/keys/<key>/<version>. Ha kihagyja a kulcsverziót a kulcsazonosító végén, a rendszer a kulcs legújabb verzióját használja.

    • Meghatározza algorithm , hogy melyik algoritmust kell használni a kulcstitkosítási kulcs ügyfél által felügyelt kulccsal való burkolásához.
var database = client.GetDatabase("my-database");
await database.CreateClientEncryptionKeyAsync(
    "my-key",
    DataEncryptionAlgorithm.AeadAes256CbcHmacSha256,
    new EncryptionKeyWrapMetadata(
        KeyEncryptionKeyResolverName.AzureKeyVault,
        "akvKey",
        "https://<my-key-vault>.vault.azure.net/keys/<key>/<version>",
        EncryptionAlgorithm.RsaOaep.ToString()));

Tároló létrehozása titkosítási szabályzattal

A tároló létrehozásakor adja meg a tárolószintű titkosítási szabályzatot.

var path1 = new ClientEncryptionIncludedPath
{
    Path = "/property1",
    ClientEncryptionKeyId = "my-key",
    EncryptionType = EncryptionType.Deterministic.ToString(),
    EncryptionAlgorithm = DataEncryptionAlgorithm.AeadAes256CbcHmacSha256
};
var path2 = new ClientEncryptionIncludedPath
{
    Path = "/property2",
    ClientEncryptionKeyId = "my-key",
    EncryptionType = EncryptionType.Randomized.ToString(),
    EncryptionAlgorithm = DataEncryptionAlgorithm.AeadAes256CbcHmacSha256
};
await database.DefineContainer("my-container", "/partition-key")
    .WithClientEncryptionPolicy()
    .WithIncludedPath(path1)
    .WithIncludedPath(path2)
    .Attach()
    .CreateAsync();

Titkosított adatok olvasása és írása

Az adatok titkosításának menete

Amikor egy dokumentumot ír az Azure Cosmos DB-be, az SDK megkeresi a titkosítási szabályzatot, hogy megtudja, mely tulajdonságokat kell titkosítani, és hogyan. A titkosítás eredménye egy 64-es alapsztring.

Összetett típusok titkosítása:

  • Ha a titkosítandó tulajdonság egy JSON-tömb, a tömb minden bejegyzése titkosítva lesz.

  • Ha a titkosítandó tulajdonság egy JSON-objektum, csak az objektum levélértékei lesznek titkosítva. A köztes altulajdonságok nevei egyszerű szöveges formában maradnak.

Titkosított elemek olvasása

A titkosított tulajdonságok visszafejtéséhez nincs szükség explicit műveletre a pontolvasások kiadásakor (egyetlen elem beolvasása az azonosító és a partíciókulcs alapján), lekérdezések vagy a változáscsatorna olvasása. Ennek oka a következő:

  • Az SDK megkeresi a titkosítási szabályzatot, hogy megtudja, mely tulajdonságokat kell visszafejteni.
  • A titkosítás eredménye beágyazza az érték eredeti JSON-típusát.

Vegye figyelembe, hogy a titkosított tulajdonságok feloldása és az azt követő visszafejtésük csak a kérésekből visszaadott eredményeken alapul. Ha például titkosítva van, property1 de a (SELECT property1 AS property2 FROM c)-be property2 van vetítve, akkor az nem lesz titkosított tulajdonságként azonosítva, amikor az SDK megkapja.

Lekérdezések szűrése titkosított tulajdonságokon

Titkosított tulajdonságokra szűrő lekérdezések írásakor egy adott metódust kell használni a lekérdezési paraméter értékének átadásához. Ez a metódus a következő argumentumokat foglalja össze:

  • A lekérdezési paraméter neve.
  • A lekérdezésben használandó érték.
  • A titkosított tulajdonság elérési útja (a titkosítási szabályzatban meghatározottak szerint).

Fontos

A titkosított tulajdonságok csak egyenlőségi szűrőkben (WHERE c.property = @Value) használhatók. Minden más használat kiszámíthatatlan és helytelen lekérdezési eredményeket ad vissza. Ezt a kényszert jobban érvényesítjük az SDK következő verzióiban.

var queryDefinition = container.CreateQueryDefinition(
    "SELECT * FROM c where c.property1 = @Property1");
await queryDefinition.AddParameterAsync(
    "@Property1",
    1234,
    "/property1");

Dokumentumok olvasása, ha csak a tulajdonságok egy részhalmaza fejthető vissza

Olyan esetekben, amikor az ügyfél nem fér hozzá a tulajdonságok titkosításához használt összes CMK-hoz, az adatok visszaolvasásakor csak a tulajdonságok egy részhalmaza fejthető vissza. Ha például kulcs1-zel van titkosítva, property1 és property2 kulcs2-vel van titkosítva, akkor egy olyan ügyfélalkalmazás, amely csak az 1. kulcshoz fér hozzá, továbbra is képes olvasni az adatokat, de nem property2. Ilyen esetben sql-lekérdezéseken keresztül kell beolvasnia az adatokat, és el kell vetnie azokat a tulajdonságokat, amelyeket az ügyfél nem tud visszafejteni: SELECT c.property1, c.property3 FROM c.

CMK elforgatása

Érdemes lehet "elforgatni" a CMK-t (azaz az aktuális helyett egy új CMK-t használni), ha azt gyanítja, hogy az aktuális CMK sérült. Gyakori biztonsági gyakorlat a CMK rendszeres elforgatása is. A forgatás végrehajtásához csak az új CMK kulcsazonosítóját kell megadnia, amelyet egy adott DEK körbefuttatásához kell használni. Vegye figyelembe, hogy ez a művelet nem befolyásolja az adatok titkosítását, hanem a DEK védelmét. Az előző CMK-hoz való hozzáférést a forgatás befejezéséig nem szabad visszavonni.

await database.RewrapClientEncryptionKeyAsync(
    "my-key",
    new EncryptionKeyWrapMetadata(
        KeyEncryptionKeyResolverName.AzureKeyVault,
        "akvKey",
        "https://<my-key-vault>.vault.azure.net/keys/<new-key>/<version>",
        EncryptionAlgorithm.RsaOaep.ToString()));

DEK-elforgatás

Az adattitkosítási kulcs forgatása nem kínál kulcsrakész képességként. Ennek az az oka, hogy a DEK frissítéséhez be kell vizsgálni az összes tárolót, ahol ezt a kulcsot használják, és újra kell titkosítást alkalmazni az ezzel a kulccsal titkosított összes tulajdonságra. Ez a művelet csak ügyféloldali módon történhet, mivel az Azure Cosmos DB szolgáltatás nem tárolja vagy soha nem éri el a DEK egyszerű szöveges értékét.

A gyakorlatban a DEK-rotáció úgy végezhető el, hogy adatmigrálást hajt végre az érintett tárolókról az új tárolókra. Az új tárolók ugyanúgy hozhatók létre, mint az eredeti tárolók. Az ilyen adatmigráláshoz egy különálló migrálási eszközt találhat a GitHubon.

További titkosított tulajdonságok hozzáadása

Ha további titkosított tulajdonságokat ad hozzá egy meglévő titkosítási szabályzathoz, a fenti szakaszban ismertetett okok miatt nem támogatott. Ehhez a művelethez a tároló teljes vizsgálatára van szükség annak biztosításához, hogy a tulajdonságok összes példánya megfelelően legyen titkosítva, és ez egy olyan művelet, amely csak ügyféloldali módon történhet. A DEK-rotációhoz hasonlóan további titkosított tulajdonságok hozzáadása is elvégezhető úgy, hogy adatmigrálást hajt végre egy új tárolóba egy megfelelő titkosítási szabályzattal.

Ha rugalmassággal rendelkezik az új titkosított tulajdonságok séma szempontjából való hozzáadásának módjában, az Azure Cosmos DB sémafüggetlen jellegét is kihasználhatja. Ha a titkosítási szabályzatban definiált tulajdonságot "tulajdonságtáskaként" használja, az alábbiakban további tulajdonságokat adhat hozzá korlátozás nélkül. Tegyük fel például, hogy ez property1 a titkosítási szabályzatban van definiálva, és kezdetben a dokumentumokba ír property1.property2 . Ha egy későbbi szakaszban titkosított tulajdonságként kell hozzáadnia property3 , elkezdheti írni property1.property3 a dokumentumokat, és az új tulajdonság is automatikusan titkosítva lesz. Ez a megközelítés nem igényel adatmigrálást.

Következő lépések