Hantera programutvecklingsmiljöer i Azure-landningszoner

Artikel
12/13/2023

Den här artikeln beskriver hur molnplattformsteam kan implementera skyddsräcken för att hantera programmiljöer i Azure-landningszoner. Den förklarar också hur du anpassar olika programutvecklingsmiljöer till deras ramverk. En viktig aspekt när du skapar rätt miljö är att placera prenumerationer i lämpliga hanteringsgrupper.

Ange grunden

Utvecklingsteam kräver möjligheten att iterera snabbt, och molnstyrnings- och plattformsteam behöver hantera organisationsrisker, efterlevnad och säkerhet i stor skala. Du kan hantera programmiljöer korrekt genom att fokusera på två viktiga designprinciper för Azure-landningszoner: principdriven styrning och prenumerationsdemokratisering. Dessa principer ger grundläggande skyddsmekanismer och beskriver hur du delegerar kontroller till programteam. Programteamen använder Vägledning för Azure Well-Architected Framework för att utforma sin arbetsbelastning. De distribuerar och hanterar sina egna resurser i landningszonen, och plattformsteamet styr resurserna genom att tilldela Azure-principer.

Det är viktigt att tillhandahålla sandbox-resurser för halvstyrda resurser, så att programteam kan experimentera med tekniker och funktioner.

När programägare använder prenumerationsförsäljning eller andra processer för att skapa prenumerationer måste de veta hur de begär prenumerationer för flera utvecklingsmiljöer.

I den här artikeln beskrivs Azure-landningszonen, inklusive hanteringsgrupper, principer och arkitektur för delad plattform, samt landningszonen för arbetsbelastningar eller program.

Kommentar

Vägledningen i den här artikeln gäller endast för arbetsbelastnings- eller programlandningszoner. Information om testning och miljösegregering för själva Azure-landningszonplattformen finns i Testmetod för Azure-landningszoner, som beskriver kanariemetoden.

I praktiken kan du använda valfritt antal och typer av fasade miljöer. Den här artikeln refererar till följande fasade miljöer.

Environment	beskrivning	Hanteringsgrupp
Sandbox-miljö	Miljön som används för snabb innovation av prototyper men inte produktionsbundna konfigurationer	Sandbox-hanteringsgrupp
Utveckling	Miljön som används för att skapa potentiella versionskandidater	Arketyphanteringsgrupp, till exempel corp eller online
Testa	Miljön som används för att utföra testning, inklusive enhetstestning, godkännandetestning av användare och kvalitetssäkringstestning	Arketyphanteringsgrupp, till exempel corp eller online
Produktion	Miljön som används för att leverera värde till kunder	Arketyphanteringsgrupp, till exempel corp eller online

Mer information finns i videorna Hantera utvecklings-, testnings- och produktionsmiljöer för programarbetsbelastningar och Hur många prenumerationer ska jag använda i Azure?

Miljöer, prenumerationer och hanteringsgrupper

En förutsättning för det här avsnittet finns i Designområdet för resursorganisation.

Du måste ordna dina prenumerationer korrekt när du använder metoder för Azure-landningszoner. Helst bör varje programmiljö ha en egen prenumeration. Den här metoden tillhandahåller säkerhets- och principkontroller som håller miljöerna isolerade. Den innehåller potentiella problem i en miljö.

Separata prenumerationer har samma principer på arketypsnivå. Om det behövs kan programägare tilldela prenumerationsspecifika principer för att framtvinga program- och miljöspecifikt beteende.

Vissa programarkitekturer kräver att tjänsterna delas mellan miljöer. Om så är fallet kan du använda en enda prenumeration för flera miljöer. Vi rekommenderar att arbetsbelastningsägare arbetar med molnplattformsteam för att avgöra om en enda prenumeration för flera miljöer behövs.

Använd en enda prenumeration för flera programmiljöer om:

Miljöer kan inte isoleras i sina egna prenumerationer.
Miljöerna har samma team tilldelade funktionella roller, till exempel nätverksoperatorer.
Miljöerna kan använda samma principer.

Om en program- eller tjänstarbetsbelastning måste finnas i en enda prenumeration och du behöver göra ändringar i de principer som gäller för varje miljö kan du:

Skapa en ny arketypjusterad hanteringsgrupp under hanteringsgruppen för landningszoner. Mer information finns i Hanteringsgruppshierarki i den här artikeln.
Använd sandbox-prenumerationer för utvecklingsaktiviteter. Sandbox-miljön har en mindre restriktiv principuppsättning.
Använd principer som tillämpas på prenumerationsnivå i stället för hanteringsgruppsnivå. Du kan lägga till taggar i principdefinitionerna för att filtrera och tillämpa principer på rätt miljö. Du kan också tilldela principer till eller exkludera dem från specifika resursgrupper.

Du kan tilldela principer när prenumerationen skapas som en del av prenumerationsförsäljning.

För principer som du implementerar för att styra kostnader tillämpar du principdefinitionen på prenumerationsnivå där det behövs. Eller så kan du göra landningszonens ägare ansvarig för kostnader, vilket ger verklig autonomi. Mer information finns i Plattformsautomatisering och DevOps.

Varning

Till skillnad från principer och kontroller på hanteringsgruppsnivå kan prenumerationsbaserade principer och taggar ändras av personer med utökade behörigheter till prenumerationen. Administratörer med lämpliga roller kan kringgå dessa kontroller genom att exkludera principer, ändra principer eller ändra taggarna för resurser.

Därför bör du inte använda taggar i definitionerna av säkerhetsfokuserade principer. Tilldela inte dessutom behörigheter som alltid aktiva för följande åtgärder:

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

Du kan styra dessa åtgärder med hjälp av Privileged Identity Management (PIM).

Hierarki för hanteringsgrupp

Undvik komplicerade hanteringsgruppshierarkier. De kan kräva frekventa ändringar, skala ineffektivt och sakna värde. För att undvika dessa potentiella problem är Hanteringsgrupper för Azure-landningszoner arketypjusterade för arbetsbelastningar. Mer information finns i Hanteringsgrupp och prenumerationsorganisation.

Arketypjusterad innebär att hanteringsgrupper endast skapas för specifika arketyper för arbetsbelastningar. I den konceptuella arkitekturen har till exempel hanteringsgruppen för landningszoner corp- och online-underordnade hanteringsgrupper. Dessa underordnade hanteringsgrupper överensstämmer med distinkta arketypmönster för de arbetsbelastningar som de har. De underordnade hanteringsgrupperna fokuserar på krav för hybridanslutning (VPN/Azure ExpressRoute), till exempel endast interna jämfört med offentliga program och tjänster.

Förutom sandbox-miljöer bör olika programmiljöer använda samma arketyp för distribution. Även om miljöer är uppdelade i flera prenumerationer lagras de i samma hanteringsgrupp (corp eller online), baserat på hanteringsgruppens arketyp och kraven.

Du kan använda sandbox-prenumerationer för ostrukturerad utveckling, till exempel personliga labb eller för en arbetsbelastning som inte har en arketyp. Ett program- eller tjänstarbetsbelastningsteam använder en sandbox-hanteringsgrupp för att testa olika Azure-tjänster för att avgöra vad som fungerar bäst för deras krav. När de har bestämt sig för tjänster kan de etablera en landningszon (i rätt arbetsbelastnings arketypjusterade hanteringsgrupp i hierarkin för hanteringsgruppen för landningszoner ) för teamet.

Sandbox-miljöer kan användas för specifika program, eller så kan ett arbetsbelastningsteam använda dem för experimentering.

Mer information finns i:

Hanteringsgrupper.
Designområde för resursorganisation.
Anpassa Arkitekturen för Azure-landningszonen efter behov.

Utmaningar för miljöbaserade hanteringsgrupper

Hanteringsgrupper för miljöer inom arketyper kan lägga till hanteringskostnader och ge minimalt värde.

Hanteringsgruppen för landningszoner bör ha universella principer som tillämpar skyddsräcken för både corp - och online-underordnade hanteringsgrupper. Corp och online har unika principer som tillämpar företagets riktlinjer som rör offentliga och privata arbetsbelastningar.

Många organisationer skapar separata hanteringsgrupper för SDLC-miljöer (software development lifecycle) för att tilldela miljöprinciper och kontroller. I praktiken skapar den här metoden fler utmaningar för arbetsbelastningsteam än vad den löser. SDLC-miljöer bör inte ha olika principer, så vi rekommenderar inte separata hanteringsgrupper.

Programägare kan ändra topologin eller resurskonfigurationen för en arbetsbelastning så att den överensstämmer med principer i flera SDLC-miljöer som den befordras genom. Den här metoden ökar risken. Regler som är specifika för varje miljö kan resultera i en dålig utvecklingsupplevelse för utvecklar- och kvalitetssäkringsteam. Problem kan också uppstå om ett program har en uppsättning skyddsmekanismsprinciper som fungerar i en miljö och programmet exponeras för en annan uppsättning principer senare i sin kampanjcykel. Du kan behöva göra justeringar i ett program om kontrollerna ändras.

För att förhindra det här extra arbetet skapar du konsekventa principer under befordran av kod i SDLC-miljöer. Du bör inte skapa principer för varje miljö, utan i stället tillhandahålla en konsekvent uppsättning för alla utvecklingsmiljöer, exklusive sandbox-miljöer.

Anta till exempel att en organisation definierar en princip som kräver att lagringskonton konfigureras med specifika brandväggsregler för att förhindra ingress från offentliga nätverk. I stället använder lagringskontona privata slutpunkter i Azure-landningszonens nätverk för kommunikation. Om utvecklingsmiljön inte har någon sådan princip hittar testning av arbetsbelastningen inte någon felaktig konfiguration av lagringskontot som tillåter offentlig åtkomst. Testdistributionerna fungerar i utvecklingsmiljön och itereras på. När lösningen befordras till en annan miljö som har lagringskontoprincipen misslyckas distributionen på grund av den framtvingade principen.

Därför måste programutvecklingsteamet omarbeta sin distribution och arkitektur efter att redan ha investerat betydande arbete. Det här exemplet visar hur olika principer i olika miljöer kan skapa problem.

Kommentar

Följande ekvation visar varför en separat hanteringsgrupp för varje miljö eller arbetsbelastning inte skalas bra: N-arbetsbelastningar x Z-hanteringsgrupper = totalt antal hanteringsgrupper.

Om en organisation har 30 arbetsbelastningar som var och en kräver en hanteringsgrupp och en underordnad hanteringsgrupp för utvecklings-, testnings- och produktionsmiljöer lämnas organisationen med:

N = antalet arbetsbelastningar/appar = 30

Z = antalet hanteringsgrupper för arbetsbelastningen och miljöerna (1 för arbetsbelastningen + 3 för miljöerna) = 4

N (30) x Z (4) = 120 totala hanteringsgrupper

Programägare kan behöva principer för att tillämpa olika på flera miljöer. Programägare kan till exempel kräva säkerhetskopieringskonfigurationer för produktionsmiljöer, men inte för andra miljöer.

Vissa principer kan aktiveras som granskningsprinciper på hanteringsgruppsnivå. Programteam bestämmer hur kontrollen ska implementeras. Den här metoden förhindrar inte distributioner, men den skapar medvetenhet och gör det möjligt för programteam att hantera sina unika behov. De kan sedan skapa undernivåprinciper eller införliva dessa krav i distributionsmodulerna infrastruktur som kod (IaC).

I den här modellen med delat ansvar granskar plattformsteamet metoder och programteamet hanterar implementeringen. Den här modellen kan förbättra flexibiliteten i distributioner.

Plattformsoperatörer måste arbeta med varje program- eller tjänstarbetsbelastningsteam (ägare av landningszoner) för att förstå deras krav. Plattformsoperatorerna kan tillhandahålla prenumerationer baserat på programkrav och planer. Plattformsoperatörerna kan också välja att utse produktlinjer för olika typer av arbetsbelastningar så att de kan skapa processer och verktyg för att skapa prenumerationer baserat på vanliga krav från program- eller tjänstarbetsbelastningsteam.

Scenario: Vm-baserade arbetsbelastningar

Tidiga arbetsbelastningar i Azure-landningszoner består ofta av virtuella Azure-datorer. Du kan distribuera dessa arbetsbelastningar i Azure eller migrera dem från befintliga datacenter.

I stället för att distribuera virtuella datorer till flera miljöer i en enda prenumeration kan du:

Upprätta prenumerationer för varje programmiljö och placera dem alla i samma arketyphanteringsgrupp.
Distribuera ett virtuellt nätverk för varje programmiljö i lämplig prenumeration. Du kan fastställa storleken på det virtuella nätverket baserat på storleken på programmiljön.
Distribuera de virtuella datorerna till lämplig prenumeration. Virtuella datorer kan använda olika SKU:er och olika tillgänglighetskonfigurationer för varje miljö, om det är lämpligt.

Olika programmiljöresurser skyddas av olika åtkomstkontroller. När programutvecklare konfigurerar distributionspipelines kan därför varje pipelines identitet begränsas till miljön. Den här konfigurationen hjälper till att skydda miljöer från oavsiktliga distributioner.

Scenario: Azure App Service

En arbetsbelastning med miljöprenumerationer som använder App Service kan skapa utmaningar. För programutvecklare är bästa praxis för App Service att använda distributionsplatser för att hantera ändringar och uppdateringar av en webbapp.

Den här funktionen kan dock bara användas med appen som finns i App Service-planen, som bara kan leva i en enda prenumeration. Om plattformsoperatörerna kräver att programägarna använder separata prenumerationer för utvecklings-, testnings- och produktionsmiljöer kan livscykeln för programdistribution vara svårare att hantera.

I det här exemplet är det bästa alternativet en enskild prenumeration för program- eller tjänstarbetsbelastningen. Programägare kan använda rollbaserad åtkomstkontroll i Azure (RBAC) med PIM på resursgruppsnivå för ökad säkerhet.