Transparent datakryptering i Azure SQL med kundhanterad nyckel

Gäller för:Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (endast dedikerade SQL-pooler)

Azure SQL transparent datakryptering (TDE) med kundhanterad nyckel (CMK) möjliggör BYOK-scenario (Bring Your Own Key) för dataskydd i vila och gör det möjligt för organisationer att implementera ansvarsfördelning vid hantering av nycklar och data. Med kundhanterad TDE ansvarar kunden för och har fullständig kontroll över nyckellivscykeln (skapande, uppladdning, rotation och borttagning av nycklar), behörigheter för nyckelanvändning samt granskning av åtgärder på nycklar.

I det här scenariot är nyckeln som används för kryptering av databaskrypteringsnyckeln (DEK), som kallas TDE-skydd, en kundhanterad asymmetrisk nyckel som lagras i ett kundägt och kundhanterat Azure Key Vault (AKV), ett molnbaserat externt nyckelhanteringssystem. Key Vault är mycket tillgängligt och skalbar säker lagring för RSA-kryptografiska nycklar, som eventuellt backas upp av FIPS 140-2 Level 2-verifierade maskinvarusäkerhetsmoduler (HSM). Den tillåter inte direkt åtkomst till en lagrad nyckel, men tillhandahåller tjänster för kryptering/dekryptering med hjälp av nyckeln till de auktoriserade entiteterna. Nyckeln kan genereras av nyckelvalvet, importeras eller överföras till nyckelvalvet från en lokal HSM-enhet.

För Azure SQL Database och Azure Synapse Analytics anges TDE-skyddet på servernivå och ärvs av alla krypterade databaser som är associerade med servern. För Azure SQL Managed Instance anges TDE-skyddet på instansnivå och ärvs av alla krypterade databaser på den instansen. Termen server refererar både till en server i SQL Database och Azure Synapse och till en hanterad instans i SQL Managed Instance i hela det här dokumentet, om inte annat anges.

Det är tillgängligt att hantera TDE-skyddet på databasnivå i Azure SQL Database. Mer information finns i Transparent datakryptering (TDE) med kundhanterade nycklar på databasnivå.

Kommentar

• Den här artikeln gäller för Azure SQL Database, Azure SQL Managed Instance och Azure Synapse Analytics (dedikerade SQL-pooler (tidigare SQL DW)). Dokumentation om transparent datakryptering för dedikerade SQL-pooler i Synapse-arbetsytor finns i Azure Synapse Analytics-kryptering.
• För att ge Azure SQL-kunder två lager kryptering av vilande data distribueras infrastrukturkryptering (med AES-256-krypteringsalgoritm) med plattformshanterade nycklar. Detta ger ett tilläggslager av kryptering i vila tillsammans med TDE med kundhanterade nycklar, som redan är tillgängligt. För Azure SQL Database och Azure SQL Managed Instance krypteras alla databaser, inklusive master databasen och andra systemdatabaser, när infrastrukturkryptering aktiveras. För närvarande måste kunderna begära åtkomst till den här funktionen. Om du är intresserad av den här funktionen kontaktar du AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Kommentar

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

Fördelar med kundhanterad TDE

Kundhanterad TDE ger kunden följande fördelar:

• Fullständig och detaljerad kontroll över användning och hantering av TDE-skyddet.

• Insyn i TDE-skyddsanvändningen.

• Förmåga att implementera uppdelning av uppgifter i hanteringen av nycklar och data inom organisationen;

• Key Vault-administratören kan återkalla behörigheter för nyckelåtkomst för att göra krypterad databas otillgänglig.

• Central hantering av nycklar i AKV;

• Större förtroende från dina slutkunder, eftersom AKV är utformat så att Microsoft inte kan se eller extrahera krypteringsnycklar.

Viktigt!

För dem som använder tjänsthanterad TDE och vill börja använda kundhanterad TDE förblir data krypterade under växlingsprocessen, och det behövs ingen avbrottstid eller omkryptering av databasfilerna. Växling från en tjänsthanterad nyckel till en kundhanterad nyckel kräver endast omkryptering av DEK, vilket är en snabb onlinebaserad åtgärd.

Så här fungerar kundhanterad TDE

För att den logiska servern i Azure ska kunna använda TDE-skyddet som lagras i AKV för kryptering av DEK måste nyckelvalvsadministratören ge följande åtkomsträttigheter till servern med sin unika Microsoft Entra-identitet:

• get – för att hämta den offentliga delen och egenskaperna för nyckeln i Key Vault

• wrapKey – för att kunna skydda (kryptera) DEK

• unwrapKey – för att kunna ta bort skyddet (dekryptera) DEK

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

När servern har konfigurerats för att använda ett TDE-skydd från AKV skickar servern DEK för varje TDE-aktiverad databas till nyckelvalvet för kryptering. Key Vault returnerar den krypterade DEK som sedan lagras i användardatabasen.

Vid behov skickar servern skyddad DEK till nyckelvalvet för dekryptering.

Granskare kan använda Azure Monitor för att granska Key Vault AuditEvent-loggar om loggning är aktiverat.

Kommentar

Det kan ta cirka 10 minuter innan eventuella behörighetsändringar börjar gälla för 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 konfiguration av kundhanterad TDE

Krav för att konfigurera AKV

• Funktioner för skydd mot mjuk borttagning och rensning måste vara aktiverade i nyckelvalvet för att skydda mot dataförlust på grund av oavsiktlig borttagning av nycklar (eller nyckelvalv).

• Ge servern eller den hanterade instansen åtkomst till nyckelvalvet (get, wrapKey, unwrapKey) med hjälp av dess Microsoft Entra-identitet. Serveridentiteten kan vara en systemtilldelad hanterad identitet eller en användartilldelad hanterad identitet som tilldelats servern. När du använder Azure-portalen skapas Microsoft Entra-identiteten automatiskt när servern skapas. När du använder PowerShell eller Azure CLI måste Microsoft Entra-identiteten skapas uttryckligen och verifieras. Se Konfigurera TDE med BYOK och Konfigurera TDE med BYOK för SQL Managed Instance för detaljerade stegvisa instruktioner när du använder PowerShell.

  • Beroende på behörighetsmodellen för nyckelvalvet (åtkomstprincip eller Azure RBAC) kan åtkomst till nyckelvalvet beviljas antingen genom att skapa en åtkomstprincip för nyckelvalvet eller genom att skapa en ny Azure RBAC-rolltilldelning med rollen som användare av Key Vault-krypteringstjänst.

• När du använder en brandvägg med AKV måste du aktivera alternativet Tillåt betrodda Microsoft-tjänster att kringgå brandväggen. Mer information finns i Konfigurera Azure Key Vault-brandväggar och virtuella nätverk.

Aktivera skydd mot mjuk borttagning och rensning för AKV

Viktigt!

Både skydd mot mjuk borttagning och rensning måste vara aktiverat i nyckelvalvet när du konfigurerar kundhanterad TDE på en ny eller befintlig server eller hanterad instans.

Skydd mot mjuk borttagning och rensning är viktiga funktioner i Azure Key Vault som möjliggör återställning av borttagna valv och borttagna nyckelvalvobjekt, vilket minskar risken för att en användare oavsiktligt eller skadligt tar bort en nyckel eller ett nyckelvalv.

• Mjukt borttagna resurser behålls i 90 dagar, såvida de inte återställs eller rensas av kunden. Åtgärderna för återställning och rensning har sina egna behörigheter associerade i en åtkomstprincip för nyckelvalvet. Funktionen för mjuk borttagning är aktiverad som standard för nya nyckelvalv och kan också aktiveras med hjälp av Azure-portalen, PowerShell eller Azure CLI.

• Rensningsskydd kan aktiveras med Hjälp av Azure CLI eller PowerShell. När rensningsskyddet är aktiverat kan valv eller objekt i borttaget tillstånd rensas förrän efter kvarhållningsperioden. Standardkvarhållningsperioden är 90 dagar, men kan konfigureras från 7 till 90 dagar via Azure-portalen.

• Azure SQL kräver mjuk borttagning och rensningsskydd för att aktiveras i nyckelvalvet som innehåller krypteringsnyckeln som används som TDE-skydd för servern eller den hanterade instansen. Detta hjälper till att förhindra scenariot med oavsiktligt eller skadligt nyckelvalv eller nyckelborttagning som kan leda till att databasen hamnar i otillgängligt tillstånd.

• När du konfigurerar TDE-skyddet på en befintlig server eller när servern skapas verifierar Azure SQL att nyckelvalvet som används har mjuk borttagning och rensningsskydd aktiverat. Om skydd mot mjuk borttagning och rensning inte är aktiverat i nyckelvalvet misslyckas konfigurationen av TDE-skyddet med ett fel. I det här fallet måste skydd mot mjuk borttagning och rensning först aktiveras i nyckelvalvet och sedan ska TDE-skyddskonfigurationen utföras.

Krav för att konfigurera TDE-skydd

• TDE-skyddet kan bara vara en asymmetrisk, RSA- eller RSA HSM-nyckel. Nyckellängderna som stöds är 2 048 bitar och 3 072 bitar.

• Nyckelaktiveringsdatumet (om det anges) måste vara ett datum och en tid i det förflutna. Förfallodatum (om det anges) måste vara ett framtida datum och en framtida tid.

• Nyckeln måste vara i tillståndet Aktiverad .

• Om du importerar en befintlig nyckel till nyckelvalvet måste du ange den i de filformat som stöds (.pfx, .byokeller .backup).

Kommentar

Azure SQL stöder nu användning av en RSA-nyckel som lagras i en hanterad HSM som TDE-skydd. Azure Key Vault Managed HSM är en fullständigt hanterad, högtillgänglig molntjänst med en enda klient, standardkompatibel molntjänst som gör att du kan skydda kryptografiska nycklar för dina molnprogram med fips 140-2 nivå 3-verifierade HSM:er. Läs mer om hanterade HSM:er.

Kommentar

Ett problem med Thales CipherTrust Manager-versioner före v2.8.0 förhindrar att nycklar som nyligen importerats till Azure Key Vault används med Azure SQL Database eller Azure SQL Managed Instance för kundhanterade TDE-scenarier. Mer information om det här problemet finns här. I sådana fall väntar du 24 timmar efter att du har importerat nyckeln till nyckelvalvet för att börja använda den som TDE-skydd för servern eller den hanterade instansen. Det här problemet har lösts i Thales CipherTrust Manager v2.8.0.

Rekommendationer vid konfiguration av kundhanterad TDE

Rekommendationer när du konfigurerar AKV

• Associera högst 500 generell användning eller 200 Affärskritisk databaser totalt med ett nyckelvalv i en enda prenumeration för att säkerställa hög tillgänglighet när servern kommer åt TDE-skyddet i nyckelvalvet. Dessa siffror baseras på upplevelsen och dokumenteras i key vault-tjänstens gränser. Avsikten här är att förhindra problem efter serverredundans, eftersom det utlöser så många nyckelåtgärder mot valvet som det finns databaser på servern.

• Ange ett resurslås i nyckelvalvet som styr vem som kan ta bort den kritiska resursen för att förhindra oavsiktlig eller obehörig borttagning. Läs mer om resurslås.

• 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. Operations Management Suite Log Analytics är ett exempel på en tjänst som redan är integrerad.

• Länka varje server med två nyckelvalv som finns i olika regioner och har samma nyckelmaterial för att säkerställa hög tillgänglighet för krypterade databaser. Markera nyckeln från ett av nyckelvalven som TDE-skydd. Systemet växlar automatiskt till nyckelvalvet i den andra regionen med samma nyckelmaterial, om det uppstår ett avbrott som påverkar nyckelvalvet i den första regionen.

Kommentar

För att ge större flexibilitet när det gäller att konfigurera kundhanterad TDE kan Azure SQL Database och Azure SQL Managed Instance i en region nu länkas till nyckelvalvet i vilken annan region som helst. Servern och nyckelvalvet måste inte finnas i samma region.

Rekommendationer när du konfigurerar TDE-skydd

• Behåll en kopia av TDE-skyddet på en säker plats eller deponering av det till depositionstjänsten.

• Om nyckeln genereras i nyckelvalvet skapar du en nyckelsäkerhetskopia innan du använder nyckeln i AKV för första gången. Säkerhetskopiering kan endast återställas till ett Azure Key Vault. Läs mer om kommandot Backup-AzKeyVaultKey .

• Skapa en ny säkerhetskopia när ändringar görs i nyckeln (till exempel nyckelattribut, taggar, ACL:er).

• Behåll tidigare versioner av nyckeln i nyckelvalvet när du roterar nycklar, så att äldre databassäkerhetskopior kan återställas. När TDE-skyddet ändras för en databas uppdateras inte gamla säkerhetskopior av databasen för att använda det senaste TDE-skyddet. Vid återställningstillfället behöver varje säkerhetskopia det TDE-skydd som den krypterades med när den skapades. Nyckelrotationer kan utföras enligt anvisningarna i Rotera det transparenta datakrypteringsskyddet med PowerShell.

• Behåll alla nycklar som du tidigare har använt i AKV även efter att du har bytt till tjänsthanterade nycklar. Det säkerställer att säkerhetskopior av databaser kan återställas med TDE-skydd som lagras i AKV. TDE-skydd som skapats med Azure Key Vault måste underhållas tills alla återstående lagrade säkerhetskopior har skapats med tjänsthanterade nycklar. Skapa återställningsbara säkerhetskopior av dessa nycklar med hjälp av Backup-AzKeyVaultKey.

• Om du vill ta bort en potentiellt komprometterad nyckel under en säkerhetsincident utan risk för dataförlust följer du stegen från ta bort en potentiellt komprometterad nyckel.

Rotation av TDE-skydd

Att rotera TDE-skyddet för en server innebär att växla till en ny asymmetrisk nyckel som skyddar databaserna på servern. 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.

Rotation av TDE-skyddet kan antingen göras manuellt eller med hjälp av den automatiserade rotationsfunktionen.

Automatisk rotation av TDE-skyddet kan aktiveras när du konfigurerar TDE-skyddet för servern. Automatisk rotation är inaktiverad som standard. När den är aktiverad kontrollerar servern kontinuerligt nyckelvalvet efter nya versioner av nyckeln som används som TDE-skydd. Om en ny version av nyckeln identifieras roteras TDE-skyddet på servern automatiskt till den senaste nyckelversionen inom 60 minuter.

När den här funktionen används med automatiserad nyckelrotation i Azure Key Vault kan du använda nolltouchrotation från slutpunkt till slutpunkt för TDE-skyddet i Azure SQL Database och Azure SQL Managed Instance.

Kommentar

Om du ställer in TDE med CMK med manuell eller automatiserad rotation av nycklar används alltid den senaste versionen av nyckeln som stöds. Konfigurationen tillåter inte användning av en tidigare eller lägre version av nycklar. Att alltid använda den senaste nyckelversionen överensstämmer med Azure SQL-säkerhetsprincipen som inte tillåter tidigare nyckelversioner som kan komprometteras. Tidigare versioner av nyckeln kan behövas för säkerhetskopiering eller återställning av databaser, särskilt vid långsiktiga kvarhållningssäkerhetskopior, där de äldre nyckelversionerna måste bevaras. För geo-replikeringskonfigurationer måste alla nycklar som krävs av källservern finnas på målservern.

Överväganden för geo-replikering när du konfigurerar automatisk rotation av TDE-skyddet

För att undvika problem vid etablering eller under geo-replikering, när automatisk rotation av TDE-skyddet är aktiverat på den primära eller sekundära servern, är det viktigt att följa dessa regler när du konfigurerar geo-replikering:

• Både de primära och sekundära servrarna måste ha behörigheten Hämta, wrapKey och unwrapKey till den primära serverns nyckelvalv (nyckelvalv som innehåller den primära serverns TDE-skyddsnyckel).

• För en server med automatisk nyckelrotation aktiverad lägger du till krypteringsnyckeln som används som TDE-skydd på den primära servern till den sekundära servern innan du initierar geo-replikering. Den sekundära servern kräver åtkomst till nyckeln i samma nyckelvalv som används med den primära servern (och inte en annan nyckel med samma nyckelmaterial). Innan du initierar geo-replikering kan du också kontrollera att den sekundära serverns hanterade identitet (användartilldelad eller systemtilldelad) har nödvändiga behörigheter för den primära serverns nyckelvalv och att systemet försöker lägga till nyckeln till den sekundära servern.

• För en befintlig konfiguration av geo-replikering lägger du till krypteringsnyckeln som används som TDE-skydd på den primära servern till den sekundära servern innan du aktiverar automatisk nyckelrotation på den primära servern. Den sekundära servern kräver åtkomst till nyckeln i samma nyckelvalv som används med den primära servern (och inte en annan nyckel med samma nyckelmaterial). Innan du aktiverar automatisk nyckel kan du också se till att den sekundära serverns hanterade identitet (användartilldelad eller systemtilldelad) har nödvändiga behörigheter för den primära serverns nyckelvalv och att systemet försöker lägga till nyckeln till den sekundära servern.

• Geo-replikeringsscenarier med hjälp av kundhanterade nycklar (CMK) för TDE stöds. TDE med automatisk nyckelrotation måste konfigureras på alla servrar om du konfigurerar TDE i Azure-portalen. Mer information om hur du konfigurerar automatisk nyckelrotation för geo-replikeringskonfigurationer med TDE finns i Automatisk nyckelrotation för geo-replikeringskonfigurationer.

Otillgängligt TDE-skydd

När transparent datakryptering (TDE) har konfigurerats till att använda en kundhanterad nyckel, krävs kontinuerlig åtkomst till TDE-skyddet för att databasen ska fortsätta vara online. Om servern förlorar åtkomsten till det kundhanterade TDE-skyddet i AKV börjar en databas på upp till 10 minuter neka alla anslutningar med motsvarande felmeddelande och ändra dess tillstånd till Otillgängligt. Den enda åtgärd som tillåts för en databas i otillgängligt tillstånd är att ta bort den.

Kommentar

Om databasen inte är tillgänglig på grund av ett tillfälligt nätverksfel krävs ingen åtgärd och databaserna kommer att vara online igen automatiskt.

När åtkomsten till nyckeln har återställts krävs det extra tid och steg för att ta databasen online igen, vilket kan variera beroende på den tid som förflutit utan åtkomst till nyckeln och storleken på data i databasen:

Kommentar

• Om nyckelåtkomsten återställs inom 30 minuter kommer databasen att höras automatiskt inom den närmaste timmen.
• Om nyckelåtkomsten återställs efter mer än 30 minuter är autoheal av databasen inte möjlig. För att återställa databasen krävs extra steg i Azure-portalen och kan ta lång tid beroende på databasens storlek.
• När databasen är online igen går tidigare konfigurerade inställningar på servernivå som kan innehålla konfiguration av redundansgrupper , taggar och inställningar på databasnivå, till exempel konfiguration av elastiska pooler, lässkalning, automatisk pausning, återställningshistorik vid tidpunkt, långsiktig kvarhållningsprincip och andra förlorade. Därför rekommenderar vi att kunderna implementerar ett meddelandesystem som identifierar förlust av krypteringsnyckelåtkomst inom 30 minuter. När fönstret på 30 minuter har upphört att gälla rekommenderar vi att du verifierar alla inställningar på server- och databasnivå på den återställda databasen.

Nedan visas en vy över de extra steg som krävs på portalen för att få en otillgänglig databas online igen.

OavsiktligT återkallande av TDE-skydd

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

• återkalla nyckelvalvets behörigheter get, wrapKey, unwrapKey från servern

• ta bort nyckeln

• ta bort nyckelvalvet

• ändra nyckelvalvets brandväggsregler

• ta bort serverns hanterade identitet i Microsoft Entra-ID

Läs mer om vanliga orsaker till att databasen blir otillgänglig.

Blockerad anslutning mellan SQL Managed Instance och Key Vault

På SQL Managed Instance kan nätverksfel vid försök att komma åt TDE-skydd i Azure Key Vault inte leda till att databaserna ändrar dess tillstånd till Otillgängligt , men gör instansen otillgänglig efteråt. Detta sker främst när nyckelvalvsresursen finns men dess slutpunkt inte kan nås från den hanterade instansen. Alla scenarier där nyckelvalvsslutpunkten kan nås men anslutningen nekas, saknade behörigheter osv. gör att databaserna ändrar dess tillstånd till Otillgängligt.

De vanligaste orsakerna till bristande nätverksanslutning till Key Vault är:

• Key Vault exponeras via privat slutpunkt och den privata IP-adressen för AKV-tjänsten tillåts inte i de utgående reglerna för den nätverkssäkerhetsgrupp (NSG) som är associerad med undernätet för den hanterade instansen.
• Felaktig DNS-matchning, till exempel när nyckelvalvets FQDN inte matchas eller matchas till en ogiltig IP-adress.

Testa anslutningen från SQL Managed Instance till Key Vault som är värd för TDE-skyddet.

• Slutpunkten är ditt valv-FQDN, till exempel <vault_name.vault.azure.net> (utan https://).
• Porten som ska testas är 443.
• Resultatet för RemoteAddress ska finnas och vara den korrekta IP-adressen
• Resultatet för TCP-test ska vara TcpTestSucceeded: True.

Om testet ger TcpTestSucceeded: False ska du granska nätverkskonfigurationen:

• Kontrollera den lösta IP-adressen och bekräfta att den är giltig. Ett värde som saknas innebär att det finns problem med DNS-matchning.
  • Bekräfta att nätverkssäkerhetsgruppen på den hanterade instansen har en regel för utgående trafik som täcker den lösta IP-adressen på port 443, särskilt när den lösta adressen tillhör nyckelvalvets privata slutpunkt.
  • Kontrollera andra nätverkskonfigurationer som routningstabell, förekomsten av en virtuell installation och dess konfiguration osv.

Övervakning av kundhanterad TDE

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

• Azure Resource Health. En otillgänglig databas som har förlorat åtkomsten till TDE-skyddet visas som "otillgänglig" efter att den första anslutningen till databasen har nekats.
• Aktivitetslogg när åtkomsten till TDE-skyddet i det kundhanterade nyckelvalvet misslyckas läggs poster till i aktivitetsloggen. Genom att skapa aviseringar för dessa händelser kan du återställa åtkomsten så snart som möjligt.
• Åtgärdsgrupper kan definieras för att skicka meddelanden och aviseringar baserat på dina inställningar, till exempel e-post/SMS/push/röst, logikapp, webhook, ITSM eller Automation Runbook.

Säkerhetskopiering och återställning av databaser med kundhanterad TDE

När en databas har krypterats med TDE med hjälp av en nyckel från 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 krypterad med ett TDE-skydd från Key Vault kontrollerar du att nyckelmaterialet är tillgängligt för målservern. Vi rekommenderar därför att du behåller alla gamla versioner av TDE-skyddet i nyckelvalvet, så att säkerhetskopior av databasen kan återställas.

Viktigt!

När som helst kan det inte finnas fler än en TDE-skyddsuppsättning för en server. Det är nyckeln som är markerad med "Gör nyckeln till standard-TDE-skydd" på Azure-portalbladet. Flera ytterligare nycklar kan dock länkas till en server 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.

Om nyckeln som behövs för att återställa en säkerhetskopia inte längre är tillgänglig för målservern returneras följande felmeddelande vid återställnings försöket: "Målservern <Servername> har inte åtkomst till alla AKV-URI:er som skapats mellan <Tidsstämpel nr 1> och <Tidsstämpel 2>. Försök igen när du har återställt alla AKV-URI:er."

Du kan åtgärda problemet genom att köra cmdleten Get-AzSqlServerKeyVaultKey för målservern eller Get-AzSqlInstanceKeyVaultKey för den hanterade målinstansen för att returnera listan över tillgängliga nycklar och identifiera de saknade. Kontrollera att målservern för återställningen har åtkomst till alla nycklar som behövs för att säkerställa att alla säkerhetskopior kan återställas. Dessa nycklar behöver inte markeras som TDE-skydd.

Mer information om säkerhetskopieringsåterställning för SQL Database finns i Återställa en databas i SQL Database. Mer information om säkerhetskopieringsåterställning för dedikerade SQL-pooler i Azure Synapse Analytics finns i Återställa en dedikerad SQL-pool. Information om SQL Server:s interna säkerhetskopiering/återställning med SQL Managed Instance finns i Snabbstart: Återställa en databas till SQL Managed Instance.

Ett annat övervägande för loggfiler: Säkerhetskopierade loggfiler förblir krypterade med det ursprungliga TDE-skyddet, även om det roterades och databasen nu använder ett nytt TDE-skydd. Vid återställningen krävs båda nycklarna för att återställa databasen. Om loggfilen använder ett TDE-skydd som lagras i Azure Key Vault behövs den här nyckeln vid återställningen, även om databasen har ändrats för att använda tjänsthanterad TDE under tiden.

Hög tillgänglighet med kundhanterad TDE

Även om det inte finns någon konfigurerad geo-redundans för servern rekommenderar vi starkt att du konfigurerar servern att använda två olika nyckelvalv i två olika regioner med samma nyckelmaterial. Nyckeln i det sekundära nyckelvalvet i den andra regionen bör inte markeras som TDE-skydd, och det är inte ens tillåtet. Om det uppstår ett avbrott som påverkar det primära nyckelvalvet, och endast då, växlar systemet automatiskt till den andra länkade nyckeln med samma tumavtryck i det sekundära nyckelvalvet, om det finns. Observera att växeln inte inträffar om TDE-skyddet inte är tillgängligt på grund av återkallade åtkomsträttigheter, eller på grund av att nyckel- eller nyckelvalvet tas bort, eftersom det kan tyda på att kunden avsiktligt ville begränsa servern från att komma åt nyckeln. Att tillhandahålla samma nyckelmaterial till två nyckelvalv i olika regioner kan göras genom att skapa nyckeln utanför nyckelvalvet och importera dem till båda nyckelvalven.

Du kan också göra det genom att generera en nyckel med hjälp av det primära nyckelvalvet i en region och klona nyckeln till ett nyckelvalv i en annan Azure-region. Använd cmdleten Backup-AzKeyVaultKey för att hämta nyckeln i krypterat format från det primära nyckelvalvet och sedan använda cmdleten Restore-AzKeyVaultKey och ange ett nyckelvalv i den andra regionen för att klona nyckeln. Du kan också använda Azure-portalen för att säkerhetskopiera och återställa nyckeln. Säkerhetskopiering/återställning av nycklar tillåts endast mellan nyckelvalv inom samma Azure-prenumeration och Azure-geografi.

Geo-DR och kundhanterad TDE

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

För att undvika problem vid etablering eller under geo-replikering på grund av ofullständigt nyckelmaterial är det viktigt att följa dessa regler när du konfigurerar kundhanterad TDE (om separata nyckelvalv används för de primära och sekundära servrarna):

• Alla berörda nyckelvalv måste ha samma egenskaper och samma åtkomsträttigheter för respektive servrar.

• Alla nyckelvalv måste innehålla identiskt nyckelmaterial. Det gäller inte bara för det aktuella TDE-skyddet, utan för alla tidigare TDE-skydd som kan användas i säkerhetskopieringsfilerna.

• Både den inledande installationen och rotationen av TDE-skyddet måste utföras på den sekundära först och sedan på den primära.

Om du vill testa en redundans följer du stegen i Översikt över aktiv geo-replikering. Redundanstestning bör utföras regelbundet för att verifiera att SQL Database har bibehållit åtkomstbehörigheten till båda nyckelvalv.

Azure SQL Database-servern och SQL Managed Instance i en region kan nu länkas till nyckelvalv i vilken annan region som helst. Servern och nyckelvalvet behöver inte finnas i samma region. För enkelhets skull kan de primära och sekundära servrarna anslutas till samma nyckelvalv (i vilken region som helst). Detta hjälper till att undvika scenarier där nyckelmaterial kan vara osynkroniserat om separata nyckelvalv används för båda servrarna. Azure Key Vault har flera redundanslager för att se till att dina nycklar och nyckelvalv förblir tillgängliga om det uppstår fel i tjänsten eller regionen. Tillgänglighet och redundans för Azure Key Vault

Azure Policy för kundhanterad TDE

Azure Policy kan användas för att framtvinga kundhanterad TDE när en Azure SQL Database-server eller Azure SQL Managed Instance skapas eller uppdateras. När den här principen är på plats misslyckas alla försök att skapa eller uppdatera en logisk server i Azure eller den hanterade instansen om den inte har konfigurerats med en kundhanterad nyckel. Azure Policy kan tillämpas på hela Azure-prenumerationen, eller bara inom en resursgrupp.

Mer information om Azure Policy finns i Vad är Azure Policy? och Definitionsstruktur för Azure Policy.

Följande två inbyggda principer stöds för kundhanterad TDE i Azure Policy:

• SQL-servrar bör använda kundhanterade nycklar för att kryptera vilande data
• Hanterade instanser bör använda kundhanterade nycklar för att kryptera vilande data

Den kundhanterade TDE-principen kan hanteras genom att gå till Azure-portalen och söka efter principtjänsten . Under Definitioner söker du efter kundhanterad nyckel.

Det finns tre effekter för dessa principer:

• Granskning – standardinställningen och samlar bara in en granskningsrapport i Azure Policy-aktivitetsloggarna
• Neka – förhindrar att logisk server eller hanterad instans skapas eller uppdateras utan att en kundhanterad nyckel har konfigurerats
• Inaktiverad – inaktiverar principen och begränsar inte användare från att skapa eller uppdatera en logisk server eller hanterad instans utan kundhanterad TDE aktiverat

Om Azure Policy för kundhanterad TDE har angetts till Neka misslyckas skapande av logisk Azure SQL-server eller hanterad instans. Information om det här felet registreras i aktivitetsloggen för resursgruppen.

Viktigt!

Tidigare versioner av inbyggda principer för kundhanterad TDE som innehåller effekten AuditIfNotExist har blivit inaktuella. Befintliga principtilldelningar som använder inaktuella principer påverkas inte och fortsätter att fungera som tidigare.

Nästa steg

Du kanske också vill kontrollera följande PowerShell-exempelskript för vanliga åtgärder med kundhanterad TDE:

• Rotera det transparenta datakrypteringsskyddet för SQL Database

• Ta bort ett transparent skydd för datakryptering (TDE) för SQL Database

• Hantera transparent datakryptering i SQL Managed Instance med din egen nyckel med hjälp av PowerShell

Dessutom kan du göra det möjligt för Microsoft Defender för SQL att skydda dina databaser och deras data, med funktioner för att identifiera och minimera potentiella databassårbarheter och identifiera avvikande aktiviteter som kan tyda på ett hot mot dina databaser.