Azure Database for MySQL-datakryptering med en kundhanterad nyckel

  • Artikel

GÄLLER FÖR: Azure Database for MySQL – enskild server

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?

Datakryptering med kundhanterade nycklar för Azure Database for MySQL gör att du kan ta med din egen nyckel (BYOK) för dataskydd i vila. Det gör det även möjligt för organisationer att implementera ansvarsfördelning vad gäller hanteringen av nycklar och data. Med kundhanterad kryptering ansvarar du för och har fullständig kontroll över en nyckels livscykel, behörigheter för nyckelanvändning och granskning av åtgärder på nycklar.

Datakryptering med kundhanterade nycklar för Azure Database for MySQL anges på servernivå. För en viss server används en kundhanterad nyckel, kallad nyckelkrypteringsnyckeln (KEK), för att kryptera datakrypteringsnyckeln (DEK) som används av tjänsten. KEK är en asymmetrisk nyckel som lagras i en kundägd och kundhanterad Azure Key Vault-instans . Nyckelkrypteringsnyckeln (KEK) och datakrypteringsnyckeln (DEK) beskrivs mer detaljerat senare i den här artikeln.

Key Vault är ett molnbaserat, externt nyckelhanteringssystem. Den har hög tillgänglighet och ger skalbar och säker lagring för RSA-kryptografiska nycklar, som eventuellt backas upp av FIPS 140-verifierade maskinvarusäkerhetsmoduler (HSM). Den tillåter inte direkt åtkomst till en lagrad nyckel, men tillhandahåller tjänster för kryptering och dekryptering till auktoriserade entiteter. Key Vault kan generera nyckeln, importera den eller överföra den från en lokal HSM-enhet.

Kommentar

Den här funktionen stöds endast på lagring för generell användning v2 (stöd för upp till 16 TB)"-lagring som är tillgänglig på prisnivåerna Generell användning och Minnesoptimerad. Mer information finns i Lagringsbegrepp . Andra begränsningar finns i avsnittet om begränsning .

Förmåner

Datakryptering med kundhanterade nycklar för Azure Database for MySQL medför följande fördelar:

  • Dataåtkomst styrs helt av dig genom möjligheten att ta bort nyckeln och göra databasen otillgänglig
  • Fullständig kontroll över nyckellivscykeln, inklusive rotation av nyckeln för att anpassa till företagets principer
  • Central hantering och organisation av nycklar i Azure Key Vault
  • Möjlighet att implementera ansvarsfördelning mellan säkerhetsansvariga och DBA- och systemadministratörer

Terminologi och beskrivning

Datakrypteringsnyckel (DEK): En symmetrisk AES256-nyckel som används för att kryptera en partition eller ett datablock. Kryptering av varje datablock med en annan nyckel gör krypteringsanalysattacker svårare. Åtkomst till DEK:er krävs av resursprovidern eller programinstansen som krypterar och dekrypterar ett specifikt block. När du ersätter en DEK med en ny nyckel måste endast data i dess associerade block omkrypteras med den nya nyckeln.

Nyckelkrypteringsnyckel (KEK): En krypteringsnyckel som används för att kryptera DEK:erna. En KEK som aldrig lämnar Key Vault gör att DEK:erna själva kan krypteras och kontrolleras. Entiteten som har åtkomst till KEK kan skilja sig från den entitet som kräver DEK. Eftersom KEK krävs för att dekryptera DEK:erna är KEK i själva verket en enda punkt med vilken DEK:er effektivt kan tas bort genom borttagning av KEK.

DEK:erna, krypterade med KEK:erna, lagras separat. Endast en entitet med åtkomst till KEK kan dekryptera dessa DEK:er. Mer information finns i Säkerhet i kryptering i vila.

Så här fungerar datakryptering med en kundhanterad nyckel

Diagram that shows an overview of Bring Your Own Key

För att en MySQL-server ska använda kundhanterade nycklar som lagras i Key Vault för kryptering av DEK ger en Key Vault-administratör följande åtkomstbehörighet till servern:

  • get: För att hämta den offentliga delen och egenskaperna för nyckeln i nyckelvalvet.
  • wrapKey: För att kunna kryptera DEK. Den krypterade DEK:en lagras i Azure Database for MySQL.
  • unwrapKey: För att kunna dekryptera DEK. Azure Database for MySQL behöver den dekrypterade DEK:en för att kryptera/dekryptera data

Key Vault-administratören kan också aktivera loggning av Key Vault-granskningshändelser, så att de kan granskas senare.

När servern har konfigurerats för att använda den kundhanterade nyckeln som lagras i nyckelvalvet skickar servern DEK till nyckelvalvet för kryptering. Key Vault returnerar den krypterade DEK som lagras i användardatabasen. På samma sätt skickar servern vid behov den skyddade DEK:en till nyckelvalvet för dekryptering. Granskare kan använda Azure Monitor för att granska Key Vault-granskningshändelseloggar om loggning är aktiverat.

Krav för att konfigurera datakryptering för Azure Database for MySQL

Följande är krav för att konfigurera Key Vault:

  • Key Vault och Azure Database for MySQL måste tillhöra samma Microsoft Entra-klientorganisation. Nyckelvalv och serverinteraktioner mellan klientorganisationer stöds inte. Om du flyttar Key Vault-resursen efteråt måste du konfigurera om datakryptering.
  • Aktivera funktionen för mjuk borttagning i nyckelvalvet med kvarhållningsperioden inställd på 90 dagar för att skydda mot dataförlust om en oavsiktlig nyckel (eller Nyckelvalv) tas bort. Mjukt borttagna resurser behålls som standard i 90 dagar, såvida inte kvarhållningsperioden uttryckligen anges till <=90 dagar. Återställnings- och rensningsåtgärderna har sina egna behörigheter associerade i en Key Vault-åtkomstprincip. Funktionen för mjuk borttagning är inaktiverad som standard, men du kan aktivera den via PowerShell eller Azure CLI (observera att du inte kan aktivera den via Azure-portalen).
  • Aktivera funktionen Rensa skydd i nyckelvalvet med kvarhållningsperioden inställd på 90 dagar. Rensningsskydd kan bara aktiveras när mjuk borttagning har aktiverats. Den kan aktiveras via Azure CLI eller PowerShell. När rensningsskyddet är aktiverat kan ett valv eller ett objekt i borttaget tillstånd inte rensas förrän kvarhållningsperioden har passerat. Mjukt borttagna valv och objekt kan fortfarande återställas, vilket säkerställer att kvarhållningsprincipen följs.
  • Ge Azure Database for MySQL åtkomst till nyckelvalvet med behörigheterna get, wrapKey och unwrapKey med hjälp av dess unika hanterade identitet. I Azure-portalen skapas den unika "tjänstidentiteten" automatiskt när datakryptering aktiveras på MySQL. Se Konfigurera datakryptering för MySQL för detaljerade stegvisa instruktioner när du använder Azure-portalen.

Följande är krav för att konfigurera den kundhanterade nyckeln:

  • Den kundhanterade nyckel som ska användas för kryptering av DEK kan bara vara asymmetrisk, RSA 2048.
  • Nyckelaktiveringsdatumet (om det anges) måste vara ett datum och en tid i det förflutna. Förfallodatumet har inte angetts.
  • Nyckeln måste vara i tillståndet Aktiverad .
  • Nyckeln måste ha mjuk borttagning med kvarhållningsperioden inställd på 90 dagar. Detta anger implicit det nödvändiga nyckelattributet recoveryLevel: "Recoverable". Om kvarhållningen är inställd på < 90 dagar är recoveryLevel: "CustomdRecoverable", vilket inte är kravet, så se till att ange kvarhållningsperioden är inställd på 90 dagar.
  • Nyckeln måste ha rensningsskydd aktiverat.
  • Om du importerar en befintlig nyckel till nyckelvalvet måste du ange den i de filformat som stöds (.pfx, .byok, .backup).

Rekommendationer

Här är rekommendationer för att konfigurera Key Vault när du använder datakryptering med hjälp av en kundhanterad nyckel:

  • Ange ett resurslås på Key Vault för att styra vem som kan ta bort den här kritiska resursen och förhindra oavsiktlig eller obehörig borttagning.

  • Aktivera granskning och rapportering av alla krypteringsnycklar. Key Vault innehåller loggar som är enkla att mata in i andra verktyg för säkerhetsinformation och händelsehantering. Azure Monitor Log Analytics är ett exempel på en tjänst som redan är integrerad.

  • Se till att Key Vault och Azure Database for MySQL finns i samma region för att säkerställa snabbare åtkomst för DEK-wrap och avskrivningsåtgärder.

  • Lås Azure KeyVault till endast privat slutpunkt och valda nätverk och tillåt endast betrodda Microsoft-tjänster att skydda resurserna.

    trusted-service-with-AKV

Här följer rekommendationer för att konfigurera en kundhanterad nyckel:

  • Behåll en kopia av den kundhanterade nyckeln på en säker plats eller desläpa den till depositionstjänsten.

  • Om Key Vault genererar nyckeln skapar du en nyckelsäkerhetskopia innan du använder nyckeln för första gången. Du kan bara återställa säkerhetskopian till Key Vault. Mer information om säkerhetskopieringskommandot finns i Backup-AzKeyVaultKey.

Otillgängligt kundhanterat nyckelvillkor

När du konfigurerar datakryptering med en kundhanterad nyckel i Key Vault krävs kontinuerlig åtkomst till den här nyckeln för att servern ska vara online. Om servern förlorar åtkomsten till den kundhanterade nyckeln i Key Vault börjar servern neka alla anslutningar inom 10 minuter. Servern utfärdar ett motsvarande felmeddelande och ändrar servertillståndet till Otillgängligt. Några av anledningarna till att servern kan nå det här tillståndet är:

  • Om vi skapar en återställningsserver för tidpunkt för din Azure Database for MySQL, som har datakryptering aktiverad, är den nyligen skapade servern i otillgängligt tillstånd. Du kan åtgärda detta i Azure-portalen eller med CLI.
  • Om vi skapar en läsreplik för din Azure Database for MySQL, som har datakryptering aktiverat, är replikservern i otillgängligt tillstånd. Du kan åtgärda detta i Azure-portalen eller med CLI.
  • Om du tar bort KeyVault kommer Azure Database for MySQL inte att kunna komma åt nyckeln och övergå till otillgängligt tillstånd. Återställ Key Vault och återställ datakryptering för att göra servern tillgänglig.
  • Om vi tar bort nyckeln från KeyVault kommer Azure Database for MySQL inte att kunna komma åt nyckeln och övergå till Otillgängligt tillstånd. Återställ nyckeln och återställ datakryptering för att göra servern tillgänglig.
  • Om nyckeln som lagras i Azure KeyVault upphör att gälla blir nyckeln ogiltig och Azure Database for MySQL övergår till otillgängligt tillstånd. Utöka utgångsdatumet för nyckeln med CLIoch förnya sedan datakryptering för att göra servern tillgänglig.

Återkallande av oavsiktlig nyckelåtkomst från Key Vault

Det kan hända att någon med tillräcklig åtkomstbehörighet till Key Vault av misstag inaktiverar serveråtkomsten till nyckeln genom att:

  • Återkalla nyckelvalvets get, wrapKeyoch unwrapKey behörigheter från servern.
  • Tar bort nyckeln.
  • Ta bort nyckelvalvet.
  • Ändra nyckelvalvets brandväggsregler.
  • Ta bort serverns hanterade identitet i Microsoft Entra-ID.

Övervaka den kundhanterade nyckeln i Key Vault

Om du vill övervaka databastillståndet och aktivera aviseringar för förlust av transparent datakrypteringsskyddsåtkomst konfigurerar du följande Azure-funktioner:

  • Azure Resource Health: En otillgänglig databas som har förlorat åtkomsten till kundnyckeln visas som "otillgänglig" efter att den första anslutningen till databasen har nekats.

  • Aktivitetslogg: När åtkomsten till kundnyckeln i det kundhanterade Nyckelvalvet misslyckas läggs poster till i aktivitetsloggen. Du kan återställa åtkomsten så snart som möjligt om du skapar aviseringar för dessa händelser.

  • Åtgärdsgrupper: Definiera dessa grupper för att skicka meddelanden och aviseringar baserat på dina inställningar.

Återställa och replikera med en kunds hanterade nyckel i Key Vault

När Azure Database for MySQL har krypterats med en kunds hanterade nyckel som lagras i Key Vault krypteras även alla nyligen skapade kopior av servern. Du kan göra den här nya kopian antingen via en lokal eller geo-återställningsåtgärd eller via läsrepliker. Kopian kan dock ändras så att den återspeglar en ny kunds hanterade nyckel för kryptering. När den kundhanterade nyckeln ändras börjar gamla säkerhetskopior av servern använda den senaste nyckeln.

För att undvika problem när du konfigurerar kundhanterad datakryptering när du återställer eller läser replikskapandet är det viktigt att du följer dessa steg på käll- och återställnings-/replikservrarna:

  • Starta processen för att återställa eller läsa replikskapande från källan Azure Database for MySQL.
  • Behåll den nyligen skapade servern (återställd/replik) i ett otillgängligt tillstånd eftersom dess unika identitet ännu inte har fått behörighet till Key Vault.
  • På den återställda servern/replikservern återanvänder du den kundhanterade nyckeln i inställningarna för datakryptering för att säkerställa att den nyligen skapade servern ges wrap- och unwrap-behörigheter till nyckeln som lagras i Key Vault.

Begränsningar

För Azure Database for MySQL har stödet för kryptering av vilande data med hjälp av kundhanterad nyckel (CMK) få begränsningar –

  • Stöd för den här funktionen är begränsat till prisnivåer för generell användning och minnesoptimerad .

  • Den här funktionen stöds endast i regioner och servrar, som stöder allmän lagring v2 (upp till 16 TB). En lista över Azure-regioner som stöder lagring upp till 16 TB finns i avsnittet om lagring i dokumentationen här

    Kommentar

    • Alla nya MySQL-servrar som skapats i Azure-regionerna med stöd för generell lagring v2, stöd för kryptering med kundhanterarnycklar är tillgängligt. Pitr-servern (Point In Time Restored) eller read-repliken kvalificerar sig inte, men i teorin är de "nya".
    • Om du vill kontrollera om den etablerade serverns allmänna lagring v2 kan du gå till bladet prisnivå i portalen och se den maximala lagringsstorlek som stöds av den etablerade servern. Om du kan flytta skjutreglaget upp till 4 TB är servern på allmän lagring v1 och stöder inte kryptering med kundhanterade nycklar. Data krypteras dock alltid med hjälp av tjänsthanterade nycklar. Kontakta AskAzureDBforMySQL@service.microsoft.com om du har några frågor.

  • Kryptering stöds endast med krypteringsnyckeln RSA 2048.

Nästa steg