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 detta scenario är Transparent Data Encryption (TDE)-skyddet en kundhanterad nyckel som säkrar databaskrypteringsnyckeln (DEK). Du lagrar TDE-skyddet antingen i Azure Key Vault eller Azure Key Vault Managed HSM, som är säkra molnbaserade nyckelhanteringstjänster utformade för hög tillgänglighet och skalbarhet. Båda tjänsterna stöder kryptografiska nycklar skyddade av FIPS 140-2-validerad hårdvara: Azure Key Vault stöder FIPS 140-2 nivå 2, och Azure Key Vault Managed HSM stöder FIPS 140-2 nivå 3. Båda tjänsterna stöder också asymmetriska och symmetriska nyckeltyper, och de stödda algoritmerna och användningen beror på TDE-distributionsmodellen. Du kan generera nyckeln i tjänsten, importera den eller säkert överföra den från lokala HSM:er. Direkt åtkomst till nycklar är begränsad, så auktoriserade tjänster utför kryptografiska operationer 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 den här artikeln, 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å.

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)). Mer information 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).

Kundhanterad nyckel (CMK) och BYOK (Bring Your Own Key)

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).

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.

  • 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 använda TDE-skyddet som lagras i Azure Key Vault för kryptering av DEEK måste Key Vault Administrator ge åtkomsträttigheter till servern med dess 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.

Viktiga krav för att konfigurera TDE-skydd

Transparent Data Encryption med kundhanterade nycklar använder en extern nyckel, kallad TDE-skydd, lagrad i Azure Key Vault eller Azure Managed HSM för att skydda databasens krypteringsnyckel (DEK).

Följande krav gäller.

Nyckeltyper och storlekar som stöds

Beroende på Azure SQL-erbjudandet och TDE-konfigurationen kan TDE-skyddet backas upp av antingen asymmetriska eller symmetriska nycklar som lagras i Azure Key Vault eller Azure Key Vault Managed HSM.

  • Asymmetriska nycklar (RSA eller RSA HSM)

    • Stöds i Azure Key Vault och Azure Key Vault Managed HSM
    • Stödda nyckelstorlekar: 2 048-bit och 3 072-bit
    • Stödd för Azure SQL Database, Azure SQL Managed Instance och Azure Synapse Analytics

  • Symmetriska nycklar (AES)

    • Stöds i Azure Key Vault Premium (preview) och Azure Key Vault Managed HSM
    • Stödda nyckelstorlekar: 128-bitars, 192-bitars och 256-bitars
    • Stöds endast för Azure SQL Database, för närvarande i offentlig förhandsvisning

Anteckning

Transparent Data Encryption med symmetriska nycklar (AES) är för närvarande i förhandsvisning. Förhandsvisningsfunktioner släpps med begränsade möjligheter, men Microsoft gör dem tillgängliga som förhandsvisning så att kunder kan få tidig tillgång och ge feedback. Förhandsgranskningsfunktioner omfattas av separata kompletterande förhandsversionsvillkoroch omfattas inte av serviceavtal. Support tillhandahålls som bästa möjliga insats i vissa fall. Microsoft Support är dock angelägen om att få feedback om förhandsversionsfunktionerna och kan ge bästa möjliga stöd i vissa fall. Förhandsgranskningsfunktioner kan ha begränsade eller begränsade funktioner och kan endast vara tillgängliga i valda geografiska områden.

Nyckelhanteringsbeteende för symmetriska (AES) nycklar

Du kan använda symmetriska (AES) nycklar lagrade i Azure Key Vault Premium (förhandsvisning) eller Azure Key Vault Managed HSM som TDE-skydd. För att komma igång med en nyckel från en lokal hårdvarusäkerhetsmodul (HSM), importera nyckeln till någon av tjänsterna. Efter den initiala importen sker alla pågående nyckellivscykeloperationer i Azure Key Vault Premium (förhandsvisning) eller Azure Key Vault Managed HSM. Punkt-i-tid-återställning, geokatastrofåterställning och nyckelvalidering beror alla på vilken nyckel som finns tillgänglig där. Underhåll lokala säkerhetskopior av importerade nycklar för att stödja återställnings- och valideringsscenarier. Detta beteende gäller endast symmetriska (AES) nycklar, inte asymmetriska (RSA) nycklar.

Krav på nyckelstatus och giltighet

  • Om ett aktiveringsdatum för en nyckel har angetts måste det vara inställt på ett datum och klockslag i det förflutna.
  • Om ett förfallodatum för en nyckel har angetts måste det vara inställt på ett datum och en tid i framtiden.
  • Nyckeln måste vara i tillståndet Aktiverad.

Krav för nyckelimport

Om du importerar en befintlig nyckel till Azure Key Vault, tillhandahåll nyckeln i något av följande stödda format:

  • .pfx
  • .byok
  • .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 i Viktig information om CipherTrust Cloud Key Manager. 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 för att konfigurera kundhanterad TDE

  • För att säkerställa optimal prestanda och tillförlitlighet, använd ett dedikerat Azure Key Vault för Azure SQL. Dela inte detta nyckelvalv med andra tjänster. Om nyckelvalvet är under stor belastning på grund av delad användning eller överdriven nyckelhantering kan det påverka databasens prestanda negativt, särskilt vid åtkomst till krypteringsnyckeln. Azure Key Vault tillämpar begränsningsgränser. När dessa gränser överskrids kan åtgärder fördröjas eller misslyckas. Denna risk är störst vid serverfailovers, som utlöser nyckeloperationer för varje databas på servern.

    Mer information om begränsningsbeteende finns i Azure Key Vaults vägledning för begränsning.

    Följ dessa riktlinjer per prenumeration för att upprätthålla hög tillgänglighet och undvika begränsningsproblem:

    • Använd ett dedikerat Azure Key Vault för Azure SQL-resurser.

    • Associera högst 500 databaser för generell användning med ett enda Azure Key Vault.

    • Associera högst 200 affärskritiska databaser med ett enda Azure Key Vault.

    • Antalet Hyperskala-databaser som kan associeras med ett enda Azure Key Vault bestäms av antalet sidservrar. Varje sidserver är länkad till en logisk datafil. Kör följande fråga för att hitta antalet sidservrar.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Associera inte fler än 500 sidoservrar med ett enda Azure Key Vault. När databasen växer ökar antalet sidservrar automatiskt, så det är viktigt att övervaka databasstorleken regelbundet. Om antalet sidservrar överstiger 500, använd ett dedikerat Azure Key Vault för varje Hyperscale-databas och dela inte det nyckelvalvet med andra Azure SQL-resurser.

    • Övervaka och konfigurera Azure Key Vault-aviseringar. Mer information om övervakning och aviseringar finns i Övervaka Azure Key Vault och Konfigurera Azure Key Vault-aviseringar.

  • För att anpassa dig till långsiktig planering för kryptografisk resiliens, överväg att använda AES-256 symmetriska nycklar som TDE-skydd.

    Storskalig kvantberäkning förväntas bryta public-key kryptografiska algoritmer som RSA. Symmetrisk kryptografi, inklusive AES, anses kvantresistent vid tillräckligt stora nyckelstorlekar.

    Microsoft bredare kvantsäkra säkerhetsstrategi betonar kryptoagilitet. Anta starkare symmetriska algoritmer där de stöds och planera för framtida kryptografiska övergångar i takt med att riktlinjer och standarder utvecklas.

    Viktig

    Transparent Data Encryption med symmetriska nycklar (AES) stöds för närvarande endast för Azure SQL Database och är i offentlig förhandsversion.

  • 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 för att konfigurera 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 Managed HSM när du roterar nycklar, så att du kan återställa äldre databasbackuper. 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. Rotera nycklarna genom att följa instruktionerna i artikeln Rotera skyddet för transparent datakryptering (TDE).

  • 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 i artikeln Ta bort ett transparent datakrypteringsskydd (TDE) med PowerShell. Rotera alltid till ett nytt TDE-skydd och kontrollera att alla databaser använder den nya nyckeln innan du tar bort eller inaktiverar den komprometterade nyckeln. Att radera eller inaktivera nyckeln utan att först rotera gör att alla krypterade databaser blir otillgängliga, och ogiltigförklarar inte några nyckelkopior som tidigare säkerhetskopierats och återställts till ett annat valv.

Tips/Råd

Använda versionsbaserade och versionslösa Azure Key Vault-nycklar för TDE

När du anger TDE-skyddet kan du referera till en Azure Key Vault-nyckel med antingen en specifik nyckelversion eller en versionslös nyckelidentifierare.

I båda fallen löser Azure SQL Database alltid och använder den senaste aktiverade versionen av nyckeln i Azure Key Vault eller Azure Key Vault Managed HSM. Använd versionslösa nyckelidentifierare för att undvika att bädda in en specifik nyckelversion i TDE-skyddskonfigurationen.

Versionslösa nyckelidentifierare stöds för närvarande endast för Azure SQL Database.

Exempel:

  • Nyckelidentifierare som innehåller en specifik version

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Versionslös nyckelidentifierare

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Rotation av TDE-skydd

Genom att rotera TDE-skyddet kan du ersätta den nyckel som används för att skydda databaskrypteringsnyckeln (DEK). 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.

Du kan rotera TDE-skyddet genom att växla konfigurationen till att använda en ny nyckel som lagras i Azure Key Vault eller Azure Key Vault Managed HSM. Beroende på vilket Azure SQL erbjudande och vilken konfiguration som stöds kan följande vara:

  • Växla till en ny nyckelversion av samma nyckel
  • Växla till en annan nyckel
  • Växla mellan nyckeltyper som stöds, till exempel asymmetriska nycklar (RSA) och symmetriska nycklar (AES)

Anteckning

Transparent Data Encryption med symmetriska nycklar (AES) stöds för närvarande endast för Azure SQL Database och är i offentlig förhandsversion.

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 aktiveras kontrollerar servern kontinuerligt nyckelvalvet eller Managed HSM för 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 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 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 på den sekundära servern.

  • Georeplikeringsscenarier med 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 introduceras en 24-timmarsbuffert 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.

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

Skärmbild av en 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, saknar behörigheter osv., gör att databaserna ändrar sitt 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.

Övervaka den kundhanterade TDE:n

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 "Ej tillgä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 från en säkerhetskopia i Azure 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 Azure SQL Managed Instance med SSMS.

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.

Geokatastrofåterställning med kundhanterad TDE

Aktiv geografisk replikering och failover-grupper stöder kundhanterad TDE. De primära och sekundära servrarna kan använda en Azure Key Vault eller Azure Managed HSM i vilken stödd region som helst. Serverna och nyckelbutiken behöver inte ligga i samma region.

För en lyckad failover måste båda servrarna ha tillgång till varje Azure Key Vault eller Azure Managed HSM som innehåller en nödvändig nyckel.

Att tänka på vid konfigurationen

Följande överväganden gäller när du konfigurerar aktiv geo-replikering eller en failover-grupp i Azure-portalen:

  • TDE-skyddsplats: De primära och sekundära servrarna kan använda samma Azure Key Vault eller Azure Managed HSM. Att använda samma nyckellagring minskar risken att nyckelmaterial blir ur synk. Om du använder separata nyckelvalv i flera regioner måste du hålla det nödvändiga nyckelmaterialet synkroniserat. För information om key-store-resiliens, se Azure Key Vault tillgänglighet och redundans samt Multi-region-replikering i Managed HSM.

  • Zonredundans: Där det finns tillgängligt ger zonredundans för Azure SQL Database eller Azure SQL Managed Instance extra motståndskraft inom en region. Mer information finns i Vad är Azure-tillgänglighetszoner?.

  • Nyckelbehörigheter: Både primära och sekundära servrar måste ha de nödvändiga behörigheterna på varje Azure Key Vault eller Azure Managed HSM som innehåller ett nödvändigt TDE-skydd.

  • Nyckeltillgänglighet: Säkerställ att de nödvändiga nycklarna finns tillgängliga på både primär- och sekundärservrarna. Servrarna behöver inte använda identiska TDE-skydd, men varje server måste ha samma nyckelmaterial. Du kan lägga till nycklar till en server genom att använda Azure-portalen, PowerShell, Azure CLI eller Azure SQL REST API. Om de nödvändiga nycklarna inte finns tillgängliga vid failover-tillfället kan databasen bli otillgänglig.

  • Privata endpoints: Konfigurationen kan kräva en mer komplex DNS-zon om du använder privata endpoints i Azure SQL (till exempel kan den inte skapa två privata endpoints till samma resurs i samma DNS-zon).

  • Applikationsanslutning: Applikationer bör använda retry-logik för att hantera tillfälliga fel under failover.

Mer information om hur du konfigurerar resursen för geo-haveriberedskap i Azure SQL finns i Active geo-replication eller Översikt över redundansgrupper och bästa praxis.

Viktig

När du skapar en geo-replikationslänk eller failover-grupp validerar Azure SQL att båda servrarna kan komma åt alla nödvändiga kundhanterade nycklar. Om någon av servrarna inte kan komma åt en nödvändig nyckel misslyckas skapandeoperationen. Till exempel, om primära och sekundära servrar använder Nyckel A respektive Nyckel B, lägg till båda nycklarna på båda servrarna innan geo-replikeringslänken eller failovergruppen skapas.

Följande diagram visar Azure SQL-georeplikering med en redundansväxlingsgrupp och regional redundansväxling för Azure Key Vault i en konfiguration med regionpar:

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

Hur Azure Key Vault fungerar vid failover

  • Azure Key Vault initierar failovern, inte du.
  • Medan nyckelvalvet i primärregionen är otillgängligt, är nyckelvalvet skrivskyddat.
  • Du kan skapa, importera och rotera nycklar endast medan nyckelvalvet i primärregionen är tillgängligt. Efter en failover förblir nyckelrotationen blockerad tills primärregionen åter kan nås.
  • Du kan inte välja eller kontrollera vilken region nyckelvalvet befinner sig i, och du kan inte ansluta till den sekundära regionen manuellt.

Återhämta från ett otillgängligt TDE-skydd

Om en databas i en aktiv geo-replikationsrelation eller failover-grupp blir otillgänglig, bryter Azure SQL-kontrollplanet länken och konverterar databasen till en fristående databas.

Efter att du återställt nyckelbehörigheter kan du vanligtvis återställa huvuddatabasen online. Du kan inte ta den sekundära databasen online igen eftersom Azure SQL inte tar fullständiga säkerhetskopior av sekundära databaser. Ta bort sekundärdatabasen och återupprätta sedan länken för georeplikering eller redundansgruppen.

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:

  • 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 skapandet av en logisk Azure SQL-server eller en hanterad instans. Information om det här felet registreras i aktivitetsloggen för resursgruppen.

Viktig

Tidigare versioner av inbyggda principer för kundhanterad TDE som innehåller effekten AuditIfNotExists är inaktuella. Befintliga principtilldelningar med de inaktuella principerna påverkas inte och fortsätter att fungera som tidigare.

Relaterat innehåll

  • Last updated on