Policy as Code met Azure Policy en Azure DevOps: een praktische aanpak

Het probleem met portal-gebaseerde governance

Stel: een security engineer maakt een Azure Policy aan via de portal om te voorkomen dat resources buiten West-Europa worden aangemaakt. De policy werkt. Maar zes maanden later is de engineer vertrokken, niemand weet meer waarom de policy er is, en een nieuwe collega past de scope aan om een uitzondering te maken voor een testomgeving. Die uitzondering wordt nooit teruggedraaid. Dit scenario herhaalt zich tientallen keren in organisaties die governance via de portal beheren. Het resultaat is een governance-landschap dat niemand volledig begrijpt en dat bij elke audit voor verrassingen zorgt.

Policy as Code lost dit op door governance te behandelen als software: versiebeheer, peer review, geautomatiseerde tests en een gecontroleerde deploymentpipeline. Elke policy-wijziging is traceerbaar, elke assignment is gedocumenteerd, en de compliance-score is een directe afspiegeling van de code in de repository.

De bouwstenen: Azure Policy en Management Groups

Azure Policy is het governance-mechanisme van Azure: het evalueert resources tegen gedefinieerde regels en kan resources blokkeren (Deny), corrigeren (Modify/DeployIfNotExists) of alleen rapporteren (Audit). Policy-initiatieven bundelen meerdere policies in een logische set — bijvoorbeeld een initiatief voor CIS Microsoft Azure Foundations Benchmark of het Microsoft Cloud Security Benchmark (MCSB). Management Groups zijn de hiërarchische containers waarbinnen policies worden toegewezen: een policy op management group niveau geldt automatisch voor alle onderliggende subscriptions en resource groups.

De kracht van Policy as Code zit in de combinatie van deze twee mechanismen met een CI/CD-workflow. Policy-definities worden opgeslagen als JSON-bestanden in een Git-repository. Een Azure DevOps-pipeline valideert de policy-definities bij elke pull request, deployt ze naar een testomgeving voor validatie, en na goedkeuring naar productie. De assignment — welke policy wordt op welke scope toegepast — is eveneens als code vastgelegd, zodat de volledige governance-configuratie reproduceerbaar is.

De workflow in de praktijk

Een typische Policy as Code workflow begint met een wijzigingsverzoek: een security engineer wil een nieuwe guardrail toevoegen die voorkomt dat storage accounts publiek toegankelijk zijn. De engineer maakt een branch aan in de repository, voegt de policy-definitie toe als JSON-bestand en opent een pull request. De CI-pipeline valideert automatisch de JSON-syntax, controleert of de policy-definitie voldoet aan de naamgevingsconventie en voert een what-if analyse uit op een testomgeving om te zien welke resources non-compliant zouden worden. Na review door een tweede engineer wordt de PR gemerged en deployt de CD-pipeline de policy naar productie.

Een cruciaal detail in deze workflow is de volgorde van effecten. Nieuwe policies worden altijd eerst in Audit-modus uitgerold: ze rapporteren non-compliance maar blokkeren niets. Na een validatieperiode — typisch twee tot vier weken — worden ze omgezet naar Deny of Modify. Dit voorkomt dat een nieuwe policy onverwacht legitieme workloads blokkeert. Uitzonderingen worden beheerd via een exemption-workflow die eveneens als code is vastgelegd, met een verplichte einddatum en een goedkeuringsproces.

Compliance-rapportage als bijproduct

Een van de meest waardevolle bijproducten van Policy as Code is geautomatiseerde compliance-rapportage. Azure Policy genereert continu een compliance-score per initiatief, per subscription en per resource group. Via Azure Resource Graph kunnen deze scores worden opgevraagd en gecombineerd met andere metadata. Azure Workbooks maken het mogelijk om dashboards te bouwen die de compliance-score over tijd tonen, non-compliant resources prioriteren op basis van risico en de voortgang van remediatie bijhouden. Deze rapportage is geen handmatige exercitie meer maar een directe afspiegeling van de werkelijke toestand van de omgeving.

RBAC als code: de vergeten helft van governance

Policy as Code is onvolledig zonder RBAC as Code. Role-based access control bepaalt wie wat mag doen in de Azure-omgeving, en ook dit is te complex om handmatig bij te houden. RBAC-toewijzingen als code in versiebeheer zorgen ervoor dat elke toegangsverlening traceerbaar is, periodiek gereviewed wordt en automatisch wordt ingetrokken wanneer een medewerker de organisatie verlaat. In combinatie met Microsoft Entra ID Privileged Identity Management (PIM) voor just-in-time toegang tot privileged rollen, vormt dit de basis van een least-privilege architectuur.