Share via


Adattitkosítás ügyfél által felügyelt kulcsokkal az Azure Database for MySQL-hez – rugalmas kiszolgáló

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

A rugalmas Azure Database for MySQL-kiszolgáló ügyfél által felügyelt kulcsaival rendelkező adattitkosítással saját kulcsot (BYOK) hozhat az inaktív adatok védelméhez, és a kulcsok és adatok kezeléséhez szükséges feladatok elkülönítését valósíthatja meg. Az ügyfél által kezelt kulcsok (CMK-k) esetében az ügyfél felelős a kulcs életciklusának felügyeletéért (kulcslétrehozás, feltöltés, forgatás, törlés), kulcshasználati engedélyekért és a kulcsokon végzett naplózási műveletekért.

Juttatások

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

  • Teljes mértékben szabályozhatja az adathozzáférést, ha eltávolítja a kulcsot, és elérhetetlenné teszi az adatbázist
  • A kulcs életciklusának teljes ellenőrzése, beleértve a kulcs forgatá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, a DBA és a rendszergazdák közötti feladatok elkülönítésének megvalósítása

Hogyan működik az ügyfél által felügyelt kulccsal végzett adattitkosítás?

A Microsoft Entra ID-ban a felügyelt identitások alternatívát biztosítanak az Azure-szolgáltatások számára a hitelesítő adatok kódban való tárolására egy automatikusan hozzárendelt identitás kiépítésével, amely a Microsoft Entra-hitelesítést támogató bármely szolgáltatás, például az Azure Key Vault (AKV) hitelesítéséhez használható. A rugalmas Azure Database for MySQL-kiszolgáló jelenleg csak a felhasználó által hozzárendelt felügyelt identitást (UMI) támogatja. További információ: Felügyelt identitástípusok az Azure-ban.

Ha rugalmas Azure Database for MySQL-kiszolgálóhoz szeretné konfigurálni a CMK-t, az UMI-t a kiszolgálóhoz kell kapcsolnia, és meg kell adnia a használni kívánt Azure Key Vaultot és kulcsot.

Az UMI-nek a következő hozzáféréssel kell rendelkeznie a kulcstartóhoz:

  • Lekérés: A kulcs nyilvános részének és tulajdonságainak lekérése a kulcstartóban.
  • Lista: A Kulcstartóban tárolt kulcs verzióinak listázása.
  • Burkolókulcs: A DEK titkosításához. A titkosított DEK a rugalmas Azure Database for MySQL-kiszolgálópéldányban van tárolva.
  • Kulcs kibontása: A DEK visszafejtéséhez. A rugalmas Azure Database for MySQL-kiszolgálónak szüksége van a visszafejtett DEK-ra az adatok titkosításához/visszafejtéséhez.

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 blokkot titkosító és visszafejtő 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 szüksége van a DEK-k visszafejtésére, a KEK gyakorlatilag egyetlen pont, amellyel a DEK-k hatékonyan törölhetők a KEK törlésével. 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 a titkosítási restben.

Működés

A CMK-kkal végzett adattitkosítás a kiszolgáló szintjén van beállítva. Egy adott kiszolgáló esetében a szolgáltatás adattitkosítási kulcsának (DEK) titkosítására egy CMK-t (kulcstitkosítási kulcsot) használunk. 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 Key Vault magas rendelkezésre állású és méretezhető biztonságos tároló az RSA titkosítási kulcsokhoz, opcionálisan a FIPS 140 által ellenőrzött hardverbiztonsági modulok (HSM-ek) segítségével. A Key Vault nem teszi lehetővé a tárolt kulcs közvetlen elérését, hanem titkosítási/visszafejtési szolgáltatásokat biztosít a kulcs használatával az engedélyezett entitások számára. Az importált kulcstartó létrehozhatja a kulcsot, vagy áthelyezheti a kulcstartóba egy helyszíni HSM-eszközről.

Amikor rugalmas kiszolgálót konfigurál a kulcstartóban tárolt CMK használatára, 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, a rugalmas kiszolgáló szükség esetén elküldi a védett DEK-t a kulcstartóba a visszafejtéshez.

Diagram of how data encryption with a customer-managed key work.

A naplózás engedélyezése után az auditorok az Azure Monitor használatával áttekinthetik a Key Vault naplózási eseménynaplóit. A Key Vault naplózási eseményeinek naplózásának engedélyezéséhez tekintse meg a Key Vault szolgáltatás figyelését a Key Vault-elemzésekkel.

Feljegyzés

Az engedélymódosítások akár 10 percet is igénybe vehetnek, hogy hatással legyen a kulcstartóra. 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.

Rugalmas Azure Database for MySQL-kiszolgáló adattitkosításának konfigurálásának követelményei

Mielőtt megkísérli konfigurálni a Key Vaultot, győződjön meg arról, hogy megfelel a következő követelményeknek.

  • A Key Vaultnak és a rugalmas Azure Database for MySQL-kiszolgálópéldánynak ugyanahhoz a Microsoft Entra-bérlőhöz kell tartoznia. A bérlők közötti Key Vaultot és a rugalmas kiszolgálói interakciókat támogatni kell. Újra kell konfigurálnia az adattitkosítást, ha a konfiguráció végrehajtása után áthelyezi a Key Vault erőforrásait.
  • A Key Vaultnak és a rugalmas Azure Database for MySQL-kiszolgálópéldánynak ugyanabban a régióban kell lennie.
  • 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 a kulcs (vagy a Key Vault) véletlen törlése történik. 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 az Azure Portalon vagy a PowerShell vagy az Azure CLI használatával engedélyezheti.
  • Engedélyezze a Kulcstartó törlés elleni védelmét , és állítsa a megőrzési időtartamot 90 napra. Ha a törlés elleni védelem be van kapcsolva, a tároló vagy a törölt állapotban lévő objektumok csak a megőrzési időszak leteltével törölhetők. Ezt a funkciót a PowerShell vagy az Azure CLI használatával engedélyezheti, és csak azután, hogy engedélyezte a helyreállítható törlést.

Mielőtt megkísérli konfigurálni a CMK-t, mindenképpen feleljen meg a következő követelményeknek.

  • A DEK titkosításához az ügyfél által kezelt kulcs csak aszimmetrikus lehet, RSA\RSA-HSM(Prémium termékváltozatú tárolók) 2048 3072 vagy 4096.
  • 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ó".
  • A kulcsnak engedélyezve kell lennie a törlés elleni védelemnek.
  • Ha egy meglévő kulcsot importál a kulcstartóba, győződjön meg arról, hogy a kulcsot a támogatott fájlformátumokban (.pfx, .byok, .backup) adja meg.

Feljegyzés

A rugalmas Azure Database for MySQL-kiszolgáló dátumtitkosításának Azure Portalon keresztüli konfigurálásáról részletes, részletes útmutatást a rugalmas Azure Database for MySQL-kiszolgáló adattitkosításának konfigurálása című témakörben talál.

Javaslatok az adattitkosítás konfigurálásához

Amikor úgy konfigurálja a Key Vaultot, hogy ügyfél által felügyelt kulcs használatával használjon adattitkosítást, tartsa szem előtt az alábbi javaslatokat.

  • Á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.
  • Őrizze meg az ügyfél által felügyelt kulcs egy másolatá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.

Feljegyzés

  • Javasoljuk, hogy ugyanabból a régióból származó kulcstartót használjon, de szükség esetén használhat egy másik régióból származó kulcstartót a "kulcsazonosító megadása" adatok megadásával.
  • Az Azure Key Vault felügyelt HSM-ben tárolt RSA-kulcs jelenleg nem támogatott.

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

Ha cmK-val 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 rugalmas 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 rugalmas kiszolgáló egy megfelelő hibaüzenetet ad ki, és a kiszolgáló állapotát elérhetetlenre módosítja. A kiszolgáló többféle okból is elérheti ezt az állapotot.

  • Ha törli a kulcstartót, a rugalmas Azure Database for MySQL-kiszolgálópéldány nem fogja tudni elérni a kulcsot, és elérhetetlen állapotba kerül. Állítsa helyre a kulcstartót, és értékelje újra az adattitkosítást, hogy elérhetővé tegye az Azure Database for MySQL rugalmas kiszolgálópéldányát.
  • Ha törli a kulcsot a kulcstartóból, a rugalmas Azure Database for MySQL-kiszolgálópéldány nem fogja tudni elérni a kulcsot, és elérhetetlen állapotba kerül. A kulcs helyreállítása és az adattitkosítás újraértékelése az Azure Database for MySQL rugalmas kiszolgálópéldányának elérhetővé tétele érdekében.
  • Ha az Azure Key Vaultban tárolt kulcs lejár, a kulcs érvénytelenné válik, és a rugalmas Azure Database for MySQL-kiszolgálópéldány elérhetetlen állapotba kerül. Bővítse ki a kulcs lejárati dátumát a parancssori felülettel, majd értékelje újra az adattitkosítást, hogy elérhetővé tegye az Azure Database for MySQL rugalmas kiszolgálópéldányá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ó rugalmas kiszolgálói hozzáférést a következő módon:

  • A kulcstartó lekérési , listázási, körbefuttatási éskulcskulcs-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 rugalmas kiszolgálón történő titkosításhoz használt felhasználó által felügyelt identitás törlése ügyfél által felügyelt kulccsal 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:

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

Replika ügyfél által felügyelt kulccsal a Key Vaultban

Ha egy rugalmas Azure Database for MySQL-kiszolgálópéldányt titkosít egy ügyfél Key Vaultban tárolt felügyelt kulcsával, a kiszolgáló újonnan létrehozott példányai is titkosítva lesznek. Ha rugalmas Azure Database for MySQL-kiszolgálópéldányt próbál titkosítani egy olyan ügyfél által felügyelt kulccsal, amely már rendelkezik replikával(ok) , javasoljuk, hogy konfigurálja a replikákat a felügyelt identitás és kulcs hozzáadásával. Tegyük fel, hogy a rugalmas Azure Database for MySQL-kiszolgálópéldány georedundáns biztonsági mentéssel van konfigurálva. Ebben az esetben a replikát olyan felügyelt identitással és kulccsal kell konfigurálni, amelyhez az identitás hozzáfér, és amely a kiszolgáló földrajzilag párosított régiójában található.

Visszaállítás ügyfél által felügyelt kulccsal a Key Vaultban

Rugalmas Azure Database for MySQL-kiszolgálópéldány visszaállításakor kiválaszthatja a felhasználó által felügyelt identitást és kulcsot a visszaállítási kiszolgáló titkosításához. Tegyük fel, hogy a rugalmas Azure Database for MySQL-kiszolgálópéldány georedundáns biztonsági mentéssel van konfigurálva. Ebben az esetben konfigurálnia kell a visszaállítási kiszolgálót azzal a felügyelt identitással és kulccsal, amelyhez az identitás hozzáfér, és amely a kiszolgáló földrajzilag párosított régiójában található.

Az ügyfél által felügyelt adattitkosítás visszaállítása vagy olvasása során fellépő problémák elkerülése érdekében a forrás- és a visszaállított/replikakiszolgálókon az alábbi lépéseket kell követnie:

  • A rugalmas Azure Database for MySQL-kiszolgálópéldányból kezdeményezheti a replika létrehozásának visszaállítását vagy olvasását.
  • A visszaállított/replikakiszolgálón ellenőrizze újra az ügyfél által kezelt kulcsot az adattitkosítási beállításokban, hogy a felhasználó által felügyelt identitás get, list, wrap key és Unwrap key engedélyeket kapjon a Key Vaultban tárolt kulcshoz.

Feljegyzés

Visszaállításkor nem kötelező ugyanazt az identitást és kulcsot használni, mint a forráskiszolgálón.

Következő lépések