Testmetod för Azure-landningszoner

Kommentar

Den här artikeln gäller endast för Microsoft Azure och inte för andra Microsoft Cloud-erbjudanden som Microsoft 365 eller Microsoft Dynamics 365.

Vissa organisationer kanske vill testa sin plattformsdistribution i Azure-landningszoner för Azure Policy-definitioner och tilldelningar, rollbaserad åtkomstkontroll (RBAC) anpassade roller och tilldelningar och så vidare. Testerna kan slutföras via automatisering med hjälp av Azure Resource Manager-mallar (ARM-mallar), AzOps, Terraform, Bicep eller manuellt via Azure-portalen. Den här vägledningen ger en metod som kan användas för att testa ändringar och deras inverkan i en plattformsdistribution i Azure-landningszoner.

Den här artikeln kan också användas med vägledning för plattformsautomatisering och DevOps-kritiska designområde när det gäller platformops- och centralfunktionernas team och uppgifter.

Den här vägledningen passar bäst för organisationer med robusta ändringshanteringsprocesser som styr ändringar i produktionsmiljöns hanteringsgruppshierarki. Hierarkin för kanariehanteringsgrupper kan användas separat för att skapa och testa distributioner innan du distribuerar dem till produktionsmiljön.

Kommentar

Termen kanariefågel används för att undvika förvirring i utvecklingsmiljöer eller testmiljöer. Det här namnet används endast i illustrationssyfte. Du kan definiera vilket namn som helst som du anser vara lämpligt för din miljö med azure-landningszoner.

På samma sätt används termen produktionsmiljö i den här vägledningen för att referera till den hanteringsgruppshierarki som din organisation kan ha på plats som innehåller Azure-prenumerationer och resurser för dina arbetsbelastningar.

Plattformsdefinition

Viktigt!

Den här vägledningen gäller inte för utvecklingsmiljöer eller testmiljöer som används av program- eller tjänstägare som kallas landningszoner, arbetsbelastningar, program eller tjänster. Dessa placeras och hanteras i produktionsmiljöns hanteringsgruppshierarki och tillhörande styrning (RBAC och Azure Policy).

Den här vägledningen gäller endast testning på plattformsnivå och ändringar i kontexten för Azure-landningszoner.

Företagsskala hjälper dig att utforma och distribuera nödvändiga Azure-plattformskomponenter så att du kan skapa och operationalisera landningszoner i stor skala.

Plattformsresurserna i omfånget för den här artikeln och den här testmetoden är:

Produkt eller tjänst	Resursprovider och typ
Hanteringsgrupper	Microsoft.Management/managementGroups
Prenumerationsassociation för hanteringsgrupper	Microsoft.Management/managementGroups/subscriptions
Principdefinitioner	Microsoft.Authorization/policyDefinitions
Definitioner av principinitiativ eller principuppsättningsdefinitioner	Microsoft.Authorization/policySetDefinitions
Principtilldelningar	Microsoft.Authorization/policyAssignments
RBAC-rolldefinitioner	Microsoft.Authorization/roleDefinitions
RBAC-rolltilldelningar	Microsoft.Authorization/roleAssignments
Prenumerationer	Microsoft.Subscription/aliases

Exempelscenarier och resultat

Ett exempel på det här scenariot är en organisation som vill testa effekten och resultatet av en ny Azure Policy för att styra resurser och inställningar i alla landningszoner enligt principen principdriven styrningsdesign. De vill inte göra den här ändringen direkt till produktionsmiljön eftersom de är oroliga för vilken inverkan den kan ha.

Om du använder kanariemiljön för att testa den här plattformsändringen kan organisationen implementera och granska effekten och resultatet av Azure Policy-ändringen. Den här processen säkerställer att den uppfyller organisationens krav innan de implementerar Azure Policy i sin produktionsmiljö.

Ett liknande scenario kan vara en ändring av Azure RBAC-rolltilldelningar och Microsoft Entra-gruppmedlemskap. Det kan kräva en form av testning innan ändringarna görs i produktionsmiljön.

Viktigt!

Det här är inte en vanlig distributionsmetod eller ett mönster för de flesta kunder. Det är inte obligatoriskt för distributioner av Azure-landningszoner.

Bild 1: Hierarki för kanariehanteringsgrupp.

Som diagrammet visar dupliceras hela azure-landningszonernas grupphierarki för produktionsmiljöhantering under Tenant Root Group. Kanarienamnet läggs till i visningsnamnen och ID:na för hanteringsgruppen. ID:na måste vara unika i en enda Microsoft Entra-klientorganisation.

Kommentar

Visningsnamn för kanariemiljöhanteringsgruppen kan vara samma som visningsnamn för produktionsmiljöns hanteringsgrupp. Detta kan orsaka förvirring för användare. Därför rekommenderar vi att du lägger till namnet "canary" i visningsnamnen samt till deras ID:n.

Hierarkin för hanteringsgrupper för kanariemiljö används sedan för att förenkla testningen av följande resurstyper:

• Hanteringsgrupper
  • Prenumerationsplacering
• RBAC
  • Roller (inbyggda och anpassade)
  • Tilldelningar
• Azure Policy
  • Definitioner (inbyggda och anpassade)
  • Initiativ, även kallade uppsättningsdefinitioner
  • Tilldelningar

Vad händer om du inte vill distribuera hela hierarkin för hanteringsgrupper för kanariemiljö?

Om du inte vill distribuera hela hierarkin för hantering av kanariemiljö kan du testa plattformsresurser i produktionsmiljöhierarkin med hjälp av sandbox-prenumerationer enligt diagrammet.

Bild 2: Hierarki för hanteringsgrupper i företagsskala som markerar sandbox-miljö.

För att testa Azure Policy och RBAC i det här scenariot behöver du en enda Azure-prenumeration med rollen Ägare RBAC tilldelad till den identitet som du vill slutföra testningen som till exempel användarkonto, tjänsthuvudnamn eller hanterad tjänstidentitet. Med den här konfigurationen kan du endast skapa, tilldela och åtgärda Azure Policy-definitioner och tilldelningar inom sandbox-prenumerationens omfång.

Den här sandbox-metoden kan också användas för RBAC-testning i prenumerationen, till exempel om du utvecklar en ny anpassad RBAC-roll för att bevilja behörigheter för ett visst användningsfall. Den här testningen kan göras i sandbox-prenumerationen och testas innan du skapar och tilldelar roller högre upp i hierarkin.

En fördel med den här metoden är att sandbox-prenumerationerna kan användas för den tid som de krävs och sedan tas bort från miljön.

Den här metoden tillåter dock inte att du testar med arv av RBAC- och Azure-principer från hanteringsgruppshierarkin.

Använda en enda Microsoft Entra-klientorganisation

Att tänka på när du använder en enda Microsoft Entra-klientorganisation är:

• Följer designrekommendationer i företagsskala för Microsoft Entra-klienter.
• Enligt bästa praxis för Cloud Adoption Framework Azure kan du standardisera på en enda katalog och identitetsvägledning , och enskilda Microsoft Entra-klienter är bästa praxis för de flesta.
  • I en enda Microsoft Entra-klientorganisation kan du använda de olika Microsoft Entra-grupperna för både produktionsmiljöer och azure-landningszoner med samma användare tilldelade till deras relevanta hanteringsgruppshierarki inom samma Microsoft Entra-klientorganisation.
• Ökade eller duplicerade Licensieringskostnader för Microsoft Entra-ID på grund av flera identiteter för olika Microsoft Entra-klienter.
  • Den här punkten är särskilt relevant för kunder som använder Microsoft Entra ID P1- eller P2-funktioner.
• RBAC-ändringar blir mer komplexa i både kanariemiljöer och produktionsmiljöer, eftersom det är troligt att användarna och grupperna inte är identiska i båda Microsoft Entra-klientorganisationer.
  • Dessutom är användar- och grupp-ID:na inte desamma för Microsoft Entra-klienter på grund av att de är globalt unika.
• Minskar komplexiteten och hanteringskostnaderna som orsakas av att hantera flera Microsoft Entra-klienter.
  • Privilegierade användare som måste ha åtkomst och logga in på separata klienter för att utföra testning kan göra ändringar i produktionsmiljön av misstag, i stället för att göra ändringar i kanariemiljön och vice versa.
• Minskar sannolikheten för konfigurationsavvikelser och distributionsfel.
• Kräver inte att extra säkerhet och brytglas- eller nödåtkomstprocesser skapas.
• Minskar friktionen och den tid som krävs för att implementera ändringar i distributionen av Azure-landningszoner.

Riktlinjer för implementering

Nedan visas vägledning om hur du implementerar och använder hierarkin för kanariehanteringsgrupp för Azure-landningszoner tillsammans med en grupphierarki för hantering av produktionsmiljöer.

Varning

Om du använder portalen för att distribuera och hantera din Miljö för Azure-landningszoner i dag kan det vara svårt att använda kanariemetoden effektivt på grund av en hög risk för att både produktions- och kanariemiljöerna blir osynkroniserade ofta och därför inte tillhandahåller en replikliknande hierarki och produktionsmiljö.

Överväg att gå över till en distributionsmetod för infrastruktur som kod för Azure-landningszoner, som anges ovan, om du är i det här scenariot. Eller var medveten om de potentiella riskerna med konfigurationsavdrift mellan kanariefågel och produktion och fortsätt med försiktighet.

1. Använd separata Microsoft Entra-tjänsthuvudnamn (SPN) eller hanterade tjänstidentiteter (MSI: er) som beviljas behörigheter över den relevanta produktionsmiljön eller kanariemiljöhanteringsgruppens hierarki.
   • Den här vägledningen följer principen om lägsta behörighet (PoLP)
2. Använd separata mappar i en git-lagringsplats, grenar eller lagringsplatser för att lagra distributioner av Azure-landningszoner i infrastruktur som kod för produktionsmiljön och kanariemiljön.
   • Använda relevanta Microsoft Entra-tjänsthuvudnamn (SPN) eller hanterade tjänstidentiteter (MSI: er) som en del av CI/CD-pipelines beroende på vilken hierarki som distribueras.
3. Implementera git-grenprinciper eller säkerhet för den kanariemiljö som du har på plats för produktionsmiljön.
   • Överväg att minska antalet godkännare och kontrollera att kanariemiljön misslyckas snabbt.
4. Använd samma Azure Pipelines- eller GitHub-åtgärder som använder miljövariabler för att ändra vilken hierarki som distribueras. Ett annat alternativ är att klona pipelines och ändra de hårdkodade inställningarna för att definiera vilken hierarki som distribueras.
   • Med Azure Pipelines DevOps-mallar eller GitHub Actions-arbetsflödesmallar kan du följa principen upprepa inte dig själv (DRY).
5. Ha en uppsättning kanarieprenumerationer under en separat EA-avdelning och ett konto som kan flyttas runt hierarkin för kanariehanteringsgruppen efter behov.
   • Det kan vara fördelaktigt att ha en uppsättning resurser som alltid distribueras till kanariemiljöprenumerationer.
   • Det kan vara bra att ha infrastruktur som kod-mallar som ARM-mallar, Bicep eller Terraform, som skapar en uppsättning resurser som möjliggör validering av ändringar i kanariemiljön.
6. Skicka alla Azure-aktivitetsloggar för alla Azure-prenumerationer, inklusive eventuella prenumerationer på kanariemiljöer, till arbetsytan Azure Log Analytics i produktionsmiljön enligt designrekommendationerna för Azure-landningszoner.

Dricks

Om du redan har Azure-landningszoner distribuerade i produktion och nu vill lägga till en kanariemiljö. Överväg att klona din aktuella distribution av produktionsmiljöhierarkin och ändra namnen på resurserna så att de prefixas med ditt kanarienamnsschema.

Det här är för att säkerställa att det du distribuerar för att aktivera kanariemiljön är synkroniserat med produktion från början. Detta uppnås enkelt när du använder ett infrastruktur-som-kod-verktyg tillsammans med en git-lagringsplats.

Nästa steg

Lär dig hur du implementerar sandbox-miljöer i landningszonen.

Implementera sandbox-miljöer i landningszonen