Een Azure landing zone bouwen: stappenplan voor MKB

Een Azure landing zone is een verzameling afspraken, structuren, en geautomatiseerde guardrails die ervoor zorgen dat workloads op een veilige, beheersbare manier in Azure landen. Grote ondernemingen zetten hier teams maandenlang voor in. Een MKB-bedrijf met 3 tot 30 IT-mensen heeft die luxe niet, en heeft de volledige complexiteit ook niet nodig.

Dit is wat je wel nodig hebt, in volgorde van belang.

Start met management groups

Zonder management groups heb je geen plek om beleid op schaal te handhaven. Maak de volgende structuur aan:

Tenant Root Group
├── Platform
│   └── Management (voor log-workspace, monitoring)
└── Landing Zones
    ├── Production
    └── Non-production

Dit is de minimale structuur. Je kunt later uitbreiden met sandboxes, identity, of connectivity-management groups, maar begin hier. De reden voor deze scheiding: beleid dat je op Landing Zones hangt, geldt automatisch voor alles eronder. Dat is het punt van management groups.

Microsoft heeft een ingebouwd script om deze structuur aan te maken via PowerShell of Bicep. Gebruik het als startpunt, maar leen niet blind de volledige enterprise-scale-structuur met twaalf management group-lagen. Dat is beheerslast zonder voordeel voor een klein team.

Bekijk Azure governance en landing zone trainingen

Twee subscripties: productie en niet-productie

Abonnementen zijn de primaire isolatielaag in Azure. Resource locks, quota’s, kosten, en toegang zijn allemaal per abonnement te regelen. Twee is het minimum: één voor productie, één voor alles wat niet productie is (ontwikkeling, testen, staging).

De reden voor twee in plaats van resource groups in één abonnement: je kunt per abonnement aparte budgets, aparte alert-drempels, en aparte service-principals instellen. Als een medewerker per ongeluk een productie-database verwijdert, wil je dat de rechten voor dat soort acties in het eerste geval niet beschikbaar waren in het productie-abonnement.

Als je meerdere klanten of producten hebt, overweeg dan een abonnement per klant/product. Dat is de schone aanpak voor facturatie en isolatie.

Azure Policy op de management group

Dit is het onderdeel dat de meeste kleine teams overslaan, en dat is een gemiste kans. Azure Policy legt regels op die automatisch worden gecontroleerd of gehandhaafd op alle resources in het bereik.

Begin met deze vier beleidsregels:

Allowed locations: sta alleen de regio’s toe die je wilt gebruiken (bijvoorbeeld West Europe en North Europe). Dit voorkomt dat resources in regio’s buiten Europa worden aangemaakt, wat relevant is voor AVG-compliance.

Require a tag on resource groups: minimaal één tag, bijvoorbeeld environment, is verplicht op elke resource group. Zonder tags kun je kosten niet toewijzen aan teams of projecten.

Inherit a tag from the subscription: zorg dat resources automatisch de environment-tag van het abonnement overnemen.

Audit VMs without managed disk: machines die nog klassieke schijven gebruiken worden gevlagd voor migratie.

Alle vier zijn ingebouwde policies die je zonder code kunt toewijzen via de Azure Portal of Bicep. Begin met Audit-effect (het loggen van schendingen, geen blokkade) en schakel over naar Deny als je zeker weet dat alles klopt.

Gecentraliseerde logging

Eén Log Analytics workspace in je Management-abonnement, en alle andere abonnementen sturen er Diagnostic Settings naartoe. Dit geeft je één plek voor queries, alerts, en auditing, ongeacht in welk abonnement een resource staat.

Gebruik Azure Policy om Diagnostic Settings automatisch te configureren op nieuwe resources. Het handmatig bijhouden hiervan per resource werkt niet op schaal, ook niet in een kleine organisatie.

Stel ook een Log Analytics workspace-retentie in die past bij je beveiligingsvereisten. ISO 27001 en de AVG vereisen doorgaans minimaal 90 dagen. De Log Analytics-default is 30 dagen.

Wat je kunt overslaan

De volledige enterprise-scale landing zone van Microsoft heeft tientallen Bicep-modules voor hub-spoke-netwerken, Azure Firewall, ExpressRoute, DDoS Protection Standard, Defender for Cloud op elk level, en meer. Voor een klein team is dat overkill en het kost weken om te begrijpen.

Sla voorlopig over: Azure Firewall (gebruik NSGs en Azure Bastion als vervanging), DDoS Protection Standard (duur, alleen relevant bij echte publieke services op schaal), en de volledige hub-spoke-netwerktopologie (relevant als je meerdere VNets hebt met ingewikkelde routering).

Begin eenvoudig. Een management group-structuur, twee subscripties, vier policies, en gecentraliseerde logging geeft je al een herkenbare en beheersbare Azure-omgeving. Daarna bouw je uit op basis van wat je daadwerkelijk nodig hebt.

Bicep of de portal

Je kunt de management group-structuur en policies via de portal klikken. Doe dat voor de eerste keer: het helpt om te begrijpen wat je aanmaakt.

Leg het daarna vast in Bicep. Niet omdat het noodzakelijk is voor een klein team, maar omdat je over twee jaar blij bent dat je weet hoe de omgeving eruit ziet zonder door de portal te hoeven klikken. En als je een tweede klant of product onboardt, heb je een herbruikbaar patroon.

De Microsoft ALZ (Azure Landing Zones) Bicep-modules zijn een goed startpunt voor de code. Gooi ze niet als geheel in productie, maar gebruik de management group- en subscription-modules als basis en verwijder wat je niet nodig hebt.