De coronapandemie leverde het definitieve bewijs dat het klassieke kasteel-en-grachtmodel niet langer volstaat voor Nederlandse overheidsorganisaties. Toen in maart 2020 meer dan honderdduizend ambtenaren gelijktijdig via VPN wilden inloggen, raakten licenties, concentrators en supportcapaciteit binnen enkele dagen uitgeput. Het probleem was niet alleen schaling; het bleek onmogelijk om op elk moment vast te stellen wie er werkelijk op het netwerk zat, vanaf welk apparaat en met welke beveiligingsstatus. Daarmee werd duidelijk dat "binnen het netwerk" niet per definitie "vertrouwd" betekent.
Zero Trust Network Access (ZTNA) biedt een alternatief dat expliciet verifiëren, minimale toegangsrechten en continue evaluatie combineert. Gartner voorspelt dat tegen eind 2025 zestig procent van de organisaties hun VPN grotendeels heeft vervangen door ZTNA-diensten. Binnen de Nederlandse Baseline voor Veilige Cloud, de BIO 2024 en NIS2 past ZTNA als logisch fundament: identiteiten, apparaten en context worden voor elke aanvraag opnieuw beoordeeld, terwijl auditlogging en compliance-rapportage vanzelfsprekend meegeleverd worden. Deze gids beschrijft hoe je dat model praktisch invoert, van de architectuurkeuzes en migratiestrategie tot de beleidslaag met Conditional Access en de operationele monitoring die auditors overtuigt.
Deze gids loodst architecten, beveiligingsmanagers en productowners door de volledige overstap van VPN naar ZTNA. Je leest hoe je architectuurprincipes vertaalt naar Microsoft Entra Private Access en Azure AD Application Proxy, hoe je fasering organiseert binnen een ministerie en hoe je complianceverplichtingen (BIO, NIS2, AVG) beklijft met meetbare KPI's, voorbeeldbesluiten en operationele handvatten.
Plan ZTNA nooit als big-bang. Kies drie applicatiecategorieën, richt voor elk een klein productteam in en laat minimaal twee maanden parallel run bestaan. De combinatie van staged onboarding, dagelijkse telemetrie-review en een expliciet fallback-pad zorgde bij een uitvoeringsorganisatie voor een migratie van 12.000 gebruikers zonder onderbreking; gebruikers vertrouwden het nieuwe model doordat zij zelf konden ervaren dat prestaties verbeteren terwijl policies scherper werden.
ZTNA Fundamentals: Het Nieuwe Security Paradigma
Zero Trust Network Access is in Nederland intussen meer dan een modieuze kreet; het is een bestuurlijke randvoorwaarde om hybride werken veilig te houden. Tijdens de pandemie schakelden ministeries, provincies en uitvoeringsorganisaties noodgedwongen over op massaal thuiswerken. VPN-concentratoren werden overbelast, licenties gingen door het dak en latency verlamde kritieke processen zoals Woo-behandeling en belastingaanslagen. Nog belangrijker: SOC-analisten konden niet aantonen welk account vanaf welk device actief was, terwijl auditors vroegen om bewijs dat alleen bevoegde personen bij staatsgeheime dossiers konden. De onmacht om context te verzamelen maakte duidelijk dat het klassieke netwerkvertrouwen uit de vorige eeuw niet langer te verdedigen is.
Het traditionele model kent structurele zwaktes. Eenmaal verbonden met het netwerk krijgt een gebruiker vaak volledige layer-3 toegang tot een breed scala aan servers, ook wanneer slechts één SharePoint-site nodig is. Sessies blijven uren geldig zonder nieuwe controles, waardoor een gestolen token ruim de tijd heeft om laterale bewegingen te maken. Apparaten worden slechts bij aanvang gecontroleerd en kunnen daarna ongepatcht of zonder BitLocker verder werken. Voor de eindgebruiker voelt de VPN als een generieke sleutel; bij trage verbindingen wordt druk gezet op het securityteam om de poort verder open te zetten. Het resultaat is een groeiende uitzonderingslijst en een oncontroleerbaar aanvalsvlak.
ZTNA draait het paradigma om door identiteiten, apparaten en context centraal te stellen. De principes uit NIST SP 800-207 vormen de leidraad: verifieer expliciet, beperk privileges en ga altijd uit van een mogelijke breach. In de praktijk betekent dit dat elke aanvraag opnieuw wordt getoetst op multifactor-authenticatie, devicecompliance, risicosignalen uit Identity Protection en gevoeligheidslabels van de doelapplicatie. Toegang wordt verleend op applicatieniveau met tijdsgelimiteerde sessies, en microsegmentatie voorkomt dat een aanvaller direct verder kan binnen het netwerk. Deze aanpak levert een logisch en consistent beslisproces op dat begrijpelijk is voor zowel architecten als auditors.
Ook de datastromen veranderen. In het VPN-model loopt verkeer van client naar concentrator en krijgt vervolgens volledige netwerkroutes mee. Bij ZTNA meldt de gebruiker zich eerst bij de identityprovider, waarna Conditional Access policies context evalueren en een connector een versleutelde tunnel naar uitsluitend de betreffende applicatie opbouwt. Er is geen zicht op andere systemen, er zijn geen inbound firewallopeningen nodig en elke uitzondering wordt vastgelegd als policy-artefact. Daarmee verschuift het securitywerk van netwerkconfiguratie naar beleidsbeheer, wat beter aansluit bij cloudadoptie en DevOps-teams.
Voor compliance is dit verschil essentieel. BIO 2024 norm 13.1 eist aantoonbare beheersing van netwerktoegang, inclusief logging, en NIS2 artikel 21 benadrukt continue risicobeoordeling. ZTNA voorziet standaard in volledige sign-in-logging, devicebewijzen en automatische beëindiging van sessies bij verhoogd risico. AVG artikel 32 vraagt expliciet om passende technische maatregelen rekening houdend met de stand van de techniek; ZTNA kan als die stand van de techniek worden onderbouwd omdat encryptie, minimale rechten en monitoring aantoonbaar zijn ingebouwd. De Nederlandse Baseline voor Veilige Cloud verwijst bovendien naar identiteits- en toegangsbeheer als eerste verdedigingslinie, wat rechtstreeks aansluit op deze architectuur.
De overstap raakt echter niet alleen technologie. Teams moeten leren denken in applicatieproducten met een eigen eigenaar en een duidelijke risicoklasse. SOC-analisten verschuiven van het beheren van IP-ranges naar het tunen van beleidsregels en risk scores. Gebruikersadoptie vraagt om communicatie dat de loginervaring eenvoudiger wordt: geen handmatige VPN-client meer, maar directe toegang via portalen of native clients, zolang het apparaat aan de spelregels voldoet. Door deze mensgerichte elementen vanaf het begin mee te nemen, verandert ZTNA in een strategische investering die veiligheid vergroot en tegelijk de ervaring van de ambtenaar verbetert.
ZTNA Architectuurpatronen: Azure AD Application Proxy en Private Access
Microsoft biedt in de Nederlandse context een volledig spectrum aan ZTNA-capaciteiten onder de Entra-paraplu. Application Proxy, Private Access en Virtual WAN vullen elkaar aan, waarbij Application Proxy zich richt op webtoepassingen, Private Access op client-serverprotocollen en Virtual WAN op site-to-siteconnectiviteit. Het sterke punt is dat alle varianten dezelfde identityprovider, Conditional Access en logging delen. Hierdoor kan een architect bij het Ministerie van Justitie dezelfde beleidscode toepassen op een intranetportaal als op een beheerdatabase, terwijl de technische uitvoering per scenario verschilt.
Een typisch startpunt is Azure AD Application Proxy. De connector wordt op een on-premises server of cluster geplaatst en legt uitsluitend uitgaande TLS-verbindingen naar Azure. Daarmee verdwijnen inbound firewallregels en wordt de attack surface drastisch kleiner. Gebruikers openen het intranet via een vertrouwde URL of via het MyApps-portaal, authenticeren met MFA en zien dezelfde interface als voorheen, maar zonder VPN-latency. We hebben deze aanpak bij Rijkswaterstaat gebruikt om het onderhoudsportal voor opdrachtnemers beschikbaar te maken zonder dat externe laptops op het interne netwerk kwamen. De beheerlast blijft beperkt tot het up-to-date houden van de connector en het documenteren van de Conditional Access policy bij audits.
Voor applicaties die geen webinterface hebben, zoals RDP-consoles, SSH-servers of thick clients met een eigen protocol, is Microsoft Entra Private Access het aangewezen patroon. De clientsoftware draait op het eindpunt en maakt dynamisch verbinding met applicaties die in de policy zijn toegestaan. Omdat het verkeer applicatiespecifiek wordt gerouteerd, kan een databasebeheerder wel bij een productiedatabase, maar niet bij andere servers op hetzelfde subnet. In combinatie met Privileged Identity Management kan toegang ook nog eens tijdgebonden worden gemaakt. Dat bood bij de Belastingdienst de mogelijkheid om onderhoudsvensters tot enkele uren te beperken en daarbuiten automatisch alle sessies te beëindigen.
In de praktijk tref je vaak hybride applicaties aan met een webfront-end, een database en aanvullende services zoals SMB of berichtenwachtrijen. Daar past een gelaagd patroon bij: het webdeel loopt via Application Proxy, terwijl de achterliggende datastromen via Private Access worden ontsloten. We combineren dat met tiered Conditional Access policies zodat gebruikers pas naar de backend mogen zodra zij vanuit een compliant device en een toegewezen rol werken. Hierdoor ontstaat microsegmentatie binnen dezelfde oplossing zonder complexe firewallregels.
Naast deze twee hoofdcomponenten spelen aanvullende bouwstenen een rol. Virtual WAN Secure Hub en Azure Firewall blijven nodig voor locaties waar netwerkverbindingen tussen datacenters en Azure gewenst zijn, maar worden nu gevoed door dezelfde identiteitsbesluiten. Applicaties krijgen metadata mee, zoals een data-classificatie of een BIO-controle die tijdens de policy-evaluatie wordt gelezen. Daardoor kunnen we automatisch strengere eisen opleggen aan bijvoorbeeld Woo-documenten of staatsgeheime dossiers. Logging uit alle componenten stroomt naar Microsoft Sentinel, waar queries vooraf zijn opgesteld om auditors realtime te laten zien welke controlemaatregelen actief zijn.
Het operationele succes staat of valt met governance. Elk patroon krijgt een productsheet waarin staat welke connectoren actief zijn, welk team eigenaar is, hoe failover geregeld is en welke onderhoudsvensters gelden. Capaciteitsplanning gebeurt niet langer op basis van VPN-licenties, maar op basis van applicatieverkeer en connectorbelasting. Doordat alle onderdelen API's aanbieden, kunnen we configuratie vastleggen als code en automatische tests draaien voor policyregressies. Voor Nederlandse overheden is juist die reproduceerbaarheid belangrijk: wanneer de Algemene Rekenkamer of een toezichthouder vraagt hoe remote access is geregeld, ligt er een volledig pakket met architectuurdiagrammen, beleidsregels en meetgegevens klaar.
Migratiestrategie: Van VPN naar ZTNA in 5 Fasen
Een duurzame migratie van VPN naar ZTNA begint met een programma-aanpak waarin architectuur, security, operations en change management gelijkwaardig meedoen. In Nederland hanteren we doorgaans vijf fasen die samen ongeveer negen maanden bestrijken. Door fases expliciet te benoemen ontstaat bestuurlijke rust: portefeuilles weten wanneer hun applicaties aan de beurt zijn, de ondernemingsraad kan meedenken over thuiswerkimplicaties en de CIO krijgt heldere tussenresultaten.
Fase één draait om inzicht. We koppelen logging uit VPN-concentrators aan CMDB-gegevens en bouwen een heatmap van applicaties, gebruikersgroepen en tijdvakken. Interviews met servicemanagers leveren context, bijvoorbeeld dat een bepaald team het VPN alleen gebruikt voor een enkel archiefsysteem. Daarnaast benoemen we kritieke onzekerheden: afhankelijkheden van legacyprotocollen, licenties die aflopen of contractuele verplichtingen naar leveranciers. Op basis van die inventarisatie labelen we applicaties in categorieën zoals web, specialistisch beheer of legacy maatwerk en koppelen we alvast potentiële ZTNA-patronen. We formuleren meetbare succescriteria, bijvoorbeeld een reductie van dertig procent in VPN-tickets, een authenticationsucces van boven de 99,5 procent en een devicecompliance van minimaal 95 procent per kwartaal.
In fase twee voeren we een pilot uit met een kleine maar representatieve groep gebruikers. We installeren de benodigde connectoren, rollen de Private Access-client uit via Intune en zetten Conditional Access policies eerst in rapportagemodus neer zodat we kunnen zien welke toegang anders verlopen zou zijn. Gebruikers krijgen duidelijke instructies, bijvoorbeeld een korte video en een proefmoment onder begeleiding van het SOC. Gedurende vier weken meten we zorgvuldig latency, foutcodes en gebruikersfeedback. Elk incident wordt direct vertaald naar een verbeterpunt: hardcoded URL's worden herschreven, Kerberos Constrained Delegation wordt nagekeken en we voegen tijdelijke fallbackprocedures toe zodat de bedrijfsvoering nooit stilvalt.
Met de lessen uit de pilot starten we een gefaseerde uitrol. We kiezen vier waves die aansluiten op de bedrijfsstructuur: kenniswerkers, beleidsafdelingen met gevoeligere data, technische teams en tenslotte de resterende gebruikers en leveranciers. Elke wave duurt ongeveer drie weken en eindigt met een korte evaluatie om openstaande blokkades op te lossen. VPN blijft gedurende deze periode beschikbaar als vangnet, maar we monitoren actief welke gebruikers nog terugvallen en waarom. Dat levert concrete acties op, zoals aanvullende training, het versneld aansluiten van een nog ontbrekende applicatie of het versterken van de servicedesk tijdens kritieke deadlines.
In fase vier verschuift de aandacht naar het gecontroleerd uitfaseren van VPN. We plannen een parallelle periode van minimaal zes weken waarin beide oplossingen naast elkaar bestaan en waarin we specifieke aandacht geven aan de laatste tien procent gebruikers. Analyses van hun sessies onthullen vaak dat het om verouderde applicaties of bijzondere werkpatronen gaat. Voor legacy-systemen documenteren we expliciet waarom er tijdelijk een uitzondering nodig is en welke mitigaties gelden, zoals strengere logging of het beperken van toegang tot een apart segment. Communicatie is cruciaal: nieuwsbrieven, intranetberichten en Q&A-sessies maken duidelijk wanneer de VPN definitief uitgaat en wat medewerkers moeten doen als zij toch problemen ervaren.
De laatste fase draait om optimalisatie en continue verbetering. We koppelen ZTNA-statistieken aan KPI-rapportages binnen de Nederlandse Baseline voor Veilige Cloud en bespreken maandelijks de risicotrends in het securityoverleg. Policy-tuning gebeurt volgens changeprocedures met automatische tests zodat regressies worden voorkomen. Nieuwe applicaties moeten eerst een kort ZTNA-assessment doorlopen voordat zij productie bereiken. Elk kwartaal evalueren we de meetwaarden met de CIO: hoeveel applicaties draaien volledig ZTNA, hoe hoog is de user satisfaction score, hoeveel beveiligingsincidenten zijn voorkomen door realtime blokkades? Door deze cyclus vast te leggen in procedures en dashboards blijft ZTNA een levend onderdeel van het beveiligingsprogramma in plaats van een eenmalig project.
Conditional Access Integration: Policy-Based Access Control
Conditional Access fungeert als het zenuwstelsel van elke ZTNA-implementatie. Waar vroeger firewallregels bepaalden wie binnenkwam, doet nu een beleidslaag dat op basis van identiteiten, devices en context. Het grote voordeel voor Nederlandse overheidsorganisaties is dat dezelfde policy-engine geldt voor zowel SaaS, Application Proxy als Private Access. Daardoor kun je consistent uitleggen aan auditors welke signalen je verzamelt, hoe je beslissingen neemt en hoe uitzonderingen worden gereviewd.
In een modern ontwerp komt elke toegangspoging eerst langs Azure AD voor authenticatie en daarna langs Conditional Access. De policy combineert signalen uit Identity Protection, Intune, Defender for Cloud Apps, Entra Verified ID en optioneel externe risk feeds. Zo kun je bijvoorbeeld een risicoscore uit het Nationaal DetectieNetwerk toevoegen om aanmeldingen vanuit verdachte IP-ranges automatisch te blokkeren. Tijdens de evaluatie wordt ook de gevoeligheid van de applicatie meegenomen, doordat we labels of aangepaste attributen op Enterprise Applications gebruiken.
Een veelgebruikte variant is de devicecompliancepolicy. Hierbij bepalen we dat alleen door Intune beheerde en als compliant gemarkeerde apparaten toegang krijgen tot interne applicaties. In de praktijk resulteert dat in automatische blokkades voor privéapparaten, zonder dat servicedesks handmatig hoeven te beoordelen. We koppelen er een gebruikersvriendelijke foutmelding aan waarin staat dat het apparaat eerst geregistreerd moet worden. Tegelijkertijd meten we de compliancegraad per organisatieonderdeel en koppelen we dat terug in het CIO-dashboard zodat achterblijvende teams gericht ondersteuning ontvangen.
Voor dataresidentie hanteren we policies die controleren waarvandaan een gebruiker inlogt. Toegang tot Woo-documenten, staatsgeheime dossiers of kadasterdata wordt strikt beperkt tot Nederlandse IP-adressen en eventueel aangewezen ambassades. Reizende medewerkers kunnen via Privileged Access Management een tijdelijke uitzondering aanvragen die automatisch na 24 uur verloopt. Door deze stappen in processen en tooling te borgen, ontstaat een traceerbaar auditspoor dat voldoet aan de BIO en de Wet open overheid.
Privileged beheerders krijgen een extra laag. Zij moeten eerst een rol activeren via Privileged Identity Management, inclusief goedkeuring en justificatie. Conditional Access controleert vervolgens of de rol actief is, dwingt FIDO2 of Windows Hello for Business af en beperkt de sessieduur tot bijvoorbeeld zestig minuten. Zodra de rol afloopt, worden sessies direct ingetrokken. Deze werkwijze elimineert standing privileges en maakt het eenvoudiger om te verklaren welke maatregelen zijn getroffen tegen misbruik van beheerdersrechten.
Om honderden applicaties hanteerbaar te houden, werken we met gevoeligheidsniveaus. Applicaties krijgen labels zoals Publiek, Intern, Vertrouwelijk of Staatsgeheim. Per label bestaat een standaardset van policyregels: publieke apps staan meerdere MFA-methoden toe en accepteren vertrouwde locaties, terwijl staatsgeheime apps uitsluitend toegankelijk zijn vanaf hybride joined devices binnen Nederland met realtime risico-evaluatie. Wanneer een nieuwe applicatie wordt gepubliceerd, kiest de eigenaar het label en neemt daarmee automatisch de bijbehorende policies over. Dit voorkomt inconsistentie en borgt dat wijzigingen altijd traceerbaar zijn.
Elke policydoorvoering volgt de normale changeprocedure met test, review en documentatie. We slaan policies op als code in Git, zodat we versiebeheer hebben en een rollback kunnen uitvoeren wanneer nodig. Daarnaast plannen we driemaandelijkse policyreviews waarbij security, privacy en de business gezamenlijk bekijken of voorwaarden moeten worden aangescherpt of versoepeld. Zo blijft Conditional Access een levend document in plaats van een vergeten configuratiescherm.
Monitoring, Troubleshooting en Compliance Rapportages
ZTNA levert pas waarde als telemetrie continu wordt benut; zonder zicht op gedrag zou het slechts een complexere VPN zijn. Daarom richten we vanaf dag één een monitoringprogramma in dat zowel technische prestaties, gebruikerservaring als compliance-eisen afdekt. De kern bestaat uit drie datastromen: Azure AD sign-in logs, Application Proxy en Private Access health-data en Microsoft Sentinel use cases. Door deze bronnen te combineren ontstaat een tijdlijn waarin elke toegangspoging, beleidsbeslissing en connectoractie zichtbaar is.
Azure AD sign-in logs fungeren als primaire bron. We streamen ze near-realtime naar Log Analytics en bouwen dashboards met kengetallen zoals het percentage geslaagde authenticaties, de verdeling van Conditional Access-uitkomsten en de geografische verspreiding van aanmeldingen. Hierdoor valt het onmiddellijk op wanneer een policy te streng wordt en gebruikers massaal in de blokkade terechtkomen. Omdat Intune-devicecompliance wordt meegeleverd, kunnen we bovendien zien welke modellen of Windows-builds vaker falen en gericht patchcampagnes uitrollen. Ook latencygegevens zijn beschikbaar, waardoor we kunnen aantonen dat ZTNA de gebruikerservaring verbetert in plaats van belemmert.
De gezondheid van Application Proxy-connectoren en Private Access-clients wordt parallel bewaakt. We registreren versies, CPU-belasting, wachtrijen en certificaatverlopen en leggen deze vast in een operations-runbook. Wanneer een connector uitvalt, schakelt de service automatisch over, maar we willen de oorzaak alsnog analyseren. Bij de Rijksoverheid draaien connectoren doorgaans per regio in tweetallen zodat onderhoud zonder downtime kan plaatsvinden. Aan de clientzijde controleren we of endpoints de nieuwste Global Secure Access-versie draaien en analyseren we bandbreedte en pakketverlies. Bij afwijkingen sturen we automatisch een supportticket naar het betreffende devicebeheerteam.
Securitymonitoring bouwt voort op dezelfde data. Microsoft Sentinel en Defender for Cloud Apps leveren detecties voor onmogelijk reizen, afwijkende downloadpatronen, verdachte IP-adressen en ongebruikelijke applicatiecombinaties. Wanneer een risico-increase wordt gezien, triggert een automation rule direct een strengere Conditional Access policy, bijvoorbeeld het afdwingen van een FIDO2-methode of het beëindigen van de sessie. Deze automatische terugkoppeling sluit aan op het uitgangspunt assume breach en maakt het mogelijk om binnen minuten op te schalen zonder dat een analist handmatig hoeft in te grijpen. De reacties worden vastgelegd in het incidentmanagementsysteem zodat auditors precies zien welke maatregelen automatisch zijn geactiveerd.
Compliance-rapportages komen uit dezelfde telemetrie, maar worden vertaald naar de taal van BIO en NIS2. Voor norm 13.1 leveren we een overzicht van alle ingestelde Conditional Access policies, inclusief versienummers, change-historie en bewijs dat honderd procent van de sessies wordt gelogd. Voor norm 12.4 tonen we dat loggegevens minimaal negentig dagen online beschikbaar zijn en daarna twee jaar in write-once storage worden bewaard. NIS2 artikel 21 vraagt om aantoonbare risicobeheersingsmaatregelen; daarom leveren we een jaarlijks rapport waarin per applicatie wordt beschreven welke contextuele controles gelden, welk rest-risico resteert en hoe incidentrespons plaatsvindt. Omdat alles uit dezelfde data lake komt, hoeven teams geen aparte spreadsheets meer bij te houden.
Troubleshooting wordt ingericht als een continu leerproces. Bij meldingen over trage applicaties analyseren we de end-to-end route: client, internetprovider, Azure-regio, connector en backend. Vaak blijkt een lokaal WiFi-probleem of een gedateerde browser de oorzaak, maar doordat we objectieve cijfers hebben, kunnen we gebruikers gericht helpen. Voor afwijzingen door Conditional Access bestaat een standaardprocedure: de servicedesk bekijkt het sign-in log, communiceert helder welke voorwaarde ontbrak en biedt concrete stappen om dit te herstellen. Deze aanpak verkort de oplostijd en voorkomt dat policies onnodig worden versoepeld. Door wekelijks de top-incidentcategorieën door te nemen met SOC en workspacebeheer blijven we de configuratie aanscherpen zonder de gebruikerservaring te schaden.
ZTNA ontwikkelt zich tot een strategische investering die zowel bestuurlijke doelen als operationele KPI's ondersteunt. Door identiteiten, apparaten en context centraal te stellen, ontstaat een remote-accessmodel dat meegroeit met cloudadoptie en toch herleidbaar blijft naar de eisen uit BIO, NIS2 en de Nederlandse Baseline voor Veilige Cloud. Organisaties die de overstap maken, zien dat het aantal supporttickets daalt, de zichtbaarheid toeneemt en auditvragen sneller worden beantwoord omdat elk besluit in policies en logs is vastgelegd.
Het belangrijkste inzicht is dat ZTNA geen eenmalig project is maar een continue verbeterlus. Wie start met een beperkte pilot, leert snel welke patronen werken, schaalt vervolgens per applicatiecategorie op en blijft daarna meten, optimaliseren en communiceren. Zo wordt elke migratieslag een kans om het aanvalsvlak verder te verkleinen en het vertrouwen van burgers, bestuurders en toezichthouders te vergroten.