Governance-assessment¶

Hoe het platformteam uitzoekt welke governance een organisatie nodig heeft, die omzet in een afgedwongen baseline, en elke maand controleert dat de baseline standhoudt, inclusief de financiële risico's van cloudgebruik. Het beschrijft twee dingen:

het assessment: een herhaalbare methode om de huidige governancestatus en de gewenste toekomstige status te vinden, inclusief wettelijke eisen;
de implementatie: de baseline die het platform levert als Azure Policy initiatives, geconfigureerd met de antwoorden van het assessment.

Wie wat beslist, staat in Governance en besluitvorming. Voor het dagelijks omgaan met policies, zie Policy-toewijzingen en Policy en uitzonderingen.

Methode: de governancecyclus van het Cloud Adoption Framework¶

De methode volgt de Govern-methodologie van het Microsoft Cloud Adoption Framework. Governance is een doorlopende cyclus: bouw eenmalig een cloudgovernanceteam op en herhaal dan beoordelen, documenteren, afdwingen en monitoren, zodat governance actueel blijft als risico's en eisen veranderen.

flowchart LR
    T["1. Governance team"] --> A["2. Assess risks<br/>(workshop)"]
    A --> D["3. Document policies<br/>(initiatives as code)"]
    D --> E["4. Enforce<br/>(deployed with the platform)"]
    E --> M["5. Monitor compliance and cost<br/>(monthly check)"]
    M --> A

Stap	Activiteit op het platform	Frequentie
Een governanceteam bouwen	Een team dat de baseline beheert en er met de organisatie over praat (zie Rollen)	Continu
Risico's beoordelen	Een discovery- of designworkshop tijdens de implementatie	Bij onboarding en bij elke wijziging in de eisen
Policies documenteren	Policydefinities en initiatives als infrastructure as code	Versioned, per release
Policies afdwingen	Initiatives die door de platformdeployment worden toegewezen	Elke deployment
Compliance monitoren	De maandelijkse health check en de servicereview	Maandelijks
Kosten en financieel risico monitoren	Een maandelijkse kostenreview	Maandelijks

1. Het governanceteam¶

Iemand moet de baseline beheren: de policydefinities, de initiatives en de standaarden die ze volgen. In het managed model is dit een team bij de beherende partij dat de baseline voor al zijn klanten beheert, terwijl de eigen security- en architectuurfuncties van de klant eigenaar blijven van de beslissingen (Beheermodellen). In het zelfbeheermodel is het een rol binnen je organisatie.

2. De eisen beoordelen¶

Elke implementatie begint met een gestructureerde workshop. Die is bewust voor elke organisatie hetzelfde:

een discovery workshop als het standaardplatform ongewijzigd wordt gebruikt;
een design workshop als er maatwerkeisen zijn. De uitkomst is een geschreven high-level design.

De workshop legt de huidige status vast (bestaande Azure-footprint, billing-opzet, management groups, connectivity, identiteit en elke omgeving die wordt overgenomen) en de gewenste status over de domeinen die het platform deployt: identiteit, netwerk en connectivity, securitybaseline, databescherming en retentie, resource-indeling en naamgeving, monitoring en kostenbeheer.

Leg de antwoorden vast in een gestructureerde vragenlijst. Elk antwoord hoort bij een platforminstelling, bijvoorbeeld de logretentie in dagen, de soft delete-retentie van Key Vault, DDoS-bescherming, de firewall-SKU, de WAF-policy, VPN- of ExpressRoute- connectivity en Bastion. Het assessment is dan traceerbaar: bij elke gedeployde governance-instelling kun je de vraag en het antwoord aanwijzen die eraan ten grondslag liggen.

Wettelijke en compliance-eisen maken deel uit van het assessment. De verplichtingen van de organisatie bepalen welke standaarden je toewijst en waarover je rapporteert. Het platform wijst standaard de CIS Microsoft Azure Foundations Benchmark, de Microsoft cloud security benchmark en ISO 27001 toe, en je kunt de set uitbreiden (Platformoverzicht). Behandel de risico's die je vindt zoals elk ander risico: leg ze vast in een risicolijst en geef elk een owner.

Herhaal het assessment als de eisen veranderen, en lever het resultaat als een wijziging van de platformconfiguratie (Wijzigingsworkflow).

3. Documenteer de policies: de baseline wordt met het platform geleverd¶

De governancebaseline maakt deel uit van het platform. Het is geen document dat elke organisatie zelf moet implementeren, en het wordt niet per klant met de hand geconfigureerd.

Policy-definities en initiatives horen bij de layer foundation. Policy-toewijzingen horen bij de layer postdeployment (Deployment layers).
Alles is infrastructure as code, gedeployed door pipelines. De baseline is versioned, wordt door een tweede persoon gereviewd en is herhaalbaar. Eén keer verbeteren verbetert hem voor elk platform op de code.
De initiatives zijn gebaseerd op erkende standaarden, niet op zelfbedachte regels.
Waar je templates aanbiedt, valideer ze dan tegen dezelfde standaarden, door de template te deployen en Azure Policy te laten evalueren. Zet waarden die policies controleren waar mogelijk binnen de module vast op compliant waarden.

Omdat de baseline deel uitmaakt van het product, heeft een nieuw platform vanaf dag één een governanceminimum. De antwoorden van het assessment worden als configuratie bovenop de baseline toegepast.

4. Dwing de policies af¶

Policies worden afgedwongen, niet alleen geadviseerd. Initiatives gebruiken waar passend de effecten Deny en DeployIfNotExists, zodat een niet-compliant resource bij deployment wordt geblokkeerd of automatisch wordt hersteld, in plaats van achteraf alleen te worden gemarkeerd. Uitzonderingen zijn expliciete Azure Policy-exemptions in de gedeployde configuratie, zodat een exemption een zichtbare, gereviewde beslissing is en geen stille kloof (Exemptions).

De toewijzingen en hun effect zijn zichtbaar in de Azure-portal, onder Azure Policy en in de regulatory compliance-weergave van Microsoft Defender for Cloud.

5. Monitor compliance en onderneem actie¶

Compliance wordt elke maand geëvalueerd in de maandelijkse health check en gerapporteerd aan de klant of de stakeholders. Een geplande run in de eerste dagen van de maand kan de data verzamelen. De data komt uit Azure Resource Graph policy states: per subscription hoeveel controls van elke toegewezen benchmark compliant en niet-compliant zijn, met de namen van de niet-compliant controls. Het rapport bevat ook de secure score en de securityaanbevelingen.

Omdat het rapport elke maand hetzelfde formaat heeft, ziet de lezer de trend en kan hij controleren of de situatie verbetert.

5b. Monitor kosten en financieel risico¶

Kosten zijn een governancediscipline, niet alleen een commercieel onderwerp. Ongecontroleerde uitgaven, ongebruikte of te grote resources en onverwacht verbruik zijn risico's, en je identificeert en behandelt ze zoals elk ander risico. Als het platformteam toegang heeft tot de verbruiksdata, houd dan naast de compliancecheck een maandelijkse kostenreview:

analyseer het verbruik op afwijkingen en onverwachte groei, ongebruikte of te grote resources, en gemiste kansen voor reservations of savings plans;
valideer het gegenereerde rapport en bespreek de bevindingen, zodat een financieel risico tot een beslissing leidt zoals een compliancebevinding dat doet;
bepaal wanneer een diepgaander kostenassessment gerechtvaardigd is.

Zie Kosten en reservations. Omdat de review elke maand op dezelfde data draait, zijn kostenbewegingen vroeg zichtbaar en niet pas aan het eind van een contractjaar. De hub layers deployen geen budgets (Operationele verantwoordelijkheden).

Vervolgacties¶

Het rapport is de input voor een beslissing, niet het einde van het proces. Bespreek de resultaten met de stakeholders en spreek een vervolg af:

Bevinding	Afgehandeld als
Het platformteam kan het oplossen	Een work item in de backlog, opgepakt in een sprint
Het vraagt een beslissing of actie van de organisatie	Besproken in de servicereview of de stuurgroep (Overleggen)
Een financieel risico	Dezelfde review, met een voorgestelde optimalisatie of een diepgaander kostenassessment
Een structurele bevinding	Een wijziging van de baseline zelf, wat elk platform op de code ten goede komt

Zo sluit de cyclus: monitoring voedt het volgende assessment.

Hoe de cyclus er in de praktijk uitziet¶

De methode is overal hetzelfde. Het gesprek verschilt:

Waar de organisatie een eigen cloudteam of cloud centre of excellence heeft, worden eisen met dat team afgestemd en gereviewd in de terugkerende servicemeetings. De baseline kan worden uitgebreid met templates die tegen dezelfde standaarden zijn gevalideerd.
Waar het platform samen met een intern platformteam wordt geleverd, worden de eisen met dat team vastgesteld en opnieuw bekeken naarmate zijn platform zich ontwikkelt.

In beide gevallen is de keten van begin tot eind traceerbaar: de workshopuitkomst die tot de configuratie leidde, de gedeployde policy- toewijzingen in de portal, en een reeks maandrapporten met de trend en het ondernomen vervolg.

Rollen en verantwoordelijkheden¶

Rol	Verantwoordelijkheid
Eigenaar van de baseline (solution lead)	De policydefinities, initiatives en de standaarden die ze volgen
Service manager	Het governance-assessment en de maandelijkse review met de organisatie
Delivery- of kosteneigenaar	De maandelijkse kostenreview en de rapportage van financiële risico's
Technische richting (architect)	De technische richting van de baseline
Platform engineers	Voeren de vervolgacties uit het maandrapport uit

Beheersing¶

Compliance ten opzichte van de toegewezen initiatives wordt maandelijks geverifieerd en vastgelegd op een plek die de stakeholders kunnen lezen. Financieel risico wordt maandelijks geverifieerd waar verbruiksdata beschikbaar is. De baseline zelf wordt gereviewd als de onderliggende standaarden veranderen en als een assessment een nieuwe eis oplevert.