Dela via

Anta principdrivna skyddsräcken

  • Artikel

Innan du använder principer måste du förstå var de används i referensimplementeringarna för Azure-landningszonen och varför. Den här artikeln hjälper dig att förstå om du vill förhindra att DeployIfNotExists (DINE) eller Modifiera principer gör ändringar i din Azure-miljö.

Varför ska du använda DINE- och Modify-principer?

DINE- och Modify-principer är en del av referensimplementeringarna för Azure-landningszonen. De hjälper dig och din organisation att se till att dina landningszoner, som även kallas prenumerationer, och resurserna i dem är kompatibla. Dessa principer tar också bort driftbelastningen för plattforms- och landningszonteam när din Azure-miljö skalar.

Tänk dig till exempel ett scenario där en prenumeration för landningszoner etableras och placeras i hanteringsgruppen "corp". PRINCIPERNA DINE och Modify vidtar sedan följande åtgärder för prenumerationen på landningszonen:

  • Aktivera Microsoft Defender för molnet. Konfigurera Defender for Cloud-exporter till den centrala Log Analytics-arbetsytan i hanteringsprenumerationen.
  • Aktivera Defender för Cloud-tjänster för de olika erbjudanden som stöds, baserat på de principparametrar som konfigurerats vid principtilldelningen.
  • Konfigurera azure-aktivitetsloggarna så att de skickas till den centrala Log Analytics-arbetsytan i hanteringsprenumerationen.
  • Konfigurera diagnostikinställningarna för alla resurser som ska skickas till den centrala Log Analytics-arbetsytan i hanteringsprenumerationen.
  • Distribuera nödvändiga Azure Monitor-agenter för virtuella datorer och Azure Virtual Machine Scale Sets, inklusive Azure Arc-anslutna servrar. Anslut dem till den centrala Log Analytics-arbetsytan i hanteringsprenumerationen.

Note

Du kan inaktivera föregående alternativ när som helst eller under distributionen av referensimplementeringarna för Azure-landningszonen.

Följande lista visar en delmängd av alla principer som har tilldelats som en del av Azure-landningszonacceleratorn. En fullständig lista över principer som kan tilldelas av referensimplementeringen för Azure-landningszonen finns i Policyer som ingår i Referensimplementeringar för Azure-landningszoner.

Azure-landningszonernas bicep-repo är modulärt. Ovanstående standardprinciper kan distribueras med ALZ-modulen för standardprinciptilldelningar.

Alla tilldelade principer hjälper dig och landningszonens ägare att förbli kompatibla. Inga faktiska arbetsbelastningsresurser distribueras via DINE- eller Modifikation-policyer. Vi rekommenderar inte heller detta. Mer information finns i Ska vi använda Azure Policy för att distribuera arbetsbelastningar?. Endast extra eller stödjande resurser eller inställningar distribueras eller konfigureras av dessa DINE-principer.

Referensimplementeringar för Azure-landningszoner använder DINE- Azure-principer som hjälper dig att uppnå principdriven styrning i din Azure-miljö. Men du kanske inte kan använda DINE- eller Ändringsprinciper, eller så är du inte redo att aktivera den här typen av Azure-principeffekt på grund av:

  • Regelefterlevnadsprinciper, standarder eller lagbegränsningar.
  • Strikta ändringskontrollprocesser som kräver mänskligt godkännande för varje åtgärd i din Azure-miljö.
  • Brist på expertis, erfarenhet och förståelse för hur du hanterar och använder DINE-principer.
  • Organisationskrav att alla arbetsbelastningsresurskonfigurationer, inklusive extra resurser, stödresurser och inställningar, definieras i infrastruktur som kod (IaC) av arbetsbelastningsprogramteamen.

Om du passar in i föregående exempel eller liknande scenarier hjälper den här artikeln dig att förstå hur du implementerar den konceptuella arkitekturen i Azure-landningszonen och följer dess designprinciper. Även om du inte använder vissa principer från början kan du välja att gradvis aktivera dem i framtiden. Målet är att hjälpa dig att uppnå principdriven styrning.

Viktig

I den här artikeln ser du två möjliga värden som används för villkoren för tvingande läge:

  • Inaktiverad eller Tvinga Inte
  • Aktiverad eller förvald

Azure-portalen använder Inaktiverad och Aktiverad för tvingande läge. Azure Resource Manager-mallar (ARM) och andra API-gränssnitt använder DoNotEnforce och Default för samma alternativ.

För mer information, se genomförandeläge.

Om du fortfarande är säker på att din organisation inte kan använda DINE- eller Ändringsprinciper förklarar den här artikeln hur du förhindrar (kallas även inaktivera) principer från att göra automatiska ändringar i Azure-miljön.

Note

Den här åtgärden är inte permanent. Principerna kan när som helst återaktiveras av en medlem i ditt team om du senare bestämmer dig för att använda DINE eller modifiera policyer.

Mer information finns i fas 2 och fas 3.

Stöd för resursväljare gäller även för principdriven styrning för att säkerställa att SDP (Safe Deployment Practices) följs. Med resursväljare kan du gradvis distribuera principtilldelningar baserat på faktorer som resursplats, resurstyp eller om resursen har en plats. Mer finns i det här dokumentet.

Översikt över metod

Följande diagram sammanfattar den föreslagna stegvisa metoden:

grafik som visar en ÖVERSIKT över DINE-faser.

  1. Ange efterlevnadsläge till DoNotEnforce för principtilldelningar.
    • Genom att använda den här funktionen kan du ändra tilldelningens beteende så att den effektivt blir en princip endast för granskning utan att ändra den underliggande principdefinitionen.
    • Med den här metoden kan du också utföra manuella reparationsåtgärder på icke-kompatibla resurser med hjälp av reparationsuppgifter om du vill.
  2. Ange tvingande läge till Default på principtilldelningar för att återaktivera DINE-principtilldelningars automatiska reparation på ett reducerat omfång:
    • Du kan välja att använda en hel miljö, till exempel Sandbox-hanteringsgruppen.
    • Eller så kan du använda en icke-kritisk arbetsbelastningsprenumeration.
  3. Ange tvingande läge till Default på principtilldelningar för återstående DINE-principer i hela Azure-miljön.

På grund av regelefterlevnadsbegränsningar kan vissa kunder aldrig gå förbi fas 1. Detta är inte ett problem och kan fortsätta att vara i det här tillståndet om det behövs. Andra kunder kan gå vidare till fas 2 och 3 för att helt anta DINE- och Modify-principer för att hjälpa till med principdriven styrning för sin Azure-miljö.

Not

Scenariot och metoden som beskrivs i den här artikeln är inte avsedd för eller rekommenderas för de flesta kunder. Läs avsnittet Varför ska du använda DINE- och Ändra-principer? innan du bestämmer dig för om dessa principer är lämpliga och nödvändiga för din miljö.

Fas 1: Inaktivera automatiserade åtgärder för DINE och Ändra principer

När du tilldelar en princip gäller som standard den effekt som definierats i principdefinitionen. Vi rekommenderar att du lämnar principdefinitionen som den är. Lämna till exempel principtilldelningseffekten som DeployIfNotExists.

I stället för att ändra principdefinitionen eller dess effekt kan du i stället påverka det här beteendet med minimal ansträngning genom att använda funktionen för principtilldelningar.

Använd Azure-portalen för att ange tvingande läge till Inaktiverat

Den här skärmbilden visar hur du använder Azure-portalen för att ange tvingande läge till Inaktiverad för en principtilldelning. Avaktiverad kallas även DoNotEnforce.

Ange tvingande läge till Inaktiverat i Azure-portalen.

Använd ARM-mallen för att ange tvingande läge till DoNotEnforce

Det här kodexemplet visar hur du använder en ARM-mall för att ange enforcementMode till DoNotEnforce för en principtilldelning. DoNotEnforce kallas även Disabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "DoNotEnforce"
    … // other properties removed for display purposes
  }
}

Genom att använda verkställandemoduskan du se effekten av en princip på befintliga resurser utan att påbörja den eller utlösa poster i Azure-aktivitetsloggen. Det här scenariot kallas ofta "What If" och överensstämmer med säkra distributionsmetoder.

Även om tvingande läge är inställt på DoNotEnforcekan reparationsuppgifter utlösas manuellt. Du kan åtgärda specifika icke-kompatibla resurser. Du kan också se vad DINE- eller Ändra-principen skulle ha gjort om tillämpningsläge var inställt på Default.

Viktig

När tvingande läge är inställt på DoNotEnforcegenereras inte poster i Azure-aktivitetsloggen. Tänk på den här faktorn om du vill bli meddelad när en inkompatibel resurs skapas.

Stanna kvar i fas 1-tillståndet permanent

Som nämnts i Approach-översikten avsnittet kan vissa kunder behöva stanna kvar i fas 1 under en längre period eller till och med permanent på grund av sina krav. Det här tillståndet är giltigt och kunderna kan vara kvar i det under en längre tid.

Kanske måste du stanna i detta tillstånd permanent eller under en lång period, som år. I så fall kan det vara bättre att använda principeffekten AuditIfNotExists (AINE) och associerade definitioner och ställa in tvingande läge på Default.

Note

Genom att ändra till att använda en AINE-princip och ställa in tvingande läge på Defaultuppnår du fortfarande samma mål att inaktivera DINE.

När du ändrar från DINE till AINE och ställer in verkställighetsläget tillbaka till Default som en långsiktig eller permanent metod för fas 1 får du tillbaka Azure-aktivitetsloggposterna för policyefterlevnadsstatus. Du kan skapa automatiseringsarbetsflöden från dessa loggposter i dina övergripande plattformshanteringsåtgärder.

Du förlorar möjligheten att utföra manuella reparationsåtgärder. Till skillnad från DINE-principer utför AINE-principer inga distributioner, varken automatiserade eller manuella.

Kom ihåg att uppdatera principdefinitionen så att den accepterar och tillåter AuditIfNotExists principtilldelningseffekt.

I följande tabell sammanfattas alternativen och konsekvenserna för de olika typerna av principeffekter och kombinationer av tvingande läge:

Policyeffekt Verkställighetsläge Aktivitetsloggpost Åtgärd för reparation
ÄTA Aktiverad eller standard Ja Plattformsutlöst reparation i stor skala efter skapande eller resursuppdatering. Manuellt skapande av en reparationsuppgift som krävs om beroende resurs ändras eller finns före principtilldelningen.
ÄTA Inaktiverad eller Tvinga inte igenom Nej Krävs: Manuellt skapande av åtgärdsuppgift.
Modifiera Aktiverad eller förvald Ja Automatisk reparation när du skapar eller uppdaterar.
Modifiera Inaktiverad eller IngenTillämpning Nej Manuellt skapande av en åtgärdsuppgift krävs.
Neka Aktiverad eller förvald Ja Skapande eller uppdatering nekad.
Neka Inaktiverad eller DoNotEnforce Nej Skapande eller uppdatering tillåts. Manuell reparation krävs.
Granskning/AINE Aktiverad eller standard Ja Manuell reparation krävs.
Granskning/AINE Inaktiverad eller DoNotEnforce Nej Manuell reparation krävs.

Observera

Granska vägledningen i Reagera på förändringar i Azure Policy-statushändelser för att förstå om användning av Azure Event Grid-integration med Azure Policy ger en lämplig metod om du planerar att bygga din egen automation baserat på policy-statusevenemang.

Fas 2: Aktivera DINE och ändra principer för en specifik policy eller reducerat omfång

I den här fasen får du lära dig hur du ställer in genomdrivningsläge till Default på principtilldelningar.

När du har slutfört fas 1bestämmer du dig för att du vill testa och prova DINE- och Modify-policyns fullständiga automatiseringsmöjligheter på en specifik policy eller ett begränsat omfång. Du vill använda sandbox-hanteringsgruppen eller en icke-produktionsbaserad arbetsbelastningsprenumeration.

För att göra den här proceduren måste du först identifiera den princip eller det begränsade omfång som ska användas för att testa och prova DINE- och Modify-principernas fullständiga automatiseringsfunktioner.

Not

Du kanske vill granska och implementera en testmetod för en plattform i företagsskala. På så sätt kan du testa principer och andra plattformsändringar i en avgränsad hanteringsgruppshierarki i samma klientorganisation.

Den här metoden kallas även för en "canary"-utbyggnad.

Några exempel på omfång och principer visas i följande tabell:

När du vill... Välj bland dessa omfång Exempelprinciper som ska användas
– Testa DINE/Modify automatiserad åtgärdshantering.
– Kontrollera hur dina fullständiga distributionsprocesser och CI/CD-pipelines, inklusive tester, kan påverkas.
– Kontrollera hur din arbetsbelastning kan påverkas.		 – Sandbox-prenumeration
– Sandbox-hanteringsgrupp
– Prenumeration på landningszon för icke-produktionsarbetsbelastningar
- Kanariemiljö på företagsnivå		 – Konfigurera Azure-aktivitetsloggar för att strömma till en angiven Log Analytics-arbetsyta.
– Distribuera Defender för molnkonfiguration.
– Aktivera Azure Monitor för virtuella datorer eller VM-skalningsuppsättningar.
– Distribuera diagnostikinställningar till Azure-tjänster.
- Eventuellt aktiveras endast för specifika tjänster inom initiativet.

Du kan också välja att använda en manuell reparationsaktivitet i ett begränsat omfång eller en uppsättning resurser för att testa hur dessa principer påverkar din miljö. Mer information om hur du skapar en reparationsaktivitet finns i Azure Policy-dokumentationen Skapa en reparationsuppgift.

När du har identifierat en princip, eller principer och det begränsade omfånget för att tilldela dem, är nästa steg att tilldela principen och ange tvingande läge till Default. Lämna policyeffekten, till exempel DeployIfNotExists eller Modify, precis som på det begränsade omfång som du har valt.

Använd Azure-portalen för att ange tvingande läge till Aktiverad

Den här skärmbilden visar hur du använder Azure-portalen för att ställa in tvingande läge på Aktiverad för en principtilldelning. Alternativet 'Aktiverad' kallas också för standard.

Skärmbild som visar hur du ställer in tvingande läge på Aktiverad i Azure-portalen.

Använd en ARM-mall för att ange tvingande läge till Standard

Det här kodexemplet visar hur du använder en ARM-mall för att ange enforcementMode till Default för en principtilldelning. Default kallas även Enabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "Default"
    … // other properties removed for display purposes
  }
}

Testning

Det sista steget i den här fasen är att utföra den nödvändiga testningen. Du vill kontrollera om och hur DINE eller ändringsprinciper kan ha påverkat och ändrat dina arbetsbelastningar, din kod, dina verktyg och processer.

Utför flera tester för att samla in hela arbetsbelastningens livscykel. Du vill se till att du fullständigt förstår om och hur DINE- eller Modifiera-principer har gjort ändringar.

Några exempel på testning är:

  • Inledande distribution av arbetsbelastning.
  • Kod-/applikationsdistribution på arbetsbelastning.
  • Dag 2-åtgärder och hantering av arbetsbelastning.
  • Avaktivering av arbetsbelastning.

Fas 3: Aktivera DINE- och Ändra principer överallt

I den här fasen får du lära dig hur du ställer in införandeläge till Default på principtilldelningar.

Vi antar att din -testning i slutet av fas 2 har godkänts. Eller så kanske du är nöjd med att du nu förstår hur DINE- eller Modify-principer interagerar med din arbetsbelastning. Nu kan du utöka användningen av DINE- och Modify-principer i resten av Azure-miljön.

För att fortsätta följer du stegen som liknar stegen i fas 2. Den här gången ställer du in efterlevnadsläge på Default på alla DINE- och Modifiera principtilldelningar i hela Azure-miljön.

Här är en översikt på hög nivå över de steg du gör i den här fasen:

  • Ta bort uppgifter som används specifikt för testning under fas 2.
  • Gå igenom varje DINE- och ändra policytilldelning i din Azure-miljö och ange tvingande läge till Default. Den här processen visas i exemplen i fas 2.
  • Skapa reparationsuppgifter för befintliga resurser som inte är kompatibla genom att följa riktlinjerna i Skapa en reparationsaktivitet. Nya resurser åtgärdas automatiskt om de matchar principreglerna och existensvillkoren.

Även om vi i fas 3 rekommenderar att du ställer in tvingande läge på Default för alla DINE- och Ändra-principer i din Azure-miljö är det här valet fortfarande valfritt. Du kan göra det här valet per princip så att det passar dina behov och krav.

Avancerad principhantering

För avancerad hantering av Azure Policy i stor skala bör du överväga att implementera Enterprise Policy as Code (EPAC) för att hantera principer. EPAC ger en tillståndsbaserad hanteringsupplevelse som använder IaC. Det passar vanligtvis stora principhanteringsscenarier med komplexa krav.