Dela via

Kundhanterade nycklar i Azure Monitor

Azure Monitor krypterar data med hjälp av Microsoft-hanterade nycklar. Du kan använda din egen krypteringsnyckel för att skydda data på dina arbetsytor. Genom att använda kundhanterade nycklar i Azure Monitor styr du krypteringsnyckelns livscykel och åtkomst till loggar. När du har konfigurerat kundhanterade nycklar krypteras nya data som matas in till länkade arbetsytor med hjälp av din nyckel i Azure Key Vault eller Azure Key Vault Managed HSM (Maskinvarusäkerhetsmodul).

Översikt över kundhanterad nyckel

Kryptering av lagrad data är ett vanligt krav på integritet och säkerhet i organisationer. Du kan låta Azure helt hantera kryptering i vila eller använda olika alternativ för att hantera krypterings- och krypteringsnycklar på ett nära sätt.

Azure Monitor ser till att alla data och sparade frågor krypteras i vila med hjälp av Microsoft-hanterade nycklar (MMK). Azure Monitors användning av kryptering är identisk med hur Azure Storage-kryptering fungerar.

Om du vill styra nyckellivscykeln och återkalla åtkomsten till data krypterar du data med hjälp av din egen nyckel i Azure Key Vault eller Azure Key Vault Managed HSM. Funktionen kundhanterade nycklar är tillgänglig i dedikerade kluster och ger en högre skyddsnivå och kontroll.

Data som matas in till dedikerade kluster krypteras två gånger – på tjänstnivå med hjälp av Microsoft-hanterade nycklar eller kundhanterade nycklar och på infrastrukturnivå med hjälp av två olika krypteringsalgoritmer och två olika nycklar. Dubbel kryptering skyddar mot ett scenario där en av krypteringsalgoritmerna eller nycklarna komprometteras. Med dedikerade kluster kan du också skydda data med hjälp av Lockbox.

Data som matats in under de senaste 14 dagarna, eller som nyligen använts i frågor, sparas i frekvent cache (SSD-backad) för frågeeffektivitet. Azure Monitor krypterar SSD-data med hjälp av Microsoft-hanterade nycklar oavsett om du konfigurerar kundhanterade nycklar, men din kontroll över SSD-åtkomsten följer nyckelåterkallningen.

Viktigt!

Dedikerade kluster använder en prismodell på åtagandenivå på minst 100 GB per dag.

Så här fungerar kundhanterade nycklar i Azure Monitor

Azure Monitor använder hanterad identitet för att ge åtkomst till din nyckel i Azure Key Vault. Identiteten för Log Analytics-kluster stöds på klusternivå. För att tillhandahålla kundhanterade nycklar på flera arbetsytor fungerar en log analytics-dedikerad klusterresurs som en mellanliggande identitetsanslutning mellan ditt Key Vault och dina Log Analytics-arbetsytor. Klustrets lagring använder den hanterade identitet som är associerad med klustret för att autentisera till ditt Azure Key Vault via Microsoft Entra-ID.

Kluster stöder två hanterade identitetstyper: systemtilldelade och användartilldelade.

  • Systemtilldelad hanterad identitet är enklare och genereras automatiskt med klustret när du anger identitytype till SystemAssigned. Använd den här identiteten för att ge klusterlagringsåtkomst till ditt Key Vault för datakryptering och dekryptering.
  • Med användartilldelad hanterad identitet kan du konfigurera kundhanterade nycklar när klustret skapas, när du anger identitytype till UserAssigned, och ge den behörigheter i nyckelvalvet innan klustret skapas.

Konfigurera kundhanterade nycklar i ett nytt kluster eller ett befintligt dedikerat kluster med länkade arbetsytor som matar in data. Du kan när som helst ta bort länken mellan arbetsytor från ett kluster. Nya data som matas in till länkade arbetsytor krypteras med din nyckel och äldre data förblir krypterade med Microsoft-hanterade nycklar. Konfigurationen avbryter inte inmatning eller frågor, där frågor utförs sömlöst över gamla och nya data. När du avlänkar arbetsytor från ett kluster krypteras nya data som matas in med Microsoft-hanterade nycklar.

Viktigt!

Funktionen för kundhanterade nycklar är regional. Ditt Azure Key Vault, dedikerade kluster och länkade arbetsytor måste finnas i samma region, men de kan finnas i olika prenumerationer.

Skärmbild av översikt över kundhanterad nyckel.

  1. Nyckelvalv
  2. Log Analytics-klusterresurs som har en hanterad identitet med behörighet till Key Vault – identiteten sprids till den underliggande dedikerade klusterlagringen
  3. Dedikerat kluster
  4. Arbetsytor som är länkade till dedikerade kluster

Krypteringsnyckeltyper

Kryptering av lagringsdata använder tre typer av nycklar:

  • KEK – Nyckelkrypteringsnyckel (din kundhanterade nyckel)
  • AEK – Kontokrypteringsnyckel
  • DEK – datakrypteringsnyckel

Följande regler gäller:

  • Klusterlagringen har en unik krypteringsnyckel för varje lagringskonto, vilket kallas AEK.
  • AEK genererar DEK:er, som är de nycklar som krypterar varje datablock som skrivs till disken.
  • När du konfigurerar den kundhanterade KEK i klustret skickar klusterlagringen wrap och unwrap begäranden till din Key Vault för AEK-kryptering och dekryptering.
  • Din KEK lämnar aldrig ditt Key Vault. Om du lagrar din nyckel i en Hanterad HSM för Azure Key Vault lämnar den aldrig heller maskinvaran.
  • Azure Storage använder den hanterade identitet som är associerad med klustret för autentisering. Den kommer åt Azure Key Vault via Microsoft Entra-ID.

Behörigheter som krävs

Om du vill utföra de klusterrelaterade åtgärder som krävs för att etablera och hantera kundhanterade nycklar för ett dedikerat kluster behöver du följande behörigheter:

Åtgärd Behörigheter eller roller som behövs
Skapa ett dedikerat kluster Microsoft.Resources/deployments/* och Microsoft.OperationalInsights/clusters/write behörigheter
Till exempel, enligt den inbyggda rollen Log Analytics Contributor
Ändra klusteregenskaper Microsoft.OperationalInsights/clusters/write behörigheter, som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel
Länka arbetsytor till ett kluster Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write, och Microsoft.OperationalInsights/workspaces/linkedservices/write behörigheter som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel
Kontrollera status för arbetsytans länk Microsoft.OperationalInsights/workspaces/read behörigheter till arbetsytan, som tillhandahålls av log analytics-läsarens inbyggda roll, till exempel
Hämta kluster eller kontrollera etableringsstatus för ett kluster Microsoft.OperationalInsights/clusters/read behörigheter, som tillhandahålls av log analytics-läsarens inbyggda roll, till exempel
Uppdatera åtagandenivå eller billingType i ett kluster Microsoft.OperationalInsights/clusters/write behörigheter, som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel
Bevilja nödvändiga behörigheter Ägar- eller deltagarroll som har */write behörigheter, eller den inbyggda rollen Log Analytics-deltagare, som har Microsoft.OperationalInsights/* behörigheter
Ta bort länken till en arbetsyta från klustret Microsoft.OperationalInsights/workspaces/linkedServices/delete behörigheter, som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel
Ta bort ett dedikerat kluster Microsoft.OperationalInsights/clusters/delete behörigheter, som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel

Provisioneringssteg för kundhanterade nycklar

Följ de här stegen för att konfigurera kundhanterade nycklar i ett dedikerat kluster:

  1. Skapa eller tilldela Azure Key Vault KEK (lagringsnyckel)
  2. Matcha typer av hanterade identiteter för dedikerade kluster till Key Vault-åtkomst
  3. Bevilja Key Vault-behörigheter till den hanterade identiteten
  4. Uppdatera dedikerat kluster med information om nyckelidentifierare
  5. Verifiera dedikerad klusteretablering
  6. Länka arbetsytor till det dedikerade klustret

Skapa eller tilldela Azure Key Vault KEK (lagringsnyckel)

En portfölj med Azure Key Management-produkter visar de valv och hanterade HSM:er som du kan använda.

Skapa eller använd ett befintligt Azure Key Vault i den region där det dedikerade klustret finns eller där du planerar att det ska finnas. Generera eller importera en nyckel till ditt Azure Key Vault som ska användas för loggkryptering. Du måste konfigurera Azure Key Vault som återställningsbart för att skydda din nyckel och åtkomsten till dina data i Azure Monitor. Du kan verifiera den här konfigurationen under egenskaper i ditt Key Vault. Aktivera både mjuk borttagning och rensningsskydd.

Viktigt!

Konfigurera meddelanden via Azure Event Grid för att effektivt svara på Azure Key Vault-händelser, till exempel en nyckel som snart upphör att gälla. När nyckeln upphör att gälla påverkas inte inmatning och frågor, men du kan inte uppdatera nyckeln i klustret. Följ dessa steg för att lösa det:

  1. Identifiera nyckeln som används på klustrets översiktssida i Azure-portalen under JSON-vy.
  2. Utöka nyckelns förfallodatum i Azure Key Vault.
  3. Uppdatera klustret med den aktiva nyckeln, helst med versionsvärdet '', för att alltid använda den senaste versionen automatiskt.

Skärmbild av inställningar för skydd mot mjuk borttagning och rensning.

Du kan uppdatera de här inställningarna i Key Vault med hjälp av CLI och PowerShell:

Matcha hanterade identitetstyper för dedikerat kluster med Key Vault-åtkomst

Dedikerade kluster använder sin hanterade identitet för att få åtkomst till din Key Vault KEK för att kryptera data. Den hanterade identitetstypen för det dedikerade klustret måste matcha rolltilldelningsidentiteten för Key Vault för att tillåta datakryptering och dekrypteringsåtgärder.

Ange egenskapen identitytype till SystemAssigned eller UserAssigned när du skapar klustret.

Lägg till exempel till följande värden i begärandetexten för att skapa ett kluster med en systemtilldelad hanterad identitet:

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Anteckning

Du kan ändra identitetstypen när du har skapat klustret utan att avbryta inmatningen eller frågorna, med följande överväganden:

  • Du kan inte uppdatera identiteten och nyckeln samtidigt för ett kluster. Uppdatera dem i två på varandra följande operationer.
  • När du uppdaterar SystemAssigned till UserAssigned, bevilja UserAssigned identitet i Key Vault och uppdatera sedan i det dedikerade klustret.
  • När du uppdaterar UserAssigned till SystemAssigned, bevilja SystemAssigned identitet i Key Vault och uppdatera sedan i det dedikerade klustret.

Mer information om hur du skapar ett dedikerat kluster finns i Skapa och hantera ett dedikerat kluster.

Bevilja Key Vault-behörigheter till den hanterade identiteten

Key Vault har två behörighetsmodeller för att bevilja åtkomst till ditt dedikerade kluster och underliggande lagring: Rollbaserad åtkomstkontroll i Azure (Azure RBAC – rekommenderas) och Åtkomstprinciper för valv (äldre).

  1. Tilldela Azure RBAC (rekommenderas)

    Om du vill lägga till rolltilldelningar måste du ha en roll med Microsoft.Authorization/roleAssignments/write och Microsoft.Authorization/roleAssignments/delete behörigheter, till exempel administratör för användaråtkomst eller ägare.

    1. Öppna ditt Key Vault i Azure-portalen och välj Inställningar>Åtkomstkonfiguration>Rollbaserad åtkomstkontroll i Azure och Tillämpa.
    2. Välj Gå till åtkomstkontroll (IAM) och lägg till rolltilldelningen Key Vault Crypto Service Encryption User .
    3. Välj Hanterad identitet på fliken Medlemmar och välj prenumerationen för identitet och identiteten som medlem.

    Skärmbild av Bevilja RBAC-behörigheter för Key Vault.

  2. Tilldela åtkomstprincip för valv (äldre)

    Öppna ditt Key Vault i Azure-portalen och välj Åtkomstprinciper>Valvåtkomstprincip>+ Lägg till åtkomstprincip för att skapa en princip med följande inställningar:

    • Nyckelbehörigheter – välj Hämta>omslutningsnyckel och Packa upp nyckel.
    • Välj ett huvudnamn beroende på den identitetstyp som används i klustret (system eller användartilldelad hanterad identitet)
      • Systemtilldelad hanterad identitet – ange klusternamnet eller klustrets huvudnamns-ID
      • Användartilldelad hanterad identitet – ange identitetsnamnet

    Skärmbild av Bevilja åtkomstprincipbehörigheter för Key Vault.

    Behörigheten Hämta krävs för att verifiera att ditt Key Vault är konfigurerat som återställningsbart för att skydda din nyckel och åtkomsten till dina Azure Monitor-data.

Uppdatera dedikerat kluster med information om nyckelidentifierare

Alla åtgärder i klustret kräver åtgärdsbehörigheten Microsoft.OperationalInsights/clusters/write . Rollerna Ägare eller Deltagare, som inkluderar */write åtgärden, kan ge den här behörigheten. Rollen Log Analytics-deltagare, som inkluderar åtgärden Microsoft.OperationalInsights/*, ger även denna behörighet.

Det här steget uppdaterar dedikerad klusterlagring med nyckeln och versionen som ska användas för AEKwrap och unwrap.

Viktigt!

  • Nyckelrotation kan vara automatisk eller för varje specifik nyckelversion. Se Nyckelrotation för att fastställa en lämplig metod innan du uppdaterar information om nyckelidentifierare i dedikerade kluster.
  • Dedikerade klusteruppdateringar får inte innehålla information om både identitet och nyckelidentifierare i samma åtgärd. Om du behöver uppdatera båda måste uppdateringen ske i två på varandra följande operationer.

Skärmbild av Bevilja Key Vault-behörigheter.

Uppdatera KeyVaultProperties i klustret med information om nyckelidentifierare.

Åtgärden är asynkron och kan ta en stund att slutföra.

Ej tillämpligt

Verifiera dedikerad klusteretablering

Kontrollera att klustrets etableringstillstånd är Succeeded innan du länkar arbetsytor till klustret. Om du länkar arbetsytor och matar in data före tilldelningen tappar processen den inmatade datan och du kan inte återställa den.

Kontrollera etableringstillståndet med hjälp av CLI, PowerShell eller REST API enligt beskrivningen i avsnittet Uppdatera dedikerat kluster med information om nyckelidentifierare .

Viktigt!

Utför det här steget först efter klusteretablering. Om du länkar arbetsytor och matar in data före tilldelningen tappar processen den inmatade datan och du kan inte återställa den.

Information om hur du länkar en arbetsyta finns i Skapa och hantera ett dedikerat kluster.

Återkallande av nycklar

Viktigt!

  • Om du vill återkalla åtkomsten till dina data inaktiverar du nyckeln eller tar bort åtkomstprincipen i nyckelvalvet.
  • Om du ställer in klustrets identitytype till None återkallas även åtkomsten till dina data, men använd inte den här metoden eftersom du inte kan återställa den utan att kontakta supporten.

Klustrets lagring respekterar alltid ändringar i nyckelbehörigheter och blir otillgänglig inom en timme eller tidigare om nyckeln är inaktiverad eller åtkomstprincipen tas bort. Nya data som matas in till länkade arbetsytor tas bort och kan inte återställas. Data är otillgängliga på dessa arbetsytor och frågor misslyckas. Tidigare inmatade data finns kvar så länge klustret och arbetsytorna inte tas bort. Principen för datakvarhållning styr otillgängliga data och rensar dem när kvarhållningsperioden nås. Data som matats in under de senaste 14 dagarna och data som nyligen använts i frågor sparas också i frekvent cache (SSD-backad) för frågeeffektivitet. Data på SSD tas bort vid nyckelåterkallningsåtgärden och blir otillgängliga. Klusterlagringen försöker nå Key Vault för wrap och unwrap åtgärder med jämna mellanrum. När nyckeln är aktiverad och unwrap lyckas laddas SSD-data om från den dedikerade klusterlagringen. Datainmatning och frågefunktioner återupptas inom 30 minuter.

Nyckelrotation

Nyckelrotationen har två lägen:

  • Autorotation – uppdatera "keyVaultProperties" i kluster och utelämna "keyVersion" egenskapen, eller ange den till ''. Storage använder automatiskt den senaste nyckelversionen.
  • Explicit uppdatering av nyckelversion – uppdatera "keyVaultProperties" egenskaper och uppdatera nyckelversionen i "keyVersion" egenskapen. Nyckelrotation kräver explicit uppdatering av "keyVersion" egenskapen i klustret. För mer information, se Uppdatera kluster med detaljer om nyckelidentifierare. Om du genererar en ny nyckelversion i Key Vault men inte uppdaterar nyckeln i klustret fortsätter klusterlagringen att använda din tidigare nyckel. Om du inaktiverar eller tar bort den gamla nyckeln innan du uppdaterar en ny i klustret anger du nyckelåterkallningstillstånd .

Alla dina data är tillgängliga under och efter nyckelrotationen. Klustret krypterar alltid data med kontokrypteringsnyckeln (AEK), som krypteras med din nya KEK-version (Key Encryption Key Key) i Key Vault.

Kundhanterad nyckel för sparade frågor och loggsökningsaviseringar

Frågespråket som används i Log Analytics är uttrycksfullt och kan innehålla känslig information i frågesyntax eller kommentarer. Organisationer med strikta regel- och efterlevnadskrav måste hålla sådan information krypterad med hjälp av en kundhanterad nyckel. När du länkar ett lagringskonto till din arbetsyta kan du med Azure Monitor lagra sparade frågor, funktioner och logga sökaviseringar krypterade med din nyckel.

Anteckning

Frågor förblir krypterade med Microsoft-nyckel (MMK) i följande scenarier oavsett kundhanterad nyckelkonfiguration: Azure-instrumentpaneler, Azure Logic App, Azure Notebooks och Automation Runbooks.

När du länkar ditt lagringskonto för sparade frågor lagrar tjänsten sparade frågor och aviseringsfrågor för loggsökning i ditt lagringskonto. Genom att ha kontroll över krypteringsprincipen för lagringskontot kan du skydda sparade frågor och logga sökaviseringar med hjälp av en kundhanterad nyckel. Du ansvarar för de kostnader som är kopplade till lagringskontot.

Överväganden innan du ställer in kundhanterad nyckel för sparade frågor

  • Du behöver skrivbehörigheter på arbetsytan och lagringskontot.
  • Lagringskontot måste vara StorageV2 och i samma region som din Log Analytics-arbetsyta.
  • När du länkar ett lagringskonto för sparade frågor tar tjänsten bort befintliga sparade frågor och funktioner från arbetsytan för sekretess. Om du behöver dessa frågor kopierar du befintliga sparade frågor och funktioner före konfigurationen. Du kan visa sparade frågor med hjälp av PowerShell eller när du exporterar mallen under Automation på din arbetsyta.
  • Frågor som sparats i ett frågepaket lagras inte på ett länkat lagringskonto och kan inte krypteras med hjälp av en kundhanterad nyckel. Vi rekommenderar att du sparar som en legacyfråga för att skydda databasfrågor med hjälp av en kundhanterad nyckel.
  • Sparade frågor och funktioner i det länkade lagringskontot är tjänstartefakter och deras format kan ändras.
  • Frågehistorik och fäst på instrumentpanelen stöds inte när du länkar lagringskonto för sparade frågor.
  • Du kan länka ett enda eller separat lagringskonto för sparade frågor och aviseringsfrågor för loggsökning.
  • För att hålla frågor och funktioner krypterade med din nyckel konfigurerar du det länkade lagringskontot med hjälp av en kundhanterad nyckel. Utför den här åtgärden när du skapar lagringskontot eller senare.

Konfigurera länkat lagringskonto för sparade frågor

Länka ett lagringskonto för att behålla sparade frågor och funktioner i ditt lagringskonto.

Anteckning

Åtgärden tar bort sparade frågor och funktioner från arbetsytan till en tabell i ditt lagringskonto. Du kan ta bort länken till lagringskontot för sparade frågor för att flytta sparade frågor och funktioner tillbaka till din arbetsyta. Uppdatera webbläsaren om sparade frågor eller funktioner inte visas i Azure-portalen efter åtgärden.

Ej tillämpligt

Kundstyrd nyckel för arbetsböcker

Med Azure Monitor kan du även lagra arbetsboksfrågor som krypterats med din nyckel i ditt eget lagringskonto. Tänk på samma överväganden som beskrivs i Kundhanterad nyckel för sparade frågor och loggsökningsaviseringar.

Välj Spara innehåll till ett Azure Storage-konto i arbetsbokens Spara-åtgärd.

Skärmbild av sparad arbetsbok.

Överväganden innan du ställer in kundhanterad nyckel för sparade loggaviseringsfrågor

  • Klustret sparar aviseringsfrågor som blobar i lagringskontot.
  • Utlösta loggsökningsaviseringar innehåller inte sökresultat eller aviseringsfrågan. Använd aviseringsdimensioner för att hämta kontext för utlösta aviseringar.
  • Om du vill att frågor och funktioner ska vara krypterade med hjälp av din nyckel konfigurerar du det länkade lagringskontot med en kundhanterad nyckel. Utför den här åtgärden när du skapar lagringskontot eller senare.

Konfigurera länkat lagringskonto för loggsökningslarmfrågor

Länka ett lagringskonto för aviseringar för att hålla frågor om loggsökningsaviseringar kvar i ditt lagringskonto.

Ej tillämpligt

Kundlåsbox

Genom att använda Lockbox kan du godkänna eller avvisa Microsofts teknikerbegäranden om att få åtkomst till dina data under kundsupportens ärenden.

Log Analytics dedikerade kluster stöder Lockbox, vilket ger behörighet att komma åt data på prenumerationsnivå.

Mer information finns i Kundlåsbox för Microsoft Azure.

Överväganden och begränsningar

  • Du kan skapa upp till fem aktiva kluster i varje region och prenumeration.

  • Du kan ha upp till sju reserverade kluster (aktiva eller nyligen borttagna) i varje region och prenumeration.

  • Du kan länka upp till 1 000 Log Analytics-arbetsytor till ett kluster.

  • Du kan utföra upp till två arbetsytelänkåtgärder på en särskild arbetsyta under en 30-dagarsperiod.

  • Det finns för närvarande inte stöd för att flytta ett kluster till en annan resursgrupp eller prenumeration.

  • Klusteruppdateringar bör inte innehålla information om både identitet och nyckelidentifierare i samma åtgärd. Om du vill uppdatera båda använder du två åtgärder i följd.

  • Låsbox är inte tillgängligt i Kina för närvarande.

  • Låsboxen gäller inte för tabeller med Hjälp-tabellplanen.

  • Dubbel kryptering konfigureras automatiskt för kluster som skapats från oktober 2020 i regioner som stöds. Du kan kontrollera om klustret har konfigurerats för dubbel kryptering genom att skicka en GET begäran i klustret och observera att isDoubleEncryptionEnabled värdet är true för kluster med dubbel kryptering aktiverat.

  • Om du skapar ett kluster och får felet "region-name stöder inte dubbel kryptering för kluster" kan du fortfarande skapa klustret utan dubbel kryptering genom att lägga till "properties": {"isDoubleEncryptionEnabled": false} i REST-begärandetexten.

  • Du kan inte ändra inställningar för dubbel kryptering när klustret har skapats.

  • Återställningsåtgärden tillåts för en borttagen arbetsyta som fortfarande var länkad till klustret. Det är bara möjligt under perioden för mjuk borttagning . Återställningen returnerar arbetsytan till dess tidigare tillstånd och förblir länkad till klustret.

  • Kundhanterad nyckelkryptering gäller för nyligen inmatade data efter konfigurationstiden. Data som matades in innan konfigurationen förblir krypterade med Microsoft-nycklar. Du kan köra frågor mot data som matas in före och efter den kundhanterade nyckelkonfigurationen sömlöst.

  • Du måste konfigurera Azure Key Vault som återställningsbart. De här egenskaperna är inte aktiverade som standard och du bör konfigurera dem med hjälp av CLI eller PowerShell:

  • Dina Azure Key Vault-, kluster- och arbetsytor måste finnas i samma region och i samma Microsoft Entra-klientorganisation, men de kan finnas i olika prenumerationer.

  • Om du ställer in klustrets identitytype till None återkallas även åtkomsten till dina data, men den här metoden rekommenderas inte eftersom du inte kan återställa den utan att kontakta supporten. Det rekommenderade sättet att återkalla åtkomsten till dina data är nyckelåterkallning.

  • Du kan inte använda en kundhanterad nyckel med användartilldelad hanterad identitet om ditt Nyckelvalv finns i ett Private-Link (virtuellt nätverk). Använd en systemtilldelad hanterad identitet i det här scenariot.

Felsökning

  • Beteende beroende på Key Vault-tillgänglighet:

    • Under normal inmatning cachelagrar den dedikerade klusterlagringen AEK under korta tidsperioder och går tillbaka till Key Vault till unwrap med jämna mellanrum.

    • Under Key Vault-anslutningsfel hanterar den dedikerade klusterlagringen tillfälliga fel (timeouter, anslutningsfel, DNS-fel) genom att behålla nycklar i cacheminnet under problemet för att övervinna blips och tillfällig tillgänglighet. Fråge- och inmatningsfunktionerna fortsätter utan avbrott.

  • Åtkomstfrekvens för Key Vault – den frekvens med vilken klusterlagringen får åtkomst till Key Vault för wrap och unwrap-operationer är mellan 6 och 60 sekunder.

  • Om du uppdaterar klustret när det är i tilldelningstillståndet eller i uppdateringstillståndet, så misslyckas uppdateringen.

  • Om du får ett konfliktfel när du skapar ett kluster kan du ha tagit bort ett kluster med samma namn under de senaste 14 dagarna och reserverat dess namn. Borttagna klusternamn blir tillgängliga 14 dagar efter borttagningen.

  • Det går inte att länka en arbetsyta till ett kluster om arbetsytan är länkad till ett annat kluster.

  • Om du skapar ett kluster och anger KeyVaultProperties omedelbart kan åtgärden misslyckas tills en identitet har tilldelats klustret och beviljats till Key Vault.

  • Om du uppdaterar ett befintligt kluster med KeyVaultProperties och Get och nyckelåtkomstpolicy saknas i Key Vault misslyckas åtgärden.

  • Om du inte kan distribuera klustret kontrollerar du att dina Azure Key Vault-, kluster- och länkade arbetsytor finns i samma region. De kan vara i olika prenumerationer.

  • Om du roterar din nyckel i Key Vault och inte uppdaterar den nya informationen om nyckelidentifieraren i klustret fortsätter klustret att använda den tidigare nyckeln och dina data blir otillgängliga. Uppdatera ny information om nyckelidentifierare i klustret för att återuppta datainmatning och frågefunktioner. Uppdatera nyckelversionen med hjälp '' av notation för att säkerställa att den dedikerade klusterlagringen alltid använder den senaste nyckelversionen automatiskt.

  • Vissa åtgärder är tidskrävande och kan ta en stund att slutföra, till exempel klusterskapande, uppdatering av klusternycklar och borttagning av kluster. Du kan kontrollera åtgärdsstatusen genom att skicka en GET begäran till kluster eller arbetsyta och observera svaret. En olänkad arbetsyta har clusterResourceId till exempel inte under features.

  • Felmeddelanden

    Klusteruppdatering

    • 400 – Klustret är i raderingsläge. Asynkron åtgärd pågår. Klustret måste slutföra sin åtgärd innan någon uppdateringsåtgärd utförs.
    • 400 – KeyVaultProperties är inte tomt men har ett felaktigt format. Se uppdatering av nyckelidentifierare.
    • 400 – Det gick inte att verifiera nyckeln i Key Vault. Kan bero på brist på behörigheter eller när nyckeln inte finns. Kontrollera att du anger nyckel och åtkomstprincip i Key Vault.
    • 400 – Nyckeln kan inte återställas. Key Vault måste vara inställt på mjuk borttagning och rensningsskydd. Se Dokumentation om Key Vault.
    • 400 – Åtgärden kan inte köras nu. Vänta tills asynkroniseringsåtgärden har slutförts och försök igen.
    • 400 – Klustret är i raderingsläge. Vänta tills asynkroniseringsåtgärden har slutförts och försök igen.

    Hämta kluster

    • 404 – Klustret hittades inte. Klustret kan ha tagits bort. Om du försöker skapa ett kluster med det namnet och det uppstår en konflikt, genomgår klustret en borttagningsprocess.

Relaterat innehåll

  • Last updated on