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

A következőre 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 az Azure Active Directory (Azure AD) új neve. Jelenleg frissítjük a dokumentációt.

Áttekintés

Az Azure SQL transzparens adattitkosítással (TDE) biztosít titkosítást az ügyfelek számára. A TDE ügyfél által felügyelt kulccsal (CMK) való kiterjesztése lehetővé teszi az inaktív adatok védelmét, ahol a TDE-védő (a titkosítási kulcs) az adatbázis titkosítási kulcsait titkosító Azure Key Vaultban van tárolva. A CMK-val rendelkező TDE jelenleg a kiszolgáló szintjén van beállítva, és a kiszolgálóhoz társított összes titkosított adatbázis örökli. Ez az új funkció lehetővé teszi a TDE-védő ügyfél által felügyelt kulcsként való beállítását egyenként a kiszolgálón belüli összes adatbázishoz. Minden Microsoft.Sql/servers/databases érvényes, egyetlen tulajdonsággal nem rendelkező encryptionProtector erőforrás 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 (AKV) 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, amelyet TDE-védőnek neveznek. 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 Vault eléréséhez é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 hozzárendelt felügyelt identitást használják az Azure Key Vault eléréséhez.
• Összevont ügyfélidentitás: Az Azure Key Vaultból egy másik Microsoft Entra-bérlőben lévő ügyfél által felügyelt kulcs (CMK) is beállítható TDE-védőké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 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 modulja az adott ISV-ügyfél tulajdonában lehet egy saját kulcstartóban. 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 Azure SQL logikai kiszolgálót tartalmazó bérlő két adatbázissal, DB 1 valamint DB 2az Azure Key Vault 1 adatbázishoz DB 1 való hozzáféréssel Key 1UMI 1. 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érlelőt jelöl, amely Azure Key Vault 2 az adatbázist DB 2 az adatbázisszint CMK-bérlők közötti támogatásának részeként, az adatbázis használatával Key 2 és UMI 2 beállításával Key 2 értékeli a bérlő egészében.

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ítás 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ítás 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 TDE-védőként
• Database1 – Key2 beállítás CMK-ként
• Database2 – Szolgáltatás által felügyelt kulcskészlet 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 A TDE-hez adatbázisszintű ügyfél által felügyelt kulccsal van konfigurálva, míg a logikai kiszolgáló szolgáltatás által felügyelt kulccsal van konfigurálva. 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.

A Key Vault és a felügyelt identitás követelményei

Az adatbázisszintű CMK-ra ugyanazok a követelmények vonatkoznak az Azure Key Vault (AKV) kulcsainak és felügyelt identitásainak konfigurálására, beleértve az identitásnak adott kulcsbeállításokat és engedélyeket is, amelyek a kiszolgálószintű ügyfél által felügyelt kulcs (CMK) szolgáltatásra vonatkoznak. További információ: transzparens adattitkosítás (TDE) CMK-val és felügyelt identitásokkal a CMK-val.

Kulcskezelés

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 kulcsváltás az adatbázis szintjén érhető el, és az Azure Key Vault-kulcsokkal is 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

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 AKV-ban tárolt TDE-védelmi eszközt használhassa a DEK titkosításához, a kulcstartó 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 AKV-ban 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.

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 állíthat be összevont ü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 kulcstartó hozzáférési szabályzatához a szükséges engedélyekkel (Get, Wrap Key, Unwrap Key), az identitás-összevonási alkalmazás használata az Azure Portalon hibaüzenetet fog mutatni. 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 akadálymentessé 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 gép esetében jegyezze fel az vlf_encryptor_thumbprintsys.dm_db_log_info eredményt.
3. Az adatbázishoz tartozó sys.dm_database_encryption_keys (Transact-SQL) – SQL Server nézet használatával ellenőrizheti az adatbázist 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. A Set-AzSqlDatabase használatával -KeyListadja hozzá 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 (bármely régióban) vagy a kulcstartók elkülönítéséhez csatolhatók. Ha az elsődleges és a másodlagos kiszolgálókhoz különálló kulcstartók vannak csatlakoztatva, az ügyfél felelős azért, hogy a kulcsadatok konzisztensek maradjanak a kulcstartók között, hogy a földrajzilag másodlagos kiszolgáló szinkronizált legyen, és ugyanazt a kulcsot tudja átvenni a csatlakoztatott kulcstartóból, ha az elsődleges kiszolgáló elérhetetlenné válik egy régióbeli kimaradás miatt és feladatátvétel aktiválódik. 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ásodlagosként a New-AzSqlDatabaseSecondary használatával, és adja meg a forrásadatbázisból és a fenti identitásból beszerzett kulcsok előre feltöltött listáját (és a bérlők közötti hozzáférés konfigurálásához összevont ügyfél-DI-t) az -KeyListAPI-hívásban a , -AssignIdentity, -EncryptionProtector-UserAssignedIdentityId, ( é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 konfigurálja a georeplikációs és biztonsági mentési visszaállítást transzparens adattitkosításhoz adatbázisszintű, ügyfél által felügyelt kulcsokkal , amely leírja, hogyan állíthat be georeplikációs és feladatátvételi csoportokat 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, transzparens adattitkosításban (TDE) és a CMK kiszolgálószintű CMK-val kapcsolatos ajánlott eljárások az adatbázisszintű CMK-ra vonatkoznak.

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

Miután egy adatbázist TDE-vel titkosított az Azure Key Vault kulcsával, 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 adatbázis szintjén konfigurált Azure Key Vault TDE-védőjével 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 egy kulcstartóban tartsa, 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 paramétert, -FromPointInTimeBackup és adja meg a fenti lépésekből beszerzett kulcsok előre feltöltött 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 ) -FederatedClientIdparamé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 paramétert, -FromDeletedDatabaseBackup és adja meg a fenti lépésekből és a fenti identitásból (és a bérlők közötti hozzáférés konfigurálásakor összevont ügyfél-azonosítóból) beszerzett kulcsok előre feltöltött listáját az API-hívásban a -KeyList, -AssignIdentity, -UserAssignedIdentityId-EncryptionProtector , (és ha szükséges) -FederatedClientIdparaméterekkel.

Georeduktúra visszaállítása

Az alábbi lépések szükségesek egy adatbázis adatbázisszintű, ügyfél által felügyelt kulcsokkal konfigurált georedukált visszaállításához:

• Az elsődleges adatbázis által használt kulcsok listájának előzetes feltöltése a Get-AzSqlDatabaseGeoBackup és az -ExpandKeyList ö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 paramétert, -FromGeoBackup és adja meg a fenti lépésekből és a fenti identitásból (és a bérlők közötti hozzáférés konfigurálásakor összevont ügyfél-azonosítóból) beszerzett kulcsok előre feltöltött listáját az API-hívásban a -KeyList, -AssignIdentity, -UserAssignedIdentityId-EncryptionProtector , (és ha szükséges) -FederatedClientIdparaméterekkel.

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élnak.

Megjegyzés:

A hosszú távú biztonsági mentési (LTR) biztonsági másolatok nem tartalmazzák a biztonsági mentés á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ául 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 kezelt 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.
• T2 idő = Az adatbázis-védőt egy új adatbázisszintű, ügyfél által felügyelt kulcsra forgatja a rendszer. Thumbprint B
• T3 idő = A védelem módosítására Thumbprint C van szükség.
• Ha az aktív VLF-eket használja 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.

További lépések

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

• Identitás- és kulcskezelés a TDE-hez 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