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 är nyckeln som används för kryptering av databaskrypteringsnyckeln (DEK), som kallas TDE-skydd, en kundhanterad asymmetrisk nyckel som lagras i en kundägd och kundhanterad 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örs 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 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.
-
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.
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 Key Vault 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 Key Vault 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.
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.
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.
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 Key Vault-administratören ge åtkomstbehörighet till servern med sin unika Microsoft Entra-identitet. 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:
- hämta – för att hämta den offentliga delen och egenskaperna för nyckeln i Nyckelvalvet
- 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 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.
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
Krav för att konfigurera AKV
Mjuk radering och skydd mot rensning måste aktiveras i nyckelvalvet för att skydda mot dataförlust på grund av oavsiktlig borttagning av nycklar (eller nyckelvalvet).
Ge servern eller den hanterade instansen åtkomst till nyckelvalvet (hämta, 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 explicit 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 i nyckelvalvet eller genom att skapa en ny Azure RBAC-rolltilldelning med rollen Key Vault Crypto Service Encryption User.
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, såvida du inte använder privata slutpunkter för AKV-. Mer information finns i Konfigurera Azure Key Vault-brandväggar och virtuella nätverk.
Aktivera skydd mot mjuk borttagning och rensning för AKV
Viktig
Både mjuk borttagning och rensningsskydd måste vara aktiverade på nyckelvalvet när du konfigurerar TDE som hanteras av kunden på en ny eller befintlig server eller hanterad instans.
Mjuk borttagning och rensningsskydd ä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 avsiktligt 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. återställa och rensa åtgärder har sina egna behörigheter associerade med en behörighetspolicy för nyckelvalv. 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 rensningsskydd är aktiverat kan ett valv eller ett objekt i borttaget tillstånd inte rensas förrän kvarhållningsperioden har passerat. Standardkvarhållningsperioden är 90 dagar, men kan konfigureras från 7 till 90 dagar via Azure-portalen.
Azure SQL kräver att mjuk borttagning och rensningsskydd är aktiverade i nyckelvalvet som innehåller krypteringsnyckeln som används som TDE-skyddet för servern eller den hanterade instansen. 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 med 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.
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 måste du ange den i filformat som stöds (
.pfx,.byokeller.backup).
Anteckning
Azure SQL och SQL Server på virtuella Azure-datorer stöder användning av en RSA-nyckel som lagras i ett hanterat 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 och de konfigurations- eller RBAC-behörigheter som krävs för SQL Server via artikeln Konfigurera SQL Server TDE Extensible Key Management med hjälp av Azure Key Vault.
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 vid konfiguration av AKV
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å erfarenheten och dokumenteras i key vault-tjänstbegränsningar. 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: 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.
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 nyckelvalvet 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 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ä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 AKV även efter växling till tjänsthanterade nycklar. Det säkerställer att databassäkerhetskopior kan återställas med de 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. 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 efter nya versioner av nyckeln som används som TDE-skydd. 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 används med automatiserad nyckelrotation i Azure Key Vaultmöjliggör den här funktionen nollberöringsrotation från början till slut för TDE-skyddsprogrammet 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 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 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 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 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 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 AKV börjar en databas på upp till 10 minuter neka alla anslutningar med motsvarande felmeddelande och ändra dess tillstånd till otillgänglig. Den enda åtgärd som tillåts för en databas i otillgängligt tillstånd är att ta bort den.
Anteckning
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. För att minska effekten av nätverksfel eller avbrott vid försök att komma åt TDE-skyddet i Azure Key Vault 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.
När åtkomsten till nyckeln har återställts kräver det extra tid och steg 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:
Anteckning
- Om nyckelåtkomsten återställs inom 30 minuter kommer databasen att självläka under den följande timmen.
- Om nyckelåtkomst återställs efter mer än 30 minuter är automatisk återställning 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 redundansgrupp konfiguration, taggar och inställningar på databasnivå, till exempel konfiguration av elastiska pooler, lässkalning, automatisk paus, återställningshistorik för tidpunkter, 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å i 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-skyddsåtkomst
Det kan hända att någon med tillräcklig åtkomstbehörighet till nyckelvalvet av misstag inaktiverar serveråtkomst till nyckeln genom att:
Att återkalla serverns åtkomsträttigheter för nyckelvalvet hämta, svepNyckeloch avsvepNyckel
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
Nätverksanslutningsblocket mellan SQL Managed Instance och key vault sker främst när nyckelvalvsresursen finns men dess slutpunkt inte kan nås från den hanterade instansen. Alla scenarier där nyckelvalvets slutpunkt kan nås men anslutningen nekas, saknade behörigheter osv., gör att databaserna ändrar dess tillstånd till otillgänglig.
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 nätverkssäkerhetsgruppen (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 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 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 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 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. Därför rekommenderar vi att du behåller alla gamla versioner av TDE-skyddet i nyckelvalvet, så att databassäkerhetskopior kan återställas.
Viktig
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" i Azure Portal-fönstret. 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ä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 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
Eftersom AKV tillhandahåller flera redundanslager kan TDE:er som använder en kundhanterad nyckel dra nytta av AKV-tillgänglighet och motståndskraft och helt förlita sig på AKV-redundanslösningen.
AKV:s flera redundanslager säkerställer nyckelåtkomst även om enskilda tjänstkomponenter misslyckas eller om Azure-regioner eller tillgänglighetszoner är otillgängliga. Mer information finns i tillgänglighet och redundans för Azure Key Vault.
AKV erbjuder följande komponenter för tillgänglighet och motståndskraft som tillhandahålls automatiskt utan användarintervention:
Anteckning
För alla parregioner replikeras AKV-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.
Geo-DR och kundstyrd TDE
I både aktiva geo-replikeringsgrupper och redundansgrupper scenarier kan de primära och sekundära servrarna länkas till Azure Key Vault som finns i valfri region. Servern och nyckelvalvet behöver inte vara indelade i samma region. För enkelhetens skull kan de primära och sekundära servrarna anslutas till samma nyckelvalv (i valfri region). 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 på plats för att se till att nycklar och nyckelvalv förblir tillgängliga vid fel i tjänsten eller regionen. 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 AKV:er i flera regioner.
Använd Hanterad 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 AKV-korsredundansväxling med Azure SQL-konfiguration för geo-replikering med hjälp av en redundansgrupp:
Azure Key Vault-kommentarer för Geo-DR
Både primära och sekundära servrar i Azure SQL har åtkomst till AKV i den primära regionen.
AKV-failover initieras av AKV-tjänsten och inte av kunden.
Om AKV växlar över till den sekundära regionen kan servern i Azure SQL fortfarande komma åt samma AKV. Även om det är internt omdirigeras AKV-anslutningen till AKV i den sekundära regionen.
Nya nyckelskapanden, importer och nyckelrotationer är bara möjliga medan AKV i den primära nyckeln är tillgänglig.
När redundansväxlingen inträffar tillåts inte nyckelrotation förrän AKV i den primära regionen i den kopplade regionen är tillgänglig igen.
Kunden kan inte ansluta till den sekundära regionen manuellt.
AKV är i skrivskyddat tillstånd medan AKV i den primära regionen inte är tillgänglig
Kunden kan inte välja eller kontrollera vilken region som AKV för närvarande finns i.
För icke-parad region har båda Azure SQL-servrarna åtkomst till AKV i den första regionen (som anges i diagrammet) och AKV använder zon-redundant lagring för att replikera data inom regionen, bland oberoende tillgänglighetszoner inom 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. Mer information finns i översikten över redundansgrupper & bästa praxis.
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 HSM-lösning (Managed Hardware Security Modules) via AKV:
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 hanterade HSM-poolen i den andra regionen.
Med 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 Hanterad 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.