Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för: Dedikerade SQL-pooler i Azure Synapse Analytics (tidigare SQL DW)
Tip
Microsoft Fabric Data Warehouse är ett relationslager i företagsskala på en datasjögrund med en framtidsklar arkitektur, inbyggd AI och nya funktioner. Om du är nybörjare på datalager börjar du med Fabric Data Warehouse. Befintliga dedicerade SQL-poolarbetsbelastningar kan uppgraderas till Fabric för att få åtkomst till nya funktioner inom datavetenskap, realtidsanalys och rapportering.
Transparent datakryptering (TDE) med kundhanterad nyckel (CMK) möjliggör Bring Your Own Key (BYOK)-scenariot för dataskydd i vila och gör det möjligt för organisationer att implementera ansvarsfördelning i hanteringen av nycklar och data. Genom att använda kundhanterad TDE tar du ansvar för och har full kontroll över nyckellivscykelhanteringen (nyckelskapande, uppladdning, rotation, radering), nyckelanvändningsbehörigheter och granskning av operationer 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.
Note
Den här artikeln handlar om fristående dedikerade SQL-pooler (tidigare SQL DW).
- För Azure Synapse Analytics dedikerade SQL-pooler (tidigare SQL DW), ställ in TDE-skyddet på servernivå. Alla krypterade databaser kopplade till den servern ärver TDE-skyddet.
- Kryptera data i dedikerade SQL-pooler och serverlösa SQL-pooler i en Synapse-arbetsyta genom att använda den kundhanterade nyckeln konfigurerad på arbetsytnivå. Mer information om transparent datakryptering för dedikerade SQL-pooler i Synapse-arbetsytor finns i Azure Synapse Analytics-kryptering.
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) – Du hanterar nyckellivscykeln, inklusive nyckelskapande, rotation och radering. Lagra nyckeln i Azure Key Vault eller Azure Managed HSM och använd den för kryptering av databaskrypteringsnyckeln (DEK).
Ta med egen nyckel (BYOK) – Du kan på ett säkert sätt ta med eller importera din egen nyckel från en lokal hårdvarusäkerhetsmodul (HSM) till Azure Key Vault. 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 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.
Important
För dem som använder servicemanaged TDE och vill börja använda kundhanterad TDE, förblir data krypterad under övergången, och det blir inget driftstopp 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 i Azure Key Vault
Välj den typ av Azure Key Vault som du vill använda.
För att SQL-logiska servern i Azure ska använda TDE-skyddet som lagras i Azure Key Vault för kryptering av DEK, måste Key Vault Administrator ge åtkomsträttigheter till servern genom att använda 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. Serveridentiteten behöver rollen Key Vault Crypto Service Encryption User för att använda nyckeln för krypterings- och dekrypteringsoperationer.
Å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 behöver följande behörigheter på 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. För steg-för-steg-instruktioner för att ställa in en Azure Key Vault-åtkomstkonfiguration för TDE, se Set up SQL Server TDE Extensible Key Management by using 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 du konfigurerar en server att använda ett TDE-skydd från Azure Key Vault, skickar servern DEK:n för varje TDE-aktiverad databas till nyckelvalvet för kryptering. Nyckelvalvet returnerar den krypterade DEK:n, som servern lagrar i användardatabasen.
Vid behov skickar servern den skyddade DEK:n till nyckelvalvet för dekryptering.
Revisorer kan använda Azure Monitor för att granska nyckelvalvs AuditEvent-loggar om loggning är aktiverad.
Note
Det kan ta ungefär 10 minuter innan eventuella behörighetsändringar träder i kraft för nyckelvalvet. Denna gång inkluderar återkallelse av åtkomstbehörigheter till TDE-skyddet i AKV, och användare kan fortfarande ha åtkomsträttigheter.
Krav för att konfigurera kundhanterad TDE i Azure Key Vault
Aktivera mjuk borttagning och rensningsskydd på Azure Key Vault. Denna konfiguration hjälper till att förhindra oavsiktlig eller skadlig radering av nyckelvalvet eller nyckeln som kan leda till att databasen hamnar i tillståndet Otillgänglig. När du konfigurerar TDE-skyddet på en befintlig server eller under serverskapandet validerar Azure SQL att nyckelvalvet du använder har mjuk radering 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 detta fall, aktivera mjuk borttagning och rensningsskydd på nyckelvalvet, och konfigurera sedan TDE-skyddet.
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-skyddet, lagrad i Azure Key Vault för att skydda databasens krypteringsnyckel (DEK).
Följande krav gäller.
Nyckeltyper och storlekar som stöds
TDE-skyddet kan backas upp av asymmetriska nycklar som lagras i Azure Key Vault. Stödda nyckelstorlekar är 2 048-bitars och 3 072-bitars.
Krav på nyckelstatus och giltighet
- Om du anger ett aktiveringsdatum för nyckeln, ställ in det till ett datum och en tid i det förflutna.
- Om du anger ett utgångsdatum för nyckeln, ställ in det till 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
Rekommendationer för att konfigurera kundhanterad TDE i Azure Key Vault
Följ dessa riktlinjer per prenumeration för att upprätthålla hög tillgänglighet och undvika begränsningsproblem:
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 Vault-vägledning om begränsning.
Antalet Hyperscale-databaser som du kan koppla till en enda Azure Key Vault beror på antalet sidservrar. Varje sidserver är länkad till en logisk datafil. För att fastställa antalet sidservrar, kör följande fråga.
-- # 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. För mer information om övervakning och varningar, se Övervaka Azure Key Vault och Konfigurera Azure Key Vault-aviseringar.
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. För att lära dig 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.
Rekommendationer för att konfigurera TDE-skydd
Förvara en kopia av TDE-skyddet på en säker plats eller deponera det hos en depositionstjänst.
Om du genererar nyckeln i nyckelvalvet, skapa en nyckelbackup innan du använder nyckeln i Azure Key Vault för första gången. Du kan återställa backupen endast till ett Azure Key Vault. För att lära dig mer, se kommandot Backup-AzKeyVaultKey. Azure Managed HSM stödjer att skapa en fullständig backup av hela innehållet i HSM:n, 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 backup varje gång du gör några ändringar i nyckeln (till exempel nyckelattribut, taggar, ACL).
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 även efter att du bytt till service-managed nycklar. Den säkerställer att databasbackuper kan återställas med TDE-skydd som lagras i Azure Key Vault. TDE-skydd skapade med Azure Key Vault måste underhållas tills alla återstående lagrade säkerhetskopior har skapats med service-managed nycklar. Gör återställbara kopior av dessa nycklar genom att använda 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.
Rotation av TDE-skydd
När du roterar TDE-skyddet ersätter du nyckeln som skyddar databasens krypteringsnyckel (DEK). Nyckelrotation är en online-operation och tar bara några sekunder. Denna operation dekrypterar och återkrypterar endast databasens krypteringsnyckel, inte hela databasen.
Du kan rotera TDE-skyddet genom att byta konfiguration till att använda en ny nyckel som lagras i Azure Key Vault. Beroende på erbjudandet och den stödda konfigurationen kan denna nyckel vara:
- Växla till en ny nyckelversion av samma nyckel
- Växla till en annan nyckel
Rotationen av TDE-skyddet kan göras manuellt eller genom att använda den automatiska rotationsfunktionen.
Du kan aktivera automatisk rotation av TDE-skyddet när du konfigurerar TDE-skyddet för servern. Automatisk rotation är inaktiverad som standard. När den är aktiverad kontrollerar servern kontinuerligt nyckelvalvet för nya versioner av nyckeln som används som TDE-skyddet. Om servern upptäcker en ny version av nyckeln roterar den automatiskt TDE-skyddet på servern eller databasen till den senaste nyckelversionen inom 24 timmar.
Note
När du ställer in TDE med CMK genom manuell eller automatiserad rotation av nycklar använder du alltid den senaste versionen av nyckeln som systemet stödjer. 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.
Otillgängligt TDE-skydd
När du konfigurerar TDE att använda en kundhanterad nyckel behöver databasen kontinuerlig åtkomst till TDE-skyddet för att förbli online. Om servern förlorar åtkomst till det kundhanterade TDE-skyddet i Azure Key Vault börjar databasen neka alla anslutningar inom 10 minuter, visar ett felmeddelande och ändrar sitt 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 introducerar tjänsten en 24-timmars buffert innan den 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 åtkomst till det kundhanterade TDE-skyddet i Azure Key Vault på grund av något Azure Key Vault-fel (såsom ett 4XX-fel), går databasen över till ett otillgängligt tillstånd efter 30 minuter.
Återställ databasåtkomst efter ett Azure Key Vault-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.
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
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 är:
Azure Key Vault är exponerat via en privat endpoint och den privata IP-adressen för Azure Key Vault-tjänsten är inte tillåten i utgående regler för Network Security Group (NSG) som är kopplad till undernätet för den hanterade instansen.
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 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-test ska vara TcpTestSucceeded: True.
Om testet ger TcpTestSucceeded: False ska du granska nätverkskonfigurationen:
Kontrollera den lösta IP-adressen och bekräfta att den är giltig. Ett värde som saknas innebär att det finns problem med DNS-matchning.
Bekräfta att nätverkssäkerhetsgruppen på den hanterade instansen har en regel för utgående trafik som täcker den lösta IP-adressen på port 443, särskilt när den lösta adressen tillhör nyckelvalvets 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 förlorade åtkomst till TDE-skyddet visas som "Ej tillgänglig" efter att den första anslutningen till databasen nekats.
Aktivitetslogg när åtkomsten till TDE-skyddet i det kundhanterade nyckelvalvet misslyckas, läggs poster till i aktivitetsloggen. Genom att skapa varningar för dessa händelser kan du återställa åtkomsten så snart som möjligt.
Action Groups kan definieras för att skicka dig notiser och aviseringar baserat på dina preferenser, till exempel e-post, SMS, Push, röst, Logic App, Webhook, ITSM eller Automation Runbook.
Databasbackup och återställning med kundhanterad TDE
När en databas har krypterats med TDE med en nyckel från Azure Key Vault, krypteras även alla nygenererade säkerhetskopior med samma TDE-skydd. När TDE-skyddet ändras uppdateras inte gamla säkerhetskopior av databasen för att använda det senaste TDE-skyddet.
Om du vill återställa en säkerhetskopia som krypterats med ett TDE-skydd från Azure Key Vault kontrollerar du att nyckelmaterialet är tillgängligt för målservern. Därför ska alla gamla versioner av TDE-skyddet behållas i Key Vault eller i hanterad HSM, så att säkerhetskopior av databasen kan återställas.
Important
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 är krypterad med den nyckel som har 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 dedikerade SQL-pooler i Azure Synapse Analytics finns i Återställa en dedikerad SQL-pool.
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 denna nyckel vid återställningstid, även om databasen har ändrats till att använda service-managed TDE under tiden.
Hög tillgänglighet med kundhanterad TDE (Transparent Data Encryption)
Genom att använda Azure Key Vault:s flera lager av redundans kan TDE:er som använder en kundhanterad nyckel dra nytta av Azure Key Vault:s tillgänglighet och motståndskraft. De kan lita fullt ut på redundanslösningen i Azure Key Vault.
De många redundanslagren i Azure Key Vault säkerställer nyckelåtkomst även om enskilda tjänstekomponenter slutar fungera eller 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 av tillgänglighet och motståndskraft automatiskt utan användaringripande: