Transzparens adattitkosítás (TDE) ügyfél által felügyelt kulcsokkal az adatbázis szintjén

A következőkre vonatkozik:Azure SQL Database

Ez a cikk transzparens adattitkosítást (TDE) ismertet az Azure SQL Database adatbázisszintjén, ügyfél által felügyelt kulcsokkal.

Megjegyzés:

Az Adatbázisszintű TDE CMK elérhető az Azure SQL Database-hez (minden SQL Database-kiadáshoz). Nem érhető el a felügyelt Azure SQL-példányokhoz, a helyszíni SQL Serverhez, az Azure-beli virtuális gépekhez és az Azure Synapse Analyticshez (dedikált SQL-készletekhez (korábban SQL DW)).

Megjegyzés:

A Microsoft Entra ID-t korábban Azure Active Directorynak (Azure AD) nevezték.

Áttekintés

Az Azure SQL transzparens adattitkosítással (TDE) biztosít nyugalmi állapotban adattitkosítást az ügyfelek számára. A TDE ügyfél által felügyelt kulccsal (CMK) való kiterjesztése lehetővé teszi a inaktív adatok védelmét, ahol a TDE-védő (a titkosítási kulcs) egy Azure Key Vaultban vagy az adatbázis titkosítási kulcsait titkosító Azure Managed HSM-ben van tárolva. A CMK-val rendelkező TDE a kiszolgáló szintjén állítható be, és a kiszolgálóhoz társított összes titkosított adatbázis örökli. A TDE-védőt egyenként is beállíthatja ügyfél által felügyelt kulcsként a kiszolgálón belüli adatbázisokhoz. Minden Microsoft.Sql/servers/databases erőforrás, amely érvényes, nem üres encryptionProtector tulajdonsággal rendelkezik, adatbázisszintű, ügyfél által felügyelt kulcsokkal van konfigurálva.

Ebben a forgatókönyvben az ügyfél tulajdonában lévő és az ügyfél által felügyelt Azure Key Vaultban vagy az Azure Managed HSM-ben tárolt aszimmetrikus kulcs külön-külön használható a kiszolgálón belüli adatbázisokhoz az adatbázistitkosítási kulcs (DEK) titkosításához, más néven TDE-védőhöz. Lehetőség van kulcsok hozzáadására, kulcsok eltávolítására és a felhasználó által hozzárendelt felügyelt identitás (UMI) módosítására az egyes adatbázisokhoz. Az identitásokkal kapcsolatos további információkért lásd: Felügyelt identitástípusok az Azure-ban.

A következő funkciók érhetők el:

• Felhasználó által hozzárendelt felügyelt identitás: Egyetlen felhasználó által hozzárendelt felügyelt identitást rendelhet az adatbázishoz. Ez az identitás használható az Azure Key Vaulthoz vagy az Azure Managed HSM-hez való hozzáféréshez és a titkosítási kulcsok kezeléséhez.
• Titkosítási kulcsok kezelése: Engedélyezheti egy vagy több titkosítási kulcs hozzáadását az adatbázis szintjén, és beállíthatja a hozzáadott kulcsok egyikét TDE-védőként. A hozzáadott titkosítási kulcsok az adatbázishoz már hozzárendelt, felhasználó által meghatározott felügyelt identitással férnek hozzá az Azure Key Vaulthoz vagy az Azure Managed HSM-hez.
• Összevont ügyfélidentitás: Az Azure Key Vaultból vagy az Azure Managed HSM-ből egy másik Microsoft Entra-bérlőben lévő ügyfél által felügyelt kulcs (CMK) is engedélyezhető TDE-védelemként az adatbázis szintjén az Azure SQL Database-ben beállított összevont ügyfélidentitás használatával. Ez lehetővé teszi a TDE kezelését egy másik bérlő Azure Key Vaultjában vagy Azure Managed HSM-ben tárolt kulcsokkal.

Megjegyzés:

A rendszer által hozzárendelt felügyelt identitás adatbázisszinten nem támogatott.

Az ügyfél által felügyelt TDE előnyei az adatbázis szintjén

Mivel egyre több szolgáltató, más néven független szoftverszállítók (ISV-k) használják az Azure SQL Database-t a szolgáltatásaik összeállítására, sokan rugalmas készletekhez fordulnak, hogy hatékonyan oszthassák el a számítási erőforrásokat több adatbázis között. Az ügyfelek adatbázisainak megosztott rugalmas készletben való használatával az ISV-k kihasználhatják a készlet erőforrás-kihasználtságának optimalizálását, miközben továbbra is biztosítják, hogy minden adatbázis megfelelő erőforrásokkal rendelkezik.

Ennek a megközelítésnek azonban van egy jelentős korlátozása. Ha több adatbázist is üzemeltet ugyanazon az Azure SQL logikai kiszolgálón, akkor a kiszolgálószintű TDE-védelemmel rendelkeznek. Az ISV-k nem tudnak valódi ügyfél által felügyelt kulcsokat (CMK) kínálni ügyfeleiknek. A saját titkosítási kulcsok kezelése nélkül előfordulhat, hogy az ügyfelek nem hajlandók bizalmas adatokat megbízni az ISV szolgáltatásával, különösen akkor, ha a megfelelőségi előírások megkövetelik, hogy teljes körű ellenőrzést tartsanak fenn a titkosítási kulcsok felett.

Az adatbázisszintű TDE CMK-val az ISV-k CMK-képességet biztosíthatnak ügyfeleiknek, és biztonságos elkülönítést érhetnek el, mivel az egyes adatbázisok TDE-védelmi eszközét potenciálisan az adott ISV-ügyfél birtokolhatja a Key Vaultban vagy a saját felügyelt HSM-ben. Az ISV ügyfelei számára elért biztonsági elkülönítés mind a kulcs , mind a kulcs eléréséhez használt identitás szempontjából van.

Az alábbi ábra a fent jelzett új funkciókat foglalja össze. Két különálló Microsoft Entra-bérlőt mutat be. Az Best Services bérlő, amely tartalmazza az Azure SQL logikai szervert két adatbázissal, DB 1 és DB 2, valamint a Azure Key Vault 1, amely Key 1 hozzáféréssel használja a UMI 1 az DB 1 adatbázist. Mindkettőt UMI 1 , és Key 1 a kiszolgálószintű beállítást képviseli. Alapértelmezés szerint a kiszolgálón kezdetben létrehozott összes adatbázis örökli ezt a beállítást a TDE-hez a CMK-val. A Contoso bérlő egy olyan ügyfélbérlő, amely tartalmaz Azure Key Vault 2, és egy Key 2 értékeli az adatbázist DB 2 a bérlőn belül, a különböző bérlők közötti adatbázisszintű CMK támogatás részeként, a Key 2 és UMI 2 beállítások használatával ebben az adatbázisban.

A bérlők közötti identitáskonfigurációval kapcsolatos további információkért tekintse meg a kiszolgálószintű dokumentumot, amely transzparens adattitkosítással rendelkező, bérlők közötti ügyfél által felügyelt kulcsokat tartalmaz.

Támogatott kulcskezelési forgatókönyvek

A következő szakaszban tegyük fel, hogy van egy kiszolgáló, amely három adatbázisból (például Database1, Database2és Database3) áll.

Meglévő forgatókönyv

Key1 az ügyfél által felügyelt kulcsként van konfigurálva a logikai kiszolgáló szintjén. A kiszolgáló összes adatbázisa ugyanazt a kulcsot örökli.

• Kiszolgáló – Key1 beállítva CMK-ként
• Database1 – Key1 CMK-ként használatos
• Database2 – Key1 CMK-ként használatos
• Database3 – Key1 CMK-ként használatos

Új támogatott forgatókönyv: Ügyfél által felügyelt kulccsal konfigurált logikai kiszolgáló

Key1 az ügyfél által felügyelt kulcsként van konfigurálva a logikai kiszolgáló szintjén. Az adatbázis szintjén egy másik ügyfél által felügyelt kulcs (Key2) konfigurálható.

• Kiszolgáló – Key1 beállítva CMK-ként
• Database1 – Key2 CMK-ként használatos
• Database2 – Key1 CMK-ként használatos
• Database3 – Key1 CMK-ként használatos

Megjegyzés:

Ha a logikai kiszolgáló ügyfél által felügyelt kulcsokkal van konfigurálva a TDE-hez, a logikai kiszolgáló egy önálló adatbázisa nem választható a szolgáltatás által felügyelt kulcsok transzparens adattitkosításhoz való használatára.

Új támogatott forgatókönyv: Szolgáltatás által felügyelt kulccsal konfigurált logikai kiszolgáló

A logikai kiszolgáló a TDE szolgáltatás által felügyelt kulcsával (SMK) van konfigurálva. Az adatbázis szintjén egy másik ügyfél által felügyelt kulcs (Key2) konfigurálható.

• Kiszolgáló – Szolgáltatás által felügyelt kulcskészlet mint TDE-védő
• Database1 – Key2 CMK-ként beállítva
• Database2 – A szolgáltatás által felügyelt kulcscsomag TDE-védőként
• Database3 – Szolgáltatás által felügyelt kulcskészlet TDE-védőként

Visszaállítás kiszolgálószintű titkosításra

Database1 adatbázisszintű, ügyfél által felügyelt kulccsal van konfigurálva a TDE-hez, míg a logikai kiszolgáló szolgáltatás által felügyelt kulcsot használ. Database1 a logikai kiszolgálószintű szolgáltatás által felügyelt kulcs használatára visszaállítható.

Megjegyzés:

Ha a logikai kiszolgáló a TDE-hez készült CMK-val van konfigurálva, az adatbázisszintű CMK-val konfigurált adatbázis nem állítható vissza kiszolgálószintű titkosításra.

Bár a visszaállítási művelet csak akkor támogatott, ha a logikai kiszolgáló szolgáltatás által felügyelt kulccsal van konfigurálva a TDE használatakor, az adatbázisszintű CMK-val konfigurált adatbázis visszaállítható a CMK-val konfigurált kiszolgálóra, feltéve, hogy a kiszolgáló hozzáfér a forrásadatbázis által használt összes kulcshoz érvényes identitással.

Azure Key Vault és Azure Managed HSM – felügyelt identitáskövetelmények

Az adatbázisszintű CMK-ra ugyanazok a követelmények vonatkoznak az Azure Key Vault vagy az Azure felügyelt HSM-kulcsok és felügyelt identitások konfigurálására, beleértve a kiszolgálószintű ügyfél által felügyelt kulcs (CMK) szolgáltatásra vonatkozó identitáshoz megadott kulcsbeállításokat és engedélyeket is. További információ: Transzparens adattitkosítás (TDE) CMK-val és felügyelt identitásokkal CMK-val.

Kulcskezelés (digitális kulcsok)

Az adatbázis TDE-védőjének elforgatása azt jelenti, hogy az adatbázist védő új aszimmetrikus kulcsra vált. A kulcsváltás egy online művelet, és csak néhány másodpercet vesz igénybe. A művelet csak az adatbázis titkosítási kulcsát fejti vissza és titkosítja újra, nem a teljes adatbázist. Ha egy érvényes, felhasználó által hozzárendelt felügyelt identitást hozzárendeltek egy adatbázishoz, a kulcs az adatbázis szintjén történő elforgatása egy adatbázis CRUD művelete, amely magában foglalja az adatbázis titkosítási védelmi tulajdonságának frissítését. A Set-AzSqlDatabase és a tulajdonság -EncryptionProtector használható kulcsok elforgatására. Az adatbázisszintű CMK-val konfigurált új adatbázis létrehozásához a New-AzSqlDatabase használható a , -AssignIdentityés -UserAssignedIdentityId paraméterekkel-EncryptionProtector.

Új kulcsok vehetők fel, és a meglévő kulcsok hasonló kérések használatával és az adatbázis-erőforrás kulcstulajdonságának módosításával távolíthatók el az adatbázisból. Set-AzSqlDatabase paraméterrel -KeyList , és -KeysToRemove ezekhez a műveletekhez használható. A titkosítási védő, az identitás és a kulcsok beállításának lekéréséhez a Get-AzSqlDatabase használható. Az Azure Resource Manager Microsoft.Sql/servers/databases erőforrása alapértelmezés szerint csak az adatbázisban konfigurált TDE-védőt és felügyelt identitást jeleníti meg. A kulcsok teljes listájának kibontásához más paraméterekre is szükség van, például -ExpandKeyList . Emellett -KeysFilter "current" egy időérték (például 2023-01-01) segítségével lekérheti a használt aktuális kulcsokat és a múltban használt kulcsokat egy adott időpontban.

Automatikus kulcsváltás

Az automatikus kulcsforgatás az adatbázis szintjén érhető el, és az Azure Key Vault vagy az Azure Managed HSM billentyűkkel használható. A forgás a kulcs új verziójának észlelésekor aktiválódik, és 24 órán belül automatikusan el lesz forgatva. Az automatikus kulcsváltás az Azure Portal, a PowerShell vagy az Azure CLI használatával történő konfigurálásáról az automatikus kulcsváltás az adatbázis szintjén című témakörben olvashat.

Kulcskezelésre vonatkozó engedély

Válassza ki a használni kívánt kulcstartó típusát.

Azure Key Vault

A kulcstartó engedélymodelljének (hozzáférési szabályzat vagy Azure RBAC) függvényében a kulcstartó hozzáférése a kulcstartón létrehozott hozzáférési szabályzattal vagy egy új Azure RBAC-szerepkör-hozzárendelés létrehozásával biztosítható.

Hozzáférési szabályzat engedélymodellje

Ahhoz, hogy az adatbázis az Azure Key Vaultban tárolt TDE-védelmi eszközt használhassa a DEK titkosításához, az Azure Key Vault rendszergazdájának a következő hozzáférési jogosultságokat kell biztosítania az adatbázis felhasználó által hozzárendelt felügyelt identitásához az egyedi Microsoft Entra-identitás használatával:

• get – a kulcs nyilvános részének és tulajdonságainak lekérése az Azure Key Vaultban.
• wrapKey – a DEK védelme (titkosítása) érdekében.
• unwrapKey – a DEK védelmének feloldásához (visszafejtéséhez).

Azure RBAC-engedélymodell

Ahhoz, hogy az adatbázis az Azure Key Vaultban tárolt TDE-védőt használja a DEK titkosításához, hozzá kell adni egy új Azure RBAC-szerepkör-hozzárendelést a Key Vault crypto service encryption user szerepkörrel az adatbázis felhasználó által hozzárendelt felügyelt identitásához az egyedi Microsoft Entra-identitás használatával.

Felügyelt Azure HSM

Ahhoz, hogy az adatbázis az Azure Managed HSM-ben tárolt TDE-védőt használja a DEK titkosításához, a felügyelt HSM-titkosítási felhasználónak hozzáférési jogosultságokat kell adnia az adatbázis felhasználó által hozzárendelt felügyelt identitásához az egyedi Microsoft Entra-identitás használatával. A felügyelt HSM-rendszergazdai szerepkör nem ad engedélyt kulcs létrehozására. A kiszolgálóidentitásnak a felügyelt HSM titkosítási felhasználóra vagy felügyelt HSM titkosítási szolgáltatás titkosítási felhasználói szerepkörre van szüksége a körbefuttatási és a feloldási műveletek végrehajtásához.

További információ a helyi RBAC beépített szerepköreiről és az Azure Managed HSM engedélyezett műveleteiről: Helyi RBAC beépített szerepkörök felügyelt HSM-hez.

Bérlők közötti ügyfél által felügyelt kulcsok

A bérlők közötti ügyfél által felügyelt kulcsok transzparens adattitkosítással azt ismertetik, hogyan kell beállítani egy federált ügyfélazonosítót a kiszolgálószintű CMK-hoz. Hasonló beállítást kell elvégezni az adatbázisszintű CMK-hoz, és az összevont ügyfélazonosítót hozzá kell adni a Set-AzSqlDatabase vagy a New-AzSqlDatabase API-kérések részeként.

Megjegyzés:

Ha a több-bérlős alkalmazás nem lett hozzáadva a kulcstárhoz vagy a felügyelt HSM-hez a szükséges engedélyekkel (Get, Wrap Key, Unwrap Key), akkor az Azure Portal identitásfederációs alkalmazás használatakor hibaüzenet jelenik meg. Az összevont ügyfélidentitás konfigurálása előtt győződjön meg arról, hogy az engedélyek megfelelően vannak konfigurálva.

Az adatbázisszintű CMK-val konfigurált adatbázisok visszaállíthatók kiszolgálószintű titkosításra, ha a logikai kiszolgáló szolgáltatás által felügyelt kulccsal van konfigurálva az Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert használatával.

Ha a CMK-val végzett Transzparens adattitkosítás (TDE) nem érhető el, a kulcshozzáférés kijavítása után az Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation használatával ismét hozzáférhetővé teheti az adatbázist.

Megjegyzés:

A TDE identitás- és kulcskezelése adatbázisszintű ügyfél által felügyelt kulcsokkal részletesen ismerteti az adatbázisszintű CMK identitás- és kulcskezelési műveleteit, valamint a PowerShellt, az Azure CLI-t és a REST API-példákat.

További szempontok

• Ha a CMK-val rendelkező TDE már engedélyezve van a kiszolgáló szintjén, a CMK beállítása egy adott adatbázishoz felülírja a kiszolgálószintű CMK-beállítást (az adatbázis DEK-ját újra titkosítja az adatbázisszintű TDE-védő).
• A logikai kiszolgálószintű kulcsok változásai vagy rotációi nem befolyásolják az adatbázisszintű CMK-beállításokat, és az adatbázis továbbra is saját CMK-beállítást használ.
• Az adatbázisszintű CMK nem támogatott a Transact-SQL (T-SQL) használatával.
• A logikai kiszolgáló felhasználó által hozzárendelt felügyelt identitása (UMI) az adatbázis szintjén használható. Ajánlott azonban egy kijelölt UMI használata az adatbázisszintű CMK-hoz.
• A kiszolgálószintű bérlők közötti CMK-beállítások nincsenek hatással az adatbázisszintű CMK-val konfigurált egyes adatbázisokra, és továbbra is saját bérlői vagy bérlőközi konfigurációt használnak.
• Az adatbázis szintjén csak egyetlen felhasználó által hozzárendelt felügyelt identitás állítható be.

Megjegyzés:

Az adatbázis felügyelt identitását újra kell hozzárendelni, ha az adatbázist átnevezték.

Meglévő adatbázisok áttelepítése adatbázisszintű CMK-ba

Az új adatbázisok adatbázisszintű CMK-val konfigurálhatók a létrehozás során, és a szolgáltatás által felügyelt kulcsokkal konfigurált kiszolgálók meglévő adatbázisai áttelepíthetők az adatbázisszintű CMK-ba az identitás- és kulcskezelés tDE-hez az adatbázisszintű, ügyfél által felügyelt kulcsokkal végzett műveletekkel. A kiszolgálószintű CMK-val vagy georeplikálással konfigurált adatbázisok áttelepítéséhez további lépésekre van szükség az alábbi szakaszokban leírtak szerint.

Kiszolgálószintű CMK-val georeplikációs nélkül konfigurált adatbázis

1. Használja a sys.dm_db_log_info (Transact-SQL) – SQL Servert az adatbázishoz, és keresse meg az aktív virtuális naplófájlokat (VLF-eket).
2. Az összes aktív virtuális naplófájl esetében jegyezze fel a vlf_encryptor_thumbprint-t a sys.dm_db_log_info eredményből.
3. A sys.dm_database_encryption_keys (Transact-SQL) – SQL Server nézetet használja az adatbázisához, hogy ellenőrizze encryptor_thumbprint. Jegyezze fel a encryptor_thumbprint.
4. A Get-AzSqlServerKeyVaultKey parancsmaggal lekérheti a logikai kiszolgálón konfigurált összes kiszolgálószintű kulcsot. Az eredmények közül válassza ki azokat, amelyek ujjlenyomata megegyezik a fenti találatok listájával.
5. Hozzon létre egy frissítési adatbázis API-hívást a migrálni kívánt adatbázishoz az identitás- és titkosításvédelemmel együtt. Adja át a fenti kulcsokat adatbázisszintű kulcsként a Set-AzSqlDatabase használatával a -UserAssignedIdentityId, -AssignIdentity, -KeyList-EncryptionProtector , (és ha szükséges) -FederatedClientIdparaméterekkel.

Fontos

A frissítési adatbázis-kérelemben használt identitásnak hozzáféréssel kell rendelkeznie a bemenetként átadott összes kulcshoz.

Kiszolgálószintű CMK-val konfigurált adatbázis georeplikációs szolgáltatással

1. A migráláshoz szükséges kulcsok listájának lekéréséhez kövesse az előző szakaszban említett (1)–(4) lépéseket.
2. Hozzon létre egy frissítési adatbázis API-hívást a migrálni kívánt elsődleges és másodlagos adatbázishoz, az identitással és a fenti kulcsokkal együtt adatbázisszintű kulcsként a Set-AzSqlDatabase és a -KeyList paraméter használatával. Még ne állítsa be a titkosítási védőt.
3. Az adatbázisok elsődleges védelmeként használni kívánt adatbázisszintű kulcsot először hozzá kell adni a másodlagos adatbázishoz. Használja a Set-AzSqlDatabase parancsot, hogy -KeyList hozzáadja ezt a kulcsot a másodlagos adatbázishoz.
4. Miután hozzáadta a titkosítási védőkulcsot a másodlagos adatbázishoz, a Set-AzSqlDatabase használatával állítsa be az elsődleges adatbázis titkosítási védelmezőjeként a -EncryptionProtector paraméter használatával.
5. Állítsa be a kulcsot titkosítási védőként a másodlagos adatbázisban a (4) szakaszban leírtak szerint a migrálás befejezéséhez.

Fontos

A kiszolgálószintű szolgáltatás által felügyelt kulccsal és georeplikálással konfigurált adatbázisok áttelepítéséhez kövesse a szakasz (3), (4) és (5) lépéseit.

Georeplikációs és magas rendelkezésre állás

Az aktív georeplikációs és feladatátvételi csoportok esetében az érintett elsődleges és másodlagos adatbázisok ugyanahhoz a kulcstartóhoz vagy felügyelt HSM-hez (bármely régióban) csatolhatók, vagy külön kulcstartókhoz vagy felügyelt HSM-ekhez. Ha különálló kulcstartók vagy felügyelt HSM-ek kapcsolódnak az elsődleges és a másodlagos kiszolgálókhoz, az ügyfél feladata, hogy a kulcsanyagot a kulcstartókban vagy a felügyelt HSM-ekben konzisztensen tárolja, hogy a földrajzi szekunder rendszer szinkronban legyen, és átvehesse ugyanazt a kulcsot a csatolt kulcstartóból vagy a felügyelt HSM-ből, ha a régió leállása miatt az elsődleges elérhetetlenné válik és aktiválódik a feladatátvétel. Legfeljebb négy másodfok konfigurálható, és a láncolás (másodfokú másodfokok) nem támogatott.

Az adatbázisszintű CMK-val konfigurált adatbázisok aktív georeplikájának létrehozásához létre kell hozni egy másodlagos replikát érvényes, felhasználó által hozzárendelt felügyelt identitással és az elsődleges adatbázis által használt aktuális kulcsok listájával. Az aktuális kulcsok listája lekérhető az elsődleges adatbázisból a szükséges szűrők és lekérdezési paraméterek használatával, vagy a PowerShell és az Azure CLI használatával. Az ilyen adatbázisok georeplika beállításához szükséges lépések a következők:

1. Az elsődleges adatbázis által használt kulcsok listájának előzetes feltöltése a Get-AzSqlDatabase paranccsal, valamint a -ExpandKeyList paraméterekkel -KeysFilter "current" . Zárja ki -KeysFilter , ha le szeretné kérni az összes kulcsot.
2. Válassza ki a felhasználó által hozzárendelt felügyelt identitást (és összevont ügyfél-azonosítót, ha bérlőközi hozzáférést konfigurál).
3. Hozzon létre egy új adatbázist másodlagos adatbázisként a New-AzSqlDatabaseSecondary használatával, és adja meg a forrásadatbázisból és a korábban említett identitásból beszerzett kulcsok előre feltöltött listáját (valamint a bérlők közötti hozzáférés konfigurálásához összevont ügyfél-DI-t) az API-hívásban az -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (és ha szükséges, -FederatedClientId) paraméterekkel.
4. A New-AzSqlDatabaseCopy használatával hozzon létre egy másolatot az adatbázisról ugyanazokkal a paraméterekkel az előző lépésben.

Fontos

Az adatbázisszintű CMK-val konfigurált adatbázisoknak rendelkezniük kell egy, az adatbázisszintű CMK-val konfigurált replikával (vagy másolattal). A replika nem használhat kiszolgálószintű titkosítási beállításokat.

Ahhoz, hogy egy feladatátvevő csoportban adatbázisszintű CMK-val konfigurált adatbázist használhasson, a másodlagos kiszolgálón az elsődleges replikával azonos nevű másodlagos replika létrehozásának fenti lépéseit kell használni. A másodlagos replika konfigurálása után az adatbázisok hozzáadhatók a feladatátvételi csoporthoz.

Az adatbázisszintű CMK-val konfigurált adatbázisok nem támogatják az automatikus másodlagos létrehozást feladatátvételi csoporthoz való hozzáadásakor.

További információkért a geo replikáció és biztonsági mentés visszaállításának konfigurálása transzparens adattitkosításhoz, adatbázisszintű ügyfél által kezelt kulcsokkal című rész leírja, hogyan állíthat be geo replikációs és feladatátvételi csoportokat a REST API-k, PowerShell és az Azure CLI használatával.

Megjegyzés:

A georeplikálással és a magas rendelkezésre állással kapcsolatos, a transzparens adattitkosításban (TDE) a kiszolgálószintű CMK-val kiemelt ajánlott eljárások vonatkoznak az adatbázisszintű CMK-ra is.

Adatbázis biztonsági mentése és visszaállítása TDE használatával, ügyfél által felügyelt kulccsal az adatbázis szintjén

Ha egy adatbázist TDE-vel titkosít az Azure Key Vaultból vagy az Azure Managed HSM-ből származó kulccsal, az újonnan létrehozott biztonsági másolatok is ugyanazzal a TDE-védővel lesznek titkosítva. A TDE-védő módosításakor az adatbázis régi biztonsági másolatai nem frissülnek a legújabb TDE-védő használatára. Az Azure Key Vaultból vagy az adatbázis szintjén konfigurált Azure Managed HSM-ből TDE-védelemmel titkosított biztonsági mentés visszaállításához győződjön meg arról, hogy a kulcsanyag a céladatbázishoz van adva. Javasoljuk, hogy a TDE-védő összes régi verzióját tartsa a Key Vaultban vagy a felügyelt HSM-ben, hogy az adatbázis biztonsági másolatai visszaállíthatók legyenek.

Fontos

Adatbázishoz csak egy TDE-védő állítható be. A visszaállítás során azonban több további kulcs is átadható egy adatbázisnak TDE-védő megjelölése nélkül. Ezek a kulcsok nem a DEK védelmére szolgálnak, de biztonsági másolatból történő visszaállításkor használhatók, ha a biztonsági mentési fájl a megfelelő ujjlenyomattal ellátott kulccsal van titkosítva.

Időponthoz kötött visszaállítás

A következő lépések szükségesek egy adatbázis adatbázisszintű, ügyfél által felügyelt kulcsokkal konfigurált időponthoz kötött visszaállításához:

1. Az elsődleges adatbázis által használt kulcsok listájának előzetes feltöltése a Get-AzSqlDatabase paranccsal, valamint a -ExpandKeyList paraméterekkel -KeysFilter "2023-01-01" . 2023-01-01 Ez egy példa arra az időpontra, amelybe vissza szeretné állítani az adatbázist. Zárja ki -KeysFilter , ha le szeretné kérni az összes kulcsot.
2. Válassza ki a felhasználó által hozzárendelt felügyelt identitást (és összevont ügyfél-azonosítót, ha bérlőközi hozzáférést konfigurál).
3. Használja a Restore-AzSqlDatabase parancsot a -FromPointInTimeBackup paraméterrel, és adja meg a fenti lépésekből beszerzett kulcsok előre megadott listáját, valamint a fenti identitást (és a bérlők közötti hozzáférés konfigurálásához összevont ügyfél-azonosítót) az API-hívásban a -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (és ha szükséges, -FederatedClientId) paraméterekkel.

Megjegyzés:

Ha egy adatbázist a tulajdonság nélkül állít vissza az -EncryptionProtector összes érvényes kulccsal, az visszaállítja azt a kiszolgálószintű titkosítás használatára. Ez hasznos lehet egy adatbázisszintű, ügyfél által felügyelt kulcskonfiguráció kiszolgálószintű, ügyfél által felügyelt kulcskonfigurációra való visszaállításához.

Elvetett adatbázis-visszaállítás

Az adatbázisszintű, ügyfél által felügyelt kulcsokkal konfigurált adatbázisok elvetett adatbázis-visszaállításához a következő lépések szükségesek:

1. Az elsődleges adatbázis által használt kulcsok listájának előzetes feltöltése a Get-AzSqlDeletedDatabaseBackup és a -ExpandKeyList paraméter használatával. Javasoljuk, hogy adja át a forrásadatbázis által használt összes kulcsot, de a visszaállítást a törlési idő -KeysFilteráltal megadott kulcsokkal is meg lehet kísérelni.
2. Válassza ki a felhasználó által hozzárendelt felügyelt identitást (és összevont ügyfél-azonosítót, ha bérlőközi hozzáférést konfigurál).
3. Használja a Restore-AzSqlDatabase-ot a -FromDeletedDatabaseBackup paraméterrel, és adja meg a fenti lépésekből, valamint a fenti identitásból, (valamint a bérlők közötti hozzáférés konfigurálásakor az összevont ügyfél-azonosítóból) származó előre feltöltött kulcsok listáját az API-hívás során a -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (és ha szükséges, -FederatedClientId) paraméterekkel.

Georeduktúra visszaállítása

Az alábbi lépések szükségesek egy ügyfél által kezelt kulcsokkal adatbázisszinten konfigurált adatbázis helyreállításához földrajzi szinten:

• Az elsődleges adatbázis által használt kulcsok listájának előre feltöltése a Get-AzSqlDatabaseGeoBackup használatával és az -ExpandKeyList segítségével az összes kulcs lekéréséhez.
• Válassza ki a felhasználó által hozzárendelt felügyelt identitást (és összevont ügyfél-azonosítót, ha bérlőközi hozzáférést konfigurál).
• Használja a Restore-AzSqlDatabase utasítást a -FromGeoBackup paraméterrel, és az előre kitöltött kulcslistát, amelyet a fenti lépésekből és a fenti identitásból (valamint bérlők közötti hozzáférés beállításakor az összevont ügyfél-azonosítóból) szereztek meg. Az API-hívás során a következő paramétereket használja: -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (és ha szükséges, -FederatedClientId).

Fontos

Javasoljuk, hogy az adatbázis által használt összes kulcs megmaradjon az adatbázis visszaállításához. Azt is javasoljuk, hogy ezeket a kulcsokat adja át a visszaállítási célhelynek.

Megjegyzés:

A hosszú távú biztonsági mentési (LTR) biztonsági másolatok nem tartalmazzák a biztonsági másolat által használt kulcsok listáját. Az LTR biztonsági mentésének visszaállításához a forrásadatbázis által használt összes kulcsot át kell adni az LTR visszaállítási célnak.

Ha többet szeretne megtudni az SQL Database biztonsági mentési helyreállításáról adatbázisszintű CMK-val, példákkal a PowerShell, az Azure CLI és a REST API-k használatával, olvassa el a georeplikálás és a biztonsági mentés visszaállításának konfigurálása transzparens adattitkosításhoz adatbázisszintű ügyfél által felügyelt kulcsokkal.

Korlátozások

Az adatbázisszintű, ügyfél által felügyelt kulcsok funkció nem támogatja a kulcsváltást, ha az adatbázis virtuális naplófájljai olyan régi kulccsal vannak titkosítva, amely eltér az adatbázis jelenlegi elsődleges védelmezőétől. Ebben az esetben a következő hibaüzenet jelenik meg:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: A TDE-védő kulcsforgatása az adatbázis szintjén le lesz tiltva, ha az aktív tranzakciók a régi kulcsokkal titkosított naplót tartják.

A forgatókönyv további megértéséhez tekintsük át a következő ütemtervet:

• T0 idő = Az adatbázis titkosítás nélkül jön létre
• T1 idő = Ezt az adatbázist egy adatbázisszintű, ügyfél által Thumbprint Afelügyelt kulcs védi.
• Idő t2 = A rendszer az adatbázis védelmet egy új adatbázisszintű, ügyfél által felügyelt kulcsra forgatja. Thumbprint B
• T3 idő = A védelem módosítására Thumbprint C van szükség.
• Ha az aktív VLF-ek használatban vannak Thumbprint A, a forgatás nem engedélyezett.
• Ha az aktív VLF-eket nem használja Thumbprint A, a forgatás engedélyezett.

Használhatja a sys.dm_db_log_info (Transact-SQL) – SQL Server nézetet az adatbázishoz, és megkeresheti az aktív virtuális naplófájlokat. Az első kulccsal titkosított aktív VLF-nek kell megjelennie (például Thumbprint A). Miután elegendő naplót hozott létre az adatbeszúrással, a rendszer kiüríti ezt a régi VLF-et, és képesnek kell lennie egy másik kulcsforgatás végrehajtására.

Ha úgy véli, hogy valami a vártnál hosszabb ideig tartja a naplóját, a további hibaelhárításhoz tekintse meg az alábbi dokumentációt:

• sys.dm_db_log_stats (Transact-SQL) a lehetséges log_truncation_holdup_reason értékekhez.
• A 9002-ben észlelt teljes tranzakciónapló-hiba elhárítása.

Következő lépések

Tekintse meg a következő dokumentációt a különböző adatbázisszintű CMK-műveletekről:

• TDE identitás- és kulcskezelése adatbázisszintű, ügyfél által felügyelt kulcsokkal

• Georeplikációs és biztonsági mentési visszaállítás konfigurálása transzparens adattitkosításhoz adatbázisszintű, ügyfél által felügyelt kulcsokkal