Zero Trust Network Access (ZTNA) is een netwerkbeveiligingsmodel waarbij toegang tot applicaties en diensten nooit wordt verleend op basis van netwerklocatie alleen, maar altijd wordt gebaseerd op continue verificatie van identiteit, apparaatstatus en context. Bij organisaties in de overheids-, juridische en gereguleerde sector die migreren van Microsoft 365 naar een soevereine werkplek, is ZTNA niet alleen een beveiligingsverbetering maar ook een juridische en compliance-noodzaak.
Waarom VPN geen basis is voor een soevereine werkplek
Traditionele VPN-infrastructuur verleent na één succesvolle authenticatie brede netwerktoegang, wat het aanvalsoppervlak bij een gecompromitteerd account of apparaat dramatisch vergroot. Dit model staat haaks op de eisen die NIS-2 en BIO2 stellen aan netwerksegmentatie en minimale rechten.
VPN-concentrators vormen een enkelvoudig faalmoment: wie de tunnel binnenkomt, kan lateraal bewegen door het netwerk zonder verdere verificatie. Dat maakt VPN structureel incompatibel met het zero trust-principe dat NIST vastlegt in SP 800-207 (Zero Trust Architecture): “Zero Trust means never trust, always verify. No user or device is inherently trusted, regardless of network location.”
Bovendien zijn bij vrijwel alle grote VPN-leveranciers (Cisco AnyConnect, Pulse Secure, Fortinet) in de afgelopen jaren kritieke kwetsbaarheden ontdekt die actief werden misbruikt. Het NCSC Nederland meldde in het Cybersecuritybeeld Nederland 2023 dat VPN-misbruik de meest gemelde initiële toegangsvector was bij ransomware-incidenten. Verizon stelde in het Data Breach Investigations Report 2023 vast dat 86% van de datalekken betrekking had op gestolen of zwakke inloggegevens, precies het risicoprofiel dat een VPN-model in stand houdt.
Open-source ZTNA-oplossingen zonder Big Tech-afhankelijkheid
Voor organisaties die volledig willen ontkoppelen van Microsoft, Google of andere Amerikaanse cloudproviders, zijn open-source ZTNA-componenten de enige route naar echte digitale soevereiniteit.
OpenZiti: software-defined zero trust networking
OpenZiti is een volledig open-source framework voor zero trust networking dat applicaties direct in de beveiligingslaag integreert, zonder dat er een aparte netwerktunnel of VPN-concentrator nodig is. OpenZiti werkt met een controller die beleidsregels beheert, edge-routers die verkeer afhandelen, en SDK-integraties voor applicaties zoals Nextcloud. Er is geen afhankelijkheid van externe cloudplatforms: de volledige OpenZiti-stack kan on-premise of in een Zwitserse private cloud worden uitgerold. OpenZiti ondersteunt integratie met externe identity providers via OIDC, wat directe koppeling met Keycloak mogelijk maakt.
WireGuard-gebaseerde alternatieven
WireGuard is een modern, cryptografisch sterk tunnelprotocol dat als basis dient voor verschillende ZTNA-achtige oplossingen. WireGuard zelf is een protocol, geen compleet ZTNA-systeem: het mist identity-aware toegangsbeleid en device posture-controles. Oplossingen zoals Netbird en Headscale (een zelfgehoste implementatie van de Tailscale-controlserver) bouwen op WireGuard en voegen peer-to-peer-orkestratie en beleidsbeheer toe. Voor volledige zero trust-functionaliteit moeten deze worden gecombineerd met een IAM-oplossing zoals Keycloak. WireGuard-gebaseerde stacks zijn bijzonder geschikt voor kleinere organisaties of als aanvulling op een bestaande ZTNA-architectuur voor specifieke segmenten.
| Oplossing | Type | Identity-aware | Device posture | On-premise uitrolbaar |
|---|---|---|---|---|
| OpenZiti | Volledig ZTNA-framework | Ja (OIDC/SAML) | Ja (via SDK) | Ja |
| Netbird (WireGuard) | Mesh VPN met ZTNA-elementen | Ja (OIDC) | Beperkt | Ja (zelfgehost) |
| Headscale (WireGuard) | Mesh VPN controller | Via externe IdP | Nee | Ja |
| Cisco AnyConnect | Traditionele VPN | Beperkt | Ja (Cisco ISE) | Ja, maar propriëtair |
ZTNA integreren met Nextcloud, Keycloak en LDAP
Een soevereine werkplek op basis van Nextcloud vereist een coherente identiteits- en toegangslaag die volledig los staat van externe cloudproviders. De integratie van ZTNA met Nextcloud en on-premise identiteitsbeheer volgt een architectuurpatroon met drie lagen.
Identiteitslaag: Keycloak als centrale IAM
Keycloak is een open-source Identity and Access Management-platform dat OIDC, SAML 2.0 en LDAP-federatie ondersteunt. In een soevereine architectuur fungeert Keycloak als de enige vertrouwde identiteitsprovider: Nextcloud, OpenZiti, en eventuele andere diensten authenticeren uitsluitend tegen Keycloak, dat op zijn beurt synchroniseert met een on-premise Active Directory of OpenLDAP. Dit elimineert de verborgen afhankelijkheid van Azure AD die in hybride Microsoft-omgevingen vaak blijft bestaan, ook na de formele migratie van Microsoft 365.
Toegangslaag: device posture checks
ZTNA op basis van OpenZiti of Netbird kan worden geconfigureerd om bij elke verbindingspoging de apparaatstatus te controleren: is het apparaat voorzien van de juiste certificaten, draait het een goedgekeurde OS-versie, en is de schijfversleuteling actief? Deze device posture-checks worden afgedwongen vóórdat toegang wordt verleend tot Nextcloud of andere interne diensten. De certificaten worden uitgegeven door een interne Public Key Infrastructure, niet door een externe certificaatautoriteit die onderhevig is aan buitenlandse wetgeving.
Netwerksegmentatie
In OpenZiti worden applicaties en diensten gepubliceerd als afzonderlijke “services” met eigen toegangsbeleid. Een medewerker van de juridische afdeling krijgt uitsluitend toegang tot de Nextcloud-instantie van die afdeling en de bijbehorende collaboratieve diensten, niet tot financiële systemen of HR-databases. Dit is micro-segmentatie in de praktijk, zonder firewallregels op netwerkniveau die moeilijk te onderhouden zijn.
NIS-2 en BIO2: de regelgevende kaders voor remote access
Zowel NIS-2 als BIO2 stellen expliciete eisen aan netwerksegmentatie en remote access die met traditionele VPN-architecturen moeilijk aantoonbaar zijn te vervullen.
ENISA stelt in haar NIS-2 implementatierichtlijnen: “Organisaties die kritieke infrastructuur beheren, moeten netwerksegmentatie en toegangsbeleid inrichten op basis van het principe van minimale rechten en continue verificatie.” NIS-2 artikel 21 lid 2 sub h verplicht entiteiten expliciet tot het treffen van maatregelen voor “beveiliging van netwerken en informatiesystemen, inclusief netwerksegmentatie.” Een ZTNA-architectuur geeft hier directe invulling aan, mits gedocumenteerd en auditeerbaar ingericht.
De BIO2 (Baseline Informatiebeveiliging Overheid versie 2) verplicht overheidsorganisaties tot het toepassen van sterke authenticatie bij remote access, logging van alle toegangspogingen, en periodieke herziening van toegangsrechten. OpenZiti registreert standaard alle verbindingspogingen inclusief apparaatidentificatie, gebruikersidentiteit en tijdstempel, wat directe input levert voor de audit trail die BIO2 vereist.
Migratietraject: van Microsoft-centrisch naar soevereine ZTNA-architectuur
De migratie van een Microsoft-centrisch netwerktoegangsmodel naar een soevereine ZTNA-architectuur verloopt het best in vier fasen, waarbij elke fase een discrete set afhankelijkheden elimineert.
Fase 1: identiteitsaudit en Keycloak-uitrol
Breng alle diensten, applicaties en gebruikers in kaart die afhankelijk zijn van Azure AD of Entra ID. Implementeer Keycloak on-premise en configureer federatie met het bestaande Active Directory. Migreer applicaties één voor één naar Keycloak als primaire identiteitsprovider. Pas nadat Keycloak volledig operationeel is als enige identity source, is het veilig om Azure AD-afhankelijkheden te verwijderen.
Fase 2: OpenZiti-piloot voor een afgebakend segment
Selecteer een afdeling of applicatieset voor een piloot: bij voorkeur een afdeling met hoge gegevensvertrouwelijkheid, zoals juridisch of P&O. Implementeer OpenZiti met Keycloak-integratie voor dit segment en vervang de VPN-toegang voor deze groep. Documenteer de device posture-eisen en certificaatinfrastructuur in deze fase.
Fase 3: Nextcloud-migratie en micro-segmentatie
Migreer Microsoft 365-werkplekken naar Nextcloud en publiceer Nextcloud als een OpenZiti-service met afdelingsspecifiek toegangsbeleid. Configureer LDAP-synchronisatie tussen Keycloak en Nextcloud zodat gebruikersgroepen en rechten automatisch worden overgezet. Schakel MFA in via Keycloak voor alle Nextcloud-toegang.
Fase 4: VPN-uitfasering en compliancedocumentatie
Na volledige uitrol van OpenZiti of de gekozen ZTNA-stack wordt de VPN-infrastructuur uitgeschakeld. Documenteer de architectuur conform de eisen van NIS-2 artikel 21 en BIO2, inclusief de audit trail-configuratie en het incidentresponsproces voor ZTNA-componenten.
Veelgemaakte valkuilen
De meest structurele valkuil is het laten voortbestaan van een hybride identiteitsmodel waarbij Azure AD actief blijft als fallback of als primary identity provider voor specifieke diensten. Zolang Entra ID in de vertrouwensketen zit, is de organisatie juridisch kwetsbaar via de CLOUD Act. Een tweede valkuil is het onderschatten van de certificaatinfrastructuur: ZTNA vereist een robuuste interne PKI, en het ontbreken hiervan leidt tot ad-hoc oplossingen die de beveiligingsarchitectuur ondermijnen. Ten derde onderschatten organisaties vaak de trainings- en bewustwordingsbehoefte: gebruikers die gewend zijn aan een brede VPN-toegang, ervaren ZTNA aanvankelijk als beperkend en omzeilen beveiligingsmaatregelen als de communicatie hierover tekortschiet.
FAQ
Wat is het fundamentele verschil tussen VPN en ZTNA bij een soevereine werkplek?
VPN verleent netwerktoegang op basis van een enkelvoudige authenticatie en vertrouwt vervolgens alle verkeer vanuit dat netwerksegment. ZTNA verifieert bij elke sessie zowel de identiteit van de gebruiker als de status van het apparaat en verleent uitsluitend toegang tot de specifieke applicatie of service die nodig is, niet tot het volledige netwerk.
Is OpenZiti geschikt voor overheidsorganisaties die volledig willen ontkoppelen van Microsoft Azure AD?
Ja. OpenZiti is volledig open-source en kan worden geïntegreerd met on-premise identiteitsoplossingen zoals Keycloak via OIDC of SAML. Er is geen afhankelijkheid van Azure AD, Entra ID of andere Microsoft-cloudcomponenten vereist.
Voldoet een ZTNA-architectuur automatisch aan NIS-2 en BIO2?
ZTNA is een technisch middel dat invulling geeft aan de vereisten voor netwerksegmentatie (NIS-2 artikel 21 lid 2 sub h) en toegangsbeheer (BIO2), maar compliance vereist ook beleidsmatige maatregelen, logging, incidentrespons en periodieke audits. ZTNA is een noodzakelijke maar niet voldoende voorwaarde.
Kan WireGuard worden gebruikt als basis voor een soevereine ZTNA-implementatie?
WireGuard biedt een veilig en efficiënt tunnelprotocol, maar heeft van zichzelf geen identity-aware toegangslaag of device posture-functionaliteit. Oplossingen zoals Netbird of Headscale bouwen op WireGuard en voegen orkestratie en beleidsbeheer toe. Voor volledige zero trust-functionaliteit is aanvullende integratie met een IAM-oplossing zoals Keycloak nodig.
Welke valkuil treft organisaties het vaakst bij migratie van Microsoft 365 naar een soevereine ZTNA-architectuur?
De meest voorkomende valkuil is het handhaven van een hybride identiteitsmodel waarbij Microsoft Azure AD of Entra ID als primaire identiteitsprovider actief blijft tijdens en na de migratie. Zolang Entra ID in de vertrouwensketen zit, blijft de organisatie onderhevig aan de jurisdictionele risico’s van de CLOUD Act. Een expliciete cutover naar een volledig on-premise of Zwitserse IAM-stack is essentieel.
