Anteckning
Å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.
Data i Azure Monitor krypteras med Microsoft-hanterade nycklar. Du kan använda din egen krypteringsnyckel för att skydda data på dina arbetsytor. Kundhanterade nycklar i Azure Monitor ger dig kontroll över krypteringsnyckelns livscykel och åtkomst till loggar. När de har konfigurerats krypteras nya data som matas in till länkade arbetsytor med 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 säkerställer 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 med möjlighet att återkalla åtkomstdata krypterar du data med din egen nyckel i Azure Key Vault eller Azure Key Vault Managed HSM. Funktioner för kundhanterade nycklar är tillgängliga i dedikerade kluster och ger dig högre skydd 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 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. SSD-data krypteras med Microsoft-hanterade nycklar oavsett om du konfigurerar kundhanterade nycklar, men din kontroll över SSD-åtkomst 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-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: Systemtilldelad och Användartilldelad, medan en enda identitet kan definieras i ett kluster beroende på ditt scenario.
- Systemtilldelad hanterad identitet är enklare och genereras automatiskt med klustret när
identity
type
är inställt påSystemAssigned
. Den här identiteten används senare för att ge lagringsåtkomst till ditt Key Vault för datakryptering och dekryptering. - Med användartilldelad hanterad identitet kan du konfigurera kundhanterade nycklar vid klusterskapandet, när
identity
type
är inställt påUserAssigned
, och ge den behörigheter i din Key Vault 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änkning av 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 kan finnas i olika prenumerationer.
- Nyckelvalv
- Log Analytics-klusterresurs som har en hanterad identitet med behörighet till Key Vault – identiteten sprids till den underliggande dedikerade klusterlagringen
- Dedikerat kluster
- Arbetsytor som är länkade till dedikerade kluster
Typer av krypteringsnycklar
Det finns tre typer av nycklar som ingår i kryptering av lagringsdata:
- 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 används för att härleda DEK:er, som är de nycklar som används för att kryptera varje datablock som skrivs till disk.
- När du konfigurerar den kundhanterade
wrap
:en i klustret utför klusterlagringen ochunwrap
begär till ditt 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 får åtkomst till Azure Key Vault via Microsoft Entra-ID.
Etableringssteg för kundhanterad nyckel
- Skapa Azure Key Vault och lagra nyckeln
- Skapa ett dedikerat kluster
- Bevilja behörigheter till ditt Key Vault
- Uppdatera ett dedikerat kluster med information om nyckelidentifierare
- Länka arbetsytor
En kundhanterad nyckelkonfiguration stöder inte konfiguration av identitets- och nyckelidentifierare. Utför den här åtgärden via PowerShell-, CLI- eller REST-begäranden .
Behörigheter som krävs
Om du vill utföra klusterrelaterade åtgärder 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, som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel |
Ä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 |
Lagra krypteringsnyckel ("KEK")
En portfölj med Azure Key Management-produkter visar de valv och hanterade HSM:er som kan användas.
Skapa eller använd ett befintligt Azure Key Vault i den region som klustret planeras för. Generera eller importera en nyckel som ska användas för loggkryptering i nyckelvalvet. Azure Key Vault måste konfigureras som återställningsbart för att skydda din nyckel och åtkomsten till dina data i Azure Monitor. Du kan kontrollera den här konfigurationen under egenskaper i ditt Key Vault. Både Mjuk borttagning och Rensningsskydd ska vara aktiverade.
Viktigt!
Vi rekommenderar att du konfigurerar 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 de här stegen för att lösa problemet
- Identifiera nyckeln som används på klustrets översiktssida i Azure-portalen under JSON-vy
- Utöka nyckelns förfallodatum i Azure Key Vault
- Uppdatera klustret med den aktiva nyckeln, helst med versionsvärdet "", för att alltid använda den senaste versionen automatiskt
De här inställningarna kan uppdateras i Key Vault via CLI och PowerShell:
- Mjuk borttagning
- Förhindring av rensning skyddar mot tvångsborttagning av hemligheten och valvet även efter mjuk borttagning.
Skapa kluster
Kluster använder hanterad identitet för datakryptering med ditt Key Vault. Konfigurera identity
type
egenskapen till SystemAssigned
eller UserAssigned
när du skapar klustret för att tillåta åtkomst till ditt Key Vault för datakryptering och dekrypteringsåtgärder.
Lägg till exempel till dessa egenskaper i begärandetexten för systemtilldelad hanterad identitet
{
"identity": {
"type": "SystemAssigned"
}
}
Anteckning
Identitetstypen kan ändras när klustret har skapats utan avbrott i inmatning eller frågor, med följande överväganden:
- Identitet och nyckel kan inte uppdateras samtidigt för ett kluster. Uppdatera i två på varandra följande åtgärder.
- När du uppdaterar
SystemAssigned
tillUserAssigned
, beviljaUserAssign
identitet i Key Vault, och uppdatera sedan i klustret. - När du uppdaterar
UserAssigned
tillSystemAssigned
, beviljaSystemAssigned
identitet i Key Vault, och uppdatera sedan i klustret.
Följ proceduren som illustreras i den dedikerade klusterartikeln.
Bevilja Key Vault-behörigheter
Det finns två behörighetsmodeller i Key Vault för att bevilja åtkomst till klustret och underläggslagring – Rollbaserad åtkomstkontroll i Azure (Azure RBAC) och Åtkomstprinciper för valv (äldre).
Tilldela Azure RBAC som du styr (rekommenderas)
Om du vill lägga till rolltilldelningar måste du ha en roll med
Microsoft.Authorization/roleAssignments/write
ochMicrosoft.Authorization/roleAssignments/delete
behörigheter, till exempel administratör för användaråtkomst eller ägare.- Öppna ditt Key Vault i Azure-portalen och välj Inställningar>Åtkomstkonfiguration>Rollbaserad åtkomstkontroll i Azure och Använd.
- Välj Gå till åtkomstkontroll (IAM) och lägg till rolltilldelningen Key Vault Crypto Service Encryption User .
- Välj Hanterad identitet på fliken Medlemmar och välj prenumerationen för identitet och identiteten som medlem.
Tilldela åtkomstprincip för valv (äldre)
Öppna ditt Key Vault i Azure Portal och välj >+ 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
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 kluster med information om nyckelidentifierare
Alla åtgärder i klustret kräver åtgärdsbehörigheten Microsoft.OperationalInsights/clusters/write
. Behörigheten kan beviljas via den ägare eller deltagare som innehåller */write
åtgärden eller via rollen Log Analytics-deltagare som innehåller åtgärden Microsoft.OperationalInsights/*
.
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 per explicit nyckelversion, se Nyckelrotation för att fastställa lämplig metod innan du uppdaterar information om nyckelidentifieraren i klustret.
- Klusteruppdatering bör inte innehålla information om både identitet och nyckelidentifierare i samma åtgärd. Om du behöver uppdatera båda bör uppdateringen vara i två på varandra följande åtgärder.
Uppdatera KeyVaultProperties
i klustret med information om nyckelidentifierare.
Åtgärden är asynkron och kan ta en stund att slutföra.
Ej tillämpligt
Länka arbetsyta till kluster
Viktigt!
Det här steget bör endast utföras efter klusteretablering. Om du länkar arbetsytor och matar in data före etableringen tas inmatade data bort och kan inte återställas.
Följ proceduren som illustreras i artikeln Dedikerade kluster.
Ta bort länk till arbetsyta från kluster
Följ proceduren som illustreras i artikeln Dedikerade kluster.
Återkallande av nycklar
Viktigt!
- Det rekommenderade sättet att återkalla åtkomsten till dina data är genom att inaktivera din nyckel eller ta bort åtkomstprincipen i ditt Key Vault.
- Om du ställer in klustrets
identity
type
tillNone
återkallas även åtkomsten till dina data, men den här metoden rekommenderas inte eftersom du inte kan återställa den utan att kontakta supporten.
Klustrets lagring respekterar alltid ändringar i nyckelbehörigheter inom en timme eller tidigare och lagringen blir otillgänglig. 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 i lagringen 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 lagringen. Datainmatning och frågefunktioner återupptas inom 30 minuter.
Nyckelrotation
Nyckelrotationen har två lägen:
- Autorotation – uppdatera
"keyVaultProperties"
egenskaper i klustret 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 hamnar du i nyckelåterkallningstillstånd .
Alla dina data är tillgängliga under och efter nyckelrotationen. Data krypteras alltid 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 som begränsas av strikta regel- och efterlevnadskrav måste underhålla sådan information krypterad med kundhanterad nyckel. Med Azure Monitor kan du lagra sparade frågor, funktioner och loggsökningsaviseringar krypterade med din nyckel i ditt eget lagringskonto när du är länkad till din arbetsyta.
Kundstyrd nyckel för arbetsböcker
Med de överväganden som nämns för kundhanterad nyckel för sparade frågor och loggsökningsaviseringar kan du med Azure Monitor lagra arbetsboksfrågor krypterade med din nyckel i ditt eget lagringskonto när du väljer Spara innehåll till ett Azure Storage-konto i arbetsboken Spara.
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. Om du har kontroll över krypteringsprincipen för lagringskontot kan du skydda sparade frågor och logga sökaviseringar med kundhanterad nyckel. Du kommer dock att ansvara för de kostnader som är kopplade till lagringskontot.
Överväganden innan du ställer in kundhanterad nyckel för sparade frågor
- Du måste ha behörighet att skriva 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 tas befintliga sparade frågor och funktioner bort från din arbetsyta för sekretess. Om du behöver ha dessa lättillgängliga, kopiera de befintliga sparade frågorna och funktionerna innan du gör 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 frågepaketet lagras inte på det länkade lagringskontot och kan inte krypteras med kundhanterad nyckel. Vi rekommenderar att du sparar som äldre fråga för att skydda frågor med kundhanterad nyckel.
- Sparade frågor och funktioner i det länkade lagringskontot betraktas som tjänstartefakter och deras format kan ändras.
- "Frågehistorik och att fästa på instrumentpanelen stöds inte när man 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.
- Om du vill att frågor och funktioner ska vara krypterade med din nyckel konfigurerar du det länkade lagringskontot med kundhanterad nyckel. Den här åtgärden kan utföras när lagringskontot skapas eller senare.
Konfigurera länkat lagringskonto för sparade frågor
Länka ett lagringskonto för att spara dina frågor och funktioner, så att de sparade frågorna och funktionerna hålls kvar 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 om du vill flytta tillbaka sparade frågor och funktioner till din arbetsyta. Uppdatera webbläsaren om du inte har sparat frågor eller funktioner som inte visas i Azure-portalen efter åtgärden.
Ej tillämpligt
Efter konfigurationen sparas alla nya sparade sökfrågor i lagringen.
Konfigurera länkat lagringskonto för aviseringsfrågor för loggsökning
Överväganden innan du ställer in kundhanterad nyckel för frågor om sparad loggavisering
- Aviseringsfrågor sparas som blob 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 din nyckel konfigurerar du det länkade lagringskontot med kundhanterad nyckel. Den här åtgärden kan utföras när lagringskontot skapas eller senare.
Länka ett lagringskonto för aviseringar för att hålla frågor om loggsökningsaviseringar kvar i ditt lagringskonto.
Ej tillämpligt
Efter konfigurationen sparas alla nya aviseringsfrågor i lagringen.
Kundlåsbox
Med Låsbox kan du godkänna eller avvisa Microsofts teknikerbegäran om att få åtkomst till dina data under en supportbegäran.
Låsbox finns i ett dedikerat kluster i Azure Monitor, där din behörighet att komma åt data beviljas på prenumerationsnivå.
Läs mer om Customer Lockbox för Microsoft Azure
Kundhanterade nyckeloperationer
Kundhanterad nyckel tillhandahålls i dedikerade kluster och dessa åtgärder hänvisas till i artikeln om dedikerade kluster
- Hämta alla kluster i resursgruppen
- Hämta alla kluster i prenumerationen
- Uppdatera kapacitetsreservation i kluster
- Uppdatera billingType i kluster
- Ta bort länken till en arbetsyta från klustret
- Ta bort klustret
Begränsningar och restriktioner
Högst fem aktiva kluster kan skapas i varje region och prenumeration.
Högst sju reserverade kluster (aktiva eller nyligen borttagna) kan finnas i varje region och prenumeration.
Högst 1 000 Log Analytics-arbetsytor kan länkas till ett kluster.
Högst två länkoperationer på en viss arbetsyta tillåts 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.
Klusteruppdatering bör inte innehålla information om både identitet och nyckelidentifierare i samma åtgärd. Om du behöver uppdatera båda bör uppdateringen vara i två på varandra följande åtgärder.
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 attisDoubleEncryptionEnabled
värdet ärtrue
för kluster med dubbel kryptering aktiverat.- Om du skapar ett kluster och får ett fel – "regionnamn 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. - Det går inte att ändra inställningarna för dubbel kryptering när klustret har skapats.
- Om du skapar ett kluster och får ett fel – "regionnamn stöder inte dubbel kryptering för kluster" kan du fortfarande skapa klustret utan dubbel kryptering genom att lägga till
Det är tillåtet att ta bort en länkad arbetsyta när den är länkad till klustret. Om du bestämmer dig för att återställa arbetsytan under perioden för mjuk borttagning återgår den till föregående 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.
Azure Key Vault måste konfigureras som återställningsbart. Dessa egenskaper är inte aktiverade som standard och bör konfigureras med CLI eller PowerShell:
- Mjuk borttagning.
- Rensningsskyddet bör aktiveras för att skydda mot tvångsborttagning av hemligheten och valvet, även efter mjuk borttagning.
Din Azure Key Vault, ditt kluster och dina 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
identity
type
tillNone
å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:
Normal lagringshantering lagrar i cache AEK under korta perioder och går tillbaka till Key Vault med jämna mellanrum.
Anslutningsfel för Key Vault – lagringen hanterar tillfälliga fel (tidsgränser, anslutningsfel, DNS-problem), genom att låta nycklar stanna kvar i cacheminnet under tillgänglighetsproblemet, och det löser problem med blips och 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
ochunwrap
-operationer är mellan 6 och 60 sekunder.Om du uppdaterar klustret när det är i tillståndet för etablering eller i uppdateringstillståndet, misslyckas uppdateringen.
Om du får konfliktfel när du skapar ett kluster kan ett kluster med samma namn ha tagits bort under de senaste 14 dagarna och dess namn har reserverats. 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 till klustret och beviljats till Key Vault.Om du uppdaterar det befintliga klustret med
KeyVaultProperties
ochGet
och nyckelhanteringspolicy 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. Kan finnas 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
''
notation för att säkerställa att lagringen 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 harclusterResourceId
till exempel inte underfeatures
.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 Async-åtgärden har slutförts och försök igen.
- 400 – Klustret är i raderingsläge. Vänta tills Async-å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.
Nästa steg
- Läs mer om fakturering av dedikerade Log Analytics-kluster
- Lär dig mer om korrekt design av Log Analytics-arbetsytor