Dela via

Datakryptering med kundhanterade nycklar för Azure Database for MySQL – flexibel server

  • Artikel

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

Med datakryptering med kundhanterade nycklar för Azure Database for MySQL – flexibel server kan du ta med din egen nyckel (BYOK) för dataskydd i vila och implementera ansvarsfördelning för hantering av nycklar och data. Med kundhanterade nycklar (CMK:er) ansvarar kunden för och kontrollerar slutligen nyckellivscykelhanteringen (nyckelskapande, uppladdning, rotation, borttagning), behörigheter för nyckelanvändning och granskningsåtgärder på nycklar.

Kommentar

Azure Key Vault Managed HSM (Maskinvarusäkerhetsmodul) stöds för närvarande för kundhanterade nycklar för Azure Database for MySQL – flexibel server.

Förmåner

Datakryptering med kundhanterade nycklar för Azure Database for MySQL – flexibel server ger följande fördelar:

  • Du har fullständig kontroll över dataåtkomsten 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 eller Managed HSM
  • Möjlighet att implementera ansvarsfördelning mellan säkerhetsansvariga, DBA och systemadministratörer

Hur fungerar datakryptering med en kundhanterad nyckel?

Hanterade identiteter i Microsoft Entra-ID ger Azure-tjänster ett alternativ till att lagra autentiseringsuppgifter i koden genom att etablera en automatiskt tilldelad identitet som kan användas för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering, till exempel Azure Key Vault (AKV). Azure Database for MySQL – flexibel server stöder för närvarande endast användartilldelad hanterad identitet (UMI). Mer information finns i Hanterade identitetstyper i Azure.

För att konfigurera CMK för en flexibel Azure Database for MySQL-server måste du länka UMI till servern och ange azure-nyckelvalvet och nyckeln som ska användas.

UMI måste ha följande åtkomst till nyckelvalvet:

  • Hämta: För att hämta den offentliga delen och egenskaperna för nyckeln i nyckelvalvet.
  • Lista: Visa en lista över de versioner av nyckeln som lagras i ett Nyckelvalv.
  • Omslutningsnyckel: För att kunna kryptera DEK. Den krypterade DEK:en lagras i Azure Database for MySQL – flexibel serverinstans.
  • Packa upp nyckel: För att kunna dekryptera DEK. Azure Database for MySQL – flexibel server behöver den dekrypterade DEK:en för att kryptera/dekryptera data.

Om RBAC är aktiverat måste UMI också tilldelas följande roll:

  • Key Vault Crypto Service Encryption User eller rollen med behörigheterna:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/unwrap/action
    • Microsoft.KeyVault/vaults/keys/read like "Key Vault Crypto Service Encryption User"
  • För Managed HSM tilldelar du rollen Hanterad HSM-krypteringstjänstkryptering

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 visst 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 kan tas bort effektivt genom att ta bort KEK: et. 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 krypteringsvila.

Hur det fungerar

Datakryptering med CMK:er anges på servernivå. För en viss server används en CMK, kallad nyckelkrypteringsnyckeln (KEK), för att kryptera tjänstens datakrypteringsnyckel (DEK). KEK är en asymmetrisk nyckel som lagras i en kundägd och kundhanterad Azure Key Vault-instans. Key Vault är mycket tillgängligt och skalbar säker lagring för RSA-kryptografiska nycklar, som eventuellt backas upp av FIPS 140-verifierade maskinvarusäkerhetsmoduler (HSM). Key Vault tillåter inte direkt åtkomst till en lagrad nyckel, utan tillhandahåller i stället krypterings-/dekrypteringstjänster som använder nyckeln till de auktoriserade entiteterna. Nyckelvalvet, importerat kan generera nyckeln eller överföras till nyckelvalvet från en lokal HSM-enhet.

När du konfigurerar en flexibel server för att använda en CMK 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 den flexibla servern den skyddade DEK:en till nyckelvalvet för dekryptering vid behov.

Diagram över hur datakryptering med en kundhanterad nyckel fungerar.

När loggning har aktiverats kan granskare använda Azure Monitor för att granska Key Vault-granskningshändelseloggar. Information om hur du aktiverar loggning av Key Vault-granskningshändelser finns i Övervaka din key vault-tjänst med Key Vault-insikter.

Kommentar

Behörighetsändringar kan ta upp till 10 minuter att påverka nyckelvalvet. Detta inkluderar återkallande av åtkomstbehörigheter till TDE-skyddet i AKV, och användare inom den här tidsramen kan fortfarande ha åtkomstbehörigheter.

Krav för att konfigurera datakryptering för Azure Database for MySQL – flexibel server

Innan du försöker konfigurera Key Vault eller Managed HSM måste du uppfylla följande krav.

  • Key Vault och Azure Database for MySQL – flexibel server-instans måste tillhöra samma Microsoft Entra-klientorganisation. Key Vault för flera klientorganisationer och flexibla serverinteraktioner måste stödjas. Du måste konfigurera om datakryptering om du flyttar Key Vault-resurser när du har utfört konfigurationen.
  • Key Vault och Azure Database for MySQL – flexibel serverinstans måste finnas i samma region.
  • Aktivera funktionen för mjuk borttagning i nyckelvalvet med en kvarhållningsperiod inställd på 90 dagar för att skydda mot dataförlust om en oavsiktlig nyckel (eller Nyckelvalv) tas bort. Åtgärderna för återställning och rensning har sina egna behörigheter i en Key Vault-åtkomstprincip. Funktionen för mjuk borttagning är inaktiverad som standard, men du kan aktivera den via Azure Portal eller med hjälp av PowerShell eller Azure CLI.
  • Aktivera funktionen Rensa skydd i nyckelvalvet och ange kvarhållningsperioden till 90 dagar. När rensningsskyddet är aktiverat kan ett valv eller ett objekt i borttaget tillstånd inte rensas förrän kvarhållningsperioden har passerat. Du kan aktivera den här funktionen med Hjälp av PowerShell eller Azure CLI, och först när du har aktiverat mjuk borttagning.

Innan du försöker konfigurera CMK måste du uppfylla följande krav.

  • Den kundhanterade nyckeln för att kryptera DEK kan bara vara asymmetrisk, RSA\RSA-HSM(Valv med Premium SKU) 2048,3072 eller 4096.
  • 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: "Återställningsbar".
  • Nyckeln måste ha rensningsskydd aktiverat.
  • Om du importerar en befintlig nyckel till nyckelvalvet måste du ange den i filformat som stöds (.pfx, .byok, .backup).

Kommentar

Detaljerade stegvisa instruktioner om hur du konfigurerar datumkryptering för Azure Database for MySQL – flexibel server via Azure Portal finns i Konfigurera datakryptering för Azure Database for MySQL – flexibel server.

Rekommendationer för att konfigurera datakryptering

Tänk på följande rekommendationer när du konfigurerar Key Vault eller Hanterad HSM för att använda 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.
  • 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.

Kommentar

  • Vi rekommenderar att du använder ett nyckelvalv från samma region, men om det behövs kan du använda ett nyckelvalv från en annan region genom att ange informationen "ange nyckelidentifierare". Nyckelvalvets hanterade HSM måste finnas i samma region som den flexibla MySQL-servern.

Otillgängligt kundhanterat nyckelvillkor

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

  • Om du tar bort nyckelvalvet kommer Azure Database for MySQL Flexible Server-instansen inte att kunna komma åt nyckeln och övergå till Otillgängligt tillstånd. Återställa nyckelvalvet och återanvända datakryptering för att göra Azure Database for MySQL – flexibel server-instans tillgänglig.
  • Om du tar bort nyckeln från nyckelvalvet kommer Azure Database for MySQL – flexibel serverinstans 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 Azure Database for MySQL Flexibel server-instans tillgänglig.
  • Om nyckeln som lagras i Azure Key Vault upphör att gälla blir nyckeln ogiltig och Azure Database for MySQL – flexibel serverinstans övergår till otillgängligt tillstånd. Utöka utgångsdatumet för nyckeln med CLI och förnya sedan datakryptering för att göra Azure Database for MySQL – flexibel serverinstans 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 flexibel serveråtkomst till nyckeln genom att:

  • Återkalla nyckelvalvets behörigheter get, list, wrap key och unwrap key från servern
  • Ta bort nyckeln
  • Ta bort nyckelvalvet
  • Ändra nyckelvalvets brandväggsregler
  • Ta bort den användarhanterade identitet som används för kryptering på den flexibla servern med en kundhanterad nyckel 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:

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

Replik med en kundhanterad nyckel i Key Vault

När en Azure Database for MySQL – flexibel server-instans har krypterats med en kunds hanterade nyckel lagrad i Key Vault krypteras även alla nyligen skapade kopior av servern. När du försöker kryptera en Azure Database for MySQL Flexible Server-instans med en kundhanterad nyckel som redan har en replik rekommenderar vi att du konfigurerar replikerna genom att lägga till den hanterade identiteten och nyckeln. Anta att Azure Database for MySQL – flexibel server-instans har konfigurerats med geo-redundanssäkerhetskopiering. I så fall måste repliken konfigureras med den hanterade identiteten och nyckeln som identiteten har åtkomst till och som finns i serverns geo-kopplade region.

Återställa med en kundhanterad nyckel i Key Vault

När du försöker återställa en Azure Database for MySQL – flexibel serverinstans kan du välja den användarhanterade identiteten och nyckeln för att kryptera återställningsservern. Anta att Azure Database for MySQL – flexibel server-instans har konfigurerats med geo-redundanssäkerhetskopiering. I så fall måste du konfigurera återställningsservern med den hanterade identiteten och nyckeln som identiteten har åtkomst till och som finns i serverns geo-kopplade region.

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 azure database for MySQL–instansen för flexibel server.
  • 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 användarhanterade identiteten får behörigheterna Hämta, Lista, Radbryt nyckel och Packa upp nyckel till nyckeln som lagras i Key Vault.

Kommentar

Det är inte obligatoriskt att använda samma identitet och nyckel som på källservern när du utför en återställning.

Nästa steg