Customer-managed TDE for Azure Synapse Analytics

A következőkre vonatkozik: Dedikált Azure Synapse Analytics SQL-készletek (korábban SQL DW)

Tip

Microsoft Fabric Data Warehouse egy nagyvállalati szintű relációs raktár egy Data Lake-alaprendszeren, jövőre kész architektúrával, beépített AI-vel és új funkciókkal. Ha még nem ismerkedik az adattárházakkal, kezdje a Fabric Data Warehouse-szal. A meglévő dedikált SQL-készlet számítási feladatai frissíthetők Fabric az adatelemzés, a valós idejű elemzés és a jelentéskészítés új képességeinek eléréséhez.

Az átlátszó adattitkosítás (TDE) ügyfél által kezelt kulccsal (CMK) lehetővé teszi a Bring Your Own Key (BYOK) forgatókönyvet a nyugalmi állapotú adatok védelmét illetően, és lehetővé teszi a szervezetek számára, hogy a kulcsok és adatok kezelésében megvalósítsák a feladatkörök szétválasztását. Az ügyfél által kezelt TDE használatával te vállalod a felelősséget a kulcsok életciklus-kezeléséért (kulcs létrehozása, feltöltés, kulcsrotáció, törlés), és teljes mértékben te irányítod a kulcshasználati jogosultságokat és a kulcsokon végzett műveletek auditálását.

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.

Megjegyzés

Ez a cikk az önálló, dedikált SQL poolokat (korábban SQL DW) tárgyalja.

  • Azure Synapse Analytics dedikált SQL pool-okhoz (korábban SQL DW) állítsd be a TDE protector-t szerver szinten. Az adott szerverhez tartozó összes titkosított adatbázis örökli a TDE-védőt.
  • Az adatokat dedikált SQL poolokban és szerver nélküli SQL poolokban titkosítsd egy Synapse munkaterületen az ügyfél által kezelt kulcs segítségével, amely a munkaterület szintjén konfigurált. 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.

Ü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 kezelt kulcs (CMK) – Kezeled a kulcs életciklusát, beleértve a kulcs létrehozását, forgatását és törlését. Tárold a kulcsot az Azure Key Vault-ban vagy az Azure Managed HSM-ben, és használd a Database Encryption Key (DEK) titkosítására.

  • Bring Your Own Key (BYOK) – Biztonságosan behozza vagy importálja saját kulcsát egy helyszíni hardveres biztonsági modulból (HSM) az Azure Key Vaultba. 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 kezelt TDE az alábbi előnyöket biztosítja:

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

Important

Azok számára, akik szolgáltatás által kezelt TDE-t használnak, és szeretnének ügyfél által kezelt TDE-t használni, az adatok titkosítva maradnak az átállás során, és nincs leállás vagy 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.

Az ügyfél által felügyelt TDE Azure Key Vaultban történő konfigurálásához szükséges engedélyek

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

Ahhoz, hogy az Azure-ban működő SQL logikai szerver a Azure Key Vault-ban tárolt TDE-védőt használja 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 kiszolgálóidentitásnak rendelkeznie kell a Key Vault Crypto Service Encryption User szerepkörrel ahhoz, hogy a kulcsot titkosítási és visszafejtési műveletekhez használhassa.

  • 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ásának az alábbi engedélyekre van szüksége 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. A TDE-hez tartozó, az Azure Key Vault hozzáférési konfigurációjának beállítására vonatkozó részletes útmutatásért lásd: Az SQL Server TDE bővíthető kulcskezelésének beállítása az Azure Key Vault használatával. 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.

Amikor beállítasz egy szervert úgy, hogy TDE védelmezőt használjon az Azure Key Vault-ból, a szerver minden TDE-vel rendelkező adatbázis DEK-jét a kulcstárnak küldi titkosításra. A kulcstároló visszaadja a titkosított DEK-et, amelyet a szerver a felhasználói adatbázisban tárol.

Szükség esetén a szerver a védett DEK-et a kulcstárba küldi a visszafejtésére.

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

Megjegyzés

Körülbelül 10 percbe telhet, mire bármilyen engedélyváltoztatás hatályba lép a kulcstárban. Ez az időszak magában foglalja a hozzáférési jogok visszavonását az AKV-ben lévő TDE védőhöz, és a felhasználóknak még mindig lehetnek hozzáférési jogaik.

Az Azure Key Vaultban az ügyfél által felügyelt TDE konfigurálásának követelményei

  • Engedélyezze a helyreállítható törlési és törlés elleni védelem funkciókat az Azure Key Vaultban. Ez a konfiguráció segít megakadályozni a kulcstartó vagy kulcs véletlen vagy rosszindulatú törlését, amelyek az adatbázis elérhetetlen állapotba kerüléséhez vezethetnek. Amikor egy meglévő kiszolgálón vagy a kiszolgáló létrehozása során konfigurálod a TDE-védőt, az Azure SQL azt ellenőrzi, hogy a használt kulcstartóban be van-e kapcsolva a helyreállítható törlés és a végleges törlés elleni 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 engedélyezzük a helyreállítható törlést és a végleges törlés elleni védelmet a kulcstárolón, majd végezd el a TDE-védő beállítását.

  • 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

Az ügyfél által kezelt kulcsokat használó transzparens adattitkosítás egy külső kulcsot használ az adatbázis-titkosítási kulcs (DEK) védelmére; ezt a kulcsot TDE-protektornak nevezik, és az Azure Key Vault tárolja.

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

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

A TDE-védő az Azure Key Vaultban tárolt aszimmetrikus kulcsokkal védhető. A támogatott kulcsméretek 2 048 bites és 3 072 bites.

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

  • Ha megadsz egy kulcsaktiválási dátumot, állítsd azt a múltra eső dátumra és időpontra.
  • Ha megadsz kulcs lejárati dátumot, állítsd be egy jövőbeli dátumot és időpontot.
  • A kulcsnak engedélyezve 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

Javaslatok az ügyfél által kezelt TDE konfigurálásához az Azure Key Vaultban

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.

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

    További információért a korlátozás működéséről lásd: Azure Key Vault throttling útmutató.

    • A hiperskála-adatbázisok száma, amelyeket egyetlen Azure Key Vault-hoz lehet társítani, attól függ, hány lapszerver található. Minden lapkiszolgáló egy logikai adatfájlhoz van csatolva. Az oldalszerverek számának megtalálásához futtasd le 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. További információért a monitorozásról és riasztásokról lásd: Az Azure Key Vault monitorozása és Az Azure Key Vault riasztásainak konfigurálása.

  • Á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. Hogy többet megtudj az erőforrás-zárakró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.

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

  • Tartsd a TDE védő másolatát biztonságos helyen, vagy helyezd letétbe egy letéti szolgáltatónál.

  • Ha a kulcsot a kulcs vaultban generálod, készíts egy kulcsmentést, mielőtt először használnád a kulcsot az Azure Key Vault-ban. A mentést csak egy Azure Key Vault-ba lehet visszaállítani. További információért lásd a Backup-AzKeyVaultKey parancsot. 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éket és szerepkiosztást. További információ: Teljes biztonsági mentés, visszaállítás és szelektív kulcs-visszaállítás.

  • Hozz létre egy új biztonsági mentést, amikor bármilyen változtatást végzel a kulcshoz tartozó beállításokon (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 mindegyik biztonsági másolatnak arra a TDE-védőre van szüksége, amellyel a létrehozásakor 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.

  • Tartsd meg az összes korábban használt kulcsot az Azure Key Vault-ban, még a szolgáltatás által kezelt kulcsokra váltás után is. Biztosítja, hogy az adatbázis biztonsági mentései visszaállíthatók az Azure Key Vaultban tárolt TDE védőkkel. Az Azure Key Vault-szal létrehozott TDE-védőket karban kell tartani, amíg az összes fennmaradó tárolt biztonsági másolatot szolgáltatás által kezelt kulcsokkal nem készítik el. Készíts visszaállítható biztonsági másolatokat ezekről a kulcsokról a Backup-AzKeyVaultKey haszná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.

TDE-védő elforgatása

Amikor lecseréled a TDE-védőt, kicseréled azt a kulcsot, amely az adatbázis titkosítási kulcsot (DEK) védi. A kulcsrotáció online művelet, és csak néhány másodpercet vesz igénybe. Ez a művelet csak az adatbázis titkosítási kulcsát fejti vissza és titkosítja újra, nem az egész adatbázist.

A TDE-védőt úgy cserélheted le, hogy a konfigurációt egy, az Azure Key Vaultban tárolt új kulcs használatára állítod. A kínálattól és a támogatott konfigurációtól függően ez a kulcs a következő lehet:

  • Váltás ugyanannak a kulcsnak egy új kulcsverziójára
  • Váltás másik kulcsra

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

Engedélyezheted a TDE-védő automatikus rotációját, amikor beállítod a szerver TDE-védőjét. Az automatikus forgatás alapértelmezés szerint le van tiltva. Ha engedélyezve van, a szerver folyamatosan ellenőrzi a kulcstárolót a kulcs új verziói után, amelyet TDE-védőként használnak. Ha a szerver új kulcsverziót észlel, automatikusan 24 órán belül lecseréli a szerveren vagy az adatbázisban lévő TDE-védőt a legfrissebb kulcsverzióra.

Megjegyzés

Amikor a TDE-t CMK-val állítod be a kulcsok manuális vagy automatikus rotációjával, mindig a rendszer által támogatott kulcs legfrissebb verzióját használod. A beállítás nem teszi lehetővé a kulcsok korábbi vagy alacsonyabb verziójának használatát. A mindig a legújabb kulcsverzió használata megfelel az Azure SQL biztonsági szabályzatának, amely tiltja a korábbi, esetleg veszélyeztetett kulcsverziók használatát.

Elérhetetlen TDE-védő

Amikor a TDE-t úgy konfigurálod, hogy ügyfél által kezelt kulcsot használjon, az adatbázisnak folyamatos hozzáférésre van szüksége a TDE-védőhöz, hogy online maradjon. Ha a szerver elveszíti a hozzáférést az ügyfél által kezelt TDE-védőhöz az Azure Key Vaultban, az adatbázis 10 percen belül minden kapcsolatot megtagad, hibaüzenetet jelenít meg, és állapota Nem elérhető értékre változik. 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. A hálózati hibák vagy kiesések hatásának csökkentése érdekében az Azure Key Vaultban található TDE-védő elérésekor a szolgáltatás egy 24 órás puffert vezet be, mielőtt megpróbálná az adatbázist elérhetetlen állapotba helyezni. 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 szerver bármilyen Azure Key Vault hiba (például 4XX hiba) miatt elveszíti a hozzáférést az ügyfél által kezelt TDE védőhöz az Azure Key Vault-ban, az adatbázis 30 perc után elérhetetlen állapotba kerül.

Adatbázis-hozzáférés visszaállítása Azure Key Vault hiba 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 .

Az SQL Managed Instance és az Azure Key Vault közötti kapcsolat blokkolva van

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 Vault hálózati kapcsolatának hiányának leggyakoribb okai a következők:

  • Az Azure Key Vault privát végponton keresztül van elérhető, és az Azure Key Vault szolgáltatás privát IP-címe nem engedélyezett a Network Security Group (NSG) kimenő szabályaiban, amelyek a kezelt instance alhálózathoz kapcsolódnak.

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

Teszteld az SQL Managed Instance és a TDE-protektort tároló Azure Key Vault 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ényének a következőnek kell lennie: 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, erősítse meg, hogy érvényes. 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 hozzáférhetetlen adatbázis, amely elvesztette a hozzáférést a TDE-védőhöz, az "Nem elérhető" állapotban jelenik meg, miután az adatbázishoz való első csatlakozást elutasítják.

  • 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 értesítéseket hozsz létre ezekre az eseményekre, a lehető leghamarabb visszaállíthatod a hozzáférést.

  • Az akciócsoportok definiálhatók úgy, hogy értesítéseket és riasztásokat küldjenek a preferenciáid alapján, például Email, SMS, Push, Voice, Logic App, Webhook, ITSM vagy Automation Runbook.

Adatbázismentés és helyreállítás ügyfél által felügyelt TDE-vel

Miután egy adatbázist tde-vel titkosítanak az Azure Key Vault kulcsával, az újonnan generált biztonsági mentéseket is ugyanazzal a TDE védővel titkosítják. A TDE-védő módosításakor az adatbázis régi biztonsági másolatai nem frissülnek a legújabb TDE-védő használatára.

Az Azure Key Vault-ból származó TDE-védővel titkosított biztonsági mentés visszaállításához győződjön meg róla, hogy a kulcsanyag elérhető legyen a célszerver számára. Ezért tartsd meg a régi TDE védő verziókat kulcstárolóban vagy menedzselt HSM-ben, hogy vissza lehessen állítani az adatbázis-mentéseket.

Important

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. Ezeket a kulcsokat nem a DEK védelmére használják, de a mentés visszaállítása során használhatók, ha a biztonsági mentés 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édettként megjelölni.

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.

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 egy Azure Key Vault-ban tárolt TDE-védőt használ, akkor erre a kulcsra a visszaállításkor szükség van, még akkor is, ha az adatbázist addig szolgáltatás által kezelt TDE-re módosították.

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

Az Azure Key Vault többrétegű redundanciájának használatával azok a TDE-k, amelyek ügyfél által kezelt kulcsot használnak, profitálhatnak az Azure Key Vault elérhetőségéből és ellenállóképességéből. Teljes mértékben támaszkodhatnak az Azure Key Vault redundancia megoldására.

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

Az Azure Key Vault automatikusan kínálja a rendelkezésre állás és az ellenálló képesség következő összetevőit felhasználói beavatkozás nélkül:

Kapcsolódó tartalom

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