Azure SQL transzparens adattitkosítás ügyfél által kezelt kulccsal

A következőkre vonatkozik:Azure SQL DatabaseAzure SQL Managed Instance

Transzparens adattitkosítás (TDE) az Azure SQL-ben, ügyfél által felügyelt kulccsal (CMK), lehetővé teszi a Hozd a saját kulcsodat (BYOK) forgatókönyv használatát az inaktív adatok védelmére, és lehetővé teszi a szervezetek számára a kulcsok és adatok kezelésének feladatelkülönítését. Az ügyfél által felügyelt TDE-vel az ügyfél felelős a kulcséletciklus-kezelésért (kulcslétrehozás, feltöltés, forgatás, törlés), kulcshasználati engedélyekért és a kulcsokon végzett műveletek naplózásáért.

Ebben a helyzetben a transzparens adattitkosítás (TDE) védő egy ügyfél által kezelt kulcs, amely biztosítja az Database Encryption Kulcsot (DEK). A TDE védelmezőt vagy az Azure Key Vault-ban, vagy az Azure Key Vault Managed HSM-ben tárolod, amelyek biztonságos, felhőalapú kulcskezelő szolgáltatások, amelyek magas rendelkezésre állásra és skálázhatóságra terveztek. Mindkét szolgáltatás támogatja a FIPS 140-2 által validált hardverrel védett kriptográfiai kulcsokat: az Azure Key Vault támogatja a FIPS 140-2 2. szintet, míg az Azure Key Vault Managed HSM támogatja a FIPS 140-2 3. szintet. Mindkét szolgáltatás támogatja aszimmetrikus és szimmetrikus kulcstípusokat is, és a támogatott algoritmusok és használat a TDE telepítési modelltől függ. A kulcsot a szolgáltatásban generálhatod, importálhatod, vagy biztonságosan áthelyezheted a helyszíni HSM-ekről. A kulcsokhoz való közvetlen hozzáférés korlátozott, így a jogosult szolgáltatások kriptográfiai műveleteket végeznek anélkül, hogy a kulcsanyagot felfednék.

Azure SQL Database esetén a TDE-védőt szerver szinten állítod be, és az adott szerverhez tartozó összes titkosított adatbázis örököli azt. Azure SQL Managed Instance esetén a TDE-védőt példányszinten állítod be, és az adott instance összes titkosított adatbázisa örökli azt. A szerver kifejezés ebben a cikkben mind egy logikai szerverre utal az Azure SQL Database-ben, mind az SQL Managed Instance-ban működő menedzselt példányra, hacsak nem másként jelölik.

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.

Jegyzet

Microsoft Entra ID korábban Azure Active Directory (Azure AD) néven ismert.

Ügyfél által felügyelt kulcs (CMK) és saját kulcs (BYOK) használata

Ebben a cikkben az Ügyfél által felügyelt kulcs (CMK) és a Saját kulcs használata (BYOK) kifejezéseket használjuk felcserélhetően, de néhány különbséget jelentenek.

  • ügyfél által felügyelt kulcs (CMK) – Az ügyfél kezeli a kulcs életciklusát, beleértve a kulcs létrehozását, elforgatását és törlését. A kulcs tárolása az Azure Key Vaultban vagy az Azure Managed HSM-ben történik, és az Azure SQL-ben, az Azure-beli SQL Serveren és a helyszíni SQL Serveren található adatbázis-titkosítási kulcs (DEK) titkosításához használatos.

  • Saját kulcs használata (BYOK) – Az ügyfél biztonságosan hozza vagy importálja a saját kulcsát egy helyszíni hardveres biztonsági modulból (HSM) az Azure Key Vaultba vagy az Azure Managed HSM-be. Az ilyen importált kulcsok bármely más kulcsként használhatók az Azure Key Vaultban, például ügyfél által felügyelt kulcsként a DEK titkosításához. További információ: HSM által védett kulcsok importálása felügyelt HSM-be (BYOK).

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:

  • Teljes körű és részletes vezérlés a TDE-védő használata és kezelése felett.

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

  • A feladatok elkülönítésének megvalósítása a kulcsok és adatok szervezeten belüli kezelése során.

  • Az Azure 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 Azure Key Vaultban.

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

Fontos

Azok számára, akik szolgáltatás által felügyelt TDE-t használnak, akik szeretnék megkezdeni az ügyfél által felügyelt TDE használatát, az adatok titkosítva maradnak az átállás során, és nincs állásidő, sem az adatbázisfájlok újratitkosítása. A szolgáltatás által felügyelt kulcsról ügyfél által felügyelt kulcsra való váltáshoz csak a DEK újratitkosítása szükséges, amely gyors és online művelet.

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

Az ügyfél által felügyelt TDE beállítását és működését bemutató diagram.

Válassza ki a használni kívánt Azure Key Vault típusát.

Ahhoz, hogy a logikai szerver Azure-ban használja az Azure Key Vault-ban tárolt TDE-védelmet a DEK titkosításához, a Key Vault Administrator-nak hozzáférési jogokat kell adnia a szervernek az egyedi 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. Két hozzáférési modell biztosít hozzáférést a kiszolgálónak a kulcstartóhoz:

  • Azure szerepköralapú hozzáférés-vezérlés (RBAC) – Az Azure RBAC használatával hozzáférést biztosíthat egy felhasználónak, csoportnak vagy alkalmazásnak a kulcstartóhoz. Ez a módszer rugalmassága és részletessége érdekében ajánlott. A Key Vault titkosítási szolgáltatás titkosítási felhasználói szerepkörre a kiszolgálóidentitásnak szüksége van a kulcs titkosítási és visszafejtési műveletekhez való használatához.

  • Tárolóelérési irányelv – A kulcstároló hozzáférési irányelvével hozzáférést biztosíthat a kiszolgálónak a kulcstárolóhoz. Ez a módszer egyszerűbb és egyszerűen érthető, de kevésbé rugalmas. A kiszolgálóidentitásnak a következő engedélyekkel kell rendelkeznie a kulcstartón:

    • get – a kulcs nyilvános részének és tulajdonságainak lekérése az Azure Key Vaultban
    • wrapKey – a DEK védelmének (titkosításának) lehetősége érdekében
    • unwrapKey – a DEK védtelenné tétele (visszafejtése) érdekében

A kulcstartóhely Azure Portal Access-konfigurációs menüjében kiválaszthatja az Azure szerepköralapú hozzáférésvezérlést vagy a Kulcstartóhely hozzáférési szabályzatot. Az Azure Key Vault TDE-hez való hozzáférési konfigurációjának beállításáról részletes útmutatást Az SQL Server TDE bővíthető kulcskezelésének beállítása az Azure Key Vaulthasználatával című témakörben talál. Az elérési modellekről szóló további információkért lásd: Azure Key Vault biztonsági.

A Key Vault rendszergazda is engedélyezheti a key vault audit eseményeinek naplózását, így később is ellenőrizhetők.

Ha egy kiszolgáló úgy van konfigurálva, hogy TDE-védőt használjon az Azure Key Vaultbó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.

Jegyzet

A kulcstároló 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ára vonatkozó követelmények

  • A helyreállítható törlési és törlési védelmi funkciókat engedélyezni kell az Azure Key Vaultban. Ez segít megelőzni a véletlen vagy rosszindulatú kulcstár vagy kulcstörlés forgatókönyvét, amely ahhoz vezethet, hogy az adatbázis elérhetetlen állapotba kerüljön. Amikor egy meglévő kiszolgálón vagy a kiszolgáló létrehozása során konfigurálja a TDE-védelmet, az Azure SQL ellenőrzi, hogy a használt kulcstartóban be van-e kapcsolva a visszaállítható törlés és a törlési védelem. Ha a lágy törlés és törlés elleni védelem nincs engedélyezve a kulcstárban, a TDE-védő beállítása hibával meghiúsul. Ebben az esetben először engedélyezni kell a puha törlést és a letörlés elleni védelmet a kulcstartókban, majd végre kell hajtani a TDE védő beállítást.

  • Ha tűzfalat használ az Azure Key Vaulttal, engedélyeznie kell azt a lehetőséget, hogy a megbízható Microsoft-szolgáltatások megkerüljék a tűzfalat, kivéve, ha privát végpontokat használ az Azure Key Vaulthoz. További információ: Azure Key Vault-tűzfalak és virtuális hálózatok konfigurálása.

A TDE-védő konfigurálásának legfontosabb követelményei

A transzparens adattitkosítás ügyfél által kezelt kulcsokkal külső kulcsot, az úgynevezett TDE védelmezőt használ, amely az Azure Key Vault-ban vagy az Azure Managed HSM-ben tárolja az adatbázis titkosítási kulcs (DEK) védelmére.

A következő követelmények érvényesek.

Támogatott kulcstípusok és -méretek

A Azure SQL ajánlattól és a TDE-konfigurációtól függően a TDE-védő aszimmetrikus vagy szimmetrikus kulcsokkal is alátámasztható, amelyeket Azure Key Vault vagy Azure Key Vault felügyelt HSM-ben tárolnak.

  • Aszimmetrikus kulcsok (RSA vagy RSA HSM)

    • Az Azure Key Vaultban és az Azure Key Vault Managed HSM-ben támogatott
    • Támogatott kulcsméretek: 2 048 bites és 3 072 bites
    • Az Azure SQL Database és az Azure SQL Managed Instance esetében támogatott

  • Szimmetrikus kulcsok (AES)

    • Támogatott az Azure Key Vault Premium (előzetes verzió) és az Azure Key Vault Managed HSM szolgáltatásban
    • Támogatott kulcsméretek: 128-bites, 192-bites és 256-bites
    • Csak Azure SQL Database támogatott, jelenleg nyilvános előnézetben van

Jegyzet

A szimmetrikus kulcsokat használó transzparens adattitkosítás (AES) jelenleg előzetes verzióban érhető el. Az előzetes funkciók korlátozott képességekkel jelennek meg, de a Microsoft előzetes alapon teszi elérhetővé, hogy az ügyfelek korai hozzáférést kapjanak és visszajelzést adhassanak. Az előzetes funkciókra külön kiegészítő előzetes feltételek vonatkoznak, és nem tartoznak az SLA-k hatálya alá. Bizonyos esetekben a támogatás a legjobb megoldás. A Microsoft ügyfélszolgálata azonban szívesen kap visszajelzést az előzetes verziójú funkciókról, és bizonyos esetekben minden erőfeszítést megtesz. Az előzetes verziójú funkciók korlátozott vagy korlátozott funkciókkal rendelkezhetnek, és csak a kijelölt földrajzi területeken érhetők el.

Kulcskezelési viselkedés szimmetrikus (AES) kulcsokhoz

Használhatsz szimmetrikus (AES) kulcsokat, amelyeket az Azure Key Vault Premium-ban (előnézet) vagy Azure Key Vault Managed HSM-ben tárolsz TDE-védőként. A helyszíni hardveres biztonsági modulból (HSM) származó kulcs használatának megkezdéséhez importálja a kulcsot valamelyik szolgáltatásba. Az első importálás után minden folyamatban lévő kulcséletciklus-művelet Azure Key Vault Premiumban (előnézet) vagy Azure Key Vault Managed HSM-ben történik. Az időbeli helyreállítás, a geokatasztrófa helyreállítás és a kulcs újravalidálása mind attól függ, hogy a kulcs ott elérhető marad. Fenntartsa az importált kulcsok helyi biztonsági mentését, hogy támogassa a helyreállítási és újravalidációs forgatókönyveket. Ez a viselkedés csak a szimmetrikus (AES) kulcsokra vonatkozik, nem aszimmetrikus (RSA) kulcsokra.

A kulcsállapotra és az érvényességi követelményekre vonatkozó követelmények

  • Ha megadnak egy kulcsaktiválási dátumot, azt a múltba eső dátumra és időpontra kell beállítani.
  • Ha a kulcs lejárati dátuma meg van adva, azt a jövőben dátumra és időpontra kell állítani.
  • A kulcsnak aktív állapotban kell lennie.

Kulcsimportálási követelmények

Ha egy meglévő kulcsot importálsz az Azure Key Vault-ba, add meg a kulcsot az alábbi támogatott formátumok egyikében:

  • .pfx
  • .byok
  • .backup

Ha HSM által védett kulcsokat szeretne importálni az Azure Managed HSM-be, olvassa el a HSM által védett kulcsok importálása felügyelt HSM-be (BYOK) című témakört.

Jegyzet

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ért lásd a CipherTrust Cloud Key Manager kibocsátási megjegyzéseit. Ilyen esetekben várjon 24 órát, miután importálta a kulcsot az Azure Key Vaultba, hogy TDE-védőként használja a kiszolgáló vagy a felügyelt példány számára. Ez a probléma a Thales CipherTrust Manager 2.8.0-s verzióban van megoldva.

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

  • Az optimális teljesítmény és megbízhatóság érdekében használj dedikált Azure Key Vault-t az Azure SQL-hez. Ne oszd meg ezt a kulcsreszteret más szolgáltatásokkal. Ha a kulcstár nagy terhelés alatt áll a megosztott használat vagy túlzott kulcsműveletek miatt, az negatívan befolyásolhatja az adatbázis teljesítményét, különösen a titkosítási kulcs-hozzáférés során. Az Azure Key Vault szabályozási korlátokat kényszerít ki. Ha túllépi ezeket a korlátokat, előfordulhat, hogy a műveletek késnek vagy sikertelenek lesznek. Ez a kockázat a szerver túlellenőrzései során a legmagasabb, amikor minden adatbázis esetében kulcsműveleteket indítanak el.

    A szabályozás működéséről további információt az Azure Key Vault szabályozási útmutatójában talál.

    A magas rendelkezésre állás fenntartása és a sebességkorlátozási problémák elkerülése érdekében kövesse az alábbi irányelveket előfizetésenként.

    • Dedikált Azure Key Vault használata Azure SQL-erőforrásokhoz.

    • Legfeljebb 500 általános célú adatbázis társítása egyetlen Azure Key Vaulthoz.

    • Legfeljebb 200 üzleti szempontból kritikus adatbázis társítása egyetlen Azure Key Vaulthoz.

    • Az egyetlen Azure Key Vaulthoz társítható rugalmas skálázású adatbázisok számát az oldalkiszolgálók száma határozza meg. Minden lapkiszolgáló egy logikai adatfájlhoz van csatolva. Az oldalkiszolgálók számának megkereséséhez hajtsa végre a következő lekérdezést.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Ne társíts 500 oldalnál több szervert egyetlen Azure Key Vault-hoz. Az adatbázis növekedésével az oldalkiszolgálók száma automatikusan nő, ezért fontos az adatbázis méretének rendszeres monitorozása. Ha az oldalszerverek száma meghaladja az 500-at, használj egy dedikált Azure Key Vault-t minden Hyperscale adatbázishoz, és ne oszd meg azt a kulcstárat más Azure SQL erőforrásokkal.

    • Azure Key Vault-riasztásokmonitorozása és konfigurálása. A monitorozásról és a riasztásokról további információt az Azure Key Vault monitorozása és az Azure Key Vault-riasztások konfigurálása című témakörben talál.

  • A hosszú távú kriptografikus rezisztenszibilitási tervezéshez való igazítás érdekében fontold meg az AES-256 szimmetrikus kulcsok használatát TDE védőként.

    A nagyszabású kvantumszámítás várhatóan megtöri a nyilvános kulcsú kriptográfiai algoritmusokat, például az RSA-t. A szimmetrikus kriptográfiát, beleértve az AES-t is, kvantumellenállónak számít elég nagy kulcsméreteknél.

    A Microsoft szélesebb körű kvantum-biztonságos biztonsági stratégiája hangsúlyozza a kripto-agilitást. Alkalmazz erősebb szimmetrikus algoritmusokat, ahol támogatják őket, és tervezd meg a jövőbeli kriptográfiai átmeneteket, ahogy az iránymutatások és a szabványok fejlődnek.

    Fontos

    A szimmetrikus kulcsok (AES) használatával működő transzparens adattitkosítás jelenleg csak az Azure SQL Database esetében támogatott, és nyilvános előzetes verzióban érhető el.

  • Á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 erőforrást, és megakadályozza a véletlen vagy jogosulatlan törlést. További információ erőforrás-zárolásokról.

  • Az összes titkosítási kulcs naplózásának és jelentésének engedélyezése: Az Azure 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.

  • Használjon egy Azure-régió kulcstartó szolgáltatását, amely a maximális rendelkezésre állás érdekében replikálhatja a tartalmát egy párosított régióba. További információ: Ajánlott eljárások az Azure Key Vault és Azure Key Vault rendelkezésre állásához és redundanciához.

Jegyzet

Az ügyfél által felügyelt TDE konfigurálásának nagyobb rugalmassága érdekében az Azure SQL Database és a felügyelt Azure SQL-példány mostantól bármely más régióban összekapcsolható az Azure Key Vaulthoz. A kiszolgálót és a kulcstartót nem kell ugyanabban a régióban áthelyezni.

Javaslatok a TDE-védő konfigurálásához

  • Ő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 Azure Key Vaultban való első használat előtt. A biztonsági mentés csak Azure Key Vaultba állítható vissza. További információ az Backup-AzKeyVaultKey parancsról. Az Azure Managed HSM támogatja a HSM teljes tartalmának teljes biztonsági mentését, beleértve az összes kulcsot, verziót, attribútumot, címkét és szerepkör-hozzárendelést. További információ: Teljes biztonsági mentés, visszaállítás és szelektív kulcs-visszaállítás.

  • 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).

  • Tartsd meg a kulcs korábbi verzióit a kulcstárolóban vagy a Managed HSM-ben, amikor kulcsokat váltaszkodsz, hogy vissza tudod állítani a régebbi adatbázis-mentéseket. Amikor a TDE védő megváltozik egy adatbázisban, a régi biztonsági mentések nem frissülnek a legújabb TDE védő használatára. A visszaállításkor minden biztonsági mentésnek szüksége van arra a TDE-védőre, amellyel a létrehozáskor titkosították. A kulcsok forgatásához kövesse a cikkben szereplő utasításokat: Forgasd a Transparent adattitkosítás (TDE) védelmet.

  • Tartsa meg a korábban használt kulcsokat az Azure Key Vaultban vagy az Azure Managed HSM-ben még a szolgáltatás által felügyelt kulcsokra való váltás után is. Biztosítja, hogy az adatbázis biztonsági másolatai visszaállíthatók legyenek az Azure Key Vaultban vagy az Azure Managed HSM-ben tárolt TDE-védőkkel. Az Azure Key Vaultban vagy az Azure Managed HSM-ben 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 jön létre. Készítsen helyreállítható biztonsági másolatot ezekről a kulcsokról Backup-AzKeyVaultKeyhasználatával.

  • 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 Transzparens adattitkosítás (TDE) védő eltávolítása a PowerShell használatával című cikk lépéseit. A feltört kulcs törlése vagy letiltása előtt mindig váltson egy új TDE-védőre, és ellenőrizze, hogy az összes adatbázis használja-e az új kulcsot. Ha a kulcsot először elforgatás nélkül töröljük vagy letiltjuk, az összes titkosított adatbázis elérhetetlenné válik, és nem érvényteleníti azokat a kulcsmásolatokat, amelyeket korábban lementettek és egy másik trezorba állítottak vissza.

Jótanács

Verziószámozott és verzió nélküli Azure Key Vault-kulcsok használata a TDE-hez

A TDE-védő beállításakor hivatkozhat egy Azure Key Vault-kulcsra egy adott kulcsverzió vagy verzió nélküli kulcsazonosító használatával.

Az Azure SQL Database mindkét esetben mindig a kulcs legújabb, engedélyezett verzióját oldja fel és használja az Azure Key Vaultban vagy az Azure Key Vault felügyelt HSM-ben. Használjon verzió nélküli kulcsazonosítókat, hogy elkerülje egy adott kulcsverzió beágyazását a TDE védelmi modul konfigurációjába.

A verzió nélküli kulcsazonosítók jelenleg csak az Azure SQL Database esetében támogatottak.

Példák:

  • Egy adott verziót tartalmazó kulcsazonosító

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Verzió nélküli kulcsazonosító

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

TDE-védő elforgatása

A TDE-védő elforgatásával lecserélheti az adatbázistitkosítási kulcs (DEK) védelméhez használt kulcsot. 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őt elforgathatja úgy, hogy a konfigurációt a Azure Key Vault vagy Azure Key Vault felügyelt HSM-ben tárolt új kulcs használatára váltja. A Azure SQL ajánlattól és a támogatott konfigurációtól függően a következők lehetnek:

  • Váltás ugyanannak a kulcsnak egy új kulcsverziójára
  • Váltás másik kulcsra
  • Váltás a támogatott kulcstípusok, például az aszimmetrikus (RSA) és a szimmetrikus (AES) kulcsok között

Jegyzet

A szimmetrikus kulcsok (AES) használatával működő transzparens adattitkosítás jelenleg csak az Azure SQL Database esetében támogatott, és nyilvános előzetes verzióban érhető el.

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

TDE-védelmi automatikus elforgatása engedélyezhető a kiszolgáló TDE-védőjének 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 vagy a felügyelt HSM-et a TDE védőkulcsként használt kulcs bármilyen új verziója után. Ha a kulcs új verzióját észleli, a kiszolgáló vagy az adatbázis TDE-védője 24 órán belül automatikusan a legújabb kulcsverzióra vált.

Ha az Azure Key Vault automatikus kulcsforgatásával vagy az Azure Managed HSM autorotációjával használják, ez a funkció lehetővé teszi az érintésmentes végponttól végpontig tartó rotációt az Azure SQL Database és az Azure SQL Managed Instance TDE-védője számára.

Jegyzet

A TDE beállítása CMK-val manuális vagy automatikus kulcsforgatás esetén mindig a támogatott kulcs legújabb verzióját használja. A beállítás nem teszi lehetővé a kulcsok korábbi vagy alacsonyabb verziójának használatát. A legújabb kulcsverzió mindig megfelel az Azure SQL biztonsági szabályzatának, amely letiltja az esetlegesen feltört korábbi kulcsverziókat. Előfordulhat, hogy a kulcs korábbi verzióira szükség van adatbázis biztonsági mentéséhez vagy visszaállításához, különösen hosszú távú megőrzési mentéseknél, 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:

  • Az elsődleges és a másodlagos kiszolgálónak egyaránt rendelkeznie kell Get, wrapKey és unwrapKey engedélyekkel 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 vagy az elsődleges kiszolgálóval használt felügyelt HSM-hez (é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-e szükséges engedélyekkel az elsődleges kiszolgáló kulcstartóján vagy felügyelt HSM-jén, é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 vagy az elsődleges kiszolgálóval használt felügyelt HSM-hez (é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 esetén támogatottak az ügyfél által kezelt kulcsokat (CMK) használó georeplikációs forgatókönyvek. 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: Georeplikációs konfigurációk automatikus kulcsváltása.

Elérhetetlen TDE-védő

Ha a TDE ügyfél által felügyelt kulcs használatára van konfigurálva, a TDE-védőhöz való folyamatos hozzáférésre van szükség ahhoz, hogy az adatbázis online maradjon. Ha a kiszolgáló elveszíti a hozzáférést az ügyfél által felügyelt TDE-védőhöz az Azure Key Vaultban vagy az Azure Managed HSM-ben, az adatbázis legfeljebb 10 percen belül megtagadja a megfelelő hibaüzenettel való ö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.

Elérhetetlen állapot

Ha az adatbázis időszakos hálózatkimaradás (például 5XX-hiba) miatt nem érhető el, nincs szükség műveletre, mivel az adatbázisok automatikusan újra online állapotba kerülnek. Az Azure Key Vaultban vagy az Azure Managed HSM-ben található TDE-védő elérésekor a hálózati hibák vagy kimaradások hatásának csökkentése érdekében a szolgáltatás 24 órás puffert vezet be, mielőtt a szolgáltatás elérhetetlen állapotba kísérelné meg áthelyezni az adatbázist. Ha feladatátvétel történik a elérhetetlen állapot elérése előtt, az adatbázis a titkosítási gyorsítótár elvesztése miatt elérhetetlenné válik.

Ha a kiszolgáló az Azure Key Vaultban vagy az Azure Managed HSM-ben az ügyfél által felügyelt TDE-védőhöz az Azure Key Vault hibája (például 4XX-es hiba) miatt elveszíti a hozzáférést, az adatbázis 30 perc elteltével elérhetetlen állapotba kerül.

Adatbázis-hozzáférés visszaállítása Az Azure Key Vault vagy az Azure Managed HSM hibája után

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 kulcs elérhetetlenségének időtartamától és az adatbázisban lévő adatok méretétől függően változhatnak.

Ha a kulcshozzáférés 30 percen belül helyreáll, az adatbázis a következő órán belül automatikusan meggyógyul. Ha azonban a kulcshozzáférés több mint 30 perc után visszaáll, az adatbázis automatikus helyreállítása nem lehetséges. Ilyen esetekben az adatbázis visszaállítása további eljárásokat igényel az Azure Portalon keresztül, és az adatbázis méretétől függően időigényes lehet.

Az adatbázis online állapotba helyezése után a korábban konfigurált kiszolgálószintű beállítások, köztük a feladatátvételi csoport konfigurációi, a címkék és az adatbázisszintű beállítások, például a rugalmas készletkonfigurációk, az olvasási skálázás, az automatikus szüneteltetés, az időponthoz kötött visszaállítási előzmények, a hosszú távú adatmegőrzési szabályzat és más beállítások elvesznek. Ezért javasoljuk, hogy az ügyfelek egy értesítési rendszert implementáljanak, amely 30 percen belül észleli 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 áttekintheti a portálon a nem elérhető adatbázisok online állapotba helyezéséhez szükséges további lépéseket.

A TDE BYOK elérhetetlen adatbázis képernyőképe.

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

Előfordulhat, hogy a kulcstartóhoz vagy felügyelt HSM-hez megfelelő hozzáférési jogosultsággal rendelkező személy véletlenül letiltja a kulcshoz való kiszolgálói hozzáférést:

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

  • a kulcs törlése

  • a kulcs-vault vagy a felügyelt HSM törlése

  • a kulcstár vagy a felügyelt HSM 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 az Azure Key Vault vagy az Azure Managed HSM között

A felügyelt SQL-példány és a kulcstartó vagy a felügyelt HSM közötti hálózati kapcsolati blokk többnyire akkor fordul elő, ha a kulcstartó vagy a felügyelt HSM-erőforrás létezik, de végpontja nem érhető el a felügyelt példányról. Minden olyan forgatókönyv, amelyben a kulcstartó vagy a felügyelt HSM-végpont elérhető, de a kapcsolat elutasítva van, vagy a hiányzó engedélyek stb. miatt az adatbázisok állapota elérhetetlenné változik.

Az Azure Key Vaulthoz vagy az Azure Managed HSM-hez való hálózati kapcsolat hiányának leggyakoribb okai a következők:

  • Az Azure Key Vault vagy az Azure Managed HSM privát végponton keresztül érhető el, és az Azure Key Vault vagy az Azure Managed HSM szolgáltatás privát IP-címe nem engedélyezett a felügyelt példány alhálózatához társított hálózati biztonsági csoport (NSG) kimenő szabályaiban.

  • Hibás DNS-feloldás, például ha a kulcstartó vagy a felügyelt HSM teljes tartománynév nem oldódott fel, vagy érvénytelen IP-címre van feloldva.

Tesztelje a felügyelt SQL-példányból az Azure Key Vaulthoz vagy a TDE-védőt üzemeltető Azure Managed HSM-hez való kapcsolódást.

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

Ha a teszt TcpTestSucceeded: Falseeredményt ad vissza, tekintse át a hálózati konfigurációt:

  • Ellenőrizze a feloldott IP-címet, és ellenőrizze, hogy érvényes-e. A hiányzó érték azt jelenti, hogy problémák merülnek 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 csoportja rendelkezik egy kimenő szabállyal, amely a 443-as port feloldott IP-címére vonatkozik, főként ha a feloldott cím a kulcstár vagy a felügyelt HSM 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 felügyelt TDE figyelése

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. Egy elérhetetlen adatbázis, amely nem fér hozzá a TDE-védőhöz, "Nem érhető el" állapotúként jelenik meg, miután a rendszer megtagadta az adatbázishoz való első kapcsolatot.

  • 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.

  • műveletcsoportok úgy határozhatók meg, hogy értesítéseket és riasztásokat küldjenek Önnek a beállítások alapján, például e-mail/SMS/Push/Voice, Logic App, Webhook, ITSM vagy Automation Runbook.

Adatbázis backup és restore az ügyfél által felügyelt TDE-vel

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.

Ha TDE-védővel titkosított biztonsági mentést szeretne visszaállítani az Azure Key Vaultból vagy az Azure Managed HSM-ből, győződjön meg arról, hogy a kulcsanyag elérhető a célkiszolgáló számára. Ezért azt 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

A kiszolgálóhoz jelenleg nem lehet több TDE-védőkészlet. Az Azure portál paneljében az "A kulcs beállítása alapértelmezett TDE-védőként" megjelölt kulcs az alapértelmezett TDE-védő. Azonban több 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 is 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 <Időbélyeg #1> és <időbélyeg #2>között létrehozott összes AKV-URI-hoz. 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 Get-AzSqlInstanceKeyVaultKey a cél felügyelt példányhoz az elérhető kulcsok listájának visszaadásához és a hiányzó kulcsok azonosításához. 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.

Az SQL Database biztonsági mentésének helyreállításával kapcsolatos további információkért lásd : Adatbázis visszaállítása biztonsági másolatból az Azure SQL Database-ben. Ha az SQL Server natív biztonsági mentését/visszaállítását felügyelt SQL-példánysal szeretné elvégezni, tekintse meg a rövid útmutatót: Adatbázis visszaállítása felügyelt Azure SQL-példányra SSMS-sel.

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 van az adatbázis visszaállításához. Ha a naplófájl az Azure Key Vaultban vagy az Azure Managed HSM-ben tárolt TDE-védőt használ, akkor is szükség van erre a kulcsra a visszaállításkor, 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

Ha az Azure Key Vault vagy az Azure Managed HSM több redundanciaréteget biztosít, az ügyfél által felügyelt kulcsot használó TDE-k kihasználhatják az Azure Key Vault vagy az Azure Managed HSM rendelkezésre állását és rugalmasságát, és teljes mértékben támaszkodhatnak az Azure Key Vaultra vagy az Azure Managed HSM redundancia megoldására.

Az Azure Key Vault több redundanciarétege akkor is biztosítja a kulcshozzáférést, ha az egyes szolgáltatásösszetevők meghibásodnak, vagy az Azure-régiók vagy a rendelkezésre állási zónák leállnak. További információ: Azure Key Vault rendelkezésre állása és redundancia.

Az Azure Key Vault a következő rendelkezésre állási és rugalmassági összetevőket kínálja, amelyek automatikusan, felhasználói beavatkozás nélkül érhetők el:

Jegyzet

Minden párrégió esetében az Azure Key Vault-kulcsok mindkét régióba replikálódnak, és mindkét régióban vannak hardveres biztonsági modulok (HSM), amelyek képesek ezen kulcsok üzemeltetésére. További információért lásd: adatreplikáció. Ez a Standard és a Premium Azure Key Vault szolgáltatásszintekre, valamint a szoftver- vagy hardverkulcsokra is vonatkozik.

Az Azure Managed HSM többrégiós replikációja lehetővé teszi egy Azure-beli felügyelt HSM-készlet kiterjesztését egy Azure-régióból (az elsődleges régióból) egy másik Azure-régióba (kiterjesztett régióba). A konfigurálás után mindkét régió aktív, képes a kérések kiszolgálására, és automatizált replikációval ugyanazokkal a kulcsfontosságú anyagokkal, szerepkörökkel és engedélyekkel rendelkezik. További információ: Többrégiós replikáció engedélyezése az Azure Managed HSM-en.

Geo-katasztrófa helyreállítás ügyfél által kezelt TDE-vel

Az aktív georeplikáció és a feladatátvételi csoportok támogatják az ügyfél által felügyelt TDE-t. Az elsődleges és másodlagos szerverek bármely támogatott régióban használhatnak Azure Key Vault-t vagy Azure Managed HSM-et. A szervereknek és a kulcsboltnak nem kell ugyanabban a régióban lennie.

A sikeres failoverhez mindkét szervernek hozzáférést kell biztosítania minden Azure Key Vault-hoz vagy Azure Managed HSM-hez, amely tartalmaz egy szükséges kulcsot.

Konfigurációs szempontok

A következő szempontok érvényesek, amikor aktív georeplikációt vagy egy failover csoportot konfigurálsz az Azure portálon:

  • TDE védő hely: Az elsődleges és másodlagos szerverek ugyanazt az Azure Key Vault-ot vagy az Azure Managed HSM-et használhatják. Ugyanaz a kulcstároló használata csökkenti annak kockázatát, hogy a kulcsanyag kicsúszik a szinkronból. Ha külön kulcstartókat használsz több régióban, akkor a szükséges kulcsanyagot szinkronizálni kell tartani. A kulcstároló ellenálló képességéről további információt a Azure Key Vault rendelkezésre állása és redundanciája, valamint a Managed HSM többrégiós replikációja című cikkben talál.

  • Zóna redundancia: Ha elérhető, az Azure SQL Database vagy Azure SQL Managed Instance zóna redundancia extra ellenállóképességet biztosít egy régión belül. További információ: Mik az Azure rendelkezésre állási zónái?.

  • Kulcsjogosultságok: Mind az elsődleges, mind a másodlagos szervereknek rendelkezniük kell a szükséges jogosultságokkal minden Azure Key Vault-on vagy Azure Managed HSM-en, amely tartalmaz egy szükséges TDE-védelmet.

  • Kulcs elérhetősége: Győződjön meg róla, hogy a szükséges kulcsok elérhetők legyenek mind a primer, mind a másodlagos szervereken. A szervereknek nem kell azonos TDE-védőket használniuk, de minden szervernek ugyanazzal a kulcsanyaggal kell rendelkeznie. Kulcsokat adhatsz hozzá egy szerverhez az Azure portál, PowerShell, Azure CLI vagy az Azure SQL REST API segítségével. Ha a szükséges kulcsok a failover idején nem állnak rendelkezésre, az adatbázis elérhetetlenné válhat.

  • Privát végpontok: A konfiguráció összetettebb DNS zónát igényelhet, ha privát végpontokat használsz Azure SQL-ben (például nem tud két privát végpontot létrehozni ugyanahhoz az erőforráshoz ugyanabban a DNS zónában).

  • Alkalmazási kapcsolódás: Az alkalmazásoknak újra próbálkozási logikát kell használniuk a átmeneti hibák kezelésére a failover során.

Az Azure SQL geo-katasztrófa helyreállítási erőforrás konfigurálásával kapcsolatos információkért lásd: Aktív georeplikáció vagy Failover csoportok áttekintése és legjobb gyakorlatok.

Fontos

Amikor georeplikációs linket vagy failover csoportot hozol létre, az Azure SQL igazolja, hogy mindkét szerver hozzáférhet az összes szükséges ügyfél által kezelt kulcshoz. Ha egyik szerver sem tud hozzáférni egy szükséges kulcshoz, a létrehozási művelet meghibásodik. Például, ha az elsődleges és másodlagos szerverek az A és a B kulcsot használják, akkor mindkét kulcsot hozzáhelyezzük mindkét szerverhez, mielőtt létrehoznánk a georeplikációs kapcsolatot vagy a failover csoportot.

Az alábbi diagram az Azure SQL georeplikációt feladatátvételi csoporttal, valamint az Azure Key Vault régiók közötti feladatátvételét párosított régiós konfigurációban mutatja:

diagram az Azure Key Vault régióközi feladatátvételi támogatását mutatja egy párosított régióhoz.

Az Azure Key Vault viselkedése feladatátvétel során

  • Az Azure Key Vault indítja el a failovert, nem te.
  • Amíg az elsődleges régióban lévő kulcstároló nem érhető el, a kulcstároló csak olvasási módban érhető el.
  • Csak akkor hozhat létre, importálhat és forgathat kulcsokat, ha az elsődleges régióban lévő kulcstároló elérhető. A hiba miatti átállás után a kulcsrotáció továbbra is blokkolt marad, amíg az elsődleges régió újra el nem érhető.
  • Nem tudod sem kiválasztani, sem ellenőrizni, hogy a kulcstartó jelenleg melyik régióban található, és a másodlagos régióhoz sem tudsz manuálisan csatlakozni.

Felépülés egy elérhetetlen TDE-védőből

Ha egy aktív georeplikációs kapcsolatban vagy failover csoportban lévő adatbázis elérhetetlenné válik, az Azure SQL vezérlősík megszakítja a kapcsolatot, és az adatbázist önálló adatbázissá alakítja.

Miután visszaállítottad a kulcsjogosultságokat, általában vissza tudod állítani az elsődleges adatbázist. Nem lehet visszahozni a másodlagos adatbázist, mert az Azure SQL nem készít teljes biztonsági mentést a másodlagos adatbázisokról. Dobd el a másodlagos adatbázist, majd állítsuk vissza a georeplikációs kapcsolatot vagy a failover csoportot.

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 meghiúsulnak, 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.

További információkért az Azure Policyról lásd: Mi az Azure Policy és az Azure Policy definíciójának szerkezete.

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 a nyugalmi állapotban lévő adatokat.

Az ügyfél által felügyelt TDE-szabályzat az Azure Portál megnyitásával és a Szabályzat szolgáltatás keresésével kezelhető. A Definíciókterületen 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

  • Tiltá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 kezelt kulcs konfigurálása nélkül

  • Letiltva – Letiltja a házirendet, é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 meghiúsul. A hiba részleteit az erőforráscsoport tevékenységnaplójában rögzíti a rendszer.

Fontos

A beépített szabályzatok korábbi verziói az ügyfél által felügyelt TDE esetében, amelyek tartalmazzák a AuditIfNotExists effektust, elavultak. Az elavult szabályzatokat használó meglévő szabályzat-hozzárendelések nincsenek hatással, és a korábbiakhoz hasonlóan működnek tovább.

TDE in Azure Synapse Analytics

Az Azure Synapse Analytics ügyfél által kezelt kulcsokkal rendelkező TDE-jéről a TDE with customer-managed keys című témakörben talál információt. 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 Dedikált SQL-készlet helyreállításacímű témakörben talál.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: