Dela via

Transparent datakryptering i Azure SQL med kundhanterad nyckel

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

transparent datakryptering (TDE) i Azure SQL med kundhanterad nyckel (CMK) aktiverar BYOK-scenariot (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 en nyckellivscykelhantering (nyckelskapande, uppladdning, rotation, borttagning), behörigheter för nyckelanvändning och granskning av åtgärder på nycklar.

I det här scenariot lagras TDE-skyddet (Transparent Data Encryption) – en kundhanterad asymmetrisk nyckel som används för att skydda databaskrypteringsnyckeln (DEK) i antingen Azure Key Vault eller Azure Key Vault Managed HSM. Dessa är säkra, molnbaserade nyckelhanteringstjänster som är utformade för hög tillgänglighet och skalbarhet. Azure Key Vault stöder RSA-nycklar och kan backas upp av FIPS 140-2 Level 2-verifierade HSM:er. För kunder som kräver högre säkerhet erbjuder Azure Key Vault Managed HSM FIPS 140-2 nivå 3-verifierad maskinvara. Nyckeln kan genereras i tjänsten, importeras eller överföras på ett säkert sätt från lokala HSM:er. Direkt åtkomst till nycklar är begränsad – auktoriserade tjänster utför kryptografiska åtgärder utan att exponera nyckelmaterialet.

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 inget 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å.

Anteckning

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.

Anteckning

Microsoft Entra ID tidigare kallades Azure Active Directory (Azure AD).

Fördelar med kundhanterad TDE

Anteckning

I den här artikeln används termerna Customer Managed Key (CMK) och Bring Your Own Key (BYOK) omväxlande, men de representerar vissa skillnader.

  • kundhanterad nyckel (CMK) – Kunden hanterar nyckellivscykeln, inklusive nyckelskapande, rotation och borttagning. Nyckeln lagras i Azure Key Vault eller Azure Managed HSM och används för kryptering av databaskrypteringsnyckeln (DEK) i Azure SQL, SQL Server på en virtuell Azure-dator och SQL Server lokalt.
  • Byok (Bring Your Own Key) – Kunden tar med sig eller importerar sin egen nyckel från en lokal maskinvarusäkerhetsmodul (HSM) till Azure Key Vault eller Azure Managed HSM. Sådana importerade nycklar kan användas som andra nycklar i Azure Key Vault, inklusive som en kundhanterad nyckel för kryptering av DEK. För mer information, se Importera HSM-skyddade nycklar till Managed HSM (BYOK).

Kundhanterad TDE ger kunden följande fördelar:

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

  • Transparens i TDE-skyddsanvändningen.

  • Möjlighet att implementera ansvarsfördelning i hanteringen av nycklar och data i organisationen.

  • Azure 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 Azure Key Vault.

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

Viktig

För dem som använder tjänsthanterad TDE som vill börja använda kundhanterad TDE förblir data krypterade under övergången och det finns ingen stilleståndstid eller omkryptering av databasfilerna. Om du byter från en tjänsthanterad nyckel till en kundhanterad nyckel krävs endast omkryptering av DEK, vilket är en snabb och onlineåtgärd.

Behörigheter för att konfigurera kundhanterad TDE

diagram som visar konfiguration och funktion av kundhanterad TDE.

Välj den typ av Azure Key Vault som du vill använda.

För att den logiska servern i Azure ska kunna använda TDE-skyddet som lagras i Azure Key Vault för kryptering av DEK måste Key Vault-administratören ge åtkomstbehörighet till servern med sin unika Microsoft Entra-identitet. Serveridentiteten kan vara en systemtilldelad hanterad identitet eller en användartilldelad hanterad identitet som tilldelats servern. Det finns två åtkomstmodeller för att ge servern åtkomst till nyckelvalvet:

  • Rollbaserad åtkomstkontroll i Azure (RBAC) – Använd Azure RBAC för att ge en användare, grupp eller program åtkomst till nyckelvalvet. Den här metoden rekommenderas för dess flexibilitet och kornighet. Key Vault Crypto Service Encryption User roll krävs av serveridentiteten för att kunna använda nyckeln för krypterings- och dekrypteringsåtgärder.

  • Åtkomstprincip för valv – Använd åtkomstprincipen för nyckelvalvet för att ge servern åtkomst till nyckelvalvet. Den här metoden är enklare och mer direkt, men mindre flexibel. Serveridentiteten måste ha följande behörigheter för nyckelvalvet:

    • 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

I Access-konfigurationen Azure-portalmenyn i nyckelvalvet kan du välja rollbaserad åtkomstkontroll i Azure eller Vault-åtkomstprincip. Stegvisa instruktioner för hur du konfigurerar en Azure Key Vault-åtkomstkonfiguration för TDE finns i Konfigurera SQL Server TDE Extensible Key Management med hjälp av Azure Key Vault. Mer information om åtkomstmodellerna finns i Azure Key Vault-säkerhet.

En Key Vault-administratör kan också aktivera loggning av granskningshändelser för nyckelvalvså att de kan granskas senare.

När en server har konfigurerats för att använda ett TDE-skydd från Azure Key Vault 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.

Anteckning

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 att konfigurera kundhanterad TDE

  • Funktioner för skydd mot mjuk borttagning och rensning måste vara aktiverade i Azure Key Vault. Detta hjälper till att förhindra scenariot med oavsiktlig eller skadlig 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 och ger ett fel. I det här fallet måste mjuk radering och skydd mot rensning först aktiveras i nyckelvalvet och därefter ska TDE-skyddskonfigurationen utföras.

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

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 tidigare. 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 kontrollerar du att den finns i något av de filformat som stöds: .pfx, .byokeller .backup. Information om hur du importerar HSM-skyddade nycklar till Azure Managed HSM finns i Importera HSM-skyddade nycklar till Managed HSM (BYOK).

Anteckning

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 Azure Key Vault 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

  • Associera högst 500 databaser för generell användning eller 200 affärskritiska databaser totalt med ett nyckelvalv i en enda prenumeration för att säkerställa hög tillgänglighet när servern har åtkomst till TDE-skyddet i nyckelvalvet. Dessa siffror baseras på upplevelsen och dokumenteras i Azure Key Vault-tjänstens gränser. Avsikten ä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 på nyckelvalvet för att styra vem som kan ta bort den här kritiska resursen och förhindra oavsiktlig eller obehörig borttagning. Läs mer om resurslås.

  • Aktivera granskning och rapportering av alla krypteringsnycklar: Azure Key Vault tillhandahåller loggar som är enkla att mata in i andra säkerhetsinformations- och händelsehanteringsverktyg. Operations Management Suite Log Analytics är ett exempel på en tjänst som redan är integrerad.

  • Använd ett nyckelvalv från en Azure-region som kan replikera dess innehåll till en länkad region för maximal tillgänglighet. Mer information finns i Metodtips för att använda Azure Key Vault och tillgänglighet och redundans i Azure Key Vault.

Anteckning

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 Azure Key Vault i vilken annan region som helst. Servern och nyckelvalvet behöver inte samplaceeras i samma region.

Rekommendationer vid konfiguration av TDE-skydd

  • Behåll en kopia av TDE-skyddet på en säker plats eller deponera det hos en depositionstjänst.

  • Om nyckeln genereras i nyckelvalvet skapar du en nyckelsäkerhetskopia innan du använder nyckeln i Azure Key Vault för första gången. Säkerhetskopiering kan endast återställas till ett Azure Key Vault. Läs mer om kommandot Backup-AzKeyVaultKey. Azure Managed HSM har stöd för att skapa en fullständig säkerhetskopia av hela innehållet i HSM, inklusive alla nycklar, versioner, attribut, taggar och rolltilldelningar. Mer information finns i Fullständig säkerhetskopiering och återställning och selektiv nyckelåterställning.

  • 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 eller den hanterade HSM-enheten 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ällningen behöver varje säkerhetskopia TDE-skyddet som den krypterades med när den skapades. Nyckelrotationer kan utföras enligt anvisningarna i Rotera det transparenta datakrypteringsskyddet med PowerShell-.

  • Behåll alla tidigare använda nycklar i Azure Key Vault eller Azure Managed HSM även efter växling till tjänsthanterade nycklar. Det säkerställer att databassäkerhetskopior kan återställas med TDE-skydd som lagras i Azure Key Vault eller Azure Managed HSM. TDE-skydd som skapats med Azure Key Vault eller Azure Managed HSM måste underhållas tills alla återstående lagrade säkerhetskopior har skapats med tjänsthanterade nycklar. Gör å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 funktionen automatiserad rotation.

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 eller den hanterade HSM:n för att se om det finns några nya versioner av nyckeln som används som TDE-protektor. Om en ny version av nyckeln identifieras roteras TDE-skyddet på servern eller databasen automatiskt till den senaste nyckelversionen inom 24 timmar.

När den här funktionen används med automatiserad nyckelrotation i Azure Key Vault eller autorotation i Azure Managed HSM möjliggör den här funktionen nolltouch-rotation från slutpunkt till slutpunkt för TDE-skyddet i Azure SQL Database och Azure SQL Managed Instance.

Anteckning

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 databassäkerhetskopiering eller återställning, särskilt för 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 den automatiska rotationen 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 Get, wrapKey och unwrapKey behörigheter 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 eller hanterade HSM som används med den primära servern (och inte en annan nyckel med samma nyckelmaterial). Innan du initierar geo-replikering 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 eller hanterade HSM, och 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 eller hanterade HSM som används med den primära servern (och inte en annan nyckel med samma nyckelmaterial). Innan du aktiverar automatiserad 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 på 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 TDE har konfigurerats för att använda en kundhanterad nyckel krävs kontinuerlig åtkomst till TDE-skyddet för att databasen ska förbli online. Om servern förlorar åtkomsten till det kundhanterade TDE-skyddet i Azure Key Vault eller Azure Managed HSM 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.

Otillgängligt tillstånd

Om databasen inte är tillgänglig på grund av ett tillfälligt nätverksfel (till exempel ett 5XX-fel) krävs ingen åtgärd eftersom databaserna kommer tillbaka online automatiskt. För att minska effekten av nätverksfel eller avbrott vid åtkomst till TDE-skyddet i Azure Key Vault eller Azure Managed HSM har en 24-timmarsbuffert introducerats innan tjänsten försöker flytta databasen till ett otillgängligt tillstånd. Om en överflyttning inträffar innan systemet når det otillgängliga tillståndet blir databasen otillgänglig på grund av förlusten av krypteringscachen.

Om servern förlorar åtkomsten till det kundhanterade TDE-skyddet i Azure Key Vault eller Azure Managed HSM på grund av ett Azure Key Vault-fel (till exempel ett 4XX-fel) flyttas databasen till ett otillgängligt tillstånd efter 30 minuter.

Återställa databasåtkomst efter ett Azure Key Vault- eller Azure Managed HSM-fel

När åtkomsten till nyckeln har återställts kräver det ytterligare tid och steg för att återställa databasen, vilket kan variera beroende på hur länge nyckeln är otillgänglig och storleken på data i databasen.

Om nyckelåtkomsten återställs inom 30 minuter återställs databasen automatiskt inom den efterföljande timmen. Men om nyckelåtkomsten återställs efter mer än 30 minuter går det inte att återställa databasen automatiskt. I sådana fall innebär återställning av databasen extra procedurer via Azure-portalen och kan vara tidskrävande, beroende på databasens storlek.

När databasen är online igen går tidigare konfigurerade inställningar på servernivå, inklusive konfigurationer av redundanskluster, taggar och inställningar på databasnivå, till exempel elastiska poolkonfigurationer, 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 för att identifiera förlust av krypteringsnyckelåtkomst inom 30 minuter. När 30-minutersfönstret har upphört att gälla rekommenderar vi att du verifierar alla inställningar på server- och databasnivå för 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.

TDE BYOK otillgänglig databas.

Oavsiktligt återkallande av TDE-skyddsåtkomst

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

  • återkalla "get", wrapKey- och unwrapKey-behörigheter från nyckelvalvet eller den hanterade HSM-servern

  • ta bort nyckeln

  • ta bort nyckelvalvet eller det hanterade HSM:et

  • ändra nyckelvalvets eller hanterade HSM-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 Azure Key Vault eller Azure Managed HSM

Nätverksanslutningsblocket mellan SQL Managed Instance och nyckelvalvet eller hanterad HSM sker främst när nyckelvalvet eller den hanterade HSM-resursen finns men dess slutpunkt inte kan nås från den hanterade instansen. Alla scenarier där nyckelvalvet eller den hanterade HSM-slutpunkten 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 Azure Key Vault eller Azure Managed HSM är:

  • Azure Key Vault eller Azure Managed HSM exponeras via privat slutpunkt och den privata IP-adressen för Azure Key Vault- eller Azure Managed HSM-tjänsten tillåts inte i utgående regler för nätverkssäkerhetsgruppen (NSG) som är associerad med undernätet för hanterad instans.
  • Felaktig DNS-matchning, till exempel när nyckelvalvet eller det hanterade HSM FQDN inte matchas eller matchas till en ogiltig IP-adress.

Testa anslutningen från SQL Managed Instance till Azure Key Vault eller Azure Managed HSM 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 rätt IP-adress
  • Resultatet för TCP-testet ska vara TcpTestSucceededed: True.

Om testet returnerar TcpTestSucceededed: Falsegranskar du 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 eller den hanterade privata HSM-slutpunkten.
    • Kontrollera andra nätverkskonfigurationer som routningstabell, förekomsten av en virtuell installation och dess konfiguration osv.

Övervakning av kundhanterad Transparent Data Encryption (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.

Databas backup och restore med kundhanterad TDE

När en databas har krypterats med TDE med hjälp av en nyckel från Azure Key Vault eller Azure Managed HSM 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 Azure Key Vault eller Azure Managed HSM kontrollerar du att nyckelmaterialet är tillgängligt för målservern. Därför rekommenderar vi att du behåller alla gamla versioner av TDE-skyddet i key vault eller den hanterade HSM, så att du kan återställa databassäkerhetskopior.

Viktig

Det får inte finnas fler än en TDE-skyddsuppsättning för en server vid något tillfälle. Nyckeln som är markerad med Gör nyckeln till standard-TDE-skyddet i Azure Portal-fönstret är TDE-skyddet. Flera 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ällningskommandot: "Målservern <Servername> inte har åtkomst till alla AKV-URI:er som skapats mellan <Timestamp #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-AzSqlServerKeyVault Key för målservern eller Get-AzSqlInstanceKeyVaultKey för målhanterad instans 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-inbyggda 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 eller Azure Managed HSM 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 (Transparent Data Encryption)

Med Azure Key Vault eller Azure Managed HSM som tillhandahåller flera lager av redundans kan TDE:er som använder en kundhanterad nyckel dra nytta av Azure Key Vault eller Azure Managed HSM-tillgänglighet och återhämtning och helt förlita sig på azure key vault- eller Azure Managed HSM-redundanslösningen.

Flera redundanslager i Azure Key Vault säkerställer nyckelåtkomst även om enskilda tjänstkomponenter misslyckas eller om Azure-regioner eller tillgänglighetszoner är nere. Mer information finns i tillgänglighet och redundans för Azure Key Vault.

Azure Key Vault erbjuder följande komponenter för tillgänglighet och motståndskraft som tillhandahålls automatiskt utan användarintervention:

Anteckning

För alla parregioner replikeras Azure Key Vault-nycklar till båda regionerna och det finns maskinvarusäkerhetsmoduler (HSM) i båda regionerna som kan användas på dessa nycklar. Mer information finns i Datareplikering. Detta gäller både standard- och Premium Azure Key Vault-tjänstnivåer samt programvaru- eller maskinvarunycklar.

Med Azure Managed HSM-replikering i flera regioner kan du utöka en Azure Managed HSM-pool från en Azure-region (kallas den primära regionen) till en annan Azure-region (kallas för en utökad region). När de har konfigurerats är båda regionerna aktiva, kan hantera begäranden och, med automatiserad replikering, dela samma nyckelmaterial, roller och behörigheter. Mer information finns i Aktivera replikering i flera regioner på Azure Managed HSM.

Geo-DR och kundstyrd TDE

I scenarier med både aktiv geo-replikering och redundansgrupper kan de primära och sekundära servrarna länkas till Azure Key Vault eller Azure Managed HSM som finns i valfri region. Servern och nyckelvalvet eller den hanterade HSM:en behöver inte vara indelade i samma region. För enkelhetens skull kan de primära och sekundära servrarna anslutas till samma nyckelvalv eller hanterade HSM (i valfri region). Detta hjälper till att undvika scenarier där nyckelmaterial kan vara osynkroniserat om separata nyckelvalv eller hanterade HSM:er används för båda servrarna. 

Azure Key Vault och Azure Managed HSM har flera redundanslager på plats för att se till att nycklarna och nyckelvalven förblir tillgängliga om tjänsten eller regionen misslyckas. Redundansen stöds av de oparade och parade regionerna. Mer information finns i tillgänglighet och redundans för Azure Key Vault.

Det finns flera alternativ för att lagra TDE-skyddsnyckeln baserat på kundernas krav:

  • Utnyttja Azure Key Vault och den inbyggda resiliensen för parkopplade regioner eller resiliensen i icke-kopplade regioner.

  • Utnyttja kundens HSM och läs in nycklar i Azure Key Vault i separata Azure Key Vaults i flera regioner.

  • Använd Azure Managed HSM och replikeringsalternativet mellan regioner.

    • Med det här alternativet kan kunden välja önskad region där nycklarna ska replikeras.

Följande diagram representerar en konfiguration för en länkad region (primär och sekundär) för en korsväxling av Azure Key Vault med Azure SQL-inställning för geo-replikering med hjälp av en växlingsgrupp.

diagram som visar stöd för redundans mellan regioner i Azure Key Vault för en länkad region.

Azure Key Vault-kommentarer för Geo-DR

  • Både primära och sekundära servrar i Azure SQL har åtkomst till Azure Key Vault i den primära regionen.

  • Redundansväxlingen i Azure Key Vault initieras av Azure Key Vault-tjänsten och inte av kunden.

  • Om Azure Key Vault redundansväxlar till den sekundära regionen kan servern i Azure SQL fortfarande komma åt samma Azure Key Vault. Även om det är internt omdirigeras Azure Key Vault-anslutningen till Azure Key Vault i den sekundära regionen.

  • Nya nyckelskapanden, importer och nyckelrotationer är bara möjliga medan Azure Key Vault i det primära är tillgängligt.

  • När redundansväxlingen inträffar tillåts inte nyckelrotation förrän Azure Key Vault i den primära regionen i den kopplade regionen är tillgänglig igen.

  • Kunden kan inte ansluta till den sekundära regionen manuellt.

  • Azure Key Vault är skrivskyddat medan Azure Key Vault i den primära regionen inte är tillgängligt

  • Kunden kan inte välja eller kontrollera vilken region Azure Key Vault är i för närvarande.

  • För en icke-parad region har båda Azure SQL-servrarna åtkomst till Azure Key Vault i den första regionen (enligt diagrammet) och Azure Key Vault använder zon-redundant lagring för att replikera data inom regionen, över oberoende tillgänglighetszoner i samma region.

Mer information finns i tillgänglighet och redundans för Azure Key Vault, Azure-regionpar och icke-kopplade regioneroch serviceavtal för Azure Key Vault.

Azure SQL-kommentarer för Geo-DR

  • Använd det zonredundanta alternativet Azure SQL MI och Azure SQL DB för att öka motståndskraften. Mer information finns i Vad är Azure-tillgänglighetszoner?.

  • Använd failovergrupper för Azure SQL MI och Azure SQL DB för katastrofåterställning till en sekundär region. För mer information, se översikt och bästa praxis för failover-grupper.

  • När en databas ingår i aktiva geo-replikerings- eller redundansgrupper och blir otillgänglig, bryter SQL-kontrollplanet länken och konverterar databasen till en fristående databas. När du har åtgärdat nyckelbehörigheterna kan den primära databasen vanligtvis anslutas igen. Det går inte att ansluta den sekundära databasen igen eftersom Azure SQL inte tar fullständiga säkerhetskopior för sekundära databaser avsiktligt. Rekommendationen är att släppa de sekundära databaserna och återupprätta länken.

  • Konfigurationen kan kräva en mer komplex DNS-zon om privata slutpunkter används i Azure SQL (det kan till exempel inte skapa två privata slutpunkter till samma resurs i samma DNS-zon).

  • Se till att program använder logik för återförsök.

Det finns flera scenarier när kunder kanske vill välja Azure Managed HSM-lösning framför Azure Key Vault:

  • Manuella anslutningskrav till det sekundära valvet.

  • Krav på läsbehörighet till valvet även vid ett fel.

  • Flexibilitet att välja vilken region deras nyckelmaterial replikeras till

    • Kräver aktivering av replikering mellan regioner som skapar den andra Azure Managed HSM-poolen i den andra regionen.

  • Med Azure Managed HSM kan kunder skapa en exakt replik för HSM om originalet går förlorat eller inte är tillgängligt.

  • Användning av Azure Managed HSM för säkerhets- eller regelkrav.

  • Möjligheten att säkerhetskopiera hela valvet jämfört med att säkerhetskopiera enskilda nycklar.

Mer information finns i Aktivera replikering i flera regioner på Azure Managed HSM och Katastrofåterställning för Managed HSM.

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 hanterad instans 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-portalenoch söka efter tjänsten Policy. Under Definitionersöker du efter kundhanterad nyckel.

Det finns tre effekter för dessa principer:

  • Audit – 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 är inställd på Neka, kommer skapandet av en logisk Azure SQL-server eller hanterad instans att misslyckas. Information om det här felet registreras i aktivitetsloggen i resursgruppen.

Viktig

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

Relaterat innehåll