transzparens adattitkosítás SQL do Azure ügyfél által felügyelt kulccsal

A következőkre vonatkozik: SQL do Azure Database Azure SQL Managed Instance Azure Synapse Analytics

SQL do Azure ügyfél által felügyelt kulccsal rendelkező transzparens adattitkosítás (TDE) lehetővé teszi a Saját kulcs használata (BYOK) forgatókönyvet az inaktív adatok védelméhez, és lehetővé teszi a szervezetek számára a kulcsok és adatok kezelésével kapcsolatos feladatok elkü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, rotálá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 TDE-védőnek nevezett adatbázis-titkosítási kulcs (DEK) titkosításához használt kulcs 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 密钥保管库 (AKV) tárolnak. 密钥保管库 magas rendelkezésre állású és skálázható biztonságos tár az RSA titkosítási kulcsokhoz, opcionálisan a FIPS 140-2 2. szintű ellenőrzött hardverbiztonsági modulok (HSM-ek) segítségével. Nem engedélyezi a tárolt kulcsokhoz való közvetlen hozzáférést, de titkosítási/visszafejtési szolgáltatásokat nyújt a kulccsal az engedélyezett entitások számára. A kulcsot létrehozhatja a kulcstartó, importálhatja vagy áthelyezheti a kulcstartóba egy helyszíni HSM-eszközről.

Az SQL do Azure Database és 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. A Azure SQL Managed Instance esetében a TDE-védő a példány szintjén van beállítva, és a példány összes titkosított adatbázisa örökli. A kiszolgáló kifejezés mind a SQL Database, mind a Azure Synapse kiszolgálójára, valamint a dokumentum SQL Managed Instance felügyelt példányára hivatkozik, kivéve, ha másként van feltüntetve.

Megjegyzés

Ez a cikk a SQL do Azure Database, Azure SQL Managed Instance és Azure Synapse Analytics (dedikált SQL-készletek (korábbi nevén SQL DW)) szolgáltatásra vonatkozik. A Synapse-munkaterületeken belüli dedikált SQL-készletek transzparens adattitkosításának dokumentációját lásd: Azure Synapse Analytics-titkosítás.

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

Megjegyzés

Annak érdekében, hogy SQL do Azure ügyfelek két rétegnyi inaktív adattitkosítást biztosítsanak, infrastruktúra-titkosítás (AES-256 titkosítási algoritmus használatával) platform által felügyelt kulcsokkal. Ez egy további titkosítási réteget biztosít inaktív állapotban, valamint a TDE-t az ügyfél által felügyelt kulcsokkal, amely már elérhető. Az SQL do Azure Database és a Azure SQL Managed Instance esetében az infrastruktúra-titkosítás bekapcsolásakor minden adatbázis, beleértve a master adatbázist és a többi rendszeradatbázist is, titkosítva lesz. 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: .

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

Az ügyfél által felügyelt TDE a következő előnyöket nyújtja az ügyfélnek:

  • A TDE-védő használatának és kezelésének teljes körű és részletes ellenőrzé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 megvalósítása;

  • 密钥保管库 rendszergazda 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-t úgy tervezték, hogy a Microsoft ne láthassa és ne nyerje ki a titkosítási kulcsokat;

Az ügyfél által kezelt TDE működése

Az ügyfél által felügyelt TDE beállítása és működése

Ahhoz, hogy a SQL do Azure-kiszolgáló az AKV-ban tárolt TDE-védőt használhassa a DEK titkosításához, a Key Vault rendszergazdájának a következő hozzáférési jogosultságokat kell adnia a kiszolgálónak az egyedi Azure Active Directory- (Azure AD-) identitásával:

  • get – a kulcs nyilvános részének és tulajdonságainak lekéréséhez a 密钥保管库

  • 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 engedélyezheti a Key Vault naplózási eseményeinek naplózását is, így később 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, amely ezután a felhasználói adatbázisban lesz tárolva.

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

Ha a naplózás engedélyezve van, az auditorok az Azure Monitorral tekinthetik át a Key Vault AuditEvent-naplóit.

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

Az AKV konfigurálására vonatkozó követelmények

  • A kulcstartónak és a SQL Database/felügyelt példánynak ugyanahhoz az Azure Active Directory-bérlőhöz kell tartoznia. A bérlők közötti kulcstartó- és kiszolgálóinterakciók nem támogatottak. Az erőforrások későbbi áthelyezéséhez az AKV-vel rendelkező TDE-t újra kell konfigurálni. Mer informasjon az erőforrások áthelyezéséről.

  • A kulcstartó helyreállítható törlési és végleges törlési védelmi funkcióit engedélyezni kell a kulcstartón, hogy védelmet nyújthasson a kulcs véletlen törlése miatti adatvesztéssel szemben.

  • Adjon hozzáférést a kiszolgálónak vagy a felügyelt példánynak a kulcstartóhoz (get, wrapKey, unwrapKey) az Azure Active Directory-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. Az Azure Portal használatakor az Azure AD-identitás automatikusan létrejön a kiszolgáló létrehozásakor. A PowerShell vagy az Azure CLI használatakor az Azure AD-identitást explicit módon létre kell hozni, és ellenőrizni kell. A PowerShell használatakor a TDE konfigurálása BYOK-tal és A TDE konfigurálása BYOK-tal című cikkből SQL Managed Instance részletes részletes útmutatást.

    • A kulcstartó (hozzáférési szabályzat vagy Azure RBAC) engedélymodelljétől függően a kulcstartóhoz való hozzáférés megadható egy hozzáférési szabályzat létrehozásával a kulcstartón, vagy egy új Azure RBAC-szerepkör-hozzárendelés létrehozásával a Key Vault titkosítási szolgáltatás titkosítási felhasználója szerepkörrel.
  • Ha tűzfalat használ az AKV-val, engedélyeznie kell a Megbízható Microsoft-szolgáltatások számára a tűzfal megkerülését jelölőnégyzetet. További információ: Az Azure 密钥保管库 tűzfalak és virtuális hálózatok konfigurálása.

Helyreállítható törlés és végleges 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 helyreállítható törlés és a végleges törlés elleni védelmet is engedélyezni kell a kulcstartón.

A helyreállítható törlés és a végleges törlés elleni védelem az Azure 密钥保管库 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ásokat 90 napig őrzi meg a rendszer, kivéve, ha az ügyfél helyreállítja vagy törli őket. A visszaállítási és végleges törlési műveletek saját engedélyekkel rendelkeznek a Key Vault 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 a Azure-Portal, a PowerShell vagy az Azure CLI használatával is engedélyezhető.

  • A végleges törlés elleni védelem az Azure CLI vagy a PowerShell használatával kapcsolható be. Ha a végleges törlés elleni védelem engedélyezve van, a törölt állapotú tárolók és objektumok nem törölhetők véglegesen a megőrzési időtartam lejártáig. Az alapértelmezett megőrzési időtartam 90 nap, de 7 és 90 nap között konfigurálható a Azure-Portal.

  • SQL do Azure megköveteli, hogy engedélyezve legyen a helyreállítható törlés és végleges törlés elleni védelem 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.

  • A TDE-védő meglévő kiszolgálón vagy a kiszolgáló létrehozása során történő konfigurálásakor SQL do Azure ellenőrzi, hogy a használt kulcstartó helyreállítható törlési és végleges törlési védelemmel rendelkezik-e. Ha a helyreállítható törlés és a végleges törlés elleni védelem nincs engedélyezve a kulcstartón, a TDE-védő beállítása hibával meghiúsul. Ebben az esetben először engedélyezni kell a helyreállítható törlési és végleges törlési védelmet a kulcstartón, majd végre kell hajtani a TDE-védő beállítását.

A TDE-védő konfigurálására vonatkozó követelmények

  • A TDE-védő csak aszimmetrikus, RSA- vagy RSA HSM-kulcs lehet. A támogatott kulcshosszok 2048 bájt és 3072 bájt.

  • A kulcs aktiválási dátumának (ha be van állítva) múltbeli dátumnak és időpontnak kell lennie. A lejárati dátumnak (ha be van állítva) jövőbeli dátumnak és időpontnak kell lennie.

  • A kulcsnak Engedélyezve állapotban kell lennie.

  • Ha meglévő kulcsot importál a kulcstartóba, győződjön meg arról, hogy a támogatott fájlformátumokban (.pfx, .byokvagy .backup) adja meg.

Megjegyzés

SQL do Azure mostantól támogatja a felügyelt HSM-ben tárolt RSA-kulcs használatát TDE-védőként. Az Azure 密钥保管库 Managed 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ű ellenőrzött HSM-ekkel. Mer informasjon 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 密钥保管库 újonnan importált kulcsok SQL do Azure Database-hez vagy Azure SQL Managed Instance az ügyfél által felügyelt TDE-forgatókönyvekhez legyenek használatban. 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, és kezdje el TDE-védőként használni 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ásához

  • Legfeljebb 500 Ogólnego przeznaczenia vagy 200 Krytyczne dla działania firmy adatbázist társíthat egyetlen előfizetésben található kulcstartóhoz, 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 az adatok a Key Vault szolgáltatás korlátaiban található tapasztalatokon alapulnak. A cél az, hogy megakadályozza a kiszolgáló feladatátvétele utáni problémákat, mivel annyi kulcsműveletet aktivál a tárolón, 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. Mer informasjon az erőforrás-zárolásokról.

  • Naplózás és jelentéskészítés engedélyezése az összes titkosítási kulcson: 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 kulcstartóval, amelyek különböző régiókban találhatók, és ugyanazt a kulcsanyagot használják. 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 konfigurálásának nagyobb rugalmassága érdekében az SQL do Azure adatbázis és Azure SQL Managed Instance egy régióban mostantól bármely más régióban összekapcsolhatók a key vaulthoz. A kiszolgálónak és a kulcstartónak nem szükséges ugyanabban a régióban lennie.

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 AKV-ban való első használat előtt. A biztonsági mentés csak Azure-密钥保管库 állítható vissza. Mer informasjon a Backup-AzKeyVaultKey paranccsal kapcsolatban.

  • 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. 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 mindegyik biztonsági másolatnak arra a TDE-védőre van szüksége, amellyel a létrehozásakor titkosították. A kulcsrotálások a Transzparens adattitkosítási védő elforgatása a PowerShell használatával című témakörben található utasítások szerint végezhetők 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 密钥保管库 létrehozott TDE-védőket mindaddig fenn kell tartani, amíg az összes többi tárolt biztonsági mentést szolgáltatás által felügyelt kulcsokkal nem hozták létre. Készítsen helyreállítható biztonsági másolatokat ezekről a kulcsokról a Backup-AzKeyVaultKey használatával.

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

TDE-védő elforgatása

A kiszolgáló TDE-védőjének elforgatása azt jelenti, hogy a kiszolgáló adatbázisait védő új aszimmetrikus kulcsra vált. A kulcsváltás egy online művelet, amely 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 automatizált forgatási funkcióval végezhető el.

A TDE-védő automatikus forgatá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óinál. Ha a rendszer a kulcs új verzióját észleli, a kiszolgálón található TDE-védő automatikusan a legújabb kulcsverzióra vált 60 percen belül.

Ha az Azure 密钥保管库 automatizált kulcsrotálással használja, ez a funkció lehetővé teszi a teljes körű érintésmentes forgatást a TDE-védőhöz az SQL do Azure Database-en és Azure SQL Managed Instance.

Georeplikációs szempontok a TDE-védő automatikus forgatá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 rotálá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ó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édőkulcsát tartalmazó kulcstartóhoz).

  • Ha az automatikus kulcsrotálás engedélyezve van, a georeplikáció kezdeményezé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á kell férnie az elsődleges kiszolgálóhoz használt kulcshoz ugyanabban a kulcstartóban (és nem egy másik kulcshoz ugyanazzal a kulcsanyaggal). Másik lehetőségként a georeplikáció elindítása 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 a szükséges engedélyekkel az elsődleges kiszolgáló kulcstartó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 az elsődleges kiszolgálón az automatikus kulcsrotálás engedélyezé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á kell férnie az elsődleges kiszolgálóhoz használt kulcshoz ugyanabban a kulcstartóban (é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 a szükséges engedélyekkel az elsődleges kiszolgáló kulcstartóján, és a rendszer megpróbálja hozzáadni a kulcsot a másodlagos kiszolgálóhoz.

Nem érhető el a TDE-védő

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 múlva elkezdi megtagadni az összes kapcsolatot a megfelelő hibaüzenettel, és az állapotát Elérhetetlenre módosítja. 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:

  • Ha a kulcshozzáférés 30 percen belül helyreáll, az adatbázis a következő órán belül automatikusan megjelenik.

  • Ha a kulcshozzáférés 30 percnél hosszabb idő elteltével állítható vissza, az automatikus elérés nem lehetséges, és az adatbázis visszaállítása további lépéseket igényel a portálon, és az adatbázis méretétől függően jelentős időt vehet igénybe. Miután az adatbázis újra online állapotba kerül, a korábban konfigurált kiszolgálószintű beállítások, például a feladatátvételi csoport konfigurációja, az időponthoz kötött visszaállítási előzmények és címkék elvesznek. Ezért ajánlott egy olyan értesítési rendszer implementálása, amely lehetővé teszi a mögöttes kulcshozzáférési problémák azonosítását és megoldását 30 percen belül.

Az alábbiakban azokat a további lépéseket tekintheti meg, amelyekre a portálon szükség van egy elérhetetlen adatbázis online állapotba helyezéséhez.

A TDE BYOK elérhetetlen adatbázisa

TDE-védő véletlen 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 kulcshoz való kiszolgálói hozzáférést:

  • 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 az Azure Active Directoryban

Mer informasjon az adatbázis elérhetetlenné válásának gyakori okairól.

Blokkolt kapcsolat SQL Managed Instance és 密钥保管库 között

Ha SQL Managed Instance hálózati hibák lépnek fel, amikor megpróbál hozzáférni a TDE-védőhöz az Azure-ban 密钥保管库 előfordulhat, hogy az adatbázisok nem módosítják az állapotát elérhetetlenné, 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, amikor a kulcstartó végpontja elérhető, de a kapcsolat megtagadva, hiányzó engedélyek stb., az adatbázisok elérhetetlen állapotra módosítják az állapotát.

A hálózati kapcsolat 密钥保管库 való hiányának leggyakoribb okai a következők:

  • 密钥保管库 privát végponton keresztül érhető el, és az AKV-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ó teljes tartománynevét nem oldja fel, vagy érvénytelen IP-címre oldja fel.

Tesztelje az SQL Managed Instance és a TDE-védőt üzemeltető 密钥保管库 közötti kapcsolatot.

  • 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 a TcpTestSucceed: False értéket adja 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ő szabvánnyal, 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 monitorozásához és a TDE-védelem hozzáférésének elvesztését jelző 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 az adatbázishoz való első kapcsolat megtagadása után.
  • 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 értesítéseket és riasztásokat küldjenek Önnek a beállítások alapján, például Email/SMS/Push/Voice, Logic App, Webhook, ITSM vagy Automation Runbook.

Adatbázis biztonsági mentése és visszaállítása az ügyfél által felügyelt TDE-vel

Ha egy adatbázist egy 密钥保管库 kulcsával titkosít egy TDE-vel, 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 密钥保管库, 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 több TDE-védő is beállítható. Ez a kulcs a Azure-Portal panelen található "A kulcs alapértelmezett TDE-védővé tétele" felirattal van megjelölve. 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 rendelkező 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 visszaállítási kísérlet során a következő hibaüzenet jelenik meg: "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 ö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 a get-AzSqlInstanceKeyVaultKey parancsmagot 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 helyreállítása SQL Database. Ha többet szeretne megtudni a dedikált SQL-készletek biztonsági mentésének helyreállításáról az Azure Synapse Analyticsben, olvassa el a Dedikált SQL-készlet helyreállítása című témakört. Ha SQL Server natív biztonsági mentését/visszaállítását SQL Managed Instance szeretné, olvassa el a Gyorsútmutató: Adatbázis visszaállítása SQL Managed Instance című témakört.

A naplófájlok egy másik szempontja: A biztonsági mentési naplófájlok továbbra is titkosítva maradnak az eredeti TDE-védővel, 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 az Azure 密钥保管库-ben tárolt TDE-védőt használ, akkor is szükség lesz 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 ügyfél által felügyelt TDE-vel

Még akkor is ajánlott konfigurálni a kiszolgálót, ha nincs konfigurálva georedundancia a kiszolgálóhoz, hogy két különböző régióban két különböző kulcstartót használjon 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 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 lévő kulcstartónak adja meg, a kulcstartón kívüli létrehozásával és importálásával mindkét kulcstartóba importálhatja őket.

Azt is megteheti, hogy létrehoz egy kulcsot az elsődleges kulcstartóval egy régióban, és egy másik Azure-régióban lévő kulcstartóba klónoz egy kulcsot. 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 a Azure-Portal a kulcs biztonsági mentéséhez és visszaállításához. A kulcsok biztonsági mentési/visszaállítási művelete csak ugyanazon Az Azure-előfizetésen belüli kulcstartók és az Azure földrajzi régiója között engedélyezett.

Egykiszolgálós HA

Geo-DR és ügyfél által felügyelt TDE

Az aktív georeplikációs és feladatátvételi csoportok esetében az érintett elsődleges és másodlagos kiszolgálók ugyanahhoz a kulcstartóhoz (bármely régióban) vagy különálló kulcstartókhoz kapcsolhatók. Ha külön kulcstartók kapcsolódnak az elsődleges és a másodlagos kiszolgálókhoz, az ügyfél felelős azért, hogy a kulcs anyaga konzisztens maradjon a kulcstartók között, így a geo-secondary 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ódása miatt. Legfeljebb négy másodfok konfigurálható, és a láncolás (másodfokok) nem támogatott.

A georeplikáció hiányos kulcsanyag miatti létrehozásakor vagy közben felmerülő problémák elkerülése érdekében fontos, hogy az ügyfél által felügyelt TDE konfigurálásakor kövesse ezeket a szabályokat (ha az elsődleges és másodlagos kiszolgálókhoz külön kulcstartókat használnak):

  • 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 a jelenlegi 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ételi csoportok és georedundáns

Feladatátvétel teszteléséhez kövesse az Aktív georeplikáció áttekintése című témakör lépéseit. A feladatátvétel tesztelését rendszeresen el kell végezni annak ellenőrzéséhez, hogy SQL Database mindkét kulcstartóhoz rendelkezik-e hozzáférési engedéllyel.

SQL do Azure adatbázis-kiszolgáló és az egyik régióban lévő SQL Managed Instance mostantól bármely más régióban összekapcsolhatók a kulcstartóval. A kiszolgálónak és a kulcstartónak nem kell ugyanabban a régióban lennie. Az egyszerűség kedvéért így az elsődleges és a másodlagos kiszolgálók ugyanahhoz a kulcstartóhoz csatlakoztathatók (bármely régióban). Ez segít elkerülni az olyan eseteket, amikor a kulcsanyag nincs szinkronizálva, ha külön kulcstartókat használ a mindkét kiszolgálóhoz. Az Azure Key Vault többszintű redundanciát biztosít, hogy a kulcsok és kulcstartók szolgáltatás- vagy régióhiba esetén is rendelkezésre álljanak. Az Azure Key Vault rendelkezésre állása és redundanciája

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

Azure Policy az ügyfél által felügyelt TDE kényszerítésére használható egy SQL do Azure adatbázis-kiszolgáló vagy Azure SQL Managed Instance létrehozása vagy frissítése során. Ezzel a szabályzattal a logikai kiszolgáló Azure-ban vagy felügyelt példányban 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. A Azure Policy a teljes Azure-előfizetésre vagy csak egy erőforráscsoportra alkalmazható.

A Azure Policy kapcsolatos további információkért lásd: Mi a Azure Policy? és Azure Policy definíciós struktúra.

A következő két beépített szabályzat támogatott az ügyfél által felügyelt TDE-ben a Azure Policy:

  • Az SQL-kiszolgálóknak ügyfél által felügyelt kulcsokat kell használniuk az inaktív adatok titkosításához
  • 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 kezelhető a Azure-Portal, és megkeresheti a Szabályzat szolgáltatást. A Definíciók területen keresse meg az ügyfél által felügyelt kulcsot.

A házirendeknek három hatása van:

  • Naplózás – Az alapértelmezett beállítás, és csak a Azure Policy tevékenységnaplókban rögzít naplójelentést
  • Megtagadás – Megakadályozza a logikai kiszolgáló vagy a felügyelt példány létrehozását vagy frissítését az ü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 logikai kiszolgáló vagy felügyelt példány létrehozásában vagy frissítésében az ügyfél által felügyelt TDE engedélyezése nélkül

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

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.

Következő 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:

Emellett engedélyezze Microsoft Defender az SQL számára az adatbázisok és azok adatainak védelmét, valamint a lehetséges adatbázis-biztonsági rések felderítésére és enyhítésére szolgáló funkciókkal, valamint az adatbázisokat fenyegető rendellenes tevékenységek észlelésével.