Megosztás a következőn keresztül:

Azure Database for MySQL-adattitkosítás ügyfél által felügyelt kulccsal

  • Cikk

A következőkre vonatkozik: Azure Database for MySQL – Önálló kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

Az Azure Database for MySQL ügyfél által felügyelt kulcsokkal történő titkosítása lehetővé teszi a saját kulcs használatát (BYOK) az inaktív adatok védelméhez. Emellett lehetővé teszi a szervezetek számára a kulcsok és adatok kezelésével járó feladatok elkülönítését. Az ügyfél által felügyelt titkosítással Ön felelős a kulcs életciklusáért, a kulcshasználati engedélyekért és a kulcsokon végzett műveletek naplózásáért, teljes körű felügyeletéért.

Az Azure Database for MySQL ügyfél által felügyelt kulcsaival rendelkező adattitkosítás kiszolgálószinten van beállítva. Egy adott kiszolgáló esetében a szolgáltatás által használt adattitkosítási kulcs (DEK) titkosítására egy ügyfél által felügyelt kulcs, az úgynevezett kulcstitkosítási kulcs (KEK) szolgál. A KEK egy aszimmetrikus kulcs, amely egy ügyfél által birtokolt és ügyfél által felügyelt Azure Key Vault-példányban van tárolva. A kulcstitkosítási kulcs (KEK) és az adattitkosítási kulcs (DEK) részletesebb leírása a cikk későbbi részében olvasható.

A Key Vault egy felhőalapú, külső kulcskezelő rendszer. Magas rendelkezésre állású, és skálázható, biztonságos tárterületet biztosít az RSA titkosítási kulcsokhoz, opcionálisan a FIPS 140 által ellenőrzött hardveres biztonsági modulok (HSM-ek) segítségével. Nem teszi lehetővé a tárolt kulcsok közvetlen elérését, de titkosítási és visszafejtési szolgáltatásokat nyújt az engedélyezett entitások számára. A Key Vault létrehozhatja, importálhatja vagy áthelyezheti egy helyszíni HSM-eszközről.

Feljegyzés

Ez a funkció csak az Általános célú tárolás v2 (legfeljebb 16 TB)" tárterületen támogatott, amely általános célú és memóriaoptimalizált tarifacsomagokban érhető el. További részletekért tekintse meg a Tárolási fogalmakat . Egyéb korlátozásokért tekintse meg a korlátozási szakaszt.

Juttatások

Az Azure Database for MySQL ügyfél által felügyelt kulcsaival történő adattitkosítás a következő előnyöket biztosítja:

  • Az adathozzáférést teljes mértékben Ön szabályozza a kulcs eltávolításának és az adatbázis elérhetetlenné tételének lehetőségével
  • A kulcs életciklusának teljes ellenőrzése, beleértve a kulcs elforgatását a vállalati szabályzatokhoz való igazodás érdekében
  • Kulcsok központi kezelése és szervezése az Azure Key Vaultban
  • A biztonsági tisztviselők, valamint a DBA és a rendszergazdák közötti feladatok elkülönítésének megvalósítása

Terminológia és leírás

Adattitkosítási kulcs (DEK): Egy partíció vagy adatblokk titkosításához használt szimmetrikus AES256-kulcs. Az egyes adatblokkok más kulccsal történő titkosítása megnehezíti a titkosítási elemzési támadásokat. Az adott blokk titkosítását és visszafejtését végző erőforrás-szolgáltatónak vagy alkalmazáspéldánynak szüksége van a DEK-khoz való hozzáférésre. Ha a DEK-t új kulccsal cseréli le, csak a társított blokkban lévő adatokat kell újratitkosítani az új kulccsal.

Kulcstitkosítási kulcs (KEK): A DEK-k titkosításához használt titkosítási kulcs. A Key Vaultot soha nem elhagyó KEK lehetővé teszi, hogy maguk a DEK-k titkosítva és vezérelve legyenek. A KEK-hez hozzáféréssel rendelkező entitás eltérhet a DEK-t igénylő entitástól. Mivel a KEK-nek a DEK-k visszafejtéséhez van szükség, a KEK gyakorlatilag egyetlen pont, amellyel a DEK-k a KEK törlésével hatékonyan törölhetők.

A KEK-kkal titkosított DEK-k tárolása külön történik. Ezeket a DEK-okat csak a KEK-hez hozzáféréssel rendelkező entitás tudja visszafejteni. További információ: Biztonság inaktív állapotban.

Az ügyfél által felügyelt kulccsal végzett adattitkosítás működése

Ahhoz, hogy egy MySQL-kiszolgáló a Key Vaultban tárolt ügyfél által kezelt kulcsokat használhassa a DEK titkosításához, a Key Vault rendszergazdája a következő hozzáférési jogosultságokat biztosítja a kiszolgáló számára:

  • get: A kulcs nyilvános részének és tulajdonságainak lekéréséhez a kulcstartóban.
  • wrapKey: A DEK titkosításához. A titkosított DEK az Azure Database for MySQL-ben van tárolva.
  • unwrapKey: A DEK visszafejtéséhez. Az Azure Database for MySQL-nek visszafejtett DEK-ra van szüksége az adatok titkosítá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 is naplózhatók.

Ha a kiszolgáló úgy van konfigurálva, hogy a kulcstartóban tárolt ügyfél által kezelt kulcsot használja, a kiszolgáló elküldi a DEK-t a kulcstartónak titkosítás céljából. A Key Vault a felhasználói adatbázisban tárolt titkosított DEK-t adja vissza. Hasonlóképpen, ha szükséges, a kiszolgáló elküldi a védett DEK-t a kulcstartóba a visszafejtéshez. Az auditorok az Azure Monitor használatával áttekinthetik a Key Vault naplózási eseménynaplóit, ha a naplózás engedélyezve van.

Az Azure Database for MySQL adattitkosításának konfigurálására vonatkozó követelmények

A Key Vault konfigurálásának követelményei a következők:

  • A Key Vaultnak és az Azure Database for MySQL-nek ugyanahhoz a Microsoft Entra-bérlőhöz kell tartoznia. A bérlők közötti Key Vault és a kiszolgálói interakciók nem támogatottak. A Key Vault-erőforrás későbbi áthelyezéséhez újra kell konfigurálnia az adattitkosítást.
  • A kulcstartó helyreállítható törlési funkciójának engedélyezése 90 napos megőrzési időtartammal az adatvesztés elleni védelem érdekében, ha véletlen kulcs (vagy Key Vault) törlése történik. A helyreállíthatóan törölt erőforrások alapértelmezés szerint 90 napig maradnak meg, kivéve, ha a megőrzési időtartam kifejezetten =90 napra van állítva <. A visszaállítási és 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 ki van kapcsolva, de a PowerShellen vagy az Azure CLI-n keresztül engedélyezheti (vegye figyelembe, hogy az Azure Portalon keresztül nem engedélyezheti).
  • Engedélyezze a Kulcstartó Törlés elleni védelem funkcióját 90 napos megőrzési időtartammal. A törlés elleni védelem csak akkor engedélyezhető, ha engedélyezve van a helyreállítható törlés. Az Azure CLI-n vagy a PowerShellen keresztül is bekapcsolható. Ha a törlés elleni védelem be van kapcsolva, a törölt állapotban lévő tároló vagy objektum csak a megőrzési időszak leteltével törölhető. A helyreállíthatóan törölt tárolók és objektumok továbbra is helyreállíthatók, biztosítva a megőrzési szabályzat betartását.
  • Adjon hozzáférést az Azure Database for MySQL-nek a kulcstartóhoz a get, wrapKey és unwrapKey engedélyekkel az egyedi felügyelt identitás használatával. Az Azure Portalon a rendszer automatikusan létrehozza a szolgáltatás egyedi identitását, amikor engedélyezve van az adattitkosítás a MySQL-en. Az Azure Portal használatakor részletes, részletes útmutatást a MySQL adattitkosításának konfigurálása című témakörben talál.

Az ügyfél által felügyelt kulcs konfigurálásának követelményei a következők:

  • A DEK titkosításához használandó ügyfél által kezelt kulcs csak aszimmetrikus lehet, RSA 2048.
  • 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átum nincs beállítva.
  • A kulcsnak engedélyezve kell lennie.
  • A kulcsnak helyreállítható törléssel kell rendelkeznie, és a megőrzési idő 90 napra van beállítva. Ez implicit módon beállítja a szükséges kulcsattribútum-helyreállításiszintet: "Helyreállítható". Ha a megőrzés 90 napra van állítva<, a helyreállítási szint: "CustomizedRecoverable", ami nem követelmény, ezért győződjön meg arról, hogy a megőrzési idő 90 napra van beállítva.
  • A kulcsnak engedélyezve kell lennie a törlés elleni védelemnek.
  • Ha egy meglévő kulcsot importál a kulcstartóba, ügyeljen rá, hogy a támogatott fájlformátumokban (.pfx, , .byok) .backupadja meg.

Ajánlások

Ha ügyfél által felügyelt kulccsal használ adattitkosítást, az alábbiakban a Key Vault konfigurálására vonatkozó javaslatokat talál:

  • Állítson be egy erőforrás-zárolást a Key Vaulton 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.
  • Engedélyezze a naplózást és a jelentéskészítést az összes titkosítási kulcson. A Key Vault olyan naplókat biztosít, amelyek könnyen injektálhatóak más biztonsági információkba és eseménykezelési eszközökbe. Az Azure Monitor Log Analytics egy példa egy már integrált szolgáltatásra.
  • Győződjön meg arról, hogy a Key Vault és az Azure Database for MySQL ugyanabban a régióban található, így gyorsabb hozzáférést biztosíthat a DEK-körbefuttatáshoz és a törlési műveletekhez.
  • Zárolja az Azure KeyVaultot csak a privát végpontra és a kiválasztott hálózatokra , és csak megbízható Microsoft-szolgáltatások számára engedélyezi az erőforrások védelmét.

Az alábbiakban javaslatokat talál az ügyfél által felügyelt kulcs konfigurálására:

  • Őrizze meg az ügyfél által felügyelt kulcs egy példányát biztonságos helyen, vagy helyezze el a letéti szolgáltatásban.

  • Ha a Key Vault létrehozza a kulcsot, hozzon létre egy biztonsági másolatot a kulcs első használata előtt. A biztonsági mentést csak a Key Vaultba állíthatja vissza. A biztonsági mentési paranccsal kapcsolatos további információkért lásd: Backup-AzKeyVaultKey.

Nem érhető el az ügyfél által felügyelt kulcsfeltétel

Ha ügyfél által felügyelt kulccsal konfigurálja az adattitkosítást a Key Vaultban, a kiszolgáló folyamatos hozzáférésére van szükség ahhoz, hogy a kiszolgáló online maradjon. Ha a kiszolgáló elveszíti a hozzáférést az ügyfél által kezelt kulcshoz a Key Vaultban, a kiszolgáló 10 percen belül megtagadja az összes kapcsolatot. A kiszolgáló egy megfelelő hibaüzenetet ad ki, és a kiszolgáló állapotát elérhetetlenné módosítja. Néhány ok, amiért a kiszolgáló elérheti ezt az állapotot:

  • Ha létrehozunk egy időponthoz kötött visszaállítási kiszolgálót az Azure Database for MySQL-hez, amely engedélyezve van az adattitkosítással, az újonnan létrehozott kiszolgáló elérhetetlen állapotban lesz. Ezt a problémát az Azure Portalon vagy a parancssori felületen lehet megoldani.
  • Ha létrehozunk egy olvasási replikát az Azure Database for MySQL-hez, amely engedélyezi az adattitkosítást, a replikakiszolgáló elérhetetlen állapotban lesz. Ezt a problémát az Azure Portalon vagy a parancssori felületen lehet megoldani.
  • Ha törli a KeyVaultot, az Azure Database for MySQL nem fogja tudni elérni a kulcsot, és elérhetetlen állapotba kerül. Állítsa helyre a Key Vaultot, és értékelje újra az adattitkosítást, hogy elérhetővé tegye a kiszolgálót.
  • Ha töröljük a kulcsot a KeyVaultból, az Azure Database for MySQL nem fogja tudni elérni a kulcsot, és elérhetetlen állapotba kerül. Állítsa helyre a kulcsot, és értékelje újra az adattitkosítást, hogy elérhetővé tegye a kiszolgálót.
  • Ha az Azure KeyVaultban tárolt kulcs lejár, a kulcs érvénytelenné válik, és az Azure Database for MySQL elérhetetlen állapotba kerül. A parancssori felülettel bővítheti a kulcs lejárati dátumát, majd újraértékelheti az adattitkosítást, hogy elérhetővé tegye a kiszolgálót.

Véletlen kulcshozzáférés visszavonása a Key Vaultból

Előfordulhat, hogy a Key Vaulthoz 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 következő módon:

  • A kulcstartó és a kiszolgáló engedélyeinek getwrapKeyunwrapKey visszavonása.
  • A kulcs törlése.
  • A kulcstartó törlése.
  • A kulcstartó tűzfalszabályainak módosítása.
  • A kiszolgáló felügyelt identitásának törlése a Microsoft Entra-azonosítóban.

Az ügyfél által felügyelt kulcs figyelése a Key Vaultban

Az adatbázis állapotának figyeléséhez és a transzparens adattitkosítási védő hozzáférés elvesztésére vonatkozó riasztások engedélyezéséhez konfigurálja a következő Azure-funkciókat:

  • Azure Resource Health: Egy elérhetetlen adatbázis, amely elvesztette az ügyfélkulcshoz való hozzáférést, "Elérhetetlenként" jelenik meg az adatbázishoz való első kapcsolat megtagadása után.

  • Tevékenységnapló: Ha az ügyfél által felügyelt Key Vaultban az ügyfélkulcshoz való hozzáférés sikertelen, 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: Ezeket a csoportokat úgy határozhatja meg, hogy a beállítások alapján értesítéseket és riasztásokat küldjön Önnek.

Visszaállítás és replikálás az ügyfél által kezelt kulccsal a Key Vaultban

Miután az Azure Database for MySQL titkosítva lett egy ügyfél Key Vaultban tárolt felügyelt kulcsával, a kiszolgáló újonnan létrehozott példánya is titkosítva lesz. Ezt az új példányt helyi vagy georedukciós művelettel, illetve olvasási replikákkal is létrehozhatja. A másolat azonban módosítható úgy, hogy az egy új ügyfél által kezelt titkosítási kulcsot tükrözze. Az ügyfél által felügyelt kulcs módosításakor a kiszolgáló régi biztonsági másolatai a legújabb kulcsot használják.

Az ügyfél által felügyelt adattitkosítás visszaállítása vagy olvasási replika létrehozása során felmerülő problémák elkerülése érdekében fontos, hogy kövesse az alábbi lépéseket a forrás- és a visszaállított/replikakiszolgálókon:

  • Indítsa el a replika létrehozásának vagy visszaállításának folyamatát a forrás Azure Database for MySQL-ből.
  • Az újonnan létrehozott kiszolgáló (visszaállított/replika) elérhetetlen állapotban maradjon, mert egyedi identitása még nem kapott engedélyeket a Key Vaulthoz.
  • A visszaállított/replikakiszolgálón újraértékelje az ügyfél által kezelt kulcsot az adattitkosítási beállítások között, hogy az újonnan létrehozott kiszolgáló megkapja a Kulcstartóban tárolt kulcs tördelési és töredezettségmentes engedélyeit.

Korlátozások

Az Azure Database for MySQL esetében az inaktív adatok ügyfél által felügyelt kulcs (CMK) használatával történő titkosításának támogatása néhány korlátozással rendelkezik –

  • Ennek a funkciónak a támogatása általános célú és memóriaoptimalizált tarifacsomagokra korlátozódik.

  • Ez a funkció csak olyan régiókban és kiszolgálókon támogatott, amelyek támogatják az általános célú 2. szintű tárolót (legfeljebb 16 TB). A legfeljebb 16 TB-os tárolást támogató Azure-régiók listájáért tekintse meg az itt található dokumentáció tárolási szakaszát

    Feljegyzés

    • Az Azure-régiókban létrehozott összes új MySQL-kiszolgáló támogatja az általános célú tárolás v2-t, és elérhető az ügyfélmenedzserkulcsokkal való titkosítás támogatása. A point in time restored (PITR) kiszolgáló vagy az olvasási replika nem lesz megfelelő, bár elméletileg "újak".
    • Annak ellenőrzéséhez, hogy a kiépített kiszolgáló általános célú tárolója 2-es verzióval rendelkezik-e, lépjen a tarifacsomag paneljére a portálon, és tekintse meg a kiépített kiszolgáló által támogatott maximális tárterület-méretet. Ha a csúszkát akár 4 TB-ra is áthelyezheti, a kiszolgáló általános célú 1. szintű tárolóban van, és nem támogatja az ügyfél által kezelt kulcsokkal történő titkosítást. Az adatok azonban mindig szolgáltatás által felügyelt kulcsokkal titkosítva lesznek.

  • A titkosítás csak RSA 2048 titkosítási kulccsal támogatott.

Következő lépések

  • Megtudhatja, hogyan állíthat be adattitkosítást ügyfél által felügyelt kulccsal az Azure Database for MySQL-hez az Azure Portal és az Azure CLI használatával.
  • További információ az Önálló Azure Database for MySQL-kiszolgáló tárolási típusának támogatásáról