Vad är Azure Policy?

  • Artikel

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.

Kommentar

Mer information om reparation finns i Åtgärda 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.

Några användbara styrningsåtgärder som du kan tillämpa med Azure Policy är:

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

Det är viktigt att känna igen 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 för en principuppsättning). När dina affärsregler har skapats 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 den 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, livscykeln för principtilldelning 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 utvärderingscykeln för standardefterlevnad, 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 rollbaserad åtkomstkontroll i Azure Policy och 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 säkerställer att resurstillståndet är kompatibelt med dina affärsregler utan att behöva bry dig om vem som gjorde ä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, blockerar Azure Policy fortfarande skapande eller uppdatering om resultatet är en resurs som inte är kompatibel.

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 beviljar behörighet till Azure Policy-resurser. Rollen Resursprincipdeltagare 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 i Azure Policy.

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

Kommentar

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

Kommentar

Den hanterade identiteten för en deployIfNotExists eller ändra principtilldelningen behöver tillräckligt med behörigheter 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

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 för 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 (klassisk administratörsauktorisering stöds inte).

Mer specifikt är Microsoft.Network/networkManagers/networkGroups/join/actionden nödvändiga behörigheten för resursprovidern .

Viktigt!

Om du vill ändra dynamiska AVNM-grupper måste du endast beviljas åtkomst via Azure RBAC-rolltilldelning. Klassisk administratör/ä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

Även om en princip kan tilldelas på hanteringsgruppsnivå utvärderas endast resurser på prenumerations- eller resursgruppsnivå.

För vissa resursprovidrar, till exempel Datorkonfiguration, Azure Kubernetes Service och Azure Key Vault, finns det en djupare integrering för att hantera inställningar och objekt. Om du vill veta mer går du till 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-effekt auditIfNotExist i stället för en tillämpningseffekt (deny, modify, deployIfNotExist) 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 lagts 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. Till 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.
  • Tillåts inte resurstyper (Neka): Förhindrar att en lista över resurstyper distribueras.

Om du vill 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 enda ö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 titeln Aktivera övervakning i Microsoft Defender för molnet, med målet att övervaka alla tillgängliga säkerhetsrekommendationer i din Microsoft Defender för molnet-instans.

Kommentar

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 okrypterad 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 övervakningsservrar 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:

Princip Parameternamn Parametertyp Kommentar
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 principA:s parameter – parametern allowedLocations och policyB – 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 refererar till alla resurser, resursgrupper, prenumerationer eller hanteringsgrupper som definitionen har tilldelats 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 exkludera ett underscope 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) i en underordnad hanteringsgrupp eller till och med direkt i prenumerationer. Det här exemplet skulle dock inte fungera eftersom Azure Policy är ett explicit neka-system. 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 nekandetilldelningen.

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 använder alla befintliga tilldelningar av den definitionen den uppdaterade logiken vid utvärdering.

Mer information om hur du anger 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ång hanteringsgruppen eller prenumerationen. För tilldelningar och undantag innebär en post i Omfång hanteringsgruppen, prenumerationen, resursgruppen eller den enskilda resursen.

Där 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 Parameters 20
Initiativdefinition Principer 1000
Initiativdefinition Parameters 400
Princip- eller initiativtilldelningar Undantag (notScopes) 400
Principregel Kapslade villkor 512
Åtgärdsuppgift Resurser 50,000
Principdefinition, initiativ eller brödtext för tilldelningsbegäran Byte 1 048 576

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

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: