Hoe je een Azure-managementgroephiërarchie ontwerpt zonder je organogram te kopiëren

By Mirko Peters · 2026-10-21

Ontdek waarom het spiegelen van je organogram in Azure-managementgroepen tot governancefalen leidt, en hoe je een schaalbare cloudhiërarchie ontwerpt.

Automatically translated with AI from the original post. Read the English original

Een effectieve Azure-managementgroephiërarchie ontwerpen is een van de belangrijkste basistaken voor elke cloudarchitect. In plaats van een wildgroeiende boomstructuur te bouwen die je HR-rapportagestructuur nabootst, groepeert een succesvolle cloudarchitectuur abonnementen op basis van gemeenschappelijke beveiligings-, beleids- en compliancebehoeften. Zo bereik je schaalbaar governance zonder administratief chaos.

Belangrijkste punten

• Vermijd het spiegelen van organogrammen in je Azure-managementgroepboom om administratieve lasten en starre governance-knelpunten te voorkomen.
• Ontwerp je Azure-hiërarchie rond gedeelde regelsets, beveiligingsgrenzen en beleidshandhaving, en niet rond rapportagelijnen.
• Houd je managementgroepboom plat (streef naar drie tot vier niveaus diep) zodat het overzicht en het beheer in de hele tenant behouden blijven.
• Gebruik ingebouwde landingszones zoals platform, corp, online, sandboxes en decommissioned om een beproefde, schaalbare basis te leggen.

De valkuil van organogram-governance

Wanneer organisaties voor het eerst naar de cloud overstappen, is het verleidelijk om het bedrijfsadressenboek of het organogram als blauwdruk voor de Azure-architectuur te gebruiken. Je maakt misschien een groep op het hoogste niveau voor Marketing, een andere voor Financiën, en geneste subgroepen voor elke subafdeling eronder. Hoewel dit op dag één intuïtief aanvoelt, veroorzaakt het al snel ernstige operationele wrijving.

Organisaties veranderen voortdurend. Afdelingen fuseren, krijgen een nieuwe naam, worden afgesplitst of worden elk paar kwartalen gereorganiseerd. Als je Azure-managementgroephiërarchie strikt het organogram volgt, moet je bij elke reorganisatie je cloudinfrastructuur herschikken. Abonnementen moeten worden verplaatst, overervingsmodellen breken en beveiligingsbeleid moet volledig opnieuw worden beoordeeld. Belangrijker nog: afzonderlijke afdelingen delen vaak exact dezelfde technische governance-eisen. Ze groeperen op basis van HR-grenzen in plaats van technische regels ondermijnt het primaire doel van managementgroepen.

Bouwen rond regels, niet rond mensen

Het echte doel van een managementgroep is om consistente regels, beleid en op rollen gebaseerd toegangsbeheer (RBAC) tegelijk over meerdere abonnementen toe te passen. Daarom moet je hiërarchie zijn opgebouwd rond operationele grenzen en niet rond menselijke rapportagestructuren. Vraag jezelf af welke technische regels een workload moet volgen, in plaats van wie het budget beheert.

Vereisen bepaalde workloads strikte PCI-compliance en isolatie van het publieke internet? Hebben sommige ontwikkelomgevingen juist soepelere beleidsregels nodig om experimenteren te stimuleren? Deze technische eisen bepalen je mappenstructuur. Wanneer je abonnementen groepeert die dezelfde compliance-eisen, beveiligingsbasislijnen en netwerkverbindingsprofielen delen, wordt je governancestrategie oneindig veel eenvoudiger om te beheren.

Het bewezen Landing Zone-model

Om te voorkomen dat je een boomstructuur vanaf nul moet ontwerpen, biedt Microsoft een beproefde blauwdruk: de Enterprise-Scale Landing Zone. Deze referentiearchitectuur zorgt voor een heldere, voorspelbare hiërarchie die moeiteloos meeschaalt over honderden abonnementen, zonder dat je last krijgt van organisatorische drift.

Onder de Tenant Root Group en je eigen bedrijfsspecifieke tussenliggende root splitst de architectuur zich meestal in vier kernvertakkingen:

• Platform: Bevat gedeelde services zoals abonnementen voor connectiviteit, identiteit, beveiliging en beheer.
• Landing Zones: Hier draaien je daadwerkelijke bedrijfsworkloads, vaak opgesplitst in de groepen corp (intern gericht) en online (internetgericht).
• Sandboxes: Biedt een geïsoleerde ruimte waarin ontwikkelaars en engineers met minimale beperkingen ideeën kunnen uittesten.
• Decommissioned: Fungeert als tijdelijke parkeerplaats voor abonnementen die uit gebruik gaan, voordat Azure ze definitief verwijdert.

Deze indeling zorgt ervoor dat gedeelde basisservices, beheerd door gespecialiseerde teams zoals netwerk en beveiliging, volledig gescheiden blijven van de dagelijkse bedrijfsapplicaties. Elke vertakking kan precies de beleidsregels overnemen die nodig zijn, zonder dat beperkingen doorsijpelen naar niet-verwante delen van het bedrijf.

De hiërarchie plat en beheersbaar houden

Een veelgemaakte fout bij het implementeren van Azure-beheergroepen is overengineering. Engineers maken vaak diepe, meerlagige structuren met zes, zeven of acht niveaus aan submappen, in de overtuiging dat extreme granulariteit beter beveiligd betekent. In werkelijkheid maken diepe hiërarchieën het zicht minder helder en het oplossen van problemen lastiger.

Microsoft adviseert om je beheergroepenboom plat te houden, met een maximum van doorgaans drie tot vier niveaus diep. Houd er rekening mee dat beleidsovererving van boven naar beneden verloopt en dat deny-toewijzingen op hogere niveaus niet eenvoudig lager in de boom kunnen worden overschreven zonder expliciete uitzonderingen. Als je boom te diep is, wordt het uitzoeken waarom een specifieke resourcedeployment is geblokkeerd een frustrerende zoektocht.

Let daarnaast op het standaardgedrag bij het aanmaken van nieuwe abonnementen. Elk nieuw abonnement dat je aanmaakt, komt automatisch rechtstreeks in de Tenant Root Group terecht, tenzij je het expliciet ergens anders toewijst. Omdat de rootgroep je volledige tenant verankert en elke resource wereldwijd beïnvloedt, moet je operationele waarborgen instellen om nieuwe abonnementen meteen naar je gestructureerde landing zones te verplaatsen.

Conclusie

Het ontwerpen van je Azure-beheergroepenhiërarchie vraagt om een andere manier van denken. In plaats van je af te vragen hoe je bedrijf er op papier uitziet, richt je je op hoe je workloads zich in de praktijk gedragen. Door je cloudomgeving te structureren rond technische landing zones in plaats van organisatieschema's, elimineer je administratieve overhead en bouw je een veerkrachtige basis die netjes meeschaalt.

Wil je een volledige, jargonvrije uitleg over hoe Azure-beheergroepen en abonnementen samenwerken om cloudwildgroei te beteugelen? Luister dan naar de volledige aflevering van de M365 FM Podcast en beheers vandaag nog je cloudarchitectuur!

Veelgestelde vragen

Waarom zou ik het organigram van mijn bedrijf niet overnemen in Azure-beheergroepen?

Organigrammen veranderen vaak door reorganisaties, overnames en hernoemde afdelingen. Als je Azure-hiërarchie overeenkomt met je HR-rapportagelijnen, moet je voortdurend abonnementen verplaatsen, beleidsregels herschrijven en overervingsmodellen verstoren. Beheergroepen moeten worden gestructureerd op basis van operationele regels en beveiligingseisen, niet op basis van personen.

Hoeveel niveaus diep mag een Azure-beheergroepenhiërarchie zijn?

Microsoft raadt aan om je beheergroepenboom relatief plat te houden, meestal met drie tot vier niveaus onder de tenant-rootgroep. Te diep gaan leidt tot een warboel aan overerving die lastig te controleren, te troubleshooten en uit te leggen is aan nieuwe beheerders.

Wat is het verschil tussen platform- en workload-managementgroepen?

Platform-managementgroepen bevatten gedeelde basisabonnementen, zoals connectiviteit, beveiliging, identiteit en monitoring, waar de hele organisatie op vertrouwt. Workload-managementgroepen bevatten de daadwerkelijke bedrijfsapplicaties en -diensten, die worden ingedeeld in categorieën zoals corp, online of sandbox, afhankelijk van hun netwerk- en blootstellingsbehoeften.

Waar komen nieuw aangemaakte Azure-abonnementen automatisch terecht?

Standaard komt een nieuw Azure-abonnement, als je de locatie niet opgeeft, direct in de Tenant Root Group terecht. Omdat globale regels die op de root group worden toegepast, van invloed zijn op elk abonnement in de onderneming, is het een best practice om nieuwe abonnementen meteen naar de juiste onderliggende managementgroepen te verplaatsen.