Azure SQL átlátható adattitkosítás ügyfél által kezelt kulccsal

A következőre vonatkozik: Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (csak dedikált SQL-készletek)

Az Azure SQL transzparens adattitkosítása (TDE) az ügyfél által felügyelt kulccsal (CMK) lehetővé teszi a Saját kulcs (BYOK) forgatókönyv használatát az inaktív adatok védelméhez, és lehetővé teszi a szervezetek számára a kulcsok és adatok kezelése során a feladatok elkülönítését. Az ügyfél által kezelt TDE révén teljes mértékben az ügyfél felelős és végzi az irányítást a kulcs életciklusát (vagyis a kulcs létrehozását, feltöltését, váltását és törlését), használati engedélyeit és a kulcsokkal végzett műveletek naplózását illetően.

Ebben a forgatókönyvben az adatbázistitkosítási kulcs (DEK) titkosításához használt kulcs, az úgynevezett TDE-védő egy ügyfél által felügyelt aszimmetrikus kulcs, amelyet egy felhőalapú külső kulcskezelő rendszer, az ügyfél által birtokolt és ügyfél által felügyelt Azure Key Vault (AKV) tárol. A Key Vault magas rendelkezésre állású és méretezhető biztonságos tároló az RSA titkosítási kulcsokhoz, opcionálisan a FIPS 140-2 2. szintű hitelesített hardverbiztonsági modulok (HSM-ek) segítségével. Nem teszi lehetővé a tárolt kulcs közvetlen elérését, de a kulcs használatával nyújt titkosítási/visszafejtési szolgáltatásokat az engedélyezett entitások számára. A kulcsot a kulcstartó hozhatja létre, importálhatja vagy áthelyezheti a kulcstartóba egy helyszíni HSM-eszközről.

Az Azure SQL Database és az Azure Synapse Analytics esetében a TDE-védő a kiszolgáló szintjén van beállítva, és a kiszolgálóhoz társított összes titkosított adatbázis örökli. Felügyelt Azure SQL-példány esetén a TDE-védő a példány szintjén van beállítva, és az adott példány összes titkosított adatbázisa örökli. A kiszolgáló kifejezés az SQL Database-ben és az Azure Synapse-ben lévő kiszolgálóra, valamint a felügyelt SQL-példányban lévő felügyelt példányra egyaránt vonatkozik a dokumentum egészében, kivéve, ha másként van feltüntetve.

A TDE-védő kezelése adatbázisszinten az Azure SQL Database-ben érhető el. További információ: Transzparens adattitkosítás (TDE) ügyfél által felügyelt kulcsokkal az adatbázis szintjén.

Megjegyzés:

• Ez a cikk az Azure SQL Database-re, a felügyelt Azure SQL-példányra és az Azure Synapse Analyticsre (dedikált SQL-készletekre (korábban SQL DW)) vonatkozik. A Synapse-munkaterületeken belüli dedikált SQL-készletek transzparens adattitkosításának dokumentációját az Azure Synapse Analytics titkosításában találja.
• Annak érdekében, hogy az Azure SQL-ügyfelek két rétegnyi inaktív adattitkosítást biztosítsanak, az infrastruktúra titkosítása (az AES-256 titkosítási algoritmus használatával) platform által felügyelt kulcsokkal történik. Ez egy további titkosítási réteget biztosít inaktív állapotban, valamint az ügyfél által felügyelt kulcsokkal rendelkező TDE-t, amely már elérhető. Az Azure SQL Database és a felügyelt Azure SQL-példány esetében minden adatbázis, beleértve az master adatbázist és más rendszeradatbázisokat is, titkosítva lesz, amikor az infrastruktúra-titkosítás be van kapcsolva. Jelenleg az ügyfeleknek hozzáférést kell kérnie ehhez a képességhez. Ha érdekli ez a funkció, lépjen kapcsolatba a következővel AzureSQLDoubleEncryptionAtRest@service.microsoft.com: .

Megjegyzés:

A Microsoft Entra ID az Azure Active Directory (Azure AD) új neve. Jelenleg frissítjük a dokumentációt.

Az ügyfél által felügyelt TDE előnyei

Az ügyfél által felügyelt TDE a következő előnyöket biztosítja az ügyfél számára:

• A TDE-védő használata és kezelése teljes körű és részletes vezérlése;

• A TDE-védő használatának átláthatósága;

• A kulcsok és adatok szervezeten belüli kezelése során a feladatok elkülönítésének lehetősége;

• A Key Vault rendszergazdája visszavonhatja a kulcshozzáférés engedélyeit a titkosított adatbázis elérhetetlenné tétele érdekében;

• Kulcsok központi kezelése az AKV-ban;

• Nagyobb bizalom a végfelhasználóktól, mivel az AKV úgy lett kialakítva, hogy a Microsoft ne láthassa és ne nyerje ki a titkosítási kulcsokat;

Fontos

Ha a szolgáltatás által kezelt TDE-t használók át kívánnak térni az ügyfél által kezelt TDE használatára, az adatok a váltás folyamata során titkosítottak maradnak, nincs állásidő, és az adatbázisfájlok újbóli titkosítására sincs szükség. A szolgáltatás által kezeltről ügyfél által kezelt kulcsra történő váltáshoz csak az adattitkosítási kulcs (DEK) újbóli titkosítása szükséges, amely egy gyors online folyamat keretében elvégezhető.

How customer-managed TDE works

Ahhoz, hogy az Azure logikai kiszolgálója az AKV-ban tárolt TDE-védőt használja a DEK titkosításához, a kulcstartó rendszergazdájának a következő hozzáférési jogosultságokat kell biztosítania a kiszolgáló számára az egyedi Microsoft Entra-identitás használatával:

• get – a kulcs nyilvános részének és tulajdonságainak lekérése a Key Vaultban

• wrapKey – a DEK védelme (titkosítása) érdekében

• unwrapKey – a DEK védelmének feloldásához (visszafejtéséhez)

A Key Vault rendszergazdája emellett engedélyezheti a Key Vault naplózási eseményeinek naplózását is, így később is naplózhatók.

Ha a kiszolgáló úgy van konfigurálva, hogy TDE-védőt használjon az AKV-tól, a kiszolgáló minden TDE-kompatibilis adatbázis DEK-ját elküldi a kulcstartóba titkosítás céljából. A Key Vault visszaadja a titkosított DEK-t, amelyet a rendszer ezután a felhasználói adatbázisban tárol.

Szükség esetén a kiszolgáló védett DEK-t küld a kulcstartóba a visszafejtéshez.

Az auditorok az Azure Monitor használatával áttekinthetik a Key Vault AuditEvent naplóit, ha a naplózás engedélyezve van.

Megjegyzés:

A kulcstartó engedélymódosításainak érvénybe lépése körülbelül 10 percet vehet igénybe. Ez magában foglalja a TDE-védő hozzáférési engedélyeinek visszavonását az AKV-ban, és az ezen időkereten belüli felhasználók továbbra is rendelkezhetnek hozzáférési engedélyekkel.

Az ügyfél által felügyelt TDE konfigurálásával kapcsolatos követelmények

Requirements for configuring AKV

• A kulcstartó helyreállítható törlési és törlési védelmi funkcióit engedélyezni kell a kulcstartóban a véletlen kulcs (vagy kulcstartó) törlése miatti adatvesztés elleni védelem érdekében.

• Adjon hozzáférést a kiszolgálónak vagy a felügyelt példánynak a Kulcstartóhoz (get, wrapKey, unwrapKey) a Microsoft Entra-identitásával. A kiszolgálóidentitás lehet rendszer által hozzárendelt felügyelt identitás vagy a kiszolgálóhoz hozzárendelt felhasználó által hozzárendelt felügyelt identitás. When using the Azure portal, the Microsoft Entra identity gets automatically created when the server is created. When using PowerShell or Azure CLI, the Microsoft Entra identity must be explicitly created and should be verified. A PowerShell használatakor részletes részletes útmutatást a TDE konfigurálása BYOK-tal és a felügyelt SQL-példányHOZ készült BYOK használatával című témakörben talál.

  • Depending on the permission model of the key vault (access policy or Azure RBAC), key vault access can be granted either by creating an access policy on the key vault, or by creating a new Azure RBAC role assignment with the role Key Vault Crypto Service Encryption User.

• Ha tűzfalat használ az AKV-val, engedélyeznie kell a megbízható Microsoft-szolgáltatások engedélyezését a tűzfal megkerüléséhez. További információ: Azure Key Vault-tűzfalak és virtuális hálózatok konfigurálása.

Helyreállítható törlés és törlés elleni védelem engedélyezése az AKV-hoz

Fontos

Az ügyfél által felügyelt TDE új vagy meglévő kiszolgálón vagy felügyelt példányon való konfigurálásakor a kulcstartón engedélyezni kell a helyreállítható törlést és a törlési védelmet is.

A helyreállítható törlés és törlés elleni védelem az Azure Key Vault fontos funkciói, amelyek lehetővé teszik a törölt tárolók és a törölt kulcstartó-objektumok helyreállítását, ezáltal csökkentve annak kockázatát, hogy egy felhasználó véletlenül vagy rosszindulatúan töröl egy kulcsot vagy egy kulcstartót.

• A helyreállíthatóan törölt erőforrások 90 napig maradnak meg, kivéve, ha az ügyfél helyreállítja vagy törli őket. A helyreállító és kiürítési műveletek saját engedélyekkel rendelkeznek egy kulcstartó hozzáférési szabályzatában. A helyreállítható törlés funkció alapértelmezés szerint be van kapcsolva az új kulcstartók esetében, és az Azure Portal, a PowerShell vagy az Azure CLI használatával is engedélyezhető.

• A törlés elleni védelem az Azure CLI-vel vagy a PowerShell-lel kapcsolható be. When purge protection is enabled, a vault or an object in the deleted state can't be purged until the retention period has passed. Az alapértelmezett megőrzési időszak 90 nap, de 7 és 90 nap között konfigurálható az Azure Portalon keresztül.

• Az Azure SQL-hez engedélyezni kell a helyreállítható törlési és törlési védelmet a kiszolgáló vagy felügyelt példány TDE-védőjeként használt titkosítási kulcsot tartalmazó kulcstartón. Ez segít megelőzni a véletlen vagy rosszindulatú kulcstartó vagy kulcstörlés forgatókönyvét, amely az adatbázis elérhetetlen állapotba kerüléséhez vezethet.

• Ha a TDE-védőt egy meglévő kiszolgálón vagy a kiszolgáló létrehozása során konfigurálja, az Azure SQL ellenőrzi, hogy a használt kulcstartóban be van-e kapcsolva a helyreállítható törlési és törlési védelem. Ha a helyreállítható törlés és törlés elleni védelem nincs engedélyezve a kulcstartón, a TDE-védő beállítása hiba miatt meghiúsul. Ebben az esetben először engedélyezni kell a helyreállítható törlési és törlési védelmet a kulcstartón, majd végre kell hajtani a TDE-védelmi beállításokat.

Requirements for configuring TDE protector

• TDE protector can only be an asymmetric, RSA, or RSA HSM key. A támogatott kulcshosszok 2048 és 3072 bit.

• The key activation date (if set) must be a date and time in the past. A lejárati dátumnak (ha be van állítva) jövőbeli dátumnak és időnek kell lennie.

• A kulcsnak engedélyezve kell lennie.

• Ha meglévő kulcsot importál a kulcstartóba, mindenképpen adja meg a támogatott fájlformátumokban (.pfx.byokvagy .backup).

Megjegyzés:

Az Azure SQL mostantól támogatja a felügyelt HSM-ben tárolt RSA-kulcs TDE-védőként való használatát. Az Azure Key Vault felügyelt HSM egy teljes körűen felügyelt, magas rendelkezésre állású, egybérlős, szabványoknak megfelelő felhőszolgáltatás, amely lehetővé teszi a titkosítási kulcsok védelmét a felhőalkalmazások számára a FIPS 140-2 3. szintű hitelesített HSM-ek használatával. További információ a felügyelt HSM-ekről.

Megjegyzés:

A Thales CipherTrust Manager 2.8.0-s verzió előtti verzióival kapcsolatos probléma megakadályozza, hogy az Azure Key Vaultba újonnan importált kulcsok az Azure SQL Database-hez vagy az Azure SQL Managed Instance-hez használva legyenek az ügyfél által felügyelt TDE-forgatókönyvekhez. A problémával kapcsolatos további részletek itt találhatók. Ilyen esetekben várjon 24 órát, miután importálta a kulcsot a Key Vaultba, hogy TDE-védőként használja a kiszolgáló vagy a felügyelt példány számára. Ezt a problémát a Thales CipherTrust Manager 2.8.0-s verzióban oldottuk meg.

Javaslatok az ügyfél által felügyelt TDE konfigurálásához

Javaslatok az AKV konfigurálásakor

• Legfeljebb 500 általános célú vagy 200 üzletileg kritikus adatbázist társíthat egyetlen előfizetés kulcstartójával, hogy magas rendelkezésre állást biztosítson, amikor a kiszolgáló hozzáfér a TDE-védőhöz a kulcstartóban. Ezek a számok a key vault szolgáltatás korlátainak tapasztalatain alapulnak, és dokumentálva vannak. A cél az, hogy megelőzze a kiszolgáló feladatátvétele után felmerülő problémákat, mivel annyi kulcsműveletet indít el a tárolón, mint amennyi adatbázis található a kiszolgálón.

• Állítson be egy erőforrás-zárolást a kulcstartón annak szabályozásához, hogy ki törölheti ezt a kritikus fontosságú erőforrást, hogy megakadályozza a véletlen vagy jogosulatlan törlést. További információ az erőforrás-zárolásokról.

• Az összes titkosítási kulcs naplózásának és jelentésének engedélyezése: A Key Vault olyan naplókat biztosít, amelyek könnyen beszúrhatóak más biztonsági információkba és eseménykezelési eszközökbe. Az Operations Management Suite Log Analytics egy példa egy már integrált szolgáltatásra.

• A titkosított adatbázisok magas rendelkezésre állásának biztosítása érdekében kapcsolja össze az egyes kiszolgálókat két különböző régióban található kulcstartóval, és tartsa ugyanazt a kulcsanyagot. Jelölje meg az egyik kulcstartó kulcsát TDE-védőként. A rendszer automatikusan átvált a kulcstartóra a második régióban ugyanazzal a kulcsanyaggal, ha az első régióban kimaradás van hatással a kulcstartóra.

Megjegyzés:

Az ügyfél által felügyelt TDE, az Azure SQL Database és az Azure SQL Managed Instance konfigurálásának nagyobb rugalmassága érdekében mostantól bármely más régióban összekapcsolható a Key Vault. The server and key vault do not have to be co-located in the same region.

Javaslatok TDE-védő konfigurálásakor

• Őrizze meg a TDE-védő másolatát egy biztonságos helyen, vagy helyezze el a letéti szolgáltatásba.

• Ha a kulcs a kulcstartóban jön létre, hozzon létre egy biztonsági másolatot a kulcsról az AKV-ban való első használat előtt. A biztonsági mentés csak Azure Key Vaultba állítható vissza. További információ a Backup-AzKeyVaultKey parancsról.

• Hozzon létre egy új biztonsági másolatot, amikor bármilyen módosítás történik a kulcson (például kulcsattribútumok, címkék, ACL-ek).

• A kulcsok elforgatásakor tartsa meg a kulcs korábbi verzióit a kulcstartóban, így a régebbi adatbázis-biztonsági másolatok visszaállíthatók. Ha egy adatbázis TDE-védője módosul, az adatbázis régi biztonsági másolatai nem frissülnek a legújabb TDE-védő használatára. At restore time, each backup needs the TDE protector it was encrypted with at creation time. A kulcsok elforgatása a transzparens adattitkosítási védő PowerShell-lel történő elforgatásával kapcsolatos utasításokat követve végezhető el.

• Még a szolgáltatás által kezelt kulcsra való váltás után is őrizze meg az összes korábban használt kulcsot az AKV-ben. Ezzel biztosíthatja, hogy az adatbázisok biztonsági másolatai visszaállíthatók legyenek az AKV-ben tárolt TDE-védőkkel. Az Azure Key Vaulttal létrehozott TDE-védőket mindaddig fenn kell tartani, amíg az összes többi tárolt biztonsági mentés szolgáltatás által felügyelt kulcsokkal nem lett létrehozva. Make recoverable backup copies of these keys using Backup-AzKeyVaultKey.

• Ha adatvesztés kockázata nélkül szeretne eltávolítani egy potenciálisan feltört kulcsot egy biztonsági incidens során, kövesse a potenciálisan feltört kulcs eltávolítása című szakasz lépéseit.

TDE-védő elforgatása

A kiszolgáló TDE-védőjének elforgatása azt jelenti, hogy egy új aszimmetrikus kulcsra vált, amely védi a kiszolgálón lévő adatbázisokat. 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.

A TDE-védő elforgatása manuálisan vagy az automatikus forgatási funkcióval végezhető el.

A TDE-védő automatikus elforgatása engedélyezhető a TDE-védő kiszolgálóhoz való konfigurálásakor. Az automatikus forgatás alapértelmezés szerint le van tiltva. Ha engedélyezve van, a kiszolgáló folyamatosan ellenőrzi a kulcstartót a TDE-védőként használt kulcs új verzióihoz. Ha a rendszer a kulcs új verzióját észleli, a kiszolgáló TDE-védője 60 percen belül automatikusan a legújabb kulcsverzióra vált.

Ha az Azure Key Vaultban automatizált kulcsforgatással használják, ez a funkció lehetővé teszi a teljes körű érintésmentes forgást az Azure SQL Database és a felügyelt Azure SQL-példány TDE-védelmezője számára.

Megjegyzés:

Ha a TDE-t a CMK-val manuális vagy automatikus kulcsforgatással állítja be, mindig a támogatott kulcs legújabb verzióját fogja használni. A beállítás nem teszi lehetővé a kulcsok korábbi vagy alacsonyabb verziójának használatát. Mindig a legújabb kulcsverzió használata megfelel az Azure SQL biztonsági szabályzatának, amely letiltja az esetlegesen feltört korábbi kulcsverziókat. A kulcs korábbi verzióira szükség lehet az adatbázis biztonsági mentéséhez vagy visszaállításához, különösen hosszú távú adatmegőrzési biztonsági mentések esetén, ahol a régebbi kulcsverziókat meg kell őrizni. A georeplikációs beállításokhoz a forráskiszolgáló által igényelt összes kulcsnak jelen kell lennie a célkiszolgálón.

Georeplikációs szempontok a TDE-védő automatikus forgásának konfigurálásakor

A georeplikáció létrehozásakor vagy közben felmerülő problémák elkerülése érdekében, ha a TDE-védő automatikus forgatása engedélyezve van az elsődleges vagy másodlagos kiszolgálón, a georeplikáció konfigurálásakor fontos az alábbi szabályok betartása:

• Mind az elsődleges, mind a másodlagos kiszolgálóknak get, wrapKey és unwrapKey engedélyekkel kell rendelkezniük az elsődleges kiszolgáló kulcstartójához (az elsődleges kiszolgáló TDE-védelmi kulcsát tartalmazó kulcstartóhoz).

• Ha az automatizált kulcsforgatás engedélyezve van, a georeplikáció megkezdése előtt adja hozzá az elsődleges kiszolgálón TDE-védőként használt titkosítási kulcsot a másodlagos kiszolgálóhoz. A másodlagos kiszolgálónak hozzáférésre van szüksége a kulcshoz ugyanabban a kulcstartóban, amelyet az elsődleges kiszolgáló használ (és nem egy másik kulcshoz ugyanazzal a kulcsanyaggal). Másik lehetőségként a georeplikálás megkezdése előtt győződjön meg arról, hogy a másodlagos kiszolgáló felügyelt identitása (felhasználó által hozzárendelt vagy rendszer által hozzárendelt) rendelkezik az elsődleges kiszolgáló kulcstartóján szükséges engedélyekkel, és a rendszer megpróbálja hozzáadni a kulcsot a másodlagos kiszolgálóhoz.

• Meglévő georeplikációs beállítás esetén, mielőtt engedélyezi az automatikus kulcsváltást az elsődleges kiszolgálón, adja hozzá az elsődleges kiszolgálón TDE-védőként használt titkosítási kulcsot a másodlagos kiszolgálóhoz. A másodlagos kiszolgálónak hozzáférésre van szüksége a kulcshoz ugyanabban a kulcstartóban, amelyet az elsődleges kiszolgáló használ (és nem egy másik kulcshoz ugyanazzal a kulcsanyaggal). Másik lehetőségként az automatizált kulcs engedélyezése előtt győződjön meg arról, hogy a másodlagos kiszolgáló felügyelt identitása (felhasználó által hozzárendelt vagy rendszer által hozzárendelt) rendelkezik az elsődleges kiszolgáló kulcstartóján szükséges engedélyekkel, és a rendszer megpróbálja hozzáadni a kulcsot a másodlagos kiszolgálóhoz.

• A TDE-hez ügyfél által felügyelt kulcsokat (CMK) használó georeplikációs forgatókönyvek támogatottak. Ha a TDE-t az Azure Portalon konfigurálja, az automatikus kulcsforgatással rendelkező TDE-t minden kiszolgálón konfigurálni kell. További információ a georeplikációs konfigurációk automatikus kulcsforgatásának beállításáról a TDE-vel: Automatikus kulcsváltás a georeplikációs konfigurációkhoz.

Inaccessible TDE protector

Ha a TDE ügyfél által kezelt kulcs használatára van konfigurálva, az adatbázis online állapotban tartásához a TDE-védő folyamatos elérhetőségére van szükség. Ha a kiszolgáló elveszíti a hozzáférést az ügyfél által felügyelt TDE-védőhöz az AKV-ban, az adatbázis legfeljebb 10 perc alatt elkezdi megtagadni a megfelelő hibaüzenettel rendelkező összes kapcsolatot, és az állapotát elérhetetlenné változtatja. A nem elérhető állapotban lévő adatbázisokon az egyetlen engedélyezett művelet a törlés.

Megjegyzés:

Ha az adatbázis időszakos hálózatkimaradás miatt elérhetetlen, nincs szükség műveletre, és az adatbázisok automatikusan újra online állapotba kerülnek.

A kulcshoz való hozzáférés visszaállítása után az adatbázis online állapotba helyezése további időt és lépéseket igényel, amelyek a kulcshoz való hozzáférés nélkül eltelt időtől és az adatbázisban lévő adatok méretétől függően változhatnak:

Megjegyzés:

• Ha a kulcshozzáférés 30 percen belül helyreáll, az adatbázis a következő egy órán belül automatikusan megnyílik.
• Ha a kulcshozzáférés több mint 30 perc után visszaáll, az adatbázis automatikusan történő összekapcsolása nem lehetséges. Az adatbázis visszaállításához további lépésekre van szükség az Azure Portalon, és az adatbázis méretétől függően jelentős időt vehet igénybe.
• Ha az adatbázis ismét online állapotba kerül, a korábban konfigurált kiszolgálószintű beállítások, amelyek magukban foglalhatják a feladatátvételi csoport konfigurációját, a címkéket és az adatbázisszintű beállításokat, például a rugalmas készletek konfigurációját, az olvasási skálát, az automatikus szüneteltetéseket, az időponthoz kötött visszaállítási előzményeket, a hosszú távú adatmegőrzési szabályzatot és más beállításokat. Ezért javasoljuk, hogy az ügyfelek olyan értesítési rendszert implementáljanak, amely 30 percen belül azonosítja a titkosítási kulcshoz való hozzáférés elvesztését. A 30 perces időszak lejárta után javasoljuk, hogy ellenőrizze a helyreállított adatbázis összes kiszolgáló- és adatbázisszintű beállítását.

Az alábbiakban megtekintheti a portálon a nem elérhető adatbázisok online állapotba helyezéséhez szükséges további lépéseket.

Véletlen TDE-védelmi hozzáférés visszavonása

Előfordulhat, hogy a kulcstartóhoz megfelelő hozzáférési jogosultsággal rendelkező személy véletlenül letiltja a kiszolgáló hozzáférését a kulcshoz:

• a kulcstartó lekérési, wrapKey- és unwrapKey-engedélyeinek visszavonása a kiszolgálóról

• a kulcs törlése

• a kulcstartó törlése

• a kulcstartó tűzfalszabályainak módosítása

• a kiszolgáló felügyelt identitásának törlése a Microsoft Entra-azonosítóban

További információ az adatbázis elérhetetlenné válásának gyakori okairól.

Letiltott kapcsolat a felügyelt SQL-példány és a Key Vault között

Felügyelt SQL-példány esetén előfordulhat, hogy az Azure Key Vaultban a TDE-védő elérése közben felmerülő hálózati hibák miatt az adatbázisok nem fogják elérhetetlenné változtatni az állapotát, de később elérhetetlenné teszik a példányt. Ez többnyire akkor fordul elő, ha a Key Vault-erőforrás létezik, de a végpontja nem érhető el a felügyelt példányról. Minden olyan forgatókönyv, amelyben a kulcstartó végpontja elérhető, de a kapcsolat megtagadva, a hiányzó engedélyek stb. miatt az adatbázisok elérhetetlenné változnak.

The most common causes for lack of networking connectivity to Key Vault are:

• A Key Vault szolgáltatás privát végponton keresztül érhető el, és az AKV szolgáltatás privát IP-címe nem engedélyezett a kezelt példány alhálózatához tartozó hálózati biztonsági csoport (NSG) kimenő szabályaiban.
• Hibás DNS-feloldás, például ha a kulcstartó teljes tartománynevét nem oldják fel, vagy érvénytelen IP-címmel oldják fel.

Tesztelje a felügyelt SQL-példány és a TDE-védőt üzemeltető Key Vault kapcsolatát .

• A végpont a tároló teljes tartományneve, például <vault_name.vault.azure.net> (a https:// nélkül).
• The port to be tested is 443.
• A RemoteAddress eredményének léteznie kell, és a helyes IP-címnek kell lennie
• A TCP-teszt eredményének a következőnek kell lennie: TcpTestSucceeded: True.

Ha a teszt visszatér TcpTestSucceeded: False, ellenőrizze a hálózati konfigurációt:

• Ellenőrizze a feloldott IP-címet, erősítse meg, hogy érvényes. Ha egy érték hiányzik, az azt jelenti, hogy problémák merültek fel a DNS-feloldással kapcsolatban.
  • Győződjön meg arról, hogy a felügyelt példány hálózati biztonsági csoportjában van egy kimenő szabály, amely a 443-as port feloldott IP-címére vonatkozik, különösen akkor, ha a feloldott cím a kulcstartó privát végpontjához tartozik.
  • Ellenőrizze az egyéb hálózati konfigurációkat, például az útvonaltáblát, a virtuális berendezés meglétét és konfigurációját stb.

Az ügyfél által kezelt TDE monitorozása

Az adatbázis állapotának figyeléséhez és a TDE-védelem hozzáférésének elvesztéséhez szükséges riasztások engedélyezéséhez konfigurálja a következő Azure-funkciókat:

• Azure Resource Health. Az adatbázishoz való első kapcsolat megtagadása után egy elérhetetlen adatbázis, amely nem fér hozzá a TDE-védőhöz, "Nem érhető el" állapotúként jelenik meg.
• Tevékenységnapló , ha az ügyfél által felügyelt kulcstartóban lévő TDE-védőhöz való hozzáférés meghiúsul, a rendszer bejegyzéseket ad hozzá a tevékenységnaplóhoz. Ha riasztásokat hoz létre ezekhez az eseményekhez, a lehető leghamarabb visszaállíthatja a hozzáférést.
• A műveletcsoportok úgy határozhatók meg, hogy a beállítások alapján értesítéseket és riasztásokat küldjenek Önnek, például e-mail/SMS/Push/Voice, Logic App, Webhook, ITSM vagy Automation Runbook.

Database backup and restore with customer-managed TDE

Ha egy adatbázis tDE-vel van titkosítva a 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.

Ha TDE-védővel titkosított biztonsági másolatot szeretne visszaállítani a Key Vaultból, győződjön meg arról, hogy a kulcsanyag elérhető a célkiszolgáló számára. Ezért javasoljuk, hogy tartsa meg a TDE-védő összes korábbi verzióját a Key Vaultban, hogy az adatbázis biztonsági mentései visszaállíthatók legyenek.

Fontos

Egy kiszolgálóhoz bármikor legfeljebb egy TDE-védőkészlet állítható be. Ez az Azure Portal panel "A kulcs alapértelmezett TDE-védővé tétele" elemével megjelölt kulcs. Azonban több további kulcs is csatolható egy kiszolgálóhoz anélkül, hogy TDE-védőként jelölené meg őket. 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.

Ha a biztonsági mentés visszaállításához szükséges kulcs már nem érhető el a célkiszolgáló számára, a rendszer a következő hibaüzenetet adja vissza a visszaállítási kísérlet során: "A célkiszolgáló <Servername> nem rendelkezik hozzáféréssel az 1>. időbélyeg és <a 2>. időbélyeg között <létrehozott AKV-URI-khoz. Próbálkozzon újra a művelettel az összes AKV-URI visszaállítása után."

A probléma elhárításához futtassa a Get-AzSqlServerKeyVaultKey parancsmagot a célkiszolgálóhoz vagy a get-AzSqlInstanceKeyVaultKey parancsmagot a cél felügyelt példányhoz, hogy visszaadja az elérhető kulcsok listáját, és azonosítsa a hiányzó kulcsokat. Annak érdekében, hogy az összes biztonsági mentés visszaállítható legyen, győződjön meg arról, hogy a visszaállítás célkiszolgálója hozzáfér az összes szükséges kulcshoz. Ezeket a kulcsokat nem kell TDE-védőként megjelölni.

Ha többet szeretne megtudni az SQL Database biztonsági mentési helyreállításáról, olvassa el az ADATBÁZIS helyreállítása az SQL Database-ben című témakört. A dedikált SQL-készletek azure Synapse Analyticsben történő biztonsági mentésének helyreállításáról további információt a dedikált SQL-készlet helyreállítása című témakörben talál. Az SQL Server felügyelt SQL-példánysal történő natív biztonsági mentéséről/visszaállításáról a következő rövid útmutatóban olvashat : Adatbázis visszaállítása felügyelt SQL-példányra.

A naplófájlok egy másik szempontja: A biztonsági mentési naplófájlok az eredeti TDE-védővel titkosítva maradnak, még akkor is, ha elforgatták, és az adatbázis most egy új TDE-védőt használ. A visszaállításkor mindkét kulcsra szükség lesz az adatbázis visszaállításához. Ha a naplófájl egy Azure Key Vaultban tárolt TDE-védelmi eszközt használ, akkor a kulcsra a visszaállításkor lesz szükség, még akkor is, ha az adatbázis időközben megváltozott a szolgáltatás által felügyelt TDE használatára.

Magas rendelkezésre állás az ügyfél által felügyelt TDE-vel

Még akkor is ajánlott konfigurálni a kiszolgálót, ha nincs konfigurált georedundancia a kiszolgálóhoz, hogy két különböző kulcstartót használjon két különböző régióban ugyanazzal a kulcsanyaggal. A másik régió másodlagos kulcstartójának kulcsát nem szabad TDE-védőként megjelölni, és még csak nem is engedélyezett. Ha kimaradás van hatással az elsődleges kulcstartóra, és csak akkor, a rendszer automatikusan átvált a másodlagos kulcstartóban található ujjlenyomattal rendelkező másik csatolt kulcsra, ha létezik. Vegye figyelembe, hogy ez a kapcsoló nem fog megtörténni, ha a TDE-védő nem érhető el a visszavont hozzáférési jogosultságok vagy a kulcs- vagy kulcstartó törlése miatt, mivel ez azt jelezheti, hogy az ügyfél szándékosan korlátozni akarta a kiszolgáló hozzáférését a kulcshoz. Ha ugyanazt a kulcsanyagot két különböző régióban található kulcstartónak adja meg, a kulcstartón kívüli kulcs létrehozásával és mindkét kulcstartóba való importálásával végezhető el.

Azt is megteheti, hogy kulcsokat hoz létre az egyik régió elsődleges kulcstartójának használatával, és a kulcsot egy másik Azure-régió kulcstartójába klónozza. A Backup-AzKeyVaultKey parancsmaggal kérje le a kulcsot titkosított formátumban az elsődleges kulcstartóból, majd használja a Restore-AzKeyVaultKey parancsmagot, és adjon meg egy kulcstartót a második régióban a kulcs klónozásához. Másik lehetőségként használja az Azure Portalt a kulcs biztonsági mentésére és visszaállítására. A kulcsok biztonsági mentési/visszaállítási művelete csak az azonos Azure-előfizetésen belüli kulcstartók és az Azure földrajzi régiója között engedélyezett.

Geo-DR és ügyfél által kezelt TDE

Aktív georeplikációs és feladatátvételi csoportok esetén az érintett elsődleges és másodlagos kiszolgálók ugyanahhoz a kulcstartóhoz (bármely régióban) vagy külön kulcstartókhoz kapcsolhatók. Ha külön kulcstartók kapcsolódnak az elsődleges és másodlagos kiszolgálókhoz, az ügyfél felelős azért, hogy a kulcs anyaga konzisztens legyen a kulcstartók között, így a geo-másodlagos kulcs szinkronban van, és átveheti ugyanazt a kulcsot a csatolt kulcstartóból, ha az elsődleges elérhetetlenné válik a régióban történő kimaradás és a 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 ügyfél által felügyelt TDE konfigurálásakor (ha az elsődleges és a másodlagos kiszolgálókhoz külön kulcstartókat használnak) fontos, hogy elkerülje a georeplikálás során vagy a hiányos kulcsanyag miatti problémákat a georeplikálás során:

• Minden érintett kulcstartónak azonos tulajdonságokkal és hozzáférési jogosultságokkal kell rendelkeznie a megfelelő kiszolgálókhoz.

• Minden érintett kulcstartónak azonos kulcsanyagot kell tartalmaznia. Ez nem csak az aktuális TDE-védőre vonatkozik, hanem a biztonsági mentési fájlokban használható összes korábbi TDE-védőre is.

• A TDE-védő kezdeti beállítását és forgatását először a másodlagos, majd az elsődlegesen kell elvégezni.

Feladatátvétel teszteléséhez kövesse az Aktív georeplikációs áttekintés lépéseit. A feladatátvételt rendszeresen tesztelni kell annak ellenőrzéséhez, hogy az SQL Database mindkét kulcstartóhoz fenntartotta-e a hozzáférési engedélyt.

Az azure SQL Database-kiszolgáló és az egyik régióban található felügyelt SQL-példány mostantól bármely más régió kulcstartóhoz csatolható. A kiszolgálónak és a kulcstartónak nem kell ugyanabban a régióban találhatónak lennie. With this, for simplicity, the primary and secondary servers can be connected to the same key vault (in any region). Ez segít elkerülni azokat a forgatókönyveket, amikor a kulcsanyagok nem szinkronizálódnak, ha mindkét kiszolgálóhoz külön kulcstartókat használnak. Azure Key Vault has multiple layers of redundancy in place to make sure that your keys and key vaults remain available in case of service or region failures. Az Azure Key Vault rendelkezésre állása és redundancia

Azure Policy ügyfél által felügyelt TDE-hez

Az Azure Policy az ügyfél által felügyelt TDE kényszerítésére használható az Azure SQL Database-kiszolgáló vagy a felügyelt Azure SQL-példány létrehozása vagy frissítése során. Ha ez a szabályzat érvényben van, a logikai kiszolgáló Azure-beli vagy felügyelt példányon történő létrehozására vagy frissítésére tett kísérletek sikertelenek lesznek, ha nincs ügyfél által felügyelt kulccsal konfigurálva. Az Azure Policy alkalmazható a teljes Azure-előfizetésre, vagy csak egy erőforráscsoporton belül.

Az Azure Policyval kapcsolatos további információkért lásd : Mi az Azure Policy? és az Azure Policy definíciós struktúrája.

Az Azure Policy ügyfél által felügyelt TDE-jéhez az alábbi két beépített szabályzat támogatott:

• Az SQL-kiszolgálóknak ügyfél által felügyelt kulcsokkal kell titkosítaniuk az inaktív adatokat
• A felügyelt példányoknak ügyfél által felügyelt kulcsokkal kell titkosítaniuk az inaktív adatokat

Az ügyfél által felügyelt TDE-szabályzat az Azure Portalra való ugrással és a Szabályzat szolgáltatás megkeresésével kezelhető. A Definíciók csoportban keresse meg az ügyfél által kezelt kulcsot.

Az alábbi szabályzatoknak három hatása van:

• Naplózás – Az alapértelmezett beállítás, és csak az Azure Policy tevékenységnaplóiban rögzíti az auditjelentést
• Megtagadás – Megakadályozza a logikai kiszolgáló vagy felügyelt példány létrehozását vagy frissítését ügyfél által felügyelt kulcs konfigurálása nélkül
• Letiltva – Letiltja a szabályzatot, és nem korlátozza a felhasználókat abban, hogy logikai kiszolgálót vagy felügyelt példányt hozzanak létre vagy frissítsenek az ügyfél által felügyelt TDE engedélyezése nélkül

Ha az ügyfél által felügyelt TDE-hez készült Azure Policy Megtagadás értékre van állítva, az Azure SQL logikai kiszolgáló vagy a felügyelt példány létrehozása sikertelen lesz. A hiba részleteit az erőforráscsoport tevékenységnaplójában rögzíti a rendszer.

Fontos

Az effektust tartalmazó AuditIfNotExist , ügyfél által felügyelt TDE beépített szabályzatainak korábbi verziói elavultak. Az elavult szabályzatokat használó meglévő szabályzat-hozzárendelések nem lesznek hatással, és a korábbiakhoz hasonlóan fognak működni.

További lépések

A következő PowerShell-mintaszkripteket is érdemes ellenőrizni az ügyfél által felügyelt TDE-vel végzett gyakori műveletekhez:

• Az SQL Database transzparens adattitkosítási védőjének elforgatása

• Transzparens adattitkosítási (TDE)-védő eltávolítása az SQL Database-hez

• Transzparens adattitkosítás kezelése felügyelt SQL-példányban saját kulccsal a PowerShell használatával

Emellett engedélyezze az SQL-hez készült Microsoft Defendert, hogy biztonságossá tegye az adatbázisokat és az adataikat, és hogy az adatbázis esetleges biztonsági réseit felderítse és mérsékelje, valamint észlelje az adatbázisokat fenyegető rendellenes tevékenységeket.