Wat een Azure Landing Zone Audit echt vindt

In dit artikel

• Management Group-hiërarchieën die groeiden zonder plan
• Policy Assignments die niemand onderhoudt
• Private Endpoint DNS die niet goed werkt
• Identity Architecture die stopte met evolueren
• Network Over-Engineering
• Cost Tagging die geen bruikbare rapporten oplevert
• Typische remediatietijdlijn
• Wat een Platform Health Check oplevert

Kort samengevat: Na het reviewen van tientallen enterprise Azure-omgevingen duiken dezelfde zes problemen steeds weer op: overmatig complexe management groups, ononderhouden policies, kapotte private endpoint DNS, verouderde identity-configuraties, network sprawl en cost tags die niemand vertrouwt. De meeste zijn op te lossen in 3-5 weken met een gestructureerd remediatieplan.

We reviewen Azure-omgevingen voor de kost. Productieplatformen die twee, drie, soms vijf jaar draaien. De oorspronkelijke architecten zijn vertrokken, drie verschillende teams hebben beslissingen op elkaar gestapeld, en de documentatie werd ergens rond maand zes voor het laatst bijgewerkt.

Na dit herhaaldelijk te doen bij middelgrote en grote ondernemingen vallen de bevindingen in dezelfde gebieden. Azure landing zones zijn bedrieglijk eenvoudig te deployen en oprecht lastig te onderhouden. De initiële deployment krijgt aandacht, budget en een projectteam. De jaren die volgen krijgen de tijd die het platform team kan missen.

Dit is wat we consequent vinden.

Bevinding	Typische ernst	Hoe vaak
Management group over-engineering	Medium	70%+ van de audits
Ononderhouden policy assignments	Hoog	Vrijwel universeel
Private endpoint DNS-storingen	Kritiek	60%+ van de audits
Identity architecture-hiaten	Hoog	80%+ van de audits
Network sprawl en verouderde regels	Medium	70%+ van de audits
Cost tagging die finance negeert	Medium	Vrijwel universeel

Management Group-hiërarchieën die groeiden zonder plan

De Azure Landing Zone-referentiearchitectuur raadt drie tot vier niveaus management groups aan. Dat is genoeg voor vrijwel elke organisatie. We schreven hierover in onze oorspronkelijke landing zone-lessen en opnieuw toen we behandelden wat er toe doet in volwassen omgevingen.

Wat we in de praktijk vinden: zes, zeven, soms acht niveaus. Extra lagen voor business units, dan sublagen voor regio’s, dan sub-sublagen voor omgevingen. Elk niveau was logisch voor degene die het toevoegde. Het cumulatieve resultaat is een hiërarchie die niemand uit het hoofd kan tekenen.

De echte schade is niet cosmetisch. Policy inheritance wordt onvoorspelbaar. RBAC-toewijzingen op het ene niveau spreken die op een ander niveau tegen. Wanneer een deployment faalt omdat een policy op het vierde niveau een exemption op het zesde niveau overschrijft, loopt het debugpad door elke bovenliggende groep. We besteden regelmatig hele dagen aan het traceren van policy evaluation chains die minuten zouden moeten kosten.

Orphaned management groups komen ook vaak voor. Een divisie werd geherstructureerd, de subscriptions zijn verplaatst, maar de lege management group en zijn policy assignments bleven staan. Niemand verwijderde het omdat niemand zeker wist of het veilig was.

De oplossing is bijna altijd platslaan. Verwijder niveaus die bestaan voor organisatorische ijdelheid in plaats van concrete governance-vereisten. Als een management group geen policy assignment of RBAC-grens draagt die verschilt van zijn parent, hoort hij er waarschijnlijk niet te zijn.

Policy Assignments die niemand onderhoudt

Een vers gedeployde landing zone wordt doorgaans geleverd met een samengestelde set Azure Policy assignments: deny public IPs, enforce encryption, require tags, deploy diagnostic settings. Deze zijn correct en waardevol. Het probleem begint rond maand acht.

Nieuwe compliance-eisen komen binnen. Iemand voegt een custom policy toe voor naming conventions. Een ander team maakt een policy voor region restrictions. Een derde persoon kopieert een policy definition van een blogpost. Exemptions worden verleend voor workloads die nog niet kunnen voldoen. Meer exemptions volgen. Vervaldatums worden ingesteld maar nooit bijgehouden.

Na twee jaar heeft een typische omgeving 150 tot 300 policy assignments verspreid over de hiërarchie, 30 tot 60 exemptions (waarvan een derde verlopen datums heeft die niemand heeft opgemerkt), en 20+ custom policy definitions, waarvan sommige duplicaten zijn van built-in policies die Microsoft uitbracht nadat de custom versies waren geschreven.

Het compliance-dashboard vertelt het verhaal. We zien regelmatig management groups op 55-65% compliance. Wanneer we vragen wanneer iemand voor het laatst de compliancecijfers heeft bekeken, is het antwoord meestal een lege blik of “we checken het als er iets kapotgaat.”

Policy-hygiëne vereist dezelfde discipline als code-hygiëne. Driemaandelijkse reviews, deduplicatie tegen de groeiende built-in library, verwijdering van verouderde exemptions, en een gedocumenteerd proces voor het verlenen van nieuwe. De meeste organisaties hebben hier niets van.

Patroon: Management groups en policies zijn governance-infrastructuur. Ze worden eenmalig gebouwd en nooit onderhouden. De kloof tussen beoogde governance en daadwerkelijke governance wordt elk kwartaal groter.

Private Endpoint DNS die niet goed werkt

Private endpoints zijn overal in modern Azure. Elk storage account, key vault, SQL database en container registry dat van het publieke internet af moet krijgt een private endpoint. Elk daarvan heeft een DNS-record nodig in de juiste private DNS zone zodat clients de servicenaam resolven naar het privé-IP in plaats van het publieke.

Het aanbevolen patroon is duidelijk: gecentraliseerde private DNS zones in de connectivity subscription, gelinkt aan alle relevante VNets, met Azure Policy die automatisch DNS-records aanmaakt wanneer private endpoints worden gecreëerd.

Wat we daadwerkelijk vinden valt in drie categorieën.

Ontbrekende zones. Iemand heeft een private endpoint aangemaakt voor een Cosmos DB-account maar de privatelink.documents.azure.com zone bestaat niet in de connectivity subscription. De endpoint werkt vanaf machines die de DNS van het VNet gebruiken, maar resolution valt terug op publieke DNS voor alles buiten dat VNet. Het datapad gaat sowieso over de Microsoft backbone, maar het security team weet niet dat hun “private” endpoint publiek resolvet vanaf de helft van het netwerk.

Split-horizon-fouten. De private DNS zone bestaat en is gelinkt aan sommige VNets maar niet aan andere. Teams in VNet A resolven het storage account naar zijn privé-IP. Teams in VNet B krijgen het publieke IP. Beide teams denken dat alles werkt. Niemand heeft cross-VNet resolution getest.

Policy-hiaten. De DeployIfNotExists policy die DNS-records zou moeten aanmaken is toegewezen, maar zijn managed identity heeft geen Contributor-rechten op de resource group van de private DNS zone. De policy evalueert als compliant (de assignment bestaat) maar maakt nooit daadwerkelijk records aan. Dit komt verrassend vaak voor en is lastig te spotten zonder daadwerkelijke name resolution te testen.

De DNS-audit is vaak het meest tijdrovende deel van een landing zone review, en levert de meest urgente bevindingen op. Een kapotte DNS-configuratie kan betekenen dat verkeer waarvan het security team denkt dat het privé is, in werkelijkheid via publieke endpoints resolvet.

Identity Architecture die stopte met evolueren

Azure identity-patronen zijn aanzienlijk veranderd sinds de meeste landing zones werden gedeployd. Privileged Identity Management (PIM), Conditional Access, en workload identity federation zijn allemaal standaardvereisten in 2025. We behandelden deze verschuivingen in onze 2026 landing zone-update.

Wat we in audits vinden is dat de identity-configuratie het jaar weerspiegelt waarin het werd opgezet, niet de huidige stand van zaken.

Permanente Contributor- en Owner-toewijzingen op productiesubscriptions zijn de meest voorkomende bevinding. Geen PIM, geen just-in-time activatie, geen goedkeuringsworkflow. Het security team weet dat PIM bestaat maar “is er nog niet aan toegekomen” omdat de uitrol elke subscription moet raken.

Gedeelde service accounts met client secrets opgeslagen in key vaults zijn de op een na meest voorkomende bevinding. CI/CD-pipelines authenticeren met langlevende secrets die twee jaar geleden zijn aangemaakt en nooit zijn geroteerd. Workload identity federation zou deze secrets volledig elimineren, maar de migratie vereist wijzigingen in elke pipeline.

Workload identities zijn een ander blind punt. App registrations en service principals stapelen zich op over de tijd zonder eigendomstracking. We vinden tientallen app registrations waarvan de oorspronkelijke maker de organisatie heeft verlaten, niemand weet wat de applicatie doet, en de credentials zijn nog steeds actief. Applicaties die op Azure compute draaien maar authenticeren naar andere Azure-services met client secrets in plaats van managed identity voegen onnodige credential management overhead en rotatierisico toe. Managed identity elimineert de secret volledig, maar de migratie vereist het identificeren van elke authenticatiestroom.

Conditional Access-hiaten maken het beeld compleet. Policies bestaan voor eindgebruikers maar niet voor beheertoegang. Of ze bestaan maar dekken geen device compliance, zodat een beheerder een Global Admin-rol kan activeren vanaf een onbeheerde persoonlijke laptop.

Geen van deze bevindingen is exotisch. Het zijn goed gedocumenteerde best practices die gerichte inspanning vereisen om te implementeren. Die inspanning krijgt zelden prioriteit wanneer het platform team druk is met het blussen van branden elders.

Patroon: DNS en identity zijn de twee gebieden waar de kloof tussen “het was ooit correct opgezet” en “het werkt vandaag nog steeds correct” het grootst is. Beide vereisen periodieke validatie, niet alleen initiële configuratie.

Network Over-Engineering

Hub-spoke is de correcte standaardtopologie, en de meeste ondernemingen die we auditen hebben het gedeployd. Het probleem is niet de topologie. Het is wat er na de initiële deployment gebeurde.

Ongebruikte spokes komen veel voor. Een project was gepland, een spoke VNet was ingericht en gepeered naar de hub, maar het project werd geannuleerd of ging een andere richting op. De peering blijft, de adresruimte is gealloceerd, en de hub firewall heeft regels voor verkeer dat nooit zal aankomen.

Peering meshes zijn erger. Iemand had spoke-to-spoke communicatie nodig en voegde, in plaats van via de hub firewall te routeren, directe peerings toe. Toen deed een ander team hetzelfde. Na een paar ronden ziet het netwerkdiagram eruit als een bord spaghetti en kan niemand de vraag “kan VNet A met VNet B praten?” beantwoorden zonder elke peering en route table te traceren.

Firewall-regels stapelen zich op dezelfde manier op als policy assignments. Regels worden toegevoegd voor nieuwe workloads maar nooit verwijderd wanneer workloads worden uitgefaseerd. We vinden routinematig Azure Firewall rule collections met 200+ regels, waarvan een derde verwijst naar IP-adressen die niet meer bestaan. De laatste review-datum van de regels is ofwel “nooit” of “toen we het deployde.”

De netwerkaudit gaat niet over het vinden van de verkeerde topologie. Het gaat over het vinden van de kloof tussen het beoogde ontwerp en wat er daadwerkelijk bestaat na twee jaar incrementele wijzigingen zonder opruiming.

Cost Tagging die geen bruikbare rapporten oplevert

Elke landing zone dwingt tags af. Cost centre, environment, owner, application. De policy is ingesteld, de tags bestaan op resources, en het FinOps-team heeft dashboards in Cost Management. Op papier werkt kostenallocatie.

In de praktijk keren drie problemen terug.

Tags op resources maar niet op resource groups. Azure Policy kan tags afdwingen op resource group-niveau en het Modify-effect gebruiken om ze naar beneden te laten overerven naar resources, maar veel organisaties dwingen alleen af op resourceniveau. Cost Management-rapporten die groeperen op resource group tonen dan inconsistente tagwaarden over de resources erin, waardoor kostenallocatie onbetrouwbaar wordt.

Geen tag inheritance ingeschakeld. Azure ondersteunt tag inheritance policies die tags kopiëren van resource groups of subscriptions naar resources. De meeste organisaties gebruiken ze niet. Het resultaat is dat een resource group getagd met cost centre “CC-5678” resources bevat getagd met “CC-1234” omdat de resource uit een andere groep werd verplaatst en zijn tags nooit werden bijgewerkt.

Verouderde waarden. Afdelingen worden geherstructureerd, projecten eindigen, cost centres veranderen. De tags blijven staan. Na een paar jaar verwijst 15-20% van de cost centre-tags naar codes die niet meer bestaan in het financiële systeem. De FinOps-rapporten tonen uitgaven tegen fantoomafdelingen, en het financiële team stopt met het vertrouwen van de cijfers.

Tagnauwkeurigheid is een datakwaliteitsprobleem, geen policyprobleem. Policy kan tagaanwezigheid afdwingen en inheritance-patronen toepassen, maar het kan niet valideren of een cost centre nog bestaat in je financiële systeem of de vermelde eigenaar nog bij het bedrijf werkt. Afdwinging bij aanmaak is noodzakelijk maar niet voldoende. Je hebt periodieke reconciliatie nodig tegen de gezaghebbende bron (en die bron staat meestal buiten Azure), geautomatiseerde correctie waar mogelijk, en een proces voor het afhandelen van mismatches.

Typische remediatietijdlijn

Het fixen van een landing zone kost meer dan een enkele sprint. Op basis van wat we zien bij opdrachten ziet een realistische tijdlijn er zo uit:

• Week 1: Architecture assessment en bevindingsrapport. Loop door de omgeving, documenteer de hiaten en prioriteer op ernst en inspanning.
• Week 2: Governance baseline. Platslaan van de management group-hiërarchie, verwijderen van verouderde policy assignments, consolideren van dubbele definities.
• Weken 3-4: Identity- en policy-remediatie. Uitrol van PIM voor permanente geprivilegieerde toegang, migratie van workload identities naar managed identity of federated credentials, dichten van Conditional Access-hiaten.
• Week 5 en verder: Netwerkvereenvoudiging en kostenoptimalisatie. Opruimen van ongebruikte peerings, consolideren van firewallregels, fixen van DNS zone-dekking en aanpakken van tagnauwkeurigheid.

Elke fase bouwt voort op de vorige. Governance-opruiming maakt policy-remediatie schoner, en identity-fixes verkleinen de blast radius voordat netwerkwijzigingen beginnen.

Wat een Platform Health Check oplevert

Een gestructureerde landing zone-audit levert concrete, actionable deliverables op:

• Management group-hiërarchie-assessment met specifieke aanbevelingen om te platslaan of te herstructureren, inclusief impactanalyse voor elke wijziging
• Policy health review: dubbele definities, verouderde exemptions, compliance-hiaten per management group, en een geprioriteerde remediatie-backlog
• Private endpoint DNS-audit: zone-inventaris, VNet link-dekking, testen van policy-effectiviteit, en een lijst van endpoints die publiek resolven terwijl dat niet zou moeten
• Identity posture-rapport: inventaris van permanente geprivilegieerde toegang, PIM-gereedheidsassessment, kandidaten voor workload identity-migratie, en Conditional Access-gapanalyse
• Netwerktopologie-review: ongebruikte spokes en peerings, firewallregel-hygiëne, en een current-state diagram vergeleken met het beoogde ontwerp
• Cost tagging-assessment: tagdekking en nauwkeurigheidspercentages, verweesde tagwaarden, en aanbevelingen voor inheritance en reconciliatie

Elke bevinding komt met een ernstclassificatie en een remediatiepad. Het doel is een backlog waar het platform team mee aan de slag kan, geen lijst van observaties.

Als je landing zones langer dan een jaar draaien zonder een gestructureerde review, liggen er bevindingen te wachten. De vraag is of je ze proactief vindt of ontdekt tijdens een incident.

Typische opdracht: Bij het reviewen van Azure-platformen beginnen we meestal met een gestructureerd Azure architecture assessment dat landing zone-structuur, management group-hiërarchie, policy health, identity posture, netwerktopologie en cost tagging omvat. Het assessment levert een geprioriteerd bevindingsrapport op met ernstclassificaties en een remediatie-roadmap. De meeste reviews duren 2-3 weken.

Gerelateerd: Azure Landing Zones in 2026 en wat er nu echt toe doet day-2 operationele uitdagingen · Azure Policy Guardrails die developers niet haten afdwinging zonder wrijving · Waarom je Azure-factuur hoog is ook als je resources juist gedimensioneerd zijn kostenlekken die audits missen · Azure DNS Private Resolver hub DNS VM’s vervangen