Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Genom att använda datakryptering med kundhanterade nycklar för Azure Database for MySQL kan du ta med din egen nyckel (BYOK) för dataskydd i vila för att implementera ansvarsfördelning för hantering av nycklar och data. När du använder kundhanterade nycklar (CMK:er) kontrollerar du:
- Nyckellivscykelhantering, inklusive nyckelskapande, uppladdning, rotation och borttagning
- Behörigheter för nyckelanvändning
- Granskningsåtgärder för nycklar
Fördelar med kundhanterade nycklar (CMK)
Datakryptering med kundhanterade nycklar för Azure Database for MySQL medför följande fördelar:
- Du kontrollerar dataåtkomsten fullständigt genom att ta bort nyckeln och göra databasen otillgänglig.
- Du har fullständig kontroll över nyckellivscykeln, inklusive rotation av nyckeln för att anpassa till företagets principer.
- Du kan centralt hantera och ordna nycklar i Azure Key Vault eller hanterad HSM.
- Du kan implementera ansvarsfördelning mellan säkerhetsansvariga, DBA och systemadministratörer.
Hur fungerar datakryptering med en kundhanterad nyckel?
Hanterade identiteter i Microsoft Entra-ID är ett säkrare sätt att autentisera klienter till tjänster. CMK-kryptering använder Azure Database for MySQL-serverns hanterade identitet för att ansluta till Azure Key Vault som lagrar CMK:t. Azure Database for MySQL stöder för närvarande endast användartilldelad hanterad identitet (UAMI) för åtkomst till Key Vault. Mer information finns i Hanterade identitetstyper i Azure.
Om du vill konfigurera CMK för en Azure Database for MySQL länkar du UAMI till servern och anger Azure Key Vault och nyckel som ska användas.
UAMI behöver följande åtkomst till nyckelvalvet:
- Hämta: För att få fram den publika delen och egenskaperna för nyckeln i nyckelvalvet.
- Lista: Om du vill visa en lista över de versioner av nyckeln som lagras i en Key Vault.
- Omslutningsnyckel: För att kryptera DEK. Den krypterade DEK:en lagras i azure database for MySQL– flexibel serverinstans.
- Packa upp nyckel: Dekryptera DEK. Azure Database for MySQL behöver dekrypterade DEK för att kryptera eller dekryptera data.
Om Azure RBAC är aktiverat tilldelar du roller till UAMI i stället för individuell åtkomst.
-
Key Vault Crypto Service Encryption User eller rollen med behörigheterna:
- Microsoft.KeyVault/vaults/keys/wrap/action
- Microsoft.KeyVault/vaults/keys/unwrap/åtgärd
- Microsoft.KeyVault/vaults/keys/read som "Användare för krypteringstjänsten Key Vault Crypto"
- För Managed HSM tilldelar du rollen Användare av Hanterad HSM-krypteringstjänst
Ange datakryptering med CMK:er på servernivå. För en viss server använder du 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- och dekrypteringstjänster med hjälp av nyckeln till auktoriserade entiteter. Nyckelvalvet kan generera nyckeln eller överföra den 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.
När du har aktiverat loggning 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.
Note
Det kan ta upp till 10 minuter innan behörighetsändringar börjar gälla i nyckelvalvet.
Krav för att konfigurera datakryptering för Azure Database for MySQL
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 serverinstans måste tillhöra samma Microsoft Entra-klientorganisation. Stöd för klientorganisationsövergripande Key Vault och flexibla serverinteraktioner måste finnas. 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 Soft Delete på nyckelvalvet.
- Aktivera rensningsskyddet.
- Ange kvarhållningsperioden till 90 dagar.
- Å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.
Innan du försöker konfigurera CMK måste du uppfylla följande krav.
- Den kundhanterade nyckeln för att kryptera DEK kan endast 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. Den här inställningen anger implicit det obligatoriska nyckelattributet
recoveryLeveltillRecoverable. - 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).
Note
Detaljerade stegvisa instruktioner om hur du konfigurerar datakryptering finns i Datakryptering för Azure Database for MySQL med Azure-portalen eller Datakryptering för Azure Database for MySQL – flexibel server med Azure CLI.
Rekommendationer för att konfigurera datakryptering
När du konfigurerar Key Vault eller hanterad HSM för att använda datakryptering med en kundhanterad nyckel bör du ha följande rekommendationer i åtanke:
- 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.
- Behåll en kopia av den kundhanterade nyckeln på en säker plats eller deponera den hos escrowtjä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.
Note
Nyckelvalvet som du använder måste vara från samma region som databasservern.
Otillgängligt kundhanterat nyckelvillkor
När du konfigurerar datakryptering med en CMK i Key Vault kräver servern kontinuerlig åtkomst till den här nyckeln för att 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 kan instansen Azure Database for MySQL – Flexibel server inte komma åt nyckeln och övergår till Inaccessible-tillstånd. Så här gör du serverinstansen Available:
- Återställ nyckelvalvet.
- Omvalidera datakryptering.
Om du tar bort nyckeln från nyckelvalvet kan instansen av Azure Database for MySQL – flexibel server inte komma åt nyckeln och övergår till tillståndet Inaccessible. Så här gör du serverinstansen Available:
- Återställ nyckeln.
- Omvalidera datakryptering.
Note
Även om nyckeln upphör att gälla förblir servern tillgänglig avsiktligt för att förhindra stilleståndstid.
Oavsiktligt återkallande av nyckelåtkomst från Key Vault
Någon med tillräcklig åtkomstbehörighet för Key Vault kan av misstag inaktivera flexibel serveråtkomst till nyckeln genom att:
- Återkalla nyckelvalvet hämtning, listning, nyckelinkapsling och avinkapsling av nyckel behörigheter 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 du krypterar en Azure Database for MySQL flexibel serverinstans 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 flexibel serverinstans med en kundhanterad nyckel som redan har en replik konfigurerar du en eller flera repliker genom att lägga till den hanterade identiteten och nyckeln. Om du konfigurerar instansen Azure Database for MySQL Flexibel server med geo-redundant säkerhetskopiering måste du konfigurera repliken med den hanterade identiteten och den nyckel som identiteten har åtkomst till och som finns i serverns geoparade region.
Återställa med en kundhanterad nyckel i Key Vault
När du återställer en Azure Database for MySQL flexibel serverinstans väljer du den användarhanterade identiteten och nyckeln för att kryptera återställningsservern. Om instansen av Azure Database for MySQL – flexibel server har konfigurerats med georedundant säkerhetskopiering måste du konfigurera återställningsservern med den hanterade identiteten och nyckeln, som identiteten har åtkomst till och som finns i serverns geoparade region.
Vid återställning eller skapande av en läsreplik följer du dessa steg på källservern och den återställda servern eller replikservern:
- Initiera processen för att återställa eller skapa en läsreplik från källinstansen av Azure Database for MySQL – flexibel server.
- På den återställde servern eller replikservern återanvänder du CMK:t i inställningarna för datakryptering för att verifiera UAMI-behörigheterna till nyckeln.
Note
Du behöver inte använda samma identitet (UAMI) och nyckel som på källservern när du utför en återställning.