Transparent datakryptering (TDE) med kundhanterade nycklar på databasnivå

  • Artikel

Gäller för:Azure SQL Database

I den här artikeln beskrivs transparent datakryptering (TDE) med kundhanterade nycklar på databasnivå för Azure SQL Database.

Kommentar

TDE CMK på databasnivå är tillgängligt för Azure SQL Database (alla SQL Database-utgåvor). Den är inte tillgänglig för Azure SQL Managed Instance, SQL Server lokalt, virtuella Azure-datorer och Azure Synapse Analytics (dedikerade SQL-pooler (tidigare SQL DW)).

Kommentar

Microsoft Entra-ID är det nya namnet för Azure Active Directory (Azure AD). Vi uppdaterar dokumentationen just nu.

Översikt

Azure SQL erbjuder kryptering i vila till kunder via transparent datakryptering (TDE). Om du utökar TDE med kundhanterad nyckel (CMK) kan du skydda data i vila där TDE-skyddet (krypteringsnyckeln) lagras i ett Azure Key Vault som krypterar databaskrypteringsnycklarna. För närvarande anges TDE med CMK på servernivå och ärvs av alla krypterade databaser som är associerade med den servern. Med den här nya funktionen kan du ange TDE-skyddet som en kundhanterad nyckel individuellt för varje databas på servern. Alla Microsoft.Sql/servers/databases resurser med en giltig, icke-giltigt encryptionProtector egenskap konfigureras med kundhanterade nycklar på databasnivå.

I det här scenariot kan en asymmetrisk nyckel som lagras i ett kundägt och kundhanterat Azure Key Vault (AKV) användas individuellt för varje databas i en server för att kryptera databaskrypteringsnyckeln (DEK), som kallas TDE-skydd. Det finns ett alternativ för att lägga till nycklar, ta bort nycklar och ändra den användartilldelade hanterade identiteten (UMI) för varje databas. Mer information om identiteter finns i Hanterade identitetstyper i Azure.

Följande funktioner är tillgängliga:

  • Användartilldelad hanterad identitet: Du kan tilldela databasen en enda användartilldelad hanterad identitet. Den här identiteten kan användas för att komma åt Azure Key Vault och hantera krypteringsnycklar.
  • Hantering av krypteringsnycklar: Du kan aktivera att en eller flera krypteringsnycklar läggs till på databasnivå och ange en av de tillagda nycklarna som TDE-skydd. Krypteringsnycklarna som läggs till använder den användartilldelade hanterade identitet som redan har tilldelats databasen för att få åtkomst till Azure Key Vault.
  • Federerad klientidentitet: Du kan också aktivera en kundhanterad nyckel (CMK) från Azure Key Vault i en annan Microsoft Entra-klientorganisation som ska anges som TDE-skydd på databasnivå genom att använda federerad klientidentitet som angetts i Azure SQL Database. På så sätt kan du hantera TDE med nycklar som lagras i en annan klientorganisations Azure Key Vault.

Kommentar

Systemtilldelad hanterad identitet stöds inte på databasnivå.

Fördelar med kundhanterad TDE på databasnivå

När fler tjänsteleverantörer, även kallade oberoende programvaruleverantörer ,använder Azure SQL Database för att bygga sina tjänster, vänder sig många till elastiska pooler som ett sätt att effektivt distribuera beräkningsresurser över flera databaser. Genom att ha var och en av sina kunders databaser i en delad elastisk pool kan ISV:er dra nytta av poolens förmåga att optimera resursanvändningen samtidigt som de ser till att varje databas har tillräckliga resurser.

Det finns dock en betydande begränsning för den här metoden. När flera databaser finns på samma logiska Azure SQL-server delar de TDE-skyddet på servernivå. ISV:er kan inte erbjuda kundhanterade nycklar (CMK) till sina kunder. Utan möjligheten att hantera sina egna krypteringsnycklar kan kunderna vara tveksamma till att anförtro känsliga data till ISV:ns tjänst, särskilt om efterlevnadsreglerna kräver att de behåller fullständig kontroll över sina krypteringsnycklar.

Med TDE CMK på databasnivå kan ISV:er erbjuda CMK-funktioner till sina kunder och uppnå säkerhetsisolering, eftersom varje databas TDE-skydd potentiellt kan ägas av respektive ISV-kund i ett nyckelvalv som de äger. Den säkerhetsisolering som uppnås för ISV:s kunder är både när det gäller nyckeln och den identitet som används för att komma åt nyckeln.

Diagrammet nedan sammanfattar de nya funktioner som anges ovan. Den presenterar två separata Microsoft Entra-klienter. Klientorganisationen Best Services som innehåller den logiska Azure SQL-servern med två databaser DB 1 och DB 2, och Azure Key Vault 1 med en Key 1 åtkomst till databasen DB 1 med hjälp av UMI 1. Både UMI 1 och Key 1 representerar inställningen på servernivå. Som standard ärver alla databaser som skapades från början på den här servern den här inställningen för TDE med CMK. Klientorganisationen Contoso representerar en klientklient som innehåller Azure Key Vault 2 med en Key 2 utvärdering av databasen DB 2 i klientorganisationen som en del av cmk-stöd för flera klientorganisationer på databasnivå med hjälp av Key 2 och UMI 2 konfiguration för den här databasen.

Setup and functioning of the customer-managed TDE at the database level

Mer information om identitetskonfiguration mellan klientorganisationer finns i dokumentet mellan klientorganisationers kundhanterade nycklar på servernivå med transparent datakryptering.

Viktiga hanteringsscenarier som stöds

I följande avsnitt antar vi att det finns en server som består av tre databaser (till exempel Database1, Database2och Database3).

Befintligt scenario

Key1 konfigureras som kundhanterad nyckel på den logiska servernivån. Alla databaser under den här servern ärver samma nyckel.

  • Server – Key1 ange som CMK
  • Database1 – Key1 används som CMK
  • Database2 – Key1 används som CMK
  • Database3 – Key1 används som CMK

Nytt scenario som stöds: Logisk server konfigurerad med kundhanterad nyckel

Key1 konfigureras som kundhanterad nyckel på den logiska servernivån. En annan kundhanterad nyckel (Key2) kan konfigureras på databasnivå.

  • Server – Key1 ange som CMK
  • Database1 – Key2 används som CMK
  • Database2 – Key1 används som CMK
  • Database3 – Key1 används som CMK

Kommentar

Om den logiska servern har konfigurerats med kundhanterade nycklar för TDE kan en enskild databas på den här logiska servern inte väljas att använda tjänsthanterad nyckel för transparent datakryptering.

Nytt scenario som stöds: Logisk server konfigurerad med tjänsthanterad nyckel

Logisk server konfigureras med servicehanterad nyckel (SMK) för TDE. En annan kundhanterad nyckel (Key2) kan konfigureras på databasnivå.

  • Server – Tjänsthanterad nyckeluppsättning som TDE-skydd
  • Database1 – Key2 ange som CMK
  • Database2 – Tjänsthanterad nyckel inställd som TDE-skydd
  • Database3 – Tjänsthanterad nyckel inställd som TDE-skydd

Återgå till kryptering på servernivå

Database1 är konfigurerad med en kundhanterad nyckel på databasnivå för TDE medan den logiska servern har konfigurerats med tjänsthanterad nyckel. Database1 kan återställas för att använda den logiska tjänsthanterade nyckeln på servernivå.

Kommentar

Om den logiska servern har konfigurerats med CMK för TDE kan databasen som konfigurerats med CMK på databasnivå inte återställas till kryptering på servernivå.

Även om återställningsåtgärden endast stöds om den logiska servern har konfigurerats med tjänsthanterad nyckel när du använder TDE, kan en databas som konfigurerats med cmk på databasnivå återställas till en server som konfigurerats med CMK, förutsatt att servern har åtkomst till alla nycklar som används av källdatabasen med en giltig identitet.

Krav för nyckelvalv och hanterad identitet

Samma krav för att konfigurera Azure Key Vault-nycklar (AKV) och hanterade identiteter, inklusive nyckelinställningar och behörigheter som beviljats den identitet som gäller för cmk-funktionen (customer-managed key) på servernivå gäller även för CMK på databasnivå. Mer information finns i transparent datakryptering (TDE) med CMK och hanterade identiteter med CMK.

Nyckelhantering

Att rotera TDE-skyddet för en databas innebär att växla till en ny asymmetrisk nyckel som skyddar databasen. Nyckelrotation är en onlineåtgärd och bör bara ta några sekunder att slutföra. Åtgärden dekrypterar och krypterar om databaskrypteringsnyckeln, inte hela databasen. När en giltig användartilldelad hanterad identitet har tilldelats till en databas är rotering av nyckeln på databasnivå en CRUD-databasåtgärd som innebär att databasens krypteringsskyddsegenskap uppdateras. Set-AzSqlDatabase och egenskapen -EncryptionProtector kan användas för att rotera nycklar. För att skapa en ny databas som konfigurerats med CMK på databasnivå kan New-AzSqlDatabase användas med parametrarna -EncryptionProtector, -AssignIdentityoch -UserAssignedIdentityId .

Nya nycklar kan läggas till och befintliga nycklar kan tas bort från databasen med liknande begäranden och ändra nyckelegenskapen för databasresursen. Set-AzSqlDatabase med parametern -KeyList och -KeysToRemove kan användas för dessa åtgärder. Get-AzSqlDatabase kan användas för att hämta inställningen krypteringsskydd, identitet och nycklar. Azure Resource Manager-resursen Microsoft.Sql/servers/databases visar som standard endast TDE-skyddet och den hanterade identiteten som konfigurerats på databasen. Om du vill expandera den fullständiga listan med nycklar behövs andra parametrar som -ExpandKeyList behövs. Dessutom -KeysFilter "current" kan ett tidsvärde (till exempel 2023-01-01) användas för att hämta de aktuella nycklar som använts och nycklar som använts tidigare vid en viss tidpunkt.

Automatisk nyckelrotation

Automatisk nyckelrotation är tillgänglig på databasnivå och kan användas med Azure Key Vault-nycklar. Rotationen utlöses när en ny version av nyckeln identifieras och roteras automatiskt inom 24 timmar. Information om hur du konfigurerar automatisk nyckelrotation med hjälp av Azure-portalen, PowerShell eller Azure CLI finns i Automatisk nyckelrotation på databasnivå.

Behörighet för nyckelhantering

Beroende på behörighetsmodellen för nyckelvalvet (åtkomstprincip eller Azure RBAC) kan åtkomst till nyckelvalvet beviljas antingen genom att skapa en åtkomstprincip i nyckelvalvet eller genom att skapa en ny Azure RBAC-rolltilldelning.

Åtkomstprincipbehörighetsmodell

För att databasen ska kunna använda TDE-skydd som lagras i AKV för kryptering av DEK måste nyckelvalvsadministratören ge följande åtkomsträttigheter till databasens användartilldelade hanterade identitet med dess unika Microsoft Entra-identitet:

  • get – för att hämta den offentliga delen och egenskaperna för nyckeln i Azure Key Vault.
  • wrapKey – för att kunna skydda (kryptera) DEK.
  • unwrapKey – för att kunna ta bort skyddet (dekryptera) DEK.

Azure RBAC-behörighetsmodell

För att databasen ska kunna använda TDE-skyddet som lagras i AKV för kryptering av DEK måste en ny Azure RBAC-rolltilldelning med rollen Key Vault Crypto Service Encryption User läggas till för databasens användartilldelade hanterade identitet med hjälp av dess unika Microsoft Entra-identitet.

Kundhanterade nycklar mellan klientorganisationer

Kundhanterade nycklar mellan klientorganisationer med transparent datakryptering beskriver hur du konfigurerar ett federerat klient-ID för CMK på servernivå. Liknande installation måste göras för CMK på databasnivå och det federerade klient-ID:t måste läggas till som en del av API-begäranden för Set-AzSqlDatabase eller New-AzSqlDatabase .

Kommentar

Om programmet för flera klientorganisationer inte har lagts till i åtkomstprincipen för nyckelvalvet med de behörigheter som krävs (Hämta, Radbryt nyckel, Packa upp nyckel) visas ett fel när du använder ett program för identitetsfederation i Azure-portalen. Kontrollera att behörigheterna är korrekt konfigurerade innan du konfigurerar den federerade klientidentiteten.

En databas som konfigurerats med CMK på databasnivå kan återställas till kryptering på servernivå om den logiska servern har konfigurerats med en tjänsthanterad nyckel med invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

Om det finns ett Otillgängligt TDE-skydd enligt beskrivningen i Transparent datakryptering (TDE) med CMK kan invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation användas för att göra databasen tillgänglig när nyckelåtkomsten har korrigerats.

Kommentar

Identitets- och nyckelhantering för TDE med kundhanterade nycklar på databasnivå beskriver identitets- och nyckelhanteringsåtgärderna för CMK på databasnivå i detalj, tillsammans med Powershell, Azure CLI och REST API-exempel.

Ytterligare överväganden

  • Om TDE med CMK redan är aktiverat på servernivå åsidosätter cmk-inställningen för en viss databas cmk-inställningen på servernivå (databasens DEK krypteras igen med TDE-skyddet på databasnivå).
  • Ändringar eller rotationer på logisk servernivå påverkar inte CMK-inställningarna på databasnivå och databasen fortsätter att använda sin egen CMK-inställning.
  • Cmk på databasnivå stöds inte via Transact-SQL (T-SQL).
  • Den logiska serverns användartilldelade hanterade identitet (UMI) kan användas på databasnivå. Vi rekommenderar dock att du använder en utsedd UMI för cmk på databasnivå.
  • Cmk-inställningar på servernivå mellan klientorganisationer påverkar inte enskilda databaser som konfigurerats med CMK på databasnivå, och de fortsätter att använda sin egen konfiguration för en enskild klientorganisation eller mellan klientorganisationer.
  • Endast en enskild användartilldelad hanterad identitet kan anges på databasnivå.

Kommentar

De hanterade identiteterna i databasen måste omtilldelas om databasen har bytt namn.

Migrering av befintliga databaser till cmk på databasnivå

Nya databaser kan konfigureras med CMK på databasnivå när du skapar och befintliga databaser på servrar som konfigurerats med tjänsthanterade nycklar kan migreras till cmk på databasnivå med hjälp av de åtgärder som beskrivs i Identitets- och nyckelhantering för TDE med kundhanterade nycklar på databasnivå. För att migrera databaser som har konfigurerats med en CMK på servernivå eller geo-replikering krävs andra steg enligt beskrivningen i följande avsnitt.

Databas konfigurerad med en CMK på servernivå utan geo-replikering

  1. Använd sys.dm_db_log_info (Transact-SQL) – SQL Server för databasen och leta efter virtuella loggfiler (VLFs) som är aktiva.
  2. För alla aktiva VLFs registrerar vlf_encryptor_thumbprint du från resultatet sys.dm_db_log_info .
  3. Använd vyn sys.dm_database_encryption_keys (Transact-SQL) – SQL Server för databasen för encryptor_thumbprintatt söka efter . encryptor_thumbprintRegistrera .
  4. Använd cmdleten Get-AzSqlServerKeyVaultKey för att hämta alla servernivånycklar som konfigurerats på den logiska servern. Från resultaten väljer du de som har samma tumavtryck som matchar din lista från ovanstående resultat.
  5. Gör ett uppdateringsdatabas-API-anrop till den databas som du vill migrera, tillsammans med identitets- och krypteringsskydd. Skicka ovanstående nycklar som databasnivånycklar med hjälp av parametrarna Set-AzSqlDatabase med parametrarna -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (och om det behövs). -FederatedClientId

Viktigt!

Den identitet som används i begäran om uppdateringsdatabas måste ha åtkomst till alla nycklar som skickas som indata.

Databas konfigurerad med CMK på servernivå med geo-replikering

  1. Följ stegen (1) till och med (4) som nämns i föregående avsnitt för att hämta listan över nycklar som behövs för migrering.
  2. Gör ett uppdateringsdatabas-API-anrop till den primära och sekundära databas som du vill migrera, tillsammans med identiteten och ovanstående nycklar som databasnivånycklar med hjälp av Set-AzSqlDatabase och parametern -KeyList . Ställ inte in krypteringsskyddet än.
  3. Den databasnivånyckel som du vill använda som primärt skydd för databaserna måste först läggas till i den sekundära databasen. Använd Set-AzSqlDatabase med -KeyList för att lägga till den här nyckeln i den sekundära databasen.
  4. När krypteringsskyddsnyckeln har lagts till i den sekundära databasen använder du Set-AzSqlDatabase för att ange den som krypteringsskydd på den primära databasen med hjälp av parametern -EncryptionProtector .
  5. Ange nyckeln som krypteringsskydd på den sekundära databasen enligt beskrivningen i (4) för att slutföra migreringen.

Viktigt!

Om du vill migrera databaser som har konfigurerats med en tjänsthanterad nyckel på servernivå och geo-replikering följer du stegen (3), (4) och (5) i det här avsnittet.

Geo-replikering och hög tillgänglighet

I scenarier med både aktiv geo-replikering och redundansgrupper kan de primära och sekundära databaser som ingår länkas antingen till samma nyckelvalv (i valfri region) eller till separata nyckelvalv. Om separata nyckelvalv länkas till de primära och sekundära servrarna ansvarar kunden för att hålla nyckelmaterialet i nyckelvalven konsekvent, så att geo-sekundär är synkroniserad och kan ta över med samma nyckel från det länkade nyckelvalvet om den primära blir otillgänglig på grund av ett avbrott i regionen och en redundansväxling utlöses. Upp till fyra sekundärfiler kan konfigureras, och länkning (sekundärfiler för sekundärfiler) stöds inte.

För att upprätta aktiv geo-replikering för en databas som har konfigurerats med CMK på databasnivå måste en sekundär replik skapas med en giltig användartilldelad hanterad identitet och en lista över aktuella nycklar som används av den primära databasen. Listan över aktuella nycklar kan hämtas från den primära databasen med hjälp av nödvändiga filter och frågeparametrar, eller med hjälp av PowerShell och Azure CLI. De steg som krävs för att konfigurera en geo-replik av en sådan databas är:

  1. Fyll i listan över nycklar som används av den primära databasen i förväg med hjälp av kommandot Get-AzSqlDatabase och parametrarna -ExpandKeyList och -KeysFilter "current" . Exkludera -KeysFilter om du vill hämta alla nycklar.
  2. Välj den användartilldelade hanterade identiteten (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer).
  3. Skapa en ny databas som sekundär med New-AzSqlDatabaseSecondary och ange den förifyllda listan över nycklar som hämtats från källdatabasen och ovanstående identitet (och federerad klient-DI om du konfigurerar åtkomst mellan klientorganisationer) i API-anropet med parametrarna -KeyList, -AssignIdentity, , -UserAssignedIdentityId-EncryptionProtector (och vid behov ) -FederatedClientId.
  4. Använd New-AzSqlDatabaseCopy för att skapa en kopia av databasen med samma parametrar i föregående steg.

Viktigt!

En databas som konfigurerats med cmk på databasnivå måste ha en replik (eller kopia) konfigurerad med cmk på databasnivå. Repliken kan inte använda krypteringsinställningar på servernivå.

För att kunna använda en databas som konfigurerats med cmk på databasnivå i en redundansgrupp måste stegen ovan för att skapa en sekundär replik med samma namn som den primära repliken användas på den sekundära servern. När den här sekundära repliken har konfigurerats kan databaserna läggas till i redundansgruppen.

Databaser som konfigurerats med cmk på databasnivå stöder inte automatisk sekundär skapande när de läggs till i en redundansgrupp.

Mer information finns i Konfigurera geo-replikering och återställning av säkerhetskopior för transparent datakryptering med kundhanterade nycklar på databasnivå som beskriver hur du konfigurerar geo-replikering och redundansgrupper med hjälp av REST-API:er, PowerShell och Azure CLI.

Kommentar

Alla metodtips för geo-replikering och hög tillgänglighet som är markerade i transparent datakryptering (TDE) med CMK för cmk på servernivå gäller cmk på databasnivå.

Säkerhetskopiera och återställa databaser med hjälp av TDE med kundhanterad nyckel på databasnivå

När en databas har krypterats med TDE med hjälp av en nyckel från Azure Key Vault krypteras även eventuella nyligen genererade säkerhetskopior med samma TDE-skydd. När TDE-skyddet ändras uppdateras inte gamla säkerhetskopior av databasen för att använda det senaste TDE-skyddet. Om du vill återställa en säkerhetskopia som krypterats med ett TDE-skydd från Azure Key Vault som konfigurerats på databasnivå kontrollerar du att nyckelmaterialet tillhandahålls till måldatabasen. Vi rekommenderar att du behåller alla gamla versioner av TDE-skyddet i ett nyckelvalv så att databassäkerhetskopior kan återställas.

Viktigt!

Endast ett TDE-skydd kan anges för en databas. Flera ytterligare nycklar kan dock skickas till en databas under återställningen utan att markera dem som ett TDE-skydd. Dessa nycklar används inte för att skydda DEK, men kan användas vid återställning från en säkerhetskopia om säkerhetskopian krypteras med nyckeln med motsvarande tumavtryck.

Återställning till tidpunkt

Följande steg krävs för en återställning till en tidpunkt för en databas som konfigurerats med kundhanterade nycklar på databasnivå:

  1. Fyll i listan över nycklar som används av den primära databasen i förväg med hjälp av kommandot Get-AzSqlDatabase och parametrarna -ExpandKeyList och -KeysFilter "2023-01-01" . 2023-01-01 är ett exempel på den tidpunkt då du vill återställa databasen till. Exkludera -KeysFilter om du vill hämta alla nycklar.
  2. Välj den användartilldelade hanterade identiteten (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer).
  3. Använd Restore-AzSqlDatabase med parametern -FromPointInTimeBackup och ange den ifyllda listan över nycklar som hämtas från ovanstående steg och ovanstående identitet (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer) i API-anropet med parametrarna -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (och om det behövs) -FederatedClientId.

Kommentar

Om du återställer en databas utan egenskapen -EncryptionProtector med alla giltiga nycklar återställs den för att använda kryptering på servernivå. Detta kan vara användbart för att återställa en kundhanterad nyckelkonfiguration på databasnivå till konfigurationen av kundhanterad nyckel på servernivå.

Databasåterställning har tagits bort

Följande steg krävs för en borttagen databasåterställning av en databas som konfigurerats med kundhanterade nycklar på databasnivå:

  1. Fyll i listan över nycklar som används av den primära databasen i förväg med hjälp av Get-AzSqlDeletedDatabaseBackup och parametern -ExpandKeyList . Vi rekommenderar att du skickar alla nycklar som källdatabasen använde, men du kan också försöka återställa med nycklarna som tillhandahålls av borttagningstiden som -KeysFilter.
  2. Välj den användartilldelade hanterade identiteten (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer).
  3. Använd Restore-AzSqlDatabase med parametern -FromDeletedDatabaseBackup och ange den ifyllda listan över nycklar som hämtas från ovanstående steg och ovanstående identitet (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer) i API-anropet med parametrarna -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (och vid behov) -FederatedClientId.

Geo-återställning

Följande steg krävs för en geo-återställning av en databas som konfigurerats med kundhanterade nycklar på databasnivå:

  • Fyll i listan över nycklar som används av den primära databasen med hjälp av Get-AzSqlDatabaseGeoBackup och -ExpandKeyList för att hämta alla nycklar.
  • Välj den användartilldelade hanterade identiteten (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer).
  • Använd Restore-AzSqlDatabase med parametern -FromGeoBackup och ange den ifyllda listan över nycklar som hämtas från ovanstående steg och ovanstående identitet (och federerat klient-ID om du konfigurerar åtkomst mellan klientorganisationer) i API-anropet med parametrarna -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (och vid behov) -FederatedClientId.

Viktigt!

Vi rekommenderar att alla nycklar som används av databasen bevaras för att återställa databasen. Vi rekommenderar också att du skickar alla dessa nycklar till återställningsmålet.

Kommentar

Långsiktiga säkerhetskopior av kvarhållning av säkerhetskopior (LTR) innehåller inte listan över nycklar som används av säkerhetskopian. För att återställa en LTR-säkerhetskopia måste alla nycklar som används av källdatabasen skickas till LTR-återställningsmålet.

Mer information om säkerhetskopieringsåterställning för SQL Database med CMK på databasnivå med exempel med powershell, Azure CLI och REST-API:er finns i Konfigurera geo-replikering och återställning av säkerhetskopior för transparent datakryptering med kundhanterade nycklar på databasnivå.

Begränsningar

Funktionen kundhanterade nycklar på databasnivå stöder inte nyckelrotationer när databasens virtuella loggfiler krypteras med en gammal nyckel som skiljer sig från databasens aktuella primära skydd. Felet som utlöses i det här fallet är:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Nyckelrotation för TDE-skyddet på databasnivå blockeras när aktiva transaktioner håller upp loggen krypterad med gamla nycklar.

För att ytterligare förstå det här scenariot ska vi överväga följande tidslinje:

An example timeline of key rotations on a database configured with database level customer-managed keys.

  • Time t0 = En databas skapas utan kryptering
  • Time t1 = Den här databasen skyddas av Thumbprint A, vilket är en kundhanterad nyckel på databasnivå.
  • Time t2 = Databasskyddet roteras till en ny kundhanterad nyckel på databasnivå, Thumbprint B.
  • Time t3 = En skyddsändring begärs Thumbprint C .
  • Om aktiva VLF:er använder Thumbprint Atillåts inte rotationen.
  • Om de aktiva VLFs inte använder Thumbprint Atillåts rotationen.

Du kan använda vyn sys.dm_db_log_info (Transact-SQL) – SQL Server för databasen och leta efter virtuella loggfiler som är aktiva. Du bör se en aktiv VLF krypterad med den första nyckeln (till exempel Thumbprint A). När tillräckligt med logg har genererats av datainfogning rensas den gamla VLF:en och du bör kunna utföra en annan nyckelrotation.

Om du tror att något håller i loggen längre än förväntat kan du läsa följande dokumentation för ytterligare felsökning:

Nästa steg

Kontrollera följande dokumentation om olika CMK-åtgärder på databasnivå: