Dela via

Kundhanterade nycklar i Azure Monitor

  • Artikel

Data i Azure Monitor krypteras med Microsoft-hanterade nycklar. Du kan använda din egen krypteringsnyckel för att skydda data och sparade frågor på dina arbetsytor. Kundhanterade nycklar i Azure Monitor ger dig större flexibilitet att hantera åtkomstkontroller till loggar. När du har konfigurerat krypteras nya data som matas in till länkade arbetsytor med din nyckel som lagras i Azure Key Vault eller Azure Key Vault Managed "HSM".

Granska begränsningar och begränsningar före konfigurationen.

Översikt över kundhanterad nyckel

Kryptering i vila är ett vanligt sekretess- och säkerhetskrav i organisationer. Du kan låta Azure helt hantera kryptering i vila, eller så kan du använda olika alternativ för att hantera krypterings- och krypteringsnycklar noggrant.

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.

För att hantera nyckellivscykeln och kunna återkalla åtkomsten till dina data kan du kryptera data med din egen nyckel med hjälp av Azure Key Vault.

Kundhanterade nycklar är tillgängliga i dedikerade kluster och ger dig en högre skyddsnivå och kontroll. Data krypteras i lagring 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 kan 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-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 ditt Azure Key Vault. Log Analytics-klustrets identitet stöds på klusternivå. För att tillåta 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 kluster 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 när klustret skapas, när identity type det är inställt UserAssignedpå och ge den behörighet i ditt Key Vault innan klustret skapas.

Du kan konfigurera kundhanterade nycklar i ett nytt kluster eller ett befintligt kluster som är länkat till arbetsytor och som redan matar in data. Nya data som matas in till länkade arbetsytor krypteras med din nyckel och äldre data matas in innan konfigurationen förblir krypterad med Microsoft-nycklar. Kundhanterad nyckelkonfiguration påverkar inte dina frågor, som fortsätter att köras på gamla och nya data sömlöst. Du kan när som helst ta bort länken mellan arbetsytor från ett kluster. Nya data som du matar in när avlänken krypteras med Microsoft-nycklar och frågor utförs sömlöst över gamla och nya data.

Viktigt!

Funktionen för kundhanterade nycklar är regional. Dina Azure Key Vault-, 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. Key Vault
  2. Log Analytics-klusterresurs som har en hanterad identitet med behörighet till Key Vault – identiteten sprids till den dedikerade klusterlagringen underlägget
  3. Dedikerat kluster
  4. Arbetsytor som är länkade till dedikerade kluster

Åtgärden 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 en nyckel i nyckelvalvet och uppdaterar nyckelinformationen i klustret utför klusterlagringen begäranden om att "wrap" och "unwrap" "AEK" för kryptering och dekryptering.
  • Din "KEK" lämnar aldrig ditt Key Vault, och om du använder en hanterad "HSM" lämnar den aldrig maskinvaran.
  • Azure Storage använder hanterad identitet som är associerad med klusterresursen 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 kluster
  3. Bevilja behörigheter till ditt Key Vault
  4. Uppdatera kluster med information om nyckelidentifierare
  5. Länka arbetsytor

Kundhanterad nyckelkonfiguration stöds inte i Azure Portal för närvarande och etablering kan utföras via PowerShell-, CLI- eller REST-begäranden.

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.

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

Identitetsinställningar i kluster för systemtilldelad hanterad identitet

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

Kommentar

Identitetstypen kan ändras när klustret har skapats utan avbrott i inmatningen eller frågor med följande överväganden

  • Uppdaterar SystemAssigned till UserAssigned– Bevilja UserAssign-identitet i Key Vault och uppdatera identity type sedan i klustret
  • Uppdaterar UserAssigned till SystemAssigned– Eftersom systemtilldelad hanterad identitet skapades efter uppdatering av klustret identity type med SystemAssignedmåste följande steg följas
    1. Uppdatera klustret och ta bort nyckeln – ange keyVaultUri, keyNameoch keyVersion med värdet ""
    2. Uppdatera klustret identity type till SystemAssigned
    3. Uppdatera Key Vault och bevilja behörigheter till identiteten
    4. Uppdatera nyckeln i klustret

Följ proceduren som illustreras i artikeln Dedikerade kluster.

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 Portal och välj Inställningar>Åtkomstkonfiguration>Rollbaserad åtkomstkontroll i Azure och Tillämpa
    2. Klicka på knappen Gå till åtkomstkontroll (IAM) och lägg till rolltilldelning för 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 Åtkomstprinciper>Valvåtkomstprincip>+ Lägg till åtkomstprincip för att skapa en princip med följande inställningar:

    • Nyckelbehörigheter – välj Hämta, Radbryt nyckel och Packa upp nyckel.
    • Välj 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 . Den här behörigheten kan beviljas via den ägare eller deltagare som innehåller */write åtgärden eller via rollen Log Analytics-deltagare som innehåller Microsoft.OperationalInsights/* åtgärden.

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

Viktigt!

  • Nyckelrotation kan vara automatisk eller per explicit nyckelversion, se Nyckelrotation för att fastställa vilken metod som är lämplig för dig 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.

Du måste ha "skrivbehörighet" på arbetsytan och klustret för att utföra den här åtgärden. Den innehåller Microsoft.OperationalInsights/workspaces/write och Microsoft.OperationalInsights/clusters/write.

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 nyckeln eller ta bort åtkomstprincipen i nyckelvalvet.
  • Om du ställer in klustrets identity type 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.

Klusterlagringen 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. Otillgängliga data styrs av principen för datakvarhållning och rensas när kvarhållningen 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ärd och blir otillgängliga. Klusterlagringen försöker nå Key Vault för omslutning och avskrivning med jämna mellanrum, och när nyckeln är aktiverad lyckas avskrivningen, SSD-data läses in igen från lagringen och datainmatningen och frågan å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. Mer information finns i Uppdatera kluster med information 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 nyckelkrypteringsnyckel ("KEK") version 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 kommentarer eller i frågesyntaxen. Vissa organisationer kräver att sådan information hålls skyddad under kundhanterad nyckelprincip och du behöver spara dina frågor krypterade med din nyckel. Med Azure Monitor kan du lagra sparade frågor och logga sökaviseringar krypterade med din nyckel i ditt eget lagringskonto när du är länkad till din arbetsyta.

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

Kommentar

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 frågor

  • Du måste ha behörighet att skriva på arbetsytan och lagringskontot.
  • Se till att skapa ditt lagringskonto i samma region som log analytics-arbetsytan finns, med kundhanterad nyckelkryptering. Detta är viktigt eftersom sparade frågor lagras i tabelllagring och endast kan krypteras när lagringskontot skapas.
  • Frågor som sparats i frågepaketet krypteras inte med kundhanterad nyckel. Välj Spara som äldre fråga när du sparar frågor i stället för att skydda dem med kundhanterad nyckel.
  • Sparar frågor i lagring betraktas som tjänstartefakter och deras format kan ändras.
  • Om du länkar ett lagringskonto för frågor tar du bort befintliga sparar frågor från din arbetsyta. Kopiera sparar frågor som du behöver innan den här konfigurationen. Du kan visa dina sparade frågor med hjälp av PowerShell.
  • Frågan "historik" och "fäst på instrumentpanelen" stöds inte när du länkar lagringskonto för frågor.
  • Du kan länka ett enda lagringskonto till en arbetsyta för både sparade frågor och aviseringsfrågor för loggsökning.
  • Aviseringar för loggsökning sparas i bloblagring och kundhanterad nyckelkryptering kan konfigureras när lagringskontot skapas eller senare.
  • Utlösta loggsökningsaviseringar innehåller inte sökresultat eller aviseringsfråga. Du kan använda aviseringsdimensioner för att få kontext i de utlösta aviseringarna.

Konfigurera BYOS för sparade frågor

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

Ej tillämpligt

Efter konfigurationen sparas alla nya sparade sökfrågor i lagringen.

Konfigurera BYOS för aviseringsfrågor för loggsökning

Länka ett lagringskonto för aviseringar för att behålla aviseringsfrågor för loggsökning i ditt lagringskonto.

Ej tillämpligt

Efter konfigurationen sparas alla nya aviseringsfrågor i lagringen.

Customer Lockbox

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 nyckelåtgärder

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änkåtgärder för arbetsytor på en viss arbetsyta tillåts under 30 dagar.

  • 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älpplanen.

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

  • Azure Key Vault, klustret och arbetsytorna 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 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 kundhanterad nyckel med användartilldelad hanterad identitet om ditt Nyckelvalv finns i Private-Link (vNet). Du kan använda systemtilldelad hanterad identitet i det här scenariot.

  • Tabellplanen Auxiliary stöder inte kundhanterade nycklar. Data i tabeller med hjälpplanen krypteras med Microsoft-hanterade nycklar, även om du skyddar data i resten av Log Analytics-arbetsytan med hjälp av din egen krypteringsnyckel.

Felsökning

  • Beteende per Key Vault-tillgänglighet:

    • Normal åtgärd – lagring cachelagrar "AEK" under korta tidsperioder och går tillbaka till Key Vault för att packa upp med jämna mellanrum.

    • Anslutningsfel för Key Vault – lagringen hanterar tillfälliga fel (timeouter, anslutningsfel, "DNS"-problem), genom att tillåta att nycklar stannar kvar i cachen under tillgänglighetsproblemet och löser problem med blippar och tillgänglighet. Fråge- och inmatningsfunktionerna fortsätter utan avbrott.

  • Åtkomstfrekvensen för Key Vault – den frekvens med vilken klusterlagringen kommer åt Key Vault för wrap och unwrap – är mellan 6 och 60 sekunder.

  • Om du uppdaterar klustret när det är i etableringstillstånd eller uppdaterar tillståndet misslyckas uppdateringen.

  • Om du får konflikt – fel när du skapar ett kluster kan ett kluster med samma namn ha tagits bort under de senaste 14 dagarna och hållits reserverat. Borttaget klusternamn blir tillgängligt 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"-nyckelåtkomstprincipen 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 nyckeln i Key Vault och inte uppdaterar den nya informationen om nyckelidentifieraren i klustret fortsätter klustret att använda föregående nyckel så blir dina data otillgängliga. Uppdatera ny information om nyckelidentifierare i klustret för att återuppta datainmatning och fråga. Du kan uppdatera nyckelversionen med "''" så att lagringen alltid använder lates-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 GET-begäran till kluster eller arbetsyta och observera svaret. Till exempel kommer inte den olänkade arbetsytan att ha clusterResourceId under funktioner.

  • Felmeddelanden

    Klusteruppdatering

    • 400 – Klustret är i borttagningstillstånd. 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 borttagningstillstånd. 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 få en konflikt är klustret i borttagningsprocessen.

Nästa steg