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 willen mogelijk de platformimplementatie van hun Azure-landingszones testen voor 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), AzOps, Terraform, Bicep of handmatig via Azure Portal. Deze richtlijnen bieden een benadering die kan worden gebruikt om wijzigingen en de impact ervan te testen in een platformimplementatie van Azure-landingszones.

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.

Deze richtlijnen zijn het meest geschikt voor organisaties met robuuste wijzigingsbeheerprocessen voor wijzigingen in de hiërarchie van productieomgevingsbeheergroepen. 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 in deze richtlijnen gebruikt om te verwijzen naar de hiërarchie van de beheergroep 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 in de hiërarchie van de productieomgevingsbeheergroep en bijbehorende governance (RBAC en Azure Policy).

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

Op ondernemingsniveau kunt u de vereiste Azure-platformonderdelen ontwerpen en implementeren, 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/aliassen

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.

Afbeelding 1: Canary-beheergroephiërarchie.

Zoals in het diagram wordt weergegeven, wordt de volledige hiërarchie van de productieomgevingsbeheergroep van Azure-landingszones gedupliceerd onder de 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-omgevingsbeheergroep kunnen hetzelfde zijn als de weergavenamen van de productieomgevingsbeheergroep. Dit kan verwarring veroorzaken voor gebruikers. Daarom raden we aan om de naam 'canary' toe te voegen aan de weergavenamen, evenals aan hun id's.

De hiërarchie van de canary-omgevingsbeheergroep 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 setdefinities genoemd
  • Toewijzingen

Wat moet u doen als u de hele hiërarchie van de canary-omgevingsbeheergroep niet wilt implementeren?

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

Afbeelding 2: Hiërarchie van beheergroepen op ondernemingsniveau 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 RBAC die is toegewezen aan de identiteit die u wilt voltooien als bijvoorbeeld Gebruikersaccount, Service-principal of Managed Service Identity. 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.

Eén Microsoft Entra-tenant gebruiken

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

• Volgt ontwerpaanbevelingen op ondernemingsniveau voor Microsoft Entra-tenants.
• Op basis van de best practices van Cloud Adoption Framework azure, standaardiseren op één directory- en identiteitsrichtlijnen , zijn enkele Microsoft Entra-tenants voor de meeste aanbevolen procedures.
  • In één Microsoft Entra-tenant kunt u de verschillende Microsoft Entra-groepen gebruiken voor zowel productieomgevingen als canary Azure-landingszones, met dezelfde gebruikers, die zijn toegewezen aan hun relevante beheergroephiërarchie binnen dezelfde Microsoft Entra-tenant.
• De licentiekosten voor Microsoft Entra-id's zijn verhoogd of gedupliceerd vanwege meerdere identiteiten in verschillende Microsoft Entra-tenants.
  • Dit punt is vooral relevant voor klanten die microsoft Entra ID P1- of P2-functies gebruiken.
• RBAC-wijzigingen zijn complexer in zowel canary-omgevingen als productieomgevingen, omdat de gebruikers en groepen waarschijnlijk niet identiek zijn in beide Microsoft Entra-tenants.
  • Bovendien zijn de gebruikers- en groeps-id's niet hetzelfde in 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 per ongeluk wijzigingen aanbrengen in de productieomgeving in plaats van wijzigingen aan te brengen in de canary-omgeving en omgekeerd.
• 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.

Implementatierichtlijnen

Hieronder vindt u richtlijnen voor het implementeren en gebruiken van de canary-beheergroephiërarchie voor Azure-landingszones naast een hiërarchie van een productieomgevingsbeheergroep.

Waarschuwing

Als u de portal gebruikt voor het implementeren en beheren van uw Omgeving met Azure-landingszones, kan het lastig zijn om de canaire benadering efficiënt te gebruiken en te gebruiken vanwege een hoog risico dat zowel de productie- als de kanaire omgevingen vaak uit de synchronisatie gaan en daarom geen replica-achtige hiërarchie en productieomgeving bieden.

Overweeg om over te stappen op een implementatiebenadering voor infrastructure-as-code voor Azure-landingszones, zoals hierboven 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.

1. Gebruik afzonderlijke Microsoft Entra-service-principals (SPN's) of Managed Service Identities (MSA's) die machtigingen krijgen voor de relevante productieomgeving of de hiërarchie van de canary-omgevingsbeheergroep.
   • Deze richtlijnen volgen het principe van minimale bevoegdheden (PoLP)
2. Gebruik afzonderlijke mappen in een Git-opslagplaats, vertakkingen of opslagplaatsen voor het opslaan van infrastructuur als code voor de productieomgeving en implementaties van Azure-landingszones in een canary-omgeving.
   • Gebruik de relevante Microsoft Entra-service-principals (SPN's) of Managed Service Identities (MSA'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.
   • Als u Azure Pipelines DevOps-sjablonen of GitHub Actions-werkstroomsjablonen gebruikt, kunt u zich houden aan het principe dat u zich niet herhaalt (DRY).
5. U hebt een set canary-abonnementen onder een afzonderlijke EA-afdeling en -account die naar behoefte kunnen worden verplaatst rond de hiërarchie van de canary-beheergroep.
   • Het kan handig zijn om een set resources altijd te implementeren in de canary-omgevingsabonnementen.
   • Het kan handig zijn om infrastructuur als codesjablonen zoals ARM-sjablonen, Bicep of Terraform te hebben die een set resources maken die validatie van wijzigingen in de canary-omgeving mogelijk maken.
6. 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.

Fooi

Als u azure-landingszones al in productie hebt geïmplementeerd en nu een canary-omgeving wilt toevoegen. Overweeg om uw huidige implementatie van de hiërarchie van de productieomgeving te klonen en de namen van resources te wijzigen om ze te voorzien van uw canary-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 wordt eenvoudig bereikt wanneer u een hulpprogramma Infrastructure-as-Code naast een Git-opslagplaats gebruikt.

Volgende stappen

Meer informatie over het implementeren van sandbox-omgevingen voor landingszones.

Sandbox-omgevingen voor landingszones implementeren