Weet jij exact wie er op dit moment rechten heeft om een dure, production-grade SKU uit te rollen in jullie testomgeving? In veel organisch gegroeide Azure-landschappen is het antwoord op die vraag angstaanjagend onduidelijk. Waar applicaties, netwerkresources en identiteiten door elkaar heen lopen, verlies je als platformteam vroeg of laat de controle. Handmatige aanpassingen stapelen zich op en harde grenzen ontbreken. Hoe doorbreek je deze cyclus van wildgroei en access hoarding, en zorg je dat de applicatieteams daar geen vertraging van ondervinden?
De uitdaging: de strijd tegen wildgroei en access hoarding
Bij onze klanten zien we vaak dat het kernprobleem draait om beheersbaarheid. In een organisch gegroeid landschap ontbreken simpelweg de kaders om veilig en efficiënt te kunnen werken. Dit zorgt in de praktijk voor een aantal flinke pijnpunten.
Wildgroei via de portal: Er wordt veel handmatig aangepast via de Azure Portal (ClickOps). Hierdoor ontbreken kaders, is er geen reproduceerbaarheid en is de infrastructuur kwetsbaar voor menselijke fouten.
Onveilige configuraties: Omdat harde grenzen (vangrails) ontbreken, kunnen ontwikkelaars in lagere omgevingen onbewust dure production-grade SKU’s of onveilige netwerkconnecties aanmaken.
Het gevaar van access hoarding: Rechten worden uitgedeeld om snel problemen op te lossen, maar zelden weer ingetrokken. Dit resulteert in medewerkers met een berg aan permanente beheerdersrechten die ze voor hun huidige rol niet meer nodig hebben, wat een open deur is voor privilege escalation zodra dat account gecompromitteerd wordt.
De uitdaging voor platformteams is om deze complexe kluwen te ontwarren en weer controle af te dwingen via strakke policies en code. Tegelijkertijd mag de snelheid van de applicatieteams, die de dagelijkse business draaiende houden, niet in het geding komen.
De aanpak: van ARM-spaghetti naar strakke kaders
Om de beheersbaarheid te herstellen, volstaat het niet om wat policies aan te zetten. Je moet naar de fundering kijken. De aanpak is elke keer hetzelfde: eerst de omgeving uit elkaar trekken, daarna pas bouwen.
1. Inventariseren en ontvlechten
Voordat je iets nieuws bouwt, moet je de huidige situatie in kaart brengen. We trekken verstrengelde applicaties los en isoleren ze in eigen Application Landing Zones (bij voorkeur één per subscriptie). Dit legt direct harde grenzen neer.
2. Isoleren van platform resources
Gedeelde componenten, zoals de centrale DNS, netwerk-hubs of een gedeelde Key Vault voor bijvoorbeeld licenties, verplaatsen we naar streng beveiligde Platform Zones. Zo scheiden we de infrastructuur van het platformteam van de omgevingen waar developers in werken.
3. Productie is de leidraad
We exporteren de “as-is” situatie direct uit de Azure Portal, waarbij we de productieomgeving als absolute bron van waarheid nemen. Als test- of acceptatieomgevingen door de jaren heen zijn afgeweken, dwingen we af dat zij zich weer conformeren aan de productiestandaard.
4. Refactoring naar Bicep
De ruwe, geëxporteerde ARM-templates uit de Azure Portal zijn complex en onleesbaar. We gebruiken de portal-export enkel als basis en refactoren dit, vaak met de inzet van AI als versneller, naar schone, native Bicep– of Terraform-modules. Het doel is een fundering die 100% via Infrastructure as Code (IaC) is gedreven.
5. De realiteit: legacy en change management
In de praktijk verloopt een brownfield-migratie nooit als een perfect lineair stappenplan. Technisch loop je soms tegen hardnekkige legacy aan, zoals applicaties op ASP Classic die zich maar moeilijk naar een moderne Azure-omgeving laten vertalen. Maar de grootste wrijving zit bijna altijd in het change management.
Productteams staan onder enorme druk om te blijven leveren. Voor hen voelt nieuwe platform-governance al snel als een bus die van rechts komt. Je hebt hiervoor twee dingen nodig die even hard zijn: mandaat van het management, en begrip voor de druk op de productteams.
De oplossing: zero-trust governance met een Azure Landing Zone
Zodra de basis staat, mag alles wat op het platform landt uitsluitend nog via code (IaC) worden uitgerold. Developers werken binnen deze kaders via Azure Policies en strak identiteitsbeheer.
De landing zone vending machine
Application landing zones worden uitgerold door het platformteam, vanuit één centrale pipeline met een Bicep-basistemplate. Applicatieteams hoeven alleen een kleine parameterset aan te leveren, met waardes zoals subscriptienaam, locatie en kostenpost. De rest is standaard. Geen losse pipelines per team, geen afwijkende configuraties.
Dit voorkomt dubbele code en zorgt ervoor dat het platformteam centraal de kwaliteit borgt, terwijl developers makkelijk en snel nieuwe zones kunnen inzetten.
Azure Policies gebaseerd op het Well-Architected Framework
In plaats van lukraak policies te activeren, baseren we de regels op de pilaren van het Microsoft Azure Well-Architected Framework. Praktische toepassingen zijn:
| WAF-pilaar | Policymaatregel |
|---|---|
| Cost Optimization | Blokkeer onnodig dure, production-grade SKU’s in testomgevingen |
| Security | Weiger of log verouderde protocollen en onveilige connecties |
| Reliability | Verplicht Availability Zones voor kritieke resources |
| Performance Efficiency | Beperk uitrol tot specifieke Azure-regio’s dicht bij de eindgebruiker |
| Operational Excellence | Verplicht tags zoals CostCenter en log altijd naar een centrale Log Analytics Workspace |
Deny, Audit en DeployIfNotExists. Een Deny-policy blokkeert de deployment direct; een Audit-policy logt afwijkingen zonder te blokkeren. Begin met Audit om de impact te meten voordat je naar Deny gaat.Het einde van access hoarding via PIM
Het oude model, waarbij gebruikers te veel permanente rechten hadden, is vervangen door een zero-trust benadering. Door Privileged Identity Management (PIM) te gebruiken, krijgen medewerkers alleen tijdelijk toegang (Just-In-Time) wanneer dit echt nodig is.
Daarbovenop plannen we periodieke Access Reviews in. Wisselt een developer van team? Dan verliest die automatisch zijn oude permissies. In de praktijk zien we direct resultaat: bij de invoering van deze reviews worden er per product al snel één tot twee personen uit de toegangslijst verwijderd, simpelweg omdat zij na een afgerond project hun rechten nog steeds hadden behouden.
Conclusie: de menselijke factor als fundament
De technische kant, (IaC, policies, PIM) is het fundament. Maar zonder mandaat en vertrouwen staat dat fundament nergens. Je kunt de architectuur nog zo strak uittekenen, zonder draagvlak bij de developers en het management strandt het project.
Begrijp de druk op de productteams, communiceer open over aanpassingen, en respecteer hun resources. Pas als het wederzijdse vertrouwen er is, kun je samen succesvol de stap maken van brownfield chaos naar een schaalbare blauwdruk.
Technische governance slaagt alleen met managementmandaat en actieve betrokkenheid van de productteams; communicatie en vertrouwen zijn net zo kritisch als de toolkeuze.
Kun je wel wat hulp gebruiken bij het ontvlechten van jullie Cloud / Azure landschap? Onze experts van Cloud Republic denken graag met je mee.
