Kundhanterad nyckel 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, medan du har 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). Du kan kryptera data med din egen nyckel i Azure Key Vault, för kontroll över nyckellivscykeln och möjlighet att återkalla åtkomsten till dina data. Azure Monitor-användningen av kryptering är identisk med hur Azure Storage-kryptering fungerar.

Kundhanterad nyckel levereras på dedikerade kluster som ger högre skyddsnivå och kontroll. Data krypteras i lagring två gånger, en gång på tjänstnivå med hjälp av Microsoft-hanterade nycklar eller kundhanterade nycklar, och en gång 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 lagras i frekvent cache (SSD-backad) för frågeeffektivitet. SSD-data krypteras med Microsoft-nycklar oavsett kundhanterad nyckelkonfiguration, men din kontroll över SSD-åtkomst följer nyckelåterkallningen

Log Analytics-prismodellen för dedikerade kluster kräver åtagandenivå som börjar på 100 GB per dag.

Så här fungerar kundhanterad nyckel 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 kundhanterad nyckel 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 när klustret skapas när identiteten type är inställd på "SystemAssigned". Den här identiteten kan användas senare för att ge lagringsåtkomst till ditt Key Vault för wrap- och unwrap-åtgärder.
  • Med användartilldelad hanterad identitet kan du konfigurera kundhanterad nyckel när klustret skapas, när du beviljar den behörigheter i nyckelvalvet innan klustret skapas.

Du kan använda konfiguration av kundhanterad nyckel för ett nytt kluster eller ett befintligt kluster som är länkat till arbetsytor och mata in data. Nya data som matas in till länkade arbetsytor krypteras med din nyckel och äldre data som matas in före konfigurationen förblir krypterade med Microsoft-nyckeln. Dina frågor påverkas inte av kundhanterad nyckelkonfiguration och utförs sömlöst över gamla och nya data. Du kan när som helst ta bort länken mellan arbetsytor från klustret. Nya data som matas in när avlänken krypteras med Microsoft-nyckeln och frågor utförs sömlöst över gamla och nya data.

Viktigt!

Kundhanterad nyckelkapacitet är regional. Dina Azure Key Vault-, kluster- och länkade arbetsytor måste finnas i samma region, men de kan finnas i olika prenumerationer.

Screenshot of customer-managed key overview.

  1. Key Vault
  2. Log Analytics-klusterresurs med hanterad identitet med behörighet till Key Vault – Identiteten sprids till underlägget dedikerad klusterlagring
  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 när det gäller 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

Konfiguration av kundhanterad nyckel stöds för närvarande inte i Azure-portalen 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.

Screenshot of soft delete and purge protection settings.

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 identitetsegenskapen type till SystemAssigned när du skapar klustret för att tillåta åtkomst till ditt Key Vault för "wrap" och "unwrap"-åtgärder.

Identitetsinställningar i kluster för systemtilldelad hanterad identitet

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

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 behörigheterna Microsoft.Authorization/roleAssignments/write och Microsoft.Authorization/roleAssignments/delete, till exempel Administratör för användaråtkomst eller Ägare.

    Öppna ditt Key Vault i Azure-portalen, klicka på Åtkomstkonfiguration i Inställningar och välj alternativet Rollbaserad åtkomstkontroll i Azure. Ange sedan åtkomstkontroll (IAM) och lägg till rolltilldelning för Key Vault Crypto Service Encryption User .

    Screenshot of Grant Key Vault RBAC permissions.

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

    Öppna ditt Key Vault i Azure-portalen och klicka på Åtkomstprinciper, välj Åtkomstprincip för valv och klicka sedan på + 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

    Screenshot of Grant Key Vault access policy permissions.

    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 kräva explicit nyckeluppdatering. Se Nyckelrotation för att fastställa vilken metod som passar 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.

Screenshot of Grant Key Vault permissions.

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

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 klustret med "keyVaultProperties" men utelämna "keyVersion" egenskapen eller ställ in det på "". Storage använder automatiskt den senaste nyckelversionen.
  • Explicit uppdatering av nyckelversion – uppdatera klustret med nyckelversionen i "keyVersion" egenskapen . Rotation av nycklar kräver en explicit "keyVaultProperties" uppdatering i klustret, se Uppdatera kluster med information om nyckelidentifierare. Om du genererar en ny nyckelversion i Key Vault men inte uppdaterar den 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 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.

Screenshot of Workbook save.

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.

  • 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 före konfigurationen förblir krypterade med Microsoft-nyckeln. 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 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 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.

  • Asynkrona sökjobbfrågor stöds för närvarande inte i scenario med kundhanterad nyckel.

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.

  • Åtkomstfrekvens för Key Vault – Frekvensen som Azure-klusterlagringen använder för att omsluta och packa upp Key Vault ä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 arbetsytan till klustret om den är länkad till ett annat kluster.

  • Om du skapar ett kluster och anger KeyVaultProperties omedelbart kan åtgärden misslyckas tills identiteten har tilldelats i klustret och beviljats i 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å konflikter är klustret i borttagningsprocessen.

Nästa steg