Beheergroepen

Beheergroepen zijn essentieel voor het organiseren en beheren van uw Azure-abonnementen. Naarmate het aantal abonnementen toeneemt, bieden beheergroepen een kritieke structuur voor uw Azure-omgeving en maken het eenvoudiger om uw abonnementen te beheren. Gebruik de volgende richtlijnen om een effectieve hiërarchie van beheergroepen tot stand te brengen en uw abonnementen te organiseren op basis van aanbevolen procedures.

Ontwerpoverwegingen voor beheergroepen

Beheergroepstructuren binnen een Microsoft Entra-tenant ondersteunen organisatietoewijzing. Houd rekening met de structuur van uw beheergroep, aangezien uw organisatie de overstap naar Azure op schaal plant.

• Hoe scheidt uw organisatie services die eigendom zijn van of worden beheerd door specifieke teams?

• Zijn er specifieke functies die om zakelijke of operationele nalevingsredenen gescheiden moeten worden gehouden?

• U kunt beheergroepen gebruiken om beleids- en initiatieftoewijzingen te aggregeren via Azure Policy.

• Een beheergroepstructuur kan maximaal zes diepteniveaus ondersteunen. Het hoofdtenantniveau of het abonnementsniveau valt buiten deze limiet.

• Elke principal, ongeacht of een gebruiker of service-principal, binnen een Microsoft Entra-tenant kan nieuwe beheergroepen maken. Deze machtiging komt doordat RBAC-autorisatie (op rollen gebaseerd toegangsbeheer) van Azure niet standaard is ingeschakeld voor beheergroepbewerkingen. Zie Uw resourcehiërarchie beveiligen voor meer informatie

• Alle nieuwe abonnementen worden standaard onder de hoofdbeheergroep van de tenant geplaatst.

• Zie beheergroepen om hun mogelijkheden in meer detail te verkennen.

Aanbevelingen voor beheergroepen

• Houd de hiërarchie van de beheergroep redelijk plat, idealiter met niet meer dan drie tot vier niveaus. Deze beperking vermindert de overhead en complexiteit van het beheer.

• Vermijd het dupliceren van uw organisatiestructuur in een diep geneste hiërarchie van beheergroepen. Gebruik beheergroepen voor beleidstoewijzing versus factureringsdoeleinden. Deze aanpak vraagt om het gebruik van beheergroepen voor hun beoogde doel in de conceptuele architectuur van de Azure-landingszone. Deze architectuur biedt Azure-beleid voor workloads waarvoor hetzelfde type beveiliging en naleving is vereist op hetzelfde niveau van de beheergroep.

• Maak beheergroepen onder uw beheergroep op hoofdniveau om de typen workloads weer te geven die u gaat hosten. Deze groepen zijn gebaseerd op de behoeften op het gebied van beveiliging, naleving, connectiviteit en functie van de workloads. Met deze groeperingsstructuur kunt u een set Azure-beleidsregels toepassen op het niveau van de beheergroep. Deze groeperingsstructuur is bedoeld voor alle workloads die dezelfde instellingen voor beveiliging, naleving, connectiviteit en functie vereisen.

• Gebruik resourcetags om query's uit te voeren en horizontaal door de hiërarchie van de beheergroep te navigeren. Resourcetags kunnen worden afgedwongen of toegevoegd via Azure Policy. Vervolgens kunt u resources groeperen voor zoekbehoeften zonder dat er een complexe hiërarchie van beheergroepen hoeft te worden gebruikt.

• Maak een sandbox-beheergroep op het hoogste niveau, zodat gebruikers direct kunnen experimenteren met Azure. Ze kunnen vervolgens experimenteren met resources die mogelijk nog niet zijn toegestaan in productieomgevingen. De sandbox biedt isolatie van uw ontwikkel-, test- en productieomgeving.

• Maak een platformbeheergroep onder de hoofdbeheergroep ter ondersteuning van gemeenschappelijk platformbeleid en Azure-roltoewijzing. Deze groeperingsstructuur zorgt ervoor dat verschillende beleidsregels kunnen worden toegepast op de abonnementen die worden gebruikt voor uw Azure-basis. Ook wordt er zo voor gezorgd dat de facturering voor algemene resources wordt gecentraliseerd in één set basisabonnementen.

• Beperk het aantal Azure Policy-toewijzingen dat is gemaakt in het bereik van de hoofdbeheergroep. Door deze beperking is er minder foutopsporing nodig in overgenomen beleidsregels in beheergroepen op lagere niveaus.

• Gebruik beleidsregels om nalevingsvereisten af te dwingen binnen het bereik van de beheergroep of het abonnement om beleidgestuurde governance te bereiken.

• Zorg ervoor dat alleen bevoegde gebruikers beheergroepen in de tenant kunnen uitvoeren. Schakel Azure RBAC-autorisatie in de hiërarchie-instellingen van de beheergroep in om gebruikersbevoegdheden te verfijnen. Standaard zijn alle gebruikers gemachtigd om hun eigen beheergroepen te maken onder de hoofdbeheergroep.

• Configureer een standaard, toegewezen beheergroep voor nieuwe abonnementen. Deze groep zorgt ervoor dat er geen abonnementen worden geplaatst onder de hoofdbeheergroep. Deze groep is vooral belangrijk als er gebruikers in aanmerking komen voor Microsoft Developer Network (MSDN) of Voordelen en abonnementen van Visual Studio. Een goede kandidaat voor dit type beheergroep is een sandbox-beheergroep. Zie Instelling - standaardbeheergroep voor meer informatie.

• Maak geen beheergroepen voor productie-, test- en ontwikkelomgevingen. Scheid deze groepen indien nodig in verschillende abonnementen in dezelfde beheergroep. Zie de volgende onderwerpen voor meer informatie over dit onderwerp:

  • Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones
  • Testbenadering voor bedrijfsschaal

Beheergroepen in de Azure-landingszoneversneller en ALZ-Bicep-opslagplaats

De volgende beslissingen zijn genomen en opgenomen in de implementatie voor de structuur van de beheergroep. Deze beslissingen maken deel uit van de Azure-landingszoneversneller en de module beheergroepen van de ALZ-Bicep-opslagplaats.

Notitie

De hiërarchie van beheergroepen kan worden gewijzigd in de bicep-module van de Azure-landingszone door managementGroups.bicep te bewerken.

Beheergroep	Beschrijving
Tussenliggende hoofdbeheergroep	Deze beheergroep bevindt zich direct onder de hoofdgroep van de tenant. Gemaakt met een voorvoegsel dat wordt geleverd door de organisatie, waardoor het gebruik van de hoofdgroep doelloos wordt vermeden, zodat organisaties bestaande Azure-abonnementen naar de hiërarchie kunnen verplaatsen. Het maakt ook toekomstige scenario's mogelijk. Deze beheergroep is een bovenliggend element van alle andere beheergroepen die zijn gemaakt door de Azure-landingszoneversneller.
Platform	Deze beheergroep bevat alle onderliggende beheergroepen van het platform, zoals beheer, connectiviteit en identiteit.
Beheer	Deze beheergroep bevat een speciaal abonnement voor beheer, bewaking en beveiliging. Dit abonnement host een Azure Log Analytics-werkruimte, inclusief bijbehorende oplossingen en een Azure Automation-account.
Connectiviteit	Deze beheergroep bevat een toegewezen abonnement voor connectiviteit. Dit abonnement host de Azure-netwerkresources die vereist zijn voor het platform, zoals Azure Virtual WAN, Azure Firewall en Azure DNS-privézones.
Identiteit	Deze beheergroep bevat een toegewezen abonnement voor identiteit. Dit abonnement is een tijdelijke aanduiding voor virtuele machines (VM's) van Windows Server Active Directory-domein Services (AD DS) of Microsoft Entra Domain Services. Het abonnement schakelt ook AuthN of AuthZ in voor workloads binnen de landingszones. Specifieke Azure-beleidsregels worden toegewezen om de resources in het identiteitsabonnement te beveiligen en te beheren.
Landingszones	De bovenliggende beheergroep voor alle onderliggende beheergroepen van de landingszone. Er zijn workloadagnostische Azure-beleidsregels toegewezen om ervoor te zorgen dat workloads veilig en compatibel zijn.
Online	De toegewezen beheergroep voor online landingszones. Deze groep is bedoeld voor workloads waarvoor mogelijk directe inkomende/uitgaande internetconnectiviteit is vereist of voor workloads waarvoor mogelijk geen virtueel netwerk is vereist.
Corp	De toegewezen beheergroep voor bedrijfslandingszones. Deze groep is bedoeld voor workloads waarvoor connectiviteit of hybride connectiviteit met het bedrijfsnetwerk is vereist via de hub in het connectiviteitsabonnement.
Sandboxen	De toegewezen beheergroep voor abonnementen die alleen worden gebruikt voor testen en verkennen door een organisatie. Deze abonnementen worden veilig losgekoppeld van de bedrijfs- en onlinelandingszones. Sandboxes hebben ook een minder beperkende set beleidsregels toegewezen om testen, verkennen en configuratie van Azure-services mogelijk te maken.
Buiten gebruik gesteld	De toegewezen beheergroep voor landingszones die worden geannuleerd. Geannuleerde landingszones worden na 30-60 dagen verplaatst naar deze beheergroep voordat ze door Azure worden verwijderd.

Notitie

Voor veel organisaties bieden de standaard Corp - en Online beheergroepen een ideaal uitgangspunt. Sommige organisaties moeten meer toevoegen, terwijl anderen ze niet relevant vinden voor hun organisatie.

Als u overweegt om wijzigingen aan te brengen in de hiërarchie van de beheergroep, raadpleegt u de architectuur van de Azure-landingszone aanpassen om te voldoen aan de vereistenrichtlijnen .

Machtigingen voor de Azure-landingszoneversneller

• Hiervoor is een toegewezen SPN (Service Principal Name) vereist voor het uitvoeren van beheergroepbewerkingen, abonnementsbeheerbewerkingen en roltoewijzing. Gebruik van een SPN beperkt het aantal gebruikers met verhoogde rechten en volgt de richtlijnen voor minimale bevoegdheden.

• Hiervoor is de rol gebruikerstoegang Beheer istrator vereist in het bereik van de hoofdbeheergroep om de SPN-toegang op het hoofdniveau te verlenen. Nadat er machtigingen zijn verleend aan de SPN, kan de rol van beheerder van gebruikerstoegang veilig worden verwijderd. Op deze manier maakt alleen de SPN deel uit van de rol van beheerder van gebruikerstoegang.

• Vereist de rol Inzender voor de SPN die eerder is vermeld in het bereik van de hoofdbeheergroep, waardoor bewerkingen op tenantniveau mogelijk zijn. Dit machtigingsniveau zorgt ervoor dat de SPN kan worden gebruikt voor het implementeren en beheren van resources voor elk abonnement binnen uw organisatie.

Volgende stappen

Meer informatie over de rolabonnementen spelen wanneer u een grootschalige azure-acceptatie plant.

Abonnementen