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

Diagram that shows an overview of Bring Your Own Key

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.

    trusted-service-with-AKV

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. Ha kérdése van, forduljon a következőhöz AskAzureDBforMySQL@service.microsoft.com :

  • 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