Zero-trust architectuur soeverein implementeren betekent dat elke gebruiker, elk apparaat en elke netwerkverbinding continu worden geverifieerd, ongeacht of ze zich binnen of buiten de organisatie bevinden. Dit model vervangt de achterhaalde aanname dat een intern netwerk per definitie veilig is, en vormt daarmee de meest solide technische basis voor Europese organisaties die hun data buiten het bereik van Amerikaanse jurisdictie willen houden.
Waarom perimeterbeveiliging tekortschiet in een soevereine context
Perimeterbeveiliging gaat ervan uit dat aanvallers buiten staan en vertrouwde gebruikers binnen. Die aanname is al jaren onhoudbaar, en voor organisaties die onder de CLOUD Act of Patriot Act vallen via een Amerikaanse cloudprovider, is ze ronduit gevaarlijk.
Wanneer persoonsgegevens of vertrouwelijke bedrijfsdata worden opgeslagen bij een Amerikaanse hyperscaler, geldt de CLOUD Act ongeacht of de datacenters in Europa staan. De Amerikaanse overheid kan die provider dwingen gegevens te verstrekken zonder tussenkomst van een Europese rechter. Een zero-trust architectuur op soevereine, on-premise of Zwitserse infrastructuur elimineert die afhankelijkheid structureel, omdat er geen Amerikaanse dienstverlener in de keten zit die onder die jurisdictie valt.
“Trust is a vulnerability. Zero trust is not a product or a service; it is a strategy and a framework that must be implemented with deliberate architectural choices.”
Scott Rose, hoofdauteur NIST SP 800-207 Zero Trust Architecture, National Institute of Standards and Technology
NIST SP 800-207, gepubliceerd in 2020, definieert zeven kernprincipes: alle databronnen zijn resources, alle communicatie is beveiligd ongeacht locatie, toegang per sessie wordt verleend op minimale rechten, de integriteit van apparaten en identiteiten wordt continu bewaakt, authenticatie en autorisatie zijn dynamisch en strikt beleidgestuurd, en er wordt uitgebreide telemetrie verzameld om afwijkingen te detecteren. Deze principes zijn inherent beter uitvoerbaar op infrastructuur die u volledig beheert dan op een gedeeld cloudplatform waar de provider zelf bepaalt wat u kunt inzien.
Statistisch gezien is de urgentie duidelijk: volgens het Verizon Data Breach Investigations Report 2023 was 74 procent van alle datalekken in dat jaar te herleiden tot menselijke fouten of misbruik van identiteitsgegevens. Dat is precies de aanvalsvector die perimeterbeveiliging niet adresseert maar zero-trust structureel sluit.
Zero-trust implementeren zonder Big Tech identity providers
De grootste drempel bij een soevereine zero-trust implementatie is het loslaten van Microsoft Azure Active Directory of Google Identity, waarop veel bestaande toegangsbeleiden zijn gebouwd.
Het alternatief begint bij een open, zelfgehoste Identity and Access Management (IAM) laag. Keycloak, ontwikkeld onder regie van Red Hat en ingebed in de Cloud Native Computing Foundation, is de meest volwassen open-source keuze. Keycloak ondersteunt OAuth 2.0, OpenID Connect en SAML 2.0 volledig, biedt fijnmazige autorisatiebeleiden op resource-niveau, en kan worden geïntegreerd met multifactorauthenticatie via TOTP, WebAuthn of hardwaresleutels zoals YubiKey. Omdat Keycloak volledig zelfgehost draait, verlaat een token of identiteitsclaim de eigen infrastructuur nooit.
| IAM-platform | Herkomst | Hostingmodel | Protocollen | Geschikt voor ZTA |
|---|---|---|---|---|
| Microsoft Azure AD / Entra ID | VS (Microsoft) | Cloud only (CLOUD Act van toepassing) | OAuth 2.0, OIDC, SAML | Nee, bij soevereiniteitsvereiste |
| Google Identity Platform | VS (Google) | Cloud only (CLOUD Act van toepassing) | OAuth 2.0, OIDC | Nee, bij soevereiniteitsvereiste |
| Keycloak | Open source (Red Hat) | On-premise of private cloud | OAuth 2.0, OIDC, SAML 2.0 | Ja |
| Authentik | Open source (Europees) | On-premise of private cloud | OAuth 2.0, OIDC, SAML 2.0, LDAP | Ja |
| Gluu / Janssen | Open source | On-premise of private cloud | OAuth 2.0, OIDC, FIDO2 | Ja |
Bij de migratie van Microsoft 365 naar een soevereine werkomgeving op basis van Nextcloud kan Keycloak als centrale identity provider fungeren voor alle geïntegreerde diensten: Nextcloud zelf, e-mail via Dovecot en Postfix, videovergadering via Jitsi, en eventuele interne applicaties. De LDAP-synchronisatie of directe OIDC-koppeling zorgt dat gebruikersbeheer vanuit één punt plaatsvindt, zonder dat gegevens een Amerikaanse server passeren.
Microsegmentatie en software-defined perimeter in hybride omgevingen
Zero-trust vereist niet alleen sterke identiteitscontrole, maar ook netwerksegmentatie die voorkomt dat een aanvaller die één systeem heeft gecompromitteerd, zich lateraal kan bewegen.
Microsegmentatie wordt doorgaans gerealiseerd via software-defined networking (SDN) of hostgebaseerde firewallregels. Tools als Cilium (op basis van eBPF), OPNsense met VLAN-segmentatie, of WireGuard-tunnels tussen segmenten maken het mogelijk om per workload of per applicatielaag toegangsbeleid te definiëren. In een hybride omgeving, waarbij on-premise infrastructuur wordt gecombineerd met een privécloud in een Europees of Zwitsers datacenter, worden WireGuard-tunnels of IPsec-verbindingen gebruikt om segmenten logisch te verbinden zonder de controle af te geven aan een cloudprovider.
Een software-defined perimeter (SDP) gaat verder dan een VPN: resources zijn pas zichtbaar nadat apparaat en gebruiker zijn geverifieerd via een controller. De SDP-architectuur, gestandaardiseerd door de Cloud Security Alliance, maakt resources letterlijk onontdekbaar voor onbevoegden. Open-source implementaties zoals OpenZiti brengen dit principe naar on-premise omgevingen zonder licentiekosten en zonder afhankelijkheid van een externe controlelaag.
Zero-trust, NIS-2 en de Cyberbeveiligingswet
De NIS-2-richtlijn (Richtlijn 2022/2555) is via de Nederlandse Cyberbeveiligingswet (Cbw) omgezet in nationaal recht. Artikel 21 van de NIS-2-richtlijn verplicht essentiële en belangrijke entiteiten tot een reeks specifieke risicobeheersmaatregelen, waaronder toegangscontrole, segmentatie, encryptie en incidentdetectie.
“De zorgplicht onder de Cyberbeveiligingswet vereist dat organisaties aantoonbaar en continu hun risico’s beheersen, niet slechts op papier voldoen aan een controlelijst.”
Nationaal Cyber Security Centrum (NCSC), Handreiking Zorgplicht
De zorgplicht uit de Cbw is nadrukkelijk technologieneutraal geformuleerd: de wet schrijft geen specifiek product voor, maar eist aantoonbare en proportionele beheersing van risico’s. Een gedocumenteerde zero-trust architectuur, gebaseerd op NIST SP 800-207, vormt een stevige onderbouwing voor die aantoonbaarheid. De continue verificatie, minimale rechten en telemetrievereisten van zero-trust sluiten direct aan op de eisen in artikel 21, lid 2, sub a tot en met j van de richtlijn.
Het IBM Cost of a Data Breach Report 2023 toont aan dat organisaties met een volwassen zero-trust architectuur gemiddeld 1,76 miljoen dollar minder schade leden bij een datalek dan vergelijkbare organisaties zonder zero-trust. Dat financiële argument ondersteunt de proportionaliteitsafweging die de Cbw zorgplicht vereist: de kosten van implementatie wegen aantoonbaar op tegen de risicoreductie.
De Europese Commissie schat dat eind 2023 meer dan 160.000 organisaties onder de NIS-2-richtlijn vallen. Voor sectoren als zorg, energie, transport, overheid en financiën is naleving geen keuze maar een wettelijke verplichting met toezicht van nationale autoriteiten, in Nederland het Rijksinspectoraat Digitale Infrastructuur (RDI) en het NCSC.
Security-by-design en ketenveiligheid als toetskader
Het Regeerakkoord 2026 bevat een expliciete verplichting tot security-by-design voor overheidsorganisaties en hun leveranciers. Dit principe stelt dat beveiliging moet worden ingebakken in de architectuur vanaf de eerste ontwerpfase, niet achteraf als laag worden toegevoegd.
Een zero-trust implementatie voldoet aan security-by-design als drie voorwaarden zijn vervuld. Ten eerste: het toegangsbeleid is gedocumenteerd in architectuurstukken en wordt als wijzigingsverzoek behandeld bij elke aanpassing. Ten tweede: microsegmentatie en identiteitscontrole zijn meegenomen in de initiële systeemontwerpen, niet pas ingesteld na oplevering. Ten derde: penetratietests en configuratiereview vinden periodiek en aantoonbaar plaats, waarbij bevindingen worden verwerkt in een verbeterplan.
Ketenveiligheid voegt daar een extra dimensie aan toe: ook leveranciers, verwerkers en koppelingen met externe systemen moeten onder hetzelfde zero-trust beleid vallen. In de praktijk betekent dit dat een Nextcloud-integratie met een externe e-mailprovider of een koppeling met een loonadministratiesysteem via dezelfde Keycloak-identiteitslaag loopt, en dat de toegangsrechten van externe partijen minimaal en tijdgebonden zijn. Leverancierscontracten moeten de beveiligingsvereisten expliciet benoemen en auditrechten voor de opdrachtgever vastleggen.
Voor organisaties in de rechtssector, bij gemeenten of in de zorg, die werken met bijzondere persoonsgegevens, vormt de combinatie van een soevereine zero-trust architectuur, Keycloak als IAM, en een on-premise of Zwitsers gehoste Nextcloud-omgeving de meest verdedigbare technische keuze bij een toetsing door de Autoriteit Persoonsgegevens of het RDI.
FAQ
Wat is het fundamentele verschil tussen zero-trust en traditionele perimeterbeveiliging?
Perimeterbeveiliging vertrouwt op een veilige buitengrens: wie eenmaal binnen is, krijgt breed toegang. Zero-trust veronderstelt dat elk netwerksegment, elk apparaat en elke gebruiker potentieel gecompromitteerd is. Toegang wordt per sessie, per resource en op basis van contextfactoren zoals apparaatstatus en gebruikersgedrag continu geverifieerd.
Kan Keycloak volledig vervangen wat Microsoft Azure Active Directory biedt?
Keycloak ondersteunt OAuth 2.0, OpenID Connect, SAML 2.0 en fijnmazige autorisatiebeleiden, wat de kernfunctionaliteit van Azure AD dekt. Sommige Microsoft-specifieke integraties vereisen extra configuratie of middleware. Voor organisaties die volledig afstappen van het Microsoft-ecosysteem is Keycloak de meest volwassen open-source keuze, zeker in combinatie met een Nextcloud-werkomgeving.
Wat houdt de zorgplicht onder de Cyberbeveiligingswet concreet in voor IT-beslissers?
De zorgplicht verplicht organisaties die onder de Cbw vallen tot het treffen van passende en evenredige technische en organisatorische maatregelen om de risico’s voor hun netwerk- en informatiesystemen te beheersen. Concreet betekent dit een aantoonbaar risicobeheersproces, incidentregistratie, en het kunnen onderbouwen van beveiligingskeuzen zoals de keuze voor een zero-trust architectuur boven perimeterbeveiliging.
Wat is een software-defined perimeter en hoe verschilt het van een VPN?
Een software-defined perimeter maakt resources onzichtbaar voor het netwerk totdat een gebruiker en apparaat zijn geverifieerd: de resource bestaat niet voor onbevoegden. Een traditionele VPN verleent na authenticatie doorgaans breed netwerktoegang. Een SDP combineert toegangscontrole met micro-isolatie en past daarmee beter in een zero-trust model.
Hoe toets je een zero-trust implementatie aan de security-by-design verplichting?
Security-by-design vereist dat beveiligingsmaatregelen in de architectuur zijn ingebouwd, niet achteraf toegevoegd. Een zero-trust implementatie voldoet hieraan als toegangsbeleid, microsegmentatie en identiteitsverificatie zijn gedocumenteerd in het ontwerp, worden meegenomen bij elke wijziging, en aantoonbaar worden getest via periodieke penetratietests en configuratiereview. Ketenveiligheid betekent dat ook leveranciers en koppelingen onder hetzelfde beleid vallen.
