Vad är Azure Policy?

Azure Policy hjälper till att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala. Via dess instrumentpanel för efterlevnad finns en sammanställd vy för att utvärdera miljöns övergripande tillstånd, och du kan öka detaljnivån till per resurs och per princip. Du får också hjälp att säkerställa att resurserna efterlever kraven via massåtgärder för befintliga resurser och automatisk reparation för nya resurser.

Anteckning

Mer information om reparation finns i Reparera icke-kompatibla resurser med Azure Policy.

Några vanliga användningsområden för Azure Policy är att implementera styrning för resurskonsekvens, regelefterlevnad, säkerhet, kostnad och hantering. Principdefinitioner för dessa vanliga användningsområden finns redan inbyggda i din Azure-miljö för att hjälpa dig att komma igång.

Mer specifikt kan du använda några användbara styrningsåtgärder som du kan tillämpa med Azure Policy:

  • Se till att ditt team endast distribuerar Azure-resurser till tillåtna regioner
  • Framtvinga konsekvent tillämpning av taxonomiska taggar
  • Kräva att resurser skickar diagnostikloggar till en Log Analytics-arbetsyta

Det är viktigt att inse att med introduktionen av Azure Arc kan du utöka din principbaserade styrning mellan olika molnleverantörer och även till dina lokala datacenter.

Alla Azure Policy data och objekt krypteras i vila. Mer information finns i Azure-datakryptering i vila.

Översikt

Azure Policy utvärderar resurser och åtgärder i Azure genom att jämföra egenskaperna för dessa resurser med affärsregler. Dessa affärsregler, som beskrivs i JSON-format, kallas principdefinitioner. För att förenkla hanteringen kan flera affärsregler grupperas tillsammans för att bilda ett principinitiativ (kallas ibland en principuppsättning). När dina affärsregler har bildats tilldelas principdefinitionen eller initiativet till alla resurser som Azure stöder, till exempel hanteringsgrupper, prenumerationer, resursgrupper eller enskilda resurser. Tilldelningen gäller för alla resurser inom Resource Manager omfånget för tilldelningen. Subscopes kan uteslutas, om det behövs. Mer information finns i Omfång i Azure Policy.

Azure Policy använder ett JSON-format för att skapa den logik som utvärderingen använder för att avgöra om en resurs är kompatibel eller inte. Definitioner omfattar metadata och principregeln. Den definierade regeln kan använda funktioner, parametrar, logiska operatorer, villkor och egenskapsalias för att matcha exakt det scenario du vill ha. Principregeln avgör vilka resurser i tilldelningens omfång som utvärderas.

Förstå utvärderingsresultat

Resurser utvärderas vid specifika tidpunkter under resurslivscykeln, policytilldelningens livscykel och för regelbunden löpande efterlevnadsutvärdering. Följande är de tider eller händelser som gör att en resurs utvärderas:

  • En resurs skapas eller uppdateras i ett omfång med en principtilldelning.
  • En princip eller ett initiativ har nyligen tilldelats ett omfång.
  • En princip eller ett initiativ som redan har tilldelats ett omfång uppdateras.
  • Under standardutvärderingscykeln för efterlevnad, som inträffar en gång var 24:e timme.

Detaljerad information om när och hur principutvärdering sker finns i Utvärderingsutlösare.

Kontrollera svaret på en utvärdering

Affärsregler för hantering av icke-kompatibla resurser varierar kraftigt mellan organisationer. Exempel på hur en organisation vill att plattformen ska svara på en icke-kompatibel resurs är:

  • Neka resursändringen
  • Logga ändringen till resursen
  • Ändra resursen före ändringen
  • Ändra resursen efter ändringen
  • Distribuera relaterade kompatibla resurser
  • Blockera åtgärder för resurser

Azure Policy gör var och en av dessa affärssvar möjliga genom tillämpning av effekter. Effekter anges i principregeldelen i principdefinitionen.

Åtgärda icke-kompatibla resurser

Även om dessa effekter främst påverkar en resurs när resursen skapas eller uppdateras, stöder Azure Policy även hantering av befintliga icke-kompatibla resurser utan att behöva ändra resursen. Mer information om hur du gör befintliga resurser kompatibla finns i Åtgärda resurser.

Videoöversikt

Följande översikt över Azure Policy är från Build 2018. För nedladdning av bilder eller video besöker du sidan om att styra Azure-miljön via Azure Policy på Channel 9.

Komma igång

Azure Policy och Azure RBAC

Det finns några viktiga skillnader mellan Azure Policy och rollbaserad åtkomstkontroll i Azure (Azure RBAC). Azure Policy utvärderar tillstånd genom att undersöka egenskaper för resurser som representeras i Resource Manager och egenskaper för vissa resursprovidrar. Azure Policy ser till att resurstillståndet är kompatibelt med dina affärsregler utan att behöva bry sig om vem som har gjort ändringen eller vem som har behörighet att göra en ändring. Azure Policy via DenyAction-effekten kan också blockera vissa åtgärder på resurser. Vissa Azure Policy resurser, till exempel principdefinitioner, initiativdefinitioner och tilldelningar, är synliga för alla användare. Den här designen möjliggör transparens för alla användare och tjänster för vilka principregler som anges i deras miljö.

Azure RBAC fokuserar på att hantera användaråtgärder i olika omfång. Om kontroll av en åtgärd krävs baserat på användarinformation är Azure RBAC rätt verktyg att använda. Även om en individ har åtkomst till att utföra en åtgärd, om resultatet är en icke-kompatibel resurs, blockerar Azure Policy fortfarande skapande eller uppdatering.

Kombinationen av Azure RBAC och Azure Policy ger fullständig omfångskontroll i Azure.

Azure RBAC-behörigheter i Azure Policy

Azure Policy har flera behörigheter, som kallas åtgärder, i två olika resursprovidrar:

Många inbyggda roller ger behörighet till Azure Policy resurser. Resursprincipdeltagarerollen innehåller de flesta Azure Policy åtgärder. Ägare har fullständiga behörigheter. Både deltagare och läsare har åtkomst till alla läsåtgärder Azure Policy.

Deltagaren kan utlösa resursreparation, men kan inte skapa eller uppdatera definitioner och tilldelningar. Administratör för användaråtkomst är nödvändigt för att bevilja den hanterade identiteten för deployIfNotExists eller ändra nödvändiga behörigheter för tilldelningar.

Anteckning

Alla principobjekt, inklusive definitioner, initiativ och tilldelningar, kan läsas för alla roller i dess omfång. En principtilldelning som är begränsad till en Azure-prenumeration kan till exempel läsas av alla rollinnehavare i prenumerationsomfånget och nedan.

Om ingen av de inbyggda rollerna har de behörigheter som krävs skapar du en anpassad roll.

Azure Policy åtgärder kan ha en betydande inverkan på din Azure-miljö. Endast den minsta uppsättning behörigheter som krävs för att utföra en uppgift ska tilldelas och dessa behörigheter bör inte beviljas till användare som inte behöver dem.

Anteckning

Den hanterade identiteten för en deployIfNotExists eller ändra principtilldelningen behöver tillräcklig behörighet för att skapa eller uppdatera målresurser. Mer information finns i Konfigurera principdefinitioner för reparation.

Särskilda behörighetskrav för Azure Policy med Azure Virtual Network Manager (förhandsversion)

Med Azure Virtual Network Manager (förhandsversion) kan du tillämpa konsekventa hanterings- och säkerhetsprinciper på flera virtuella Azure-nätverk (VNet) i hela molninfrastrukturen. Dynamiska Grupper i Azure Virtual Network Manager (AVNM) använder Azure Policy definitioner för att utvärdera VNet-medlemskap i dessa grupper.

Om du vill skapa, redigera eller ta bort dynamiska grupprinciper i Azure Virtual Network Manager behöver du:

  • Läsa och skriva Azure RBAC-behörigheter till den underliggande principen
  • Azure RBAC-behörigheter för att ansluta till nätverksgruppen (Obs! Klassisk Admin auktorisering stöds inte)

Mer specifikt är Microsoft.Network/networkManagers/networkGroups/join/actionden nödvändiga resursproviderns behörighet .

Viktigt

Om du vill ändra dynamiska AVNM-grupper måste du endast beviljas åtkomst via Azure RBAC-rolltilldelning. Klassisk Admin/äldre auktorisering stöds inte. Det innebär att om ditt konto bara tilldelades rollen medadministratörsprenumeration skulle du inte ha några behörigheter för dynamiska AVNM-grupper.

Resurser som omfattas av Azure Policy

Azure Policy utvärderar alla Azure-resurser på eller under prenumerationsnivå, inklusive Arc-aktiverade resurser. För vissa resursprovidrar som Datorkonfiguration, Azure Kubernetes Service och Azure Key Vault finns det en djupare integrering för att hantera inställningar och objekt. Mer information finns i Lägen för resursprovider.

Rekommendationer för principhantering

Här följer några råd och tips att tänka på:

  • Börja med en audit eller auditIfNotExist effekt i stället för en tvingande (deny, modify, deployIfNotExist) effekt för att spåra effekten av din principdefinition på resurserna i din miljö. Om du redan har skript för automatisk skalning av dina program kan en tillämpningseffekt hindra sådana automatiseringsuppgifter som redan finns.

  • Ta hänsyn till på organisationens hierarkier när du skapar definitioner och tilldelningar. Vi rekommenderar att du skapar definitioner på högre nivåer, som på hanteringsgrupps- eller prenumerationsnivå. Skapa sedan tilldelningen på nästa underordnade nivå. Om du skapar en definition för en hanteringsgrupp, kan tilldelningen begränsas till en prenumeration eller resursgrupp inom den hanteringsgruppen.

  • Vi rekommenderar att du skapar och tilldelar initiativdefinitioner även för en enskild principdefinition. Om du som exempel har principdefinitionen policyDefA, så skapar du den under initiativdefinitionen initiativeDefC. Om du skapar en annan principdefinition senare för policyDefB med mål som liknar dem för policyDefA, kan du lägga till den under initiativeDefC och spåra dem tillsammans.

    • När du har skapat en initiativtilldelning blir även principdefinitioner som läggs till i initiativet en del av initiativets tilldelningar.

    • När en initiativtilldelning utvärderas, utvärderas även alla principer inom initiativet. Om du behöver utvärdera en princip individuellt är det bättre att inte inkludera den i ett initiativ.

  • Hantera Azure Policy resurser som kod med manuella granskningar av ändringar i principdefinitioner, initiativ och tilldelningar. Mer information om föreslagna mönster och verktyg finns i Designa Azure Policy som kodarbetsflöden.

Azure Policy objekt

Definition av princip

Resan med att skapa och implementera en princip i Azure Policy börjar med skapandet av en principdefinition. Varje principdefinition har villkor för när den ska tillämpas. Och den har en definierad effekt som träder ikraft om villkoren är uppfyllda.

Vi erbjuder flera inbyggda principer som är tillgängliga för dig som standard i Azure Policy. Exempel:

  • Tillåtna SKU:er för lagringskonto (neka): Avgör om ett lagringskonto som distribueras ligger inom en uppsättning SKU-storlekar. Effekten är att neka alla lagringskonton som inte överensstämmer med uppsättningen definierade SKU-storlekar.
  • Tillåten resurstyp (neka): Definierar de resurstyper som du kan distribuera. Effekten är att neka alla resurser som inte finns på den definierade listan.
  • Tillåtna platser (neka): Begränsar tillgängliga platser för nya resurser. Effekten används för att genomdriva kraven på geo-efterlevnad.
  • Tillåtna SKU:er för virtuella datorer (neka): Anger en uppsättning SKU:er för virtuella datorer som du kan distribuera.
  • Lägg till en tagg i resurser (Ändra): Tillämpar en obligatorisk tagg och dess standardvärde om den inte anges av distributionsbegäran.
  • Inte tillåtna resurstyper (Neka): Förhindrar att en lista över resurstyper distribueras.

För att implementera dessa principdefinitioner (både inbyggda och anpassade definitioner) måste du tilldela dem. Du kan tilldela de här principerna via Azure-portalen, PowerShell eller Azure CLI.

Principutvärdering sker med flera olika åtgärder, till exempel tilldelning av principer eller principuppdateringar. En fullständig lista finns i Principutvärderingsutlösare.

Läs mer om principdefinitionernas strukturer i artikeln, struktur för principdefinitioner.

Principparametrar underlättar hanteringen av principer genom att minska antalet principdefinitioner du måste skapa. Du kan definiera parametrar när du skapar en principdefinition så att den blir mer allmän. Sedan kan du återanvända den principdefinitionen för olika scenarier. Det gör du genom att ange olika värden när du tilldelar principdefinitionen. Till exempel ange du en uppsättning platser för en prenumeration.

Parametrar definieras när du skapar en principdefinition. När en parameter definieras tilldelas den ett namn och eventuellt ett bestämt värde. Du kan till exempel definiera en parameter för en princip med titeln plats. Sedan kan du ge den olika värden som EastUS eller WestUS när du tilldelar en princip.

Mer information om principparametrar finns i Struktur för definitioner – parametrar.

Initiativdefinition

En initiativdefinition är en samling principdefinitioner som är skräddarsydda för att uppnå ett unikt övergripande mål. Initiativdefinitioner gör det enklare att hantera och tilldela principdefinitioner genom att de grupperar en uppsättning principer som ett enda objekt. Du kan till exempel skapa ett initiativ med namnet Aktivera övervakning i Microsoft Defender för molnet, med målet att övervaka alla tillgängliga säkerhetsrekommendationer i din Microsoft Defender för molninstansen.

Anteckning

SDK:t, till exempel Azure CLI och Azure PowerShell, använder egenskaper och parametrar med namnet PolicySet för att referera till initiativ.

Under det här initiativet skulle du ha principdefinitioner som dessa:

  • Övervaka okrypterade SQL Database i Microsoft Defender för molnet – För övervakning av okrypterade SQL-databaser och servrar.
  • Övervaka säkerhetsproblem i Microsoft Defender för molnet – För övervakning av servrar som inte uppfyller den konfigurerade baslinjen.
  • Övervaka saknat Endpoint Protection i Microsoft Defender för molnet – För övervakning av servrar utan en installerad slutpunktsskyddsagent.

Precis som principparametrar underlättar initiativparametrar initiativhanteringen genom att minska redundansen. Initiativparametrar är parametrar som används av principdefinitionerna inom ett initiativ.

Ta till exempel scenariot där du har en initiativdefinition, initiativeC, med principdefinitionerna policyA och policyB som vardera förväntar sig olika typer av parametrar:

Policy Parameternamn Parametertyp Anteckning
principA allowedLocations matris Den här parametern förväntar sig en lista med strängar för ett värde eftersom parametertypen har definierats som en matris
principB allowedSingleLocation sträng Den här parametern förväntar sig ett ord som värde eftersom parametertypen har definierats som en sträng

I det här scenariot, när du definierar initiativparametrar för initiativC, har du tre alternativ:

  • Använd parametrarna för principdefinitionerna i det här initiativet. I det här exemplet blir allowedLocations och allowedSingleLocation initiativparametrar för initiativC.
  • Ange värden för parametrarna för principdefinitionerna i den här initiativdefinitionen. I det här exemplet kan du ange en lista över platser till policyA:s parameter – allowedLocations och policyB:s parameter – allowedSingleLocation. Du kan också ange värden när du tilldelar det här initiativet.
  • Ange en lista med alternativ värden som kan användas när du tilldelar det här initiativet. När du tilldelar det här initiativet kan ärvda parametrarna från principdefinitionerna inom initiativet endast ha värden från den här listan.

När du skapar värdealternativ i en initiativdefinition kan du inte ange ett annat värde under initiativtilldelningen eftersom det inte ingår i listan.

Mer information om strukturerna för initiativdefinitioner finns i Initiativdefinitionsstruktur.

Tilldelningar

En tilldelning är en principdefinition eller ett initiativ som har tilldelats till ett visst omfång. Det här omfånget kan sträcka sig från en hanteringsgrupp till en enskild resurs. Termen omfång avser alla resurser, resursgrupper, prenumerationer eller hanteringsgrupper som definitionen är tilldelad till. Tilldelningar ärvs av alla underordnade resurser. Den här designen innebär att en definition som tillämpas på en resursgrupp också tillämpas på resurser i den resursgruppen. Du kan dock undanta ett underskop från tilldelningen.

I prenumerationsomfånget kan du till exempel tilldela en definition som förhindrar att nätverksresurser skapas. Du kan undanta en resursgrupp i prenumerationen som är avsedd för nätverksinfrastruktur. Du beviljar därefter åtkomst till den här nätverksresursgruppen för användare som du litar på för att skapa nätverksresurser.

I ett annat exempel kanske du vill tilldela en definition av resurstypen allowlist på hanteringsgruppsnivå. Sedan tilldelar du en mer tillåtande princip (tillåter fler resurstyper) för en underordnad hanteringsgrupp eller till och med direkt i prenumerationer. Det här exemplet skulle dock inte fungera eftersom Azure Policy är ett explicit nekandesystem. I stället måste du undanta den underordnade hanteringsgruppen eller prenumerationen från tilldelningen på hanteringsgruppsnivå. Tilldela sedan den mer tillåtande definitionen på den underordnade hanteringsgruppen eller prenumerationsnivån. Om en tilldelning resulterar i att en resurs nekas är det enda sättet att tillåta resursen att ändra tilldelningen som nekar.

Principtilldelningar använder alltid det senaste tillståndet för sin tilldelade definition eller sitt initiativ vid utvärdering av resurser. Om en principdefinition som redan har tilldelats ändras kommer alla befintliga tilldelningar av den definitionen att använda den uppdaterade logiken vid utvärdering.

Mer information om hur du ställer in tilldelningar via portalen finns i Skapa en principtilldelning för att identifiera icke-kompatibla resurser i Din Azure-miljö. Steg för PowerShell och Azure CLI är också tillgängliga. Information om tilldelningsstrukturen finns i Tilldelningsstruktur.

Maximalt antal Azure Policy objekt

Det finns ett maximalt antal för varje objekttyp för Azure Policy. För definitioner innebär en post i Omfånghanteringsgruppen eller prenumerationen. För tilldelningar och undantag innebär en post i Omfånghanteringsgruppen, prenumerationen, resursgruppen eller den enskilda resursen.

Var Vad Maximalt antal
Omfång Principdefinitioner 500
Omfång Initiativdefinitioner 200
Klientorganisation Initiativdefinitioner 2 500
Omfång Princip- eller initiativtilldelningar 200
Omfång Undantag 1000
Definition av princip Parametrar 20
Initiativdefinition Principer 1000
Initiativdefinition Parametrar 300
Princip- eller initiativtilldelningar Undantag (notScopes) 400
Principregel Kapslade villkor 512
Reparationsaktivitet Resurser 50 000
Begärandetext för principdefinition, initiativ eller tilldelning Byte 1 048 576

Principregler har ytterligare gränser för antalet villkor och deras komplexitet. Mer information finns i Begränsningar för principregler .

Nästa steg

Nu när du har en översikt över Azure Policy och några av de centrala begreppen föreslår vi följande som nästa steg: