Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A következőkre vonatkozik:
Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (csak dedikált SQL-készletek)
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 forgatókönyvben a transzparens adattitkosítási (TDE) védő – az adatbázistitkosítási kulcs (DEK) védelméhez használt ügyfél által felügyelt aszimmetrikus kulcs – az Azure Key Vaultban vagy az Azure Key Vault által felügyelt HSM-ben van tárolva. Ezek biztonságos, felhőalapú kulcskezelési szolgáltatások, amelyeket magas rendelkezésre állásra és méretezhetőségre terveztek. Az Azure Key Vault támogatja az RSA-kulcsokat, és a FIPS 140-2-es szintű hitelesítéssel rendelkező HSM-ek által van biztosítva. A nagyobb biztonságot igénylő ügyfelek számára az Azure Key Vault által felügyelt HSM FIPS 140-2 3. szintű érvényesített hardvert kínál. A kulcs létrehozható a szolgáltatásban, importálható vagy biztonságosan továbbítható a helyszíni HSM-ekből. A kulcsokhoz való közvetlen hozzáférés korlátozott – az engedélyezett szolgáltatások titkosítási műveleteket hajtanak végre a kulcsanyag felfedése nélkü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 mind az SQL Database-ben, mind az Azure Synapse-ban lévő kiszolgálóra, mind pedig a felügyelt SQL-példányban lévő felügyelt példányra hivatkozik a jelen cikkben, 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.
Jegyzet
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. További információ a Synapse-munkaterületeken belüli dedikált SQL-készletek transzparens adattitkosításáról: Azure Synapse Analytics-titkosítás.
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
Válassza ki a használni kívánt Azure Key Vault típusát.
Ahhoz, hogy az Azure-beli logikai kiszolgáló az Azure Key Vaultban tárolt TDE-védőt használja a DEK titkosításához, a Key Vault rendszergazdájának hozzáférési jogosultságokat kell adnia a kiszolgálónak 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 követelményei
A TDE-védő csak aszimmetrikus, RSA vagy RSA HSM-kulcs lehet. A támogatott kulcshosszok 2048 bit és 3072 bit.
A kulcsaktiválási dátumnak (ha be van állítva) a múltban dátumnak és időnek kell lennie. A lejárati dátumnak (ha be van állítva) jövőbeli dátumnak és időnek kell lennie.
A kulcsnak aktív állapotban kell lennie.
Ha egy meglévő kulcsot importál a Key Vaultba, győződjön meg arról, hogy az egyik támogatott fájlformátumban van megadva:
.pfx,.byokvagy.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ához
Az optimális teljesítmény és megbízhatóság érdekében erősen ajánlott dedikált Azure Key Vaultot használni az Azure SQL-hez. Ezt a kulcstárat nem szabad más szolgáltatásokkal megosztani. Ha a kulcstartó nagy terhelés alatt áll a megosztott használat vagy a túlzott kulcsműveletek miatt, az negatív hatással lehet az adatbázis teljesítményére, különösen a titkosítási kulcsok elérése 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 kritikus fontosságú a kiszolgáló feladatátvétele során, amely a kiszolgálón található összes adatbázis kulcsműveleteit aktiválja.
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ítsa több mint 500 oldalkiszolgálót egyetlen Azure Key Vaulthoz. 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 oldalkiszolgálók száma meghaladja az 500-t, használjon dedikált Azure Key Vaultot minden olyan rugalmas skálázású adatbázishoz, amelyet nem oszt meg 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.
Á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á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 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).
Kulcsok elforgatásakor tartsa meg a kulcs korábbi verzióit a kulcstartóban vagy a felügyelt HSM-ben, hogy a régebbi adatbázis-biztonsági másolatok visszaállíthatók legyenek. Amikor 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ához. 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 kulcsváltások a Transzparens adattitkosítás (TDE) védőforgatása című cikk utasításait követve végezhetők el.
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.
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.
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-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: 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.
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ához.
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. 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. 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-DR és ügyfél által felügyelt TDE
Aktív georeplikációs és feladatátvételi csoportok esetén az érintett elsődleges és másodlagos kiszolgálók bármely régióban található Azure Key Vaulthoz vagy Azure Managed HSM-hez csatolhatók. A kiszolgálót és a kulcstartót vagy a felügyelt HSM-et nem kell ugyanabban a régióban csoportosítani. Ezzel az egyszerűség kedvéért az elsődleges és másodlagos kiszolgálók ugyanahhoz a kulcstartóhoz vagy felügyelt HSM-hez csatlakoztathatók (bármely régióban). Ez segít elkerülni azokat a forgatókönyveket, amikor a kulcsanyag nem szinkronizálódik, ha mindkét kiszolgálóhoz külön kulcstartókat vagy felügyelt HSM-eket használnak.
Az Azure Key Vault és az Azure Managed HSM több redundanciával rendelkezik, így biztosíthatja, hogy a kulcsok és a kulcstartók szolgáltatás- vagy régióhibák esetén is elérhetők maradjanak. A redundanciát a nem párosított és párosított régiók támogatják. További információ: Azure Key Vault rendelkezésre állása és redundancia.
A TDE védelmi kulcs tárolására számos lehetőség áll rendelkezésre az ügyfelek igényeinek megfelelően:
Használja az Azure Key Vaultot, valamint a natív párosított régiók rugalmasságát vagy a nem párosított régiók rugalmasságát.
Használja az ügyfél által használt HSM-et, és töltse be a kulcsokat az Azure Key Vault különböző régiókban található, különálló Azure Key Vaultokba.
Használja az Azure Managed HSM-et és a régiók közötti replikációs lehetőséget.
- Ezzel a beállítással az ügyfél kiválaszthatja a kívánt régiót, ahol a kulcsok replikálódnak.
Az alábbi ábra az Azure Key Vault és az Azure SQL közötti kereszt-feladatátvétel párosított régióinak (elsődleges és másodlagos) konfigurációját mutatja be geo-replikációhoz, feladatátvételi csoporttal.
Azure Key Vault megjegyzések a Geo-DR-hez
Az Azure SQL elsődleges és másodlagos kiszolgálói is hozzáférnek az Azure Key Vaulthoz az elsődleges régióban.
Az Azure Key Vault feladatátvételét nem az ügyfél, hanem az Azure Key Vault szolgáltatás kezdeményezi.
Ha az Azure Key Vault átáll a másodlagos régióra, az Azure SQL-kiszolgáló továbbra is hozzáférhet ugyanahhoz az Azure Key Vaulthoz. Bár belsőleg az Azure Key Vault-kapcsolatot a rendszer átirányítja a másodlagos régióban lévő Azure Key Vaultba.
Új kulcslétrehozások, importálások és kulcsforgatások csak akkor lehetségesek, ha az elsődleges Azure Key Vault elérhető.
A feladatátvételt követően a kulcsváltás nem engedélyezett, amíg a párosított régióban lévő elsődleges régió Azure Key Vault-ja ismét elérhetővé nem válik.
Az ügyfél nem tud manuálisan csatlakozni a másodlagos régióhoz.
Az Azure Key Vault írásvédett állapotban van, míg az elsődleges régióban lévő Azure Key Vault nem érhető el
Az ügyfél nem tudja kiválasztani vagy ellenőrizni az Azure Key Vault aktuális régióját.
Nem használt régió esetén mindkét Azure SQL-kiszolgáló az első régióban (a grafikonon látható módon) fér hozzá az Azure Key Vaulthoz, az Azure Key Vault pedig zónaredundáns tárolással replikálja az adatokat a régión belül, ugyanazon régió független rendelkezésre állási zónáiban.
További információkért lásd a Azure Key Vault rendelkezésre állási és redundancia leírását, az Azure régiópárok és különálló régiók részleteit , valamint az Azure Key Vault szolgáltatásszintű szerződései.
Azure SQL megjegyzések a "Geo-DR" számára
A rugalmasság növeléséhez használja az Azure SQL által felügyelt példány és az Azure SQL Database zónaredundáns opcióját. További információ: Mik az Azure rendelkezésre állási zónái?.
Használjon feladatátvételi csoportokat a felügyelt Azure SQL-példányhoz és az Azure SQL Database-hez egy másodlagos régióba történő vészhelyreállításhoz. További információért lásd: feladatátvételi csoportok áttekintése, & ajánlott eljárások.
Ha egy adatbázis aktív georeplikációs vagy feladatátvételi csoportok része, és elérhetetlenné válik, az SQL-vezérlősík megszakítja a kapcsolatot, és önálló adatbázissá alakítja az adatbázist. A kulcsengedélyek javítása után az elsődleges adatbázis általában újra online állapotba hozható. A másodlagos adatbázis nem állítható vissza online állapotba, mert az Azure SQL nem készít teljes biztonsági másolatot a másodlagos adatbázisokról terv szerint. A javaslat a másodlagos adatbázisok elvetése és a hivatkozás újbóli létrehozása.
A konfiguráció összetettebb DNS-zónát igényelhet, ha privát végpontokat használ az Azure SQL-ben (például nem tud két privát végpontot létrehozni ugyanabban az erőforrásban ugyanabban a DNS-zónában).
Győződjön meg arról, hogy az alkalmazások újrapróbálkozásos logikát használnak.
Az ügyfelek több esetben is az Azure Managed HSM-megoldást választhatják az Azure Key Vaulton keresztül:
Manuális kapcsolat szükséges a másodlagos tárolóhoz.
A tárolóhoz való olvasási hozzáférés szükséges akkor is, ha hiba lép fel.
Rugalmasan kiválaszthatja, hogy melyik régióba replikálja a fő anyagát
- A régiók közötti replikáció engedélyezését igényli, amely létrehozza a második Azure Managed HSM-készletet a második régióban.
Az Azure Managed HSM használatával az ügyfelek pontos replikát hozhatnak létre a HSM-hez, ha az eredeti elveszett vagy nem érhető el.
Az Azure Managed HSM használata biztonsági vagy szabályozási követelményekhez.
Annak lehetősége, hogy a teljes tárolót mentsük, szemben az egyes kulcsok mentésével.
További információért tekintse meg az Többrégiós replikáció engedélyezése az Azure Managed HSM-en és a Felügyelt HSM vészhelyreállításadokumentumokat.
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.