Delen via

Testbenadering voor Azure-landingszones

Notitie

Dit artikel is alleen van toepassing op Microsoft Azure en niet op andere Microsoft Cloud-aanbiedingen, zoals Microsoft 365 of Microsoft Dynamics 365.

Sommige organisaties zouden kunnen willen testen hoe hun platform voor Azure-landingszones functioneert op het gebied van Azure Policy-definities en -toewijzingen, aangepaste rollen en toewijzingen op basis van rollen (RBAC), enzovoort. De tests kunnen worden voltooid via automatisering met behulp van ARM-sjablonen (Azure Resource Manager-sjablonen), Terraform, Bicepof handmatig via Azure Portal. Deze richtlijnen bieden een benadering die kan worden gebruikt om wijzigingen en de impact ervan op een azure-landingszonesplatformimplementatie te testen.

Dit artikel kan ook worden gebruikt met de richtlijnen voor platformautomatisering en devOps-kritieke ontwerpgebied , omdat het betrekking heeft op de PlatformOps- en Central-functiesteams en -taken. Bovendien kan het worden gecombineerd met de richtlijnen in op beleid gebaseerde kaders implementeren voor technieken voor het implementeren van beleidswijzigingen in een Azure-landingszonesimplementatie.

Deze richtlijnen zijn het meest geschikt voor organisaties met robuuste wijzigingsbeheerprocessen voor wijzigingen in de hiërarchie van productiebeheergroepen. De hiërarchie van de canary-beheergroep kan onafhankelijk worden gebruikt voor het ontwerpen en testen van implementaties voordat u ze in de productieomgeving implementeert.

Notitie

De term canary wordt gebruikt om verwarring met ontwikkelomgevingen of testomgevingen te voorkomen. Deze naam wordt alleen gebruikt voor illustratiedoeleinden. U kunt elke gewenste naam definiëren voor uw omgeving met canary Azure-landingszones.

Op dezelfde manier wordt de term productieomgeving/-hiërarchie in deze richtlijnen gebruikt om te verwijzen naar de beheergroephiërarchie van Azure-landingszones die uw organisatie mogelijk heeft die de Azure-abonnementen en -resources voor uw workloads bevat.

Platformdefinitie

Belangrijk

Deze richtlijnen zijn niet bedoeld voor ontwikkelomgevingen of testomgevingen die worden gebruikt door toepassings- of service-eigenaren, ook wel landingszones, workloads, toepassingen of services genoemd. Deze worden geplaatst en verwerkt binnen de hiërarchie van de managementgroep van Azure-landingszones in de productieomgeving en bijbehorende governance (RBAC en Azure Policy).

Zie Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones voor hulp bij ontwikkeling, testen, gebruikersacceptatietests (UAT) en productieomgevingen voor toepassingsworkloads en -teams.

Deze richtlijnen zijn alleen bedoeld voor testen en wijzigingen op platformniveau in de context van Azure-landingszones.

Azure-landingszones helpen u bij het ontwerpen en implementeren van de vereiste Azure-platformonderdelen, zodat u landingszones op schaal kunt bouwen en operationeel kunt maken.

De platformbronnen binnen het bereik van dit artikel en deze testbenadering zijn:

Product of dienst Resourceprovider en -type
Beheergroepen Microsoft.Management/managementGroups
Abonnementskoppeling voor beheergroepen Microsoft.Management/managementGroups/subscriptions
Beleidsdefinities Microsoft.Authorization/policyDefinitions
Beleidsinitiatiefdefinities of definities van beleidssets Microsoft.Authorization/policySetDefinitions
Beleidstoewijzingen Microsoft.Authorization/policyAssignments
RBAC-roldefinities Microsoft.Authorization/roleDefinitions
RBAC-roltoewijzingen Microsoft.Authorization/roleAssignments
Abonnementen Microsoft.Subscription/aliases

Voorbeeldscenario's en resultaten

Een voorbeeld van dit scenario is een organisatie die de impact en het resultaat van een nieuw Azure Policy wil testen om resources en instellingen in alle landingszones te beheren, volgens het ontwerpprincipe op basis van beleid. Ze willen deze wijziging niet rechtstreeks aanbrengen in de productieomgeving omdat ze zich zorgen maken over de impact die deze mogelijk heeft.

Door de canary-omgeving te gebruiken om deze platformwijziging te testen, kan de organisatie de impact en het resultaat van de wijziging in Azure Policy implementeren en controleren. Dit proces zorgt ervoor dat het voldoet aan de vereisten van de organisatie voordat ze Het Azure Policy implementeren in hun productieomgeving.

Een vergelijkbaar scenario kan een wijziging zijn in de Azure RBAC-roltoewijzingen en microsoft Entra-groepslidmaatschappen. Het kan een vorm van testen vereisen voordat de wijzigingen worden aangebracht in de productieomgeving.

Belangrijk

Dit is geen algemene implementatiebenadering of -patroon voor de meeste klanten. Het is niet verplicht voor implementaties van Azure-landingszones.

Diagram van de hiërarchie van de beheergroep met de canary-omgevingstestbenadering.

Afbeelding 1: Canary-beheergroephiërarchie.

Zoals in het diagram te zien is, wordt de volledige productiegroephiërarchie van Azure-landingszones gedupliceerd onder Tenant Root Group. De canary-naam wordt toegevoegd aan de weergavenamen en id's van de beheergroep. De id's moeten uniek zijn binnen één Microsoft Entra-tenant.

Notitie

De weergavenamen van de canary-beheergroep kunnen hetzelfde zijn als de weergavenamen van de productiebeheergroep. Dit kan verwarring veroorzaken voor gebruikers. Daarom raden we u aan de naam 'canary' toe te voegen aan de weergavenamen en aan hun id's.

De hiërarchie van de canary-beheergroep wordt vervolgens gebruikt om het testen van de volgende resourcetypen te vereenvoudigen:

  • Beheergroepen
    • Plaatsing van abonnementen
  • RBAC
    • Rollen (ingebouwd en aangepast)
    • Toewijzingen
  • Azure Policy
    • Definities (ingebouwd en aangepast)
    • Initiatieven, ook wel vaste definities genoemd
    • Toewijzingen

Wat gebeurt er als u de hiërarchie van de canary-beheergroep niet wilt implementeren?

Als u de hiërarchie van de canary-beheergroep niet wilt implementeren, kunt u platformresources in de productieomgevingshiërarchie testen met behulp van sandbox-abonnementen zoals weergegeven in het diagram.

Diagram van de testbenadering die gebruikmaakt van sandboxes.

Afbeelding 2: Beheergroephiërarchie van Azure-landingszones waarin sandboxes worden gemarkeerd.

Als u Azure Policy en RBAC in dit scenario wilt testen, hebt u één Azure-abonnement nodig met de rol Eigenaar die is toegewezen aan de identiteit waarmee u wilt testen, zoals een gebruikersaccount, een service-principal of een beheerde service-identiteit. Met deze configuratie kunt u alleen Azure Policy-definities en -toewijzingen maken, toewijzen en herstellen binnen het bereik van het sandbox-abonnement.

Deze sandbox-benadering kan ook worden gebruikt voor RBAC-tests binnen het abonnement, bijvoorbeeld als u een nieuwe aangepaste RBAC-rol ontwikkelt om machtigingen te verlenen voor een bepaalde use case. Deze tests kunnen allemaal worden uitgevoerd in het sandbox-abonnement en getest voordat u rollen hoger in de hiërarchie maakt en toewijst.

Een voordeel van deze methode is dat de sandbox-abonnementen kunnen worden gebruikt voor het moment dat ze nodig zijn en vervolgens uit de omgeving worden verwijderd.

Met deze benadering kunt u echter niet testen met de overname van RBAC- en Azure-beleidsregels uit de beheergroephiërarchie.

Implementatierichtlijnen

Hieronder vindt u richtlijnen voor het implementeren en gebruiken van de hiërarchie van de canary-beheergroep voor Azure-landingszones, parallel aan de beheergroephiërarchie voor Azure-landingszones in een productieomgeving.

Waarschuwing

Als u vandaag de portal gebruikt voor het implementeren en beheren van uw Azure-landingszoneomgeving, kan het lastig zijn om de canary-methode efficiënt toe te passen vanwege een hoog risico dat zowel de productie- als de canary-omgevingen vaak niet meer gesynchroniseerd zijn en daarom geen replica-achtige hiërarchie en productieomgeving bieden.

Overweeg om over te stappen op een IaC-implementatiebenadering (Infrastructure as Code) voor Azure-landingszones, zoals hierboven wordt vermeld, als u zich in dit scenario bevindt. Of houd rekening met de mogelijke risico's van configuratiedrift tussen kanarie en productie en ga verder met zorg. Zie IaC gebruiken om Azure-landingszones bij te werken voor meer informatie.

  1. Gebruik afzonderlijke Microsoft Entra-service-principals (SPN's) of Beheerde identiteiten (MI's) die machtigingen krijgen voor de relevante productie- of kanarie-omgevingsbeheergroephiërarchie van Azure-landingszones.
    • Deze richtlijnen volgen het principe van minimale bevoegdheden (PoLP)
  2. Gebruik afzonderlijke mappen, vertakkingen of opslagplaatsen binnen een Git-opslagplaats om de IaC voor de productieomgeving en de Canary-omgeving in de deployments van Azure-landingzones op te slaan.
    • Gebruik de relevante Microsoft Entra-service-principals (SPN's) of Beheerde identiteiten (MIs's) als onderdeel van de CI/CD-pijplijnen, afhankelijk van welke hiërarchie wordt geïmplementeerd.
  3. Implementeer git-vertakkingsbeleid of -beveiliging voor de canary-omgeving zoals u hebt ingesteld voor de productieomgeving.
    • Overweeg het aantal goedkeurders en controles voor de canary-omgeving te verminderen om snel te mislukken.
  4. Gebruik dezelfde Azure Pipelines- of GitHub-acties die omgevingsvariabelen gebruiken om te wijzigen welke hiërarchie wordt geïmplementeerd. Een andere optie is om de pijplijnen te klonen en de in code vastgelegde instellingen te wijzigen om te definiëren welke hiërarchie wordt geïmplementeerd.
  5. U hebt een set canary-abonnementen onder een afzonderlijk factureringsaccount, bijvoorbeeld een EA-account (Enterprise Agreement) of een MCA-factuursectie (Microsoft-klantovereenkomst), die indien nodig binnen de hiërarchie van de canary-beheergroep kan worden verplaatst.
    • Het kan handig zijn om een set resources altijd in de canary-omgevingsabonnementen te implementeren om het testen en valideren van wijzigingen in de canary-omgeving te versnellen.
  6. U hebt een set voorbeeldarchitecturen voor toepassingsworkloads die u in de canary-abonnementen in de canary-omgeving kunt implementeren om de wijzigingen in Azure Policy en RBAC te testen. Dit helpt u bij het valideren van de wijzigingen voordat u de wijzigingen in productie implementeert en promoveert.
    • Deze voorbeeldworkloads kunnen worden geïmplementeerd met dezelfde IaC-sjablonen die worden gebruikt voor het implementeren van de workloads van de productietoepassing. Dit helpt u ervoor te zorgen dat de canary-omgeving synchroon is met de productieomgeving en dat de wijzigingen die u test, geldig zijn en van toepassing zijn op de productieomgeving.
    • U moet de voorbeeldworkloads continu controleren en bijwerken om ervoor te zorgen dat ze relevant en up-to-date zijn met de nieuwste architectuur- en ontwerppatronen in uw organisatie.
    • Als u referentiearchitecturen aan uw toepassingsteams verstrekt, kunt u deze ook implementeren in de canary-omgeving. Zo kunt u de wijzigingen valideren op basis van de referentiearchitecturen en ervoor zorgen dat deze van toepassing zijn op de productieomgeving.
  7. Verzend alle Azure-activiteitenlogboeken voor alle Azure-abonnementen, inclusief alle canary-omgevingsabonnementen, naar de Azure Log Analytics-werkruimte in de productieomgeving volgens de ontwerpaanvelingen voor Azure-landingszones.
    • Dit helpt uw beveiligings- en operationele teams om de canary-omgeving te controleren op wijzigingen of problemen die kunnen optreden bij het testen van de Azure Policy- en RBAC-wijzigingen in de productieomgeving.

Tip

Als u reeds Azure-landingszones in productie hebt geïmplementeerd en nu overweegt een canary-omgeving toe te voegen. Overweeg om uw huidige implementatie van de hiërarchie van de productieomgeving te klonen en de namen van de bronnen aan te passen door ze te laten beginnen met uw kanarie-naamgevingsschema.

Dit is om ervoor te zorgen dat wat u implementeert om de canary-omgeving in te schakelen, vanaf het begin gesynchroniseerd is met de productie. Dit is eenvoudig te bereiken wanneer u een IaC-hulpprogramma naast een Git-opslagplaats gebruikt.

Eén Microsoft Entra-tenant gebruiken

Overwegingen waarmee u rekening moet houden wanneer u één Microsoft Entra-tenant gebruikt, zijn:

  • Als u een enkele tenant gebruikt, volgt u de Azure-landingszones ontwerpaanbevelingen voor Microsoft Entra-tenants.
    • In één Microsoft Entra-tenant kunt u de verschillende Microsoft Entra-groepen gebruiken voor zowel productie- als canary Azure-landingszones met dezelfde gebruikers die zijn toegewezen aan hun relevante hiërarchie van beheergroepen.
  • De licentiekosten voor Microsoft Entra-id's zijn verhoogd of gedupliceerd vanwege meerdere identiteiten in verschillende Microsoft Entra-tenants. Dit is met name relevant voor klanten die microsoft Entra ID P1- of P2-functies gebruiken.
  • RBAC-wijzigingen zijn complexer in zowel canary- als productieomgevingen, omdat de gebruikers en groepen waarschijnlijk niet identiek zijn in beide Microsoft Entra-tenants.
    • Houd er rekening mee dat de gebruikers- en groeps-id's niet hetzelfde zijn voor Microsoft Entra-tenants, omdat ze wereldwijd uniek zijn.
  • Vermindert de complexiteit en beheeroverhead die wordt veroorzaakt door het beheren van meerdere Microsoft Entra-tenants.
    • Bevoegde gebruikers die toegang moeten behouden en zich moeten aanmelden bij afzonderlijke tenants om tests uit te voeren, kunnen bijvoorbeeld onbedoelde wijzigingen aanbrengen in de productieomgeving in plaats van in de canary-omgeving.
  • Vermindert de kans op configuratiedrift en implementatiefouten.
  • Er hoeven geen extra beveiligings- en break-glass- of noodtoegangsprocessen te worden gemaakt.
  • Vermindert wrijving en de tijd die nodig is om wijzigingen in de implementatie van Azure-landingszones te implementeren.

Volgende stappen

Zodra u een canary-omgeving hebt, kunt u beginnen met het testen van de wijzigingen in Azure Policy en RBAC voordat u ze implementeert in de beheergroephiërarchie van uw Azure-landingszones in uw productieomgeving.

Wanneer u wijzigingen in Azure Policies in de canary-omgeving hebt getest, kunt u deze vervolgens naar de productieomgeving promoveren volgens dezelfde benadering als beschreven in de beleidsrichtlijnen voor het implementeren van beleidsgestuurde richtlijnen. Dit wordt gedaan met behulp van de afdwingingsmodusfunctie van beleidstoewijzingen. Met behulp van de methode die in deze richtlijnen wordt beschreven, kunt u doorgaan met een extra testfase voordat u Azure Policy in de productieomgeving afdwingt in het gewenste effect, zodat u vertrouwen kunt opbouwen in de Wijzigingen in Azure Policy die u aanbrengt.

U kunt ook sandbox-omgevingen bekijken die uw toepassingsteams kunnen gebruiken voor het ontwikkelen en testen van hun workloads. Dit is een afzonderlijk concept voor de canary-omgeving en wordt gebruikt om een veilige omgeving te bieden voor toepassingsteams om hun workloads te ontwikkelen en te testen voordat ze in productie worden geïmplementeerd.

Sandbox-omgevingen voor landingszones implementeren

  • Last updated on