💼 Management Samenvatting
Zero Trust-architectuur vormt de ruggengraat van veilige cloudadoptie binnen Nederlandse overheidsorganisaties: ieder verzoek tot toegang wordt behandeld als potentieel onbetrouwbaar totdat identiteit, apparaat, locatie, dataclassificatie en risicoprofiel aantoonbaar zijn gevalideerd.
✓ Microsoft Entra ID
✓ Microsoft Defender XDR
✓ Azure
✓ On-premises Active Directory
Gemeenten, ministeries, uitvoeringsorganisaties en vitale aanbieders werken steeds vaker vanuit hybride omgevingen waarin medewerkers, leveranciers en ketenpartners vanaf uiteenlopende locaties en apparaten werken. Traditionele netwerkperimeters zijn verdwenen door SaaS-diensten, thuiswerken en mobiele apps. Tegelijkertijd vragen BIO, AVG, NIS2 en sectorspecifieke kaders om strikte controle op toegang, logging en verantwoording. Zonder een doordachte Zero Trust-architectuur ontstaan versnipperde maatregelen: hier en daar een Conditional Access-regel, losse firewall-configuraties of ad-hoc segmentatie. Aanvallers profiteren juist van die inconsistentie om zich lateraal door het landschap te verplaatsen, identiteitstokens te misbruiken en gevoelige data ongezien te exfiltreren. Bestuurders staan dan met lege handen richting toezichthouders omdat er geen integraal architectuurverhaal en geen herleidbaar bewijs bestaat dat het stelsel als geheel is doordacht.
Connection:
Gebruik Connect-MgGraph en Connect-AzAccount binnen bestaande beheerprocessen; voer dit script bij voorkeur eerst lokaal in DebugMode uit met vooraf geëxporteerde datasets.Required Modules: Microsoft.Graph, Microsoft.Graph.Identity.SignIns, Microsoft.Graph.DeviceManagement, Az.Accounts, Az.ResourceGraph, Defender
Implementatie
Dit artikel vertaalt Zero Trust-principes naar een concrete architectuur voor de Nederlandse Baseline voor Veilige Cloud. We beschrijven hoe u een referentieontwerp opstelt voor identiteiten, apparaten, netwerken, applicaties en data, hoe u segmentatie en toegangsbeslissingen als code beheert, hoe u on-premises Active Directory en OT-omgevingen in het model opneemt en hoe u bewijslijnen, scripts en dashboards opbouwt. Het bijbehorende PowerShell-script maakt het mogelijk om lokaal – in DebugMode en zonder cloudverbinding – een maturity-inschatting te genereren op basis van voorbeelddata en eigen exports, zodat architecten, CISO’s en auditors direct kunnen zien waar de architectuur nog gaten vertoont voordat er productieconfiguraties worden aangepast.
Architectuurprincipes en lagenmodel voor Zero Trust
Een Zero Trust-architectuur begint met expliciete principes die door bestuur en architectuurboard worden bekrachtigd. Het meest fundamentele principe is dat toegang nooit impliciet wordt verleend op basis van netwerkpositie of functie, maar altijd het resultaat is van een aantoonbare beleidsbeslissing. In de praktijk betekent dit dat identiteiten, apparaten, applicaties, data en infrastructuur worden gemodelleerd in een lagenarchitectuur, waarbij elke laag eigen controles en verantwoordelijken kent. Microsoft Entra ID functioneert als centrale identiteitslaag, waarin alle accounts – inclusief leveranciers en tijdelijke medewerkers – eenduidig zijn geregistreerd. Bovenop deze identiteitslaag ligt een beleidslaag waarin Conditional Access, Identity Protection en Privileged Identity Management (PIM) bepalen wie, wanneer en vanaf welke omstandigheden toegang krijgt. Door deze lagen formeel vast te leggen in een referentiearchitectuur wordt helder welke componenten onder Zero Trust vallen, welke niet en welke transitiepaden nodig zijn.
Het lagenmodel onderscheidt minimaal identiteiten, devices, netwerken, applicaties en data. Voor identiteiten beschrijft de architectuur dat alle beheerders via PIM werken, dat serviceaccounts waar mogelijk worden vervangen door workload identities en dat gasten uit ketensamenwerkingen altijd via B2B-federatie worden opgenomen in plaats van losse accounts. De devicelaag definieert dat alleen compliant apparaten – beheerd via Intune of gelijkwaardige tools – toegang krijgen, dat BYOD strikt wordt beperkt tot gesandboxte scenario’s en dat privileged access workstations fysiek en logisch zijn gescheiden van kantoorwerkplekken. De netwerklagen beschrijven hoe Azure Virtual Networks, private endpoints, VPN’s en on-premises segmentatie samen een microperimeter vormen. Applicaties worden gecatalogiseerd met hun authenticatiemechanismen, gebruikte protocollen en afhankelijkheden, terwijl de datalaag vastlegt hoe classificatie, encryptie en retentie geïntegreerd zijn. Dit model is geen theoretische tekening, maar een werkdocument dat via architectuurboards, changeprocessen en documentatie voortdurend wordt bijgewerkt.
Belangrijk in de architectuur is expliciete scheiding van verantwoordelijkheden. De CISO en het security-architectuurteam definiëren principes en minimale eisen, maar proceseigenaren zijn verantwoordelijk voor de toepassing binnen hun domein. Identity-teams beheren Entra-configuraties, Conditional Access en PIM, terwijl device- en netwerkbeheerders verantwoordelijk zijn voor compliant endpoints en segmentatie. Applicatie-eigenaren dragen zorg voor integratie met moderne protocollen en voor het verwijderen van hardgecodeerde geheimen, terwijl informatie-eigenaren bepalen welke dataclassificaties en bewaartermijnen gelden. Door deze verantwoordelijkheden in RACI-tabellen en rolbeschrijvingen op te nemen, wordt het onmogelijk dat kritieke beslissingen over identiteit of segmentatie impliciet plaatsvinden in individuele projecten. Architecten gebruiken het lagenmodel bovendien als kader voor nieuwe initiatieven: elk projectplan moet aantonen hoe het de Zero Trust-principes respecteert en welke meetwaarden worden toegevoegd aan het centrale dashboard.
Het artikel benadrukt dat Zero Trust-architectuur ook rekening houdt met bestaande technische schuld. Veel overheidsorganisaties hebben on-premises Active Directory-forests, verouderde applicaties en OT-netwerken die niet onmiddellijk kunnen worden gemoderniseerd. De referentiearchitectuur bevat daarom expliciet een \"transitielaag\" waarin tijdelijke uitzonderingen worden beheerd. Legacy-applicaties worden ondergebracht in geïsoleerde netwerkgedeelten met streng gecontroleerde jumpservers en inspectie op protocolniveau. Authenticatie wordt waar mogelijk via federatie of app-proxy naar Entra gebracht, zodat er één punt van waarheidsvaststelling blijft. Voor elke uitzondering wordt vastgelegd waarom deze bestaat, welke mitigaties gelden, wat de einddatum is en welke investeringen nodig zijn om de uitzondering op te heffen. Deze informatie voedt het Zero Trust-board en bestuurders, zodat zij zicht houden op de resterende technische schuld en op de risico’s die daarmee gepaard gaan.
Segmentatie, toegangspaden en integratie met on-premises omgevingen
Segmentatie vormt in een Zero Trust-architectuur de praktische uitwerking van het principe dat geen enkel onderdeel van het landschap volledig wordt vertrouwd. In plaats van één groot intern netwerk definieert de architectuur meerdere administratieve vlakken: bijvoorbeeld tenantbeheer, securitybeheer, infrastructuurbeheer, applicatiebeheer en eindgebruikers. Elk vlak heeft eigen identiteiten, eigen toegangspaden en eigen monitoring. Beheerders die in het ene vlak werken, kunnen niet automatisch in een ander vlak opereren zonder aanvullende rechtvaardiging. Voor cloudcomponenten betekent dit dat beheerders via PIM just-in-time rollen activeren, dat beheer uitsluitend via privileged access workstations loopt en dat netwerktoegang tot managementvlakken bijvoorbeeld via Azure Bastion of Just-In-Time access wordt afgedwongen. Dit voorkomt dat een gecompromitteerde beheerder of een verkeerd geconfigureerde applicatie directe toegang heeft tot alle kroonjuwelen.
On-premises Active Directory en klassieke datacenters blijven in veel Nederlandse overheidscontexten relevant. De Zero Trust-architectuur beschrijft daarom hoe tieringmodellen (Tier 0, 1 en 2) worden toegepast en hoe deze aansluiten op cloudidentiteiten. Tier 0 omvat domeincontrollers, identityproviders en securitysystemen; Tier 1 omvat servers en bedrijfskritische applicaties; Tier 2 omvat werkplekken en gebruikersdevices. Voor iedere tier gelden aparte beheeraccounts, beheerwerkplekken en veranderingstrajecten. Netwerktechnisch worden deze tiers gescheiden met firewallregels, VLAN’s en eventueel fysieke segmentatie. Koppelingen naar Azure, Microsoft 365 of andere cloudomgevingen verlopen via gecontroleerde endpoints, waarbij alle beheerprotocollen worden gelogd en gemonitord door SIEM-oplossingen zoals Microsoft Sentinel. Hierdoor ontstaat één samenhangend beeld van segmentatie, waarin on-premises en cloud niet langer losstaande werelden zijn maar verschillende zones binnen één Zero Trust-referentieontwerp.
Voor SaaS-applicaties, mobiele apps en externe ketenpartners worden toegangspaden expliciet vastgelegd. Waar voorheen vaak gekozen werd voor generieke VPN-toegang, eist de architectuur nu dat toegang verloopt via app-proxy’s, API-gateways en identity-aware proxies waarin beslissingen worden genomen op basis van identiteit, apparaatstatus, dataclassificatie en risiconiveau. De architectuur stelt dat directe IP-toegang tot kritieke workloads zonder tussenliggende beveiligingslaag niet is toegestaan. Ook moderne technieken zoals Zero Trust Network Access (ZTNA)-oplossingen en per-app VPN’s worden in het model opgenomen, inclusief hun loggingvereisten. Hierdoor kan de organisatie aantonen dat iedere route naar gevoelige gegevens traceerbaar is en dat uitzonderingen op segmentatieprincipes tijdelijk, gemotiveerd en gemonitord zijn.
Gebruik PowerShell-script zero-trust-architecture.ps1 (functie Invoke-ZeroTrustArchitectureAssessment) – Het script leest in DebugMode lokale voorbeelddata of vooraf geëxporteerde configuratiebestanden in, beoordeelt indicatoren rond segmentatie, beheerpaden en uitzonderingen en genereert een JSON-rapport dat laat zien waar architectuurkeuzes afwijken van de Nederlandse Baseline voor Veilige Cloud..
Een volwassen segmentatiestrategie vereist ook dat beheer- en supportprocessen zijn afgestemd op Zero Trust. De architectuur schrijft bijvoorbeeld voor dat remote support van leveranciers alleen kan plaatsvinden via gecontroleerde kanalen met tijdelijke accounts, dat sessies worden opgenomen of ten minste volledig gelogd, en dat alle uitzonderingen vooraf door een change- of CAB-proces zijn goedgekeurd. Voor OT-omgevingen worden aanvullende eisen gesteld, zoals jumpservers met fysieke toegangscertificaten, offline herstelprocedures en scheiding tussen beheernetwerken en productieprocessen. Door deze processen in het architectuurdocument vast te leggen, gekoppeld aan het PowerShell-rapport en de centrale CMDB, ontstaat een compleet beeld dat zowel voor technische teams als voor auditors inzichtelijk en toetsbaar is.
Bewijsvoering, monitoring en continue verbetering van de architectuur
Zero Trust-architectuur heeft pas waarde wanneer besluitvormers, auditors en ketenpartners kunnen zien dat keuzes consequent worden doorgevoerd en onderhouden. De architectuur bevat daarom expliciet een paragraaf over bewijsvoering. Voor elke architectuurclaim – bijvoorbeeld dat alle beheerders via PIM werken of dat alle kritieke workloads achter private endpoints staan – wordt gedefinieerd welk bewijs nodig is, uit welke bron dit komt en hoe vaak dit wordt bijgewerkt. Dit kan gaan om exports uit Microsoft Graph, Defender, Intune of Azure Resource Graph, maar ook om handmatige notulen van architectuurboards, CAB-besluiten en leveranciersverklaringen. Deze artefacten worden centraal opgeslagen in een beveiligde SharePoint-site of recordsmanagementsysteem met duidelijke retentieregels. Het PowerShell-script fungeert als schakel tussen technische exports en deze bewijslijn door gegevens te normaliseren, scores te berekenen en een samenvattend JSON-rapport te genereren.
Monitoring van de architectuur richt zich niet alleen op security-incidenten, maar ook op de gezondheid van het ontwerp zelf. Dashboards tonen bijvoorbeeld hoeveel segmentatie-uitzonderingen actief zijn, welke applicaties nog niet voldoen aan moderne authenticatiestandaarden of welke beheerpaden nog afhankelijk zijn van onveilige protocollen. De architectuur beschrijft welke indicatoren minimaal moeten worden bijgehouden, hoe deze worden berekend en welke drempelwaarden gelden. Wanneer een indicator buiten bandbreedte raakt – bijvoorbeeld een toename in legacy-protocollen of een daling in PIM-dekking – moet dit automatisch leiden tot een signaal richting het Zero Trust-board en eventueel tot het openen van een ticket in het ITSM-systeem. Door architectuur- en operationele monitoring te koppelen, ontstaat een feedbacklus waarin ontwerp en uitvoering elkaar continu bijsturen.
Continue verbetering wordt verankerd via een Zero Trust-roadmap die nadrukkelijk voortbouwt op de architectuur. Iedere bevinding uit audits, pentesten, dreigingsanalyses of incidenten wordt vertaald naar wijzigingsvoorstellen in het referentieontwerp en naar concrete epics in bijvoorbeeld Azure DevOps. De architectuur documenteert hoe vaak het lagenmodel wordt herzien, hoe architectuurkeuzes opnieuw worden gewogen bij grote programma’s (zoals cloudmigraties, verkiezingssystemen of nieuwe wetgeving) en hoe lessons learned met andere overheidsorganisaties worden gedeeld. Het script ondersteunt dit door per run een maturity-score en een set verbeterpunten te genereren die direct aan de roadmap kunnen worden gekoppeld. Zo ontstaat een aantoonbaar cyclisch proces van plannen, uitvoeren, controleren en bijsturen – precies wat toezichthouders en rekenkamers verwachten van een volwassen beveiligingsarchitectuur.
Tot slot erkent de architectuur de rol van mensen en organisatiecultuur. Technisch perfecte segmentatie heeft weinig waarde als medewerkers routineus vrijstellingen aanvragen, beheerprocessen overslaan of werk omleiden via schaduw-IT. De Zero Trust-architectuur koppelt daarom ontwerpkeuzes aan opleidingsprogramma’s, communicatieplannen en veranderkundige interventies. Denk aan verplichte architectuurbriefings voor projectleiders, onboardingmodules voor nieuwe beheerders, en simulaties waarin teams ervaren hoe laterale beweging in een slecht gesegmenteerde omgeving verloopt. Resultaten van deze programma’s – zoals deelnamepercentages, examenuitslagen en feedback – worden net als technische metrics opgenomen in de architectuurdocumentatie. Hierdoor wordt zichtbaar dat Zero Trust geen eenmalig project is, maar een blijvend organisatiebreed programma dat techniek, processen en menselijk gedrag in balans brengt.
Compliance & Frameworks
- BIO: 9.1, 9.2, 12.1, 12.2 - De beschreven Zero Trust-architectuur ondersteunt de BIO door aantoonbaar toegangsbeheer, netwerksegmentatie, logging en incidentrespons te structureren en te koppelen aan duidelijke rollen, processen en bewijsvoering.
- ISO 27001:2022: A.5.17, A.5.23, A.8.16, A.8.18 - De architectuur koppelt Zero Trust aan identiteits- en toegangsbeheer, netwerkbeveiliging en continue verbetering zoals vereist in ISO 27001:2022.
- NIS2: Artikel - NIS2 vraagt om risicogestuurde beveiligingsmaatregelen, supply-chain-borging en aantoonbare governance. De Zero Trust-architectuur maakt zichtbaar hoe deze eisen zijn vertaald naar concrete segmentatie- en toegangsbesluiten.
Automation
Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).
Risico zonder implementatie
Management Samenvatting
Stel een lagenmodel op voor identiteiten, devices, netwerken, applicaties en data, segmenteer beheerpaden en kritieke workloads, leg uitzonderingen met einddata vast en gebruik het meegeleverde script om maturity-scores en bewijslijnen te genereren die direct bruikbaar zijn in audits en bestuurlijke rapportages.
- Implementatietijd: 320 uur
- FTE required: 0.7 FTE