Vad är Azure Policy?

Azure Policy hjälper till att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala. Instrumentpanelen för efterlevnad ger en sammanställd vy för att utvärdera miljöns övergripande tillstånd, med möjlighet att öka detaljnivå till detaljnivå per resurs och per princip. Det hjälper också till att få dina resurser att uppfylla efterlevnadskrav genom massreparation för befintliga resurser och automatisk reparation för nya resurser.

Vanliga användningsfall för Azure Policy omfattar implementering av styrning för resurskonsekvens, regelefterlevnad, säkerhet, kostnad och hantering. Principdefinitioner för dessa vanliga användningsfall är redan tillgängliga i Azure-miljön som inbyggda för att hjälpa dig att komma igång.

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

Översikt

Azure Policy utvärderar resurser 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 policySet). När dina affärsregler har skapats tilldelas principdefinitionen eller initiativet till alla omfång av 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. Underscope kan undantas om det behövs. Mer information finns i Omfång i Azure Policy.

Azure Policy använder ett JSON-format för att bilda den logik som utvärderingen använder för att avgöra om en resurs är kompatibel eller inte. Definitionerna 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 tilldelningsomfånget som utvärderas.

Förstå utvärderingsresultat

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

  • En resurs skapas, uppdateras eller tas bort i ett omfång med en principtilldelning.
  • En princip eller ett initiativ har nyligen tilldelats till ett omfång.
  • En princip eller ett initiativ som redan har tilldelats till 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ärderingen sker finns i Utvärderingsutlösare.

Kontrollera svaret på en utvärdering

Affärsregler för hantering av icke-kompatibla resurser varierar mycket mellan olika 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

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

Åtgärda icke-kompatibla resurser

Även om dessa effekter främst påverkar en resurs när resursen skapas eller uppdateras, Azure Policy också stöd för hantering av befintliga icke-kompatibla resurser utan att behöva ändra den 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 resursproviders. Azure Policy begränsar inte åtgärder (kallas även åtgärder). Azure Policy säkerställer att resurstillståndet är kompatibelt med dina affärsregler utan att behöva bekymra sig om vem som gjorde ändringen eller vem som har behörighet att göra en ändring. Vissa Azure Policy, till exempel principdefinitioner, initiativdefinitioneroch 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 är Azure RBAC rätt verktyg att använda. Även om en person har åtkomst till att utföra en åtgärd, om resultatet är en icke-kompatibel resurs, Azure Policy blockerar fortfarande skapa eller uppdatera.

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 Azure Policy åtgärder. Deltagare kan utlösa resursreparation, men kan inte skapa definitioner eller tilldelningar. Administratör för användaråtkomst är nödvändigt för att bevilja den hanterade identiteten på deployIfNotExists eller ändra tilldelningar som krävs behörigheter. Alla principobjekt kan läsas av alla roller i omfånget.

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

Anteckning

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

Resurser som omfattas av Azure Policy

Azure Policy utvärderar alla Azure-resurser på eller under prenumerationsnivå, inklusive Arc-aktiverade resurser. För vissa resursproviders, till exempel gästkonfiguration, Azure Kubernetes Serviceoch Azure Key Vault, finns det en djupare integrering för att hantera inställningar och objekt. Mer information finns i Resursproviderlägen.

Rekommendationer för principhantering

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

  • Börja med en spårningsseffekt i stället för en nekandeeffekt för att spåra den påverkan principdefinitionen får på resurserna i miljön. Om du redan har skript på plats för att automatiskt skala dina program kan dessa automatiserade uppgifter eventuellt blockeras om du anger en nekandeeffekt.

  • 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 principdefinitioner som läggs till i initiativet också 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.

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 Storage-SKU:er (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 virtuell dator (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 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 Azure Security Center, med målet att övervaka alla tillgängliga säkerhetsrekommendationer i Azure Security Center.

Anteckning

SDK, 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 Security Center – För övervakning av okrypterade SQL databaser och servrar.
  • Övervaka os-sårbarheter i Security Center – För att övervaka servrar som inte uppfyller den konfigurerade baslinjen.
  • Övervaka saknade Endpoint Protection i Security Center – För övervakning av servrar utan en installerad Endpoint Protection-agent.

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 parametern för policyAallowedLocations 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 inom ett specifikt omfång. Det här omfånget kan vara allt 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 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 listan över tillåtna resurstyper på hanteringsgruppsnivå. Sedan tilldelar du en mer tillåtande princip (som tillåter fler resurstyper) i en underordnad hanteringsgrupp eller till och med direkt på prenumerationer. Det här exemplet skulle dock inte fungera eftersom Azure Policy är ett system som uttryckligen nekar. 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 leder till att en resurs nekas är det enda sättet att tillåta resursen att ändra tilldelningsnekande.

Mer information om hur du anger tilldelningar via portalen finns i Skapa en principtilldelning för att identifiera icke-kompatibla resurser i Azure-miljön. 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 högsta antal för varje objekttyp för Azure Policy. För definitioner innebär en omfångspost hanteringsgruppen eller prenumerationen. För tilldelningar och undantag innebär en omfångspost hanteringsgruppen,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
Reparationsuppgift Resurser 500

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: