Azure Policy

Azure Policy är en styrningstjänst som gör det möjligt att definiera, tilldela och hantera regler — så kallade policy definitions — som styr eller granskar konfigurationen av Azure-resurser. Till skillnad från RBAC, som styr vem som får utföra åtgärder, styr Azure Policy vilken konfiguration den resulterande resursen får ha. Ni använder tjänsten för att upprätthålla organisationsstandarder som namnkonventioner, godkända resurs¬typer och obligatoriska säkerhetskonfigurationer.

En policy definition är ett JSON-dokument som definierar ett villkor som ska utvärderas mot en resurs och en effekt som ska tillämpas när villkoret uppfylls. Azure tillhandahåller hundratals inbyggda policydefinitioner för vanliga scenarier. Ni kan även skapa anpassade policydefinitioner när de inbyggda principerna inte motsvarar era krav. Policydefinitioner är återanvändbara objekt som måste tilldelas till ett omfång innan de börjar gälla.

Effekten i en policydefinition avgör vad som händer när policyvillkoret utlöses. Viktiga effekter är bland annat: Deny — blockerar skapandet eller uppdateringen av en resurs som bryter mot policyn; Audit — tillåter åtgärden men loggar en varning i efterlevnadsrapporten; Append — lägger till obligatoriska fält (till exempel taggar) i en resurs före skapandet; Modify — ändrar en egenskap hos befintliga eller nya resurser; DeployIfNotExists — distribuerar en relaterad resurs om ett villkor inte är uppfyllt (till exempel ett diagnostiktillägg till varje virtuell dator).

En policy assignment tillämpar en policydefinition på ett specifikt omfång: hanteringsgrupp, prenumeration eller resursgrupp. Alla resurser inom omfånget (och underordnade omfång) utvärderas mot den tilldelade policyn. Tilldelningar kan innehålla parametrar — exempelvis kan en policy som begränsar tillåtna Azure-regioner parametriseras så att samma definition tilldelas med olika regionlistor i olika hanteringsgrupper.

En initiative definition (även kallad en policyuppsättning) grupperar flera relaterade policydefinitioner i ett enda paket som kan tilldelas. I stället för att tilldela 20 enskilda principer tilldelar ni ett initiativ. Azure tillhandahåller inbyggda initiativ för efterlevnadsramverk som ISO 27001, NIST SP 800-53, Azure Security Benchmark och PCI DSS. Om ni till exempel tilldelar initiativet CIS Microsoft Azure Foundations Benchmark utvärderas prenumerationen mot fler än 180 säkerhetskontroller samtidigt.

När en policy har tilldelats utvärderar Azure alla befintliga resurser inom omfånget och genererar en efterlevnadsrapport. Rapporten visar den övergripande efterlevnadsprocenten (resurser som uppfyller kraven / totalt antal resurser), varje resurs efterlevnadsstatus och vilka specifika policyvillkor som inte uppfylldes. Ni kan filtrera efter policyinitiativ, omfång eller resurstyp. Resurser som inte uppfyller kraven listas tillsammans med den exakta policyregel de bröt mot, vilket vägleder åtgärdandet.

För principer med effekten DeployIfNotExists eller Modify kan Azure skapa åtgärdsuppgifter för att få befintliga resurser som inte uppfyller kraven att göra det. En DeployIfNotExists-policy som distribuerar en Log Analytics-agent till varje virtuell dator kan till exempel utlösa en åtgärdsuppgift som installerar agenten på alla befintliga virtuella datorer som saknar den. Nya resurser åtgärdas automatiskt när de skapas, medan befintliga resurser kräver en uttrycklig åtgärdsuppgift.

Ibland behöver specifika resurser legitimt undantas från en policy — exempelvis en äldre resurs som inte kan ändras eller ett godkänt undantag som dokumenterats i en ändringsbegäran. Policy exemptions gör det möjligt att undanta en specifik resurs eller resursgrupp från en policytilldelning utan att ta bort policyn globalt. Undantag kan ha ett valfritt slutdatum och en kategori (Waiver eller Mitigated) som dokumenterar orsaken till undantaget.

DeployIfNotExists är en av de mest kraftfulla policyeffekterna. När en resurs skapas utan en nödvändig relaterad resurs (till exempel en virtuell dator utan ett diagnostiktillägg) utlöser policyn automatiskt en ARM-mall för att lägga till den komponent som saknas. Därmed kan Azure Policy fungera som ett verktyg för automatisk konfigurationshantering — så att varje virtuell dator alltid har övervakningsagenter, varje lagringskonto alltid har avancerat skydd mot hot och varje SQL Database alltid har granskning aktiverad.

Organisationer använder Azure Policy i många styrningsscenarier. Platsbegränsningar — tillåt endast resurser i godkända Azure-regioner av hänsyn till datasuveränitet. Tillåtna resurstyper — förhindra distribution av dyra eller icke godkända tjänster. Tvingande taggar — kräv taggarna CostCentre och Environment på alla resurser. SKU-begränsningar — begränsa storleken på virtuella datorer till kostnadsanpassade nivåer i prenumerationer som inte gäller produktion. Säkerhetsbaslinjer — tillämpa TLS 1.2 som lägsta version, inaktivera offentlig nätverksåtkomst för lagringskonton och kräv privata slutpunkter.

Det är viktigt att förstå RBAC:s och Azure Policys olika roller. RBAC styr vem som får utföra åtgärder — det beviljar eller nekar åtgärder baserat på identitet. Azure Policy styr hur resurskonfigurationen måste se ut — den utvärderar och tillämpar egenskaper oavsett vem som utför åtgärden. Båda behövs i en välstyrd miljö: RBAC säkerställer att endast behöriga personer distribuerar resurser, och Azure Policy säkerställer att resurserna följer konfigurationsstandarderna.

I den här lektionen har ni lärt er att Azure Policy definierar villkor och effekter för att styra resurskonfigurationen på valfritt omfång, att initiativdefinitioner samlar flera principer i ett enda tilldelningsbart efterlevnadspaket och att DeployIfNotExists möjliggör automatisk konfigurationshantering av komponenter som saknas i stor skala. Härnäst går vi igenom resurstaggar och resurslås för att skydda Azure-resurser.