Dela via

Kundhanterade nycklar i Azure Monitor

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 identitytype ä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 identitytype ä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.

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

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 och unwrap 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

  1. Skapa Azure Key Vault och lagra nyckeln
  2. Skapa ett dedikerat kluster
  3. Bevilja behörigheter till ditt Key Vault
  4. Uppdatera ett dedikerat kluster med information om nyckelidentifierare
  5. 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

  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.

De här inställningarna kan uppdateras i Key Vault via CLI och PowerShell:

Skapa kluster

Kluster använder hanterad identitet för datakryptering med ditt Key Vault. Konfigurera identitytype 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 till UserAssigned, bevilja UserAssign identitet i Key Vault, och uppdatera sedan i klustret.
  • När du uppdaterar UserAssigned till SystemAssigned, bevilja SystemAssigned 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).

  1. 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 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 Använd.
    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 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

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

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

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.

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

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.

Skärmbild av sparad arbetsbok.

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 att isDoubleEncryptionEnabled värdet är true 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.

  • 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:

  • 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 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:

    • 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 och unwrap-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 och Get 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 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 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