Een zero trust soevereine infrastructuur is een beveiligingsarchitectuur waarbij geen enkel systeem, gebruiker of netwerksegment standaard vertrouwd wordt, en waarbij alle besturingscomponenten, zoals identiteitsproviders, beleidsengines en toegangshandhaving, volledig onder eigen jurisdictie vallen. Voor Europese overheidsorganisaties, advocatenkantoren en andere gereguleerde entiteiten is dit het antwoord op de gecombineerde dreiging van buitenlandse wetgeving zoals de Amerikaanse CLOUD Act en toenemende cyberdreigingen die traditionele perimeterbeveiliging structureel omzeilen.
Waarom Big Tech identity providers een soevereiniteitsprobleem zijn
Wie zijn zero-trust-architectuur laat draaien op Microsoft Entra ID of Google BeyondCorp, delegeert de meest kritieke bouwsteen van toegangscontrole aan een partij die juridisch onderworpen is aan Amerikaanse wetgeving. De CLOUD Act verplicht Amerikaanse bedrijven om op rechterlijk bevel gegevens te overhandigen, ook als die gegevens op Europese servers staan. Dit maakt de identiteitsprovider, die voor iedere toegangsbeslissing wordt geraadpleegd, tot een potentieel raakpunt voor buitenlandse inlichtingendiensten.
Dat is niet slechts een theoretisch risico. De Europese Commissie heeft in diverse richtsnoeren gewaarschuwd dat organisaties die hun identiteits- en toegangsbeheer uitbesteden aan Amerikaanse cloudproviders, een structurele afhankelijkheid creëren die strijdig is met het principe van digitale soevereiniteit.
NIST SP 800-207 als blauwdruk voor soevereine implementatie
NIST SP 800-207 is de internationale referentiestandaard voor zero-trust-architectuur. Het document definieert zeven kernprincipes en beschrijft de logische componenten waaruit een implementatie moet bestaan. Twee van die componenten zijn cruciaal voor een soevereine opzet.
De Policy Decision Point (PDP) evalueert iedere toegangsaanvraag op basis van identiteit, apparaatstatus, context en beleid, en geeft een toestemming of weigering terug. De Policy Enforcement Point (PEP) voert die beslissing uit door verkeer door te laten of te blokkeren. In een Big Tech-implementatie zijn beide componenten doorgaans verweven met de cloudinfrastructuur van de provider. Voor een soevereine opzet moeten ze volledig onder eigen beheer draaien.
NIST SP 1800-35, de bijbehorende praktijkgids, biedt concrete referentie-implementaties die ook op on-premise of Europees gehosteerde infrastructuur uitvoerbaar zijn. Daarin wordt expliciet ruimte gelaten voor open-source componenten, zolang de architectuurprincipes worden gevolgd.
Soevereine alternatieven voor PDP en PEP
Keycloak (Red Hat, open-source) is de meest volwassen soevereine keuze voor de identiteits- en toegangsbeheerlaag die de PDP ondersteunt. Het ondersteunt OpenID Connect, OAuth 2.0, SAML 2.0 en kan volledig zelfgehost worden. Keycloak fungeert als identity provider, beheert gebruikerssessies en kan beleidsregels afdwingen op basis van rollen, attributen en apparaatclaims. Het is in productie bewezen bij grote Europese overheidsinstanties.
OpenZiti is een open-source zero-trust-netwerkoverlayplatform dat de PEP-functie invult. Het creëert software-defined microperimeters rond individuele applicaties en diensten, zonder dat deze via het publieke internet bereikbaar hoeven te zijn. Toegang wordt uitsluitend verleend via wederzijdse TLS-authenticatie en een centraal beheerde policy engine. OpenZiti is geschikt voor zowel cloud-native als legacy on-premise omgevingen.
HashiCorp Vault (open-source licentie beschikbaar als OpenBao-fork) verzorgt de gecentraliseerde geheimenbeheerlaag: certificaten, API-sleutels, databasewachtwoorden en cryptografische sleutels worden dynamisch uitgegeven en automatisch verlopen. Dit is onmisbaar voor een zero-trust-implementatie waarin elk werkstation, elke applicatie en elke service afzonderlijk geauthenticeerd wordt.
| Component | Big Tech-equivalent | Soeverein open-source alternatief | Zelfhostbaar |
|---|---|---|---|
| Identity Provider (PDP) | Microsoft Entra ID, Okta | Keycloak | Ja |
| Netwerktoegang (PEP) | Google BeyondCorp, Zscaler | OpenZiti | Ja |
| Geheimenbeheer | Azure Key Vault, AWS Secrets Manager | HashiCorp Vault / OpenBao | Ja |
| Device trust | Microsoft Intune | osquery + Fleet, of Smallstep CA | Ja |
NIS-2 artikel 21 en de relatie met zero trust
NIS-2 artikel 21 verplicht essentiële en belangrijke entiteiten tot concrete technische en organisatorische maatregelen op het gebied van toegangscontrole, netwerksegmentatie, encryptie en continue monitoring. Zero-trust-architectuur dekt een groot deel van die verplichtingen structureel af.
Microsegmentatie, een kernprincipe van zero trust waarbij iedere verbinding individueel geautoriseerd wordt, komt direct overeen met de segmentatieverplichtingen van artikel 21 lid 2 onder h. De verplichting tot gebruik van multifactorauthenticatie (MFA) en continue verificatie sluit aan op de zero-trust-eis dat identiteit bij iedere sessie opnieuw wordt geverifieerd, niet slechts bij inlog.
Voor Nederlandse overheidsorganisaties geldt aanvullend de BIO2 (Baseline Informatiebeveiliging Overheid versie 2), die eisen stelt die inhoudelijk vergelijkbaar zijn met NIS-2 maar ook aansluiting zoekt bij ISO 27001. BIO2 vereist expliciete toegangsbeheerbeleid en scheiding van netwerksegmenten, waarvoor een Keycloak-plus-OpenZiti-architectuur een aantoonbare technische grondslag biedt.
Belangrijk voorbehoud: zero trust dekt niet alles. NIS-2 artikel 21 vereist ook risicobeheer, incidentmeldprocessen en supply-chainveiligheid. Die vereisen aanvullende maatregelen naast de technische toegangscontrolelaag.
Legacy systemen integreren zonder externe SaaS
Veel organisaties hebben on-premise systemen die geen moderne authenticatieprotocollen ondersteunen: oudere ERP-systemen, industriële besturingsomgevingen of interne webapplicaties die alleen LDAP of Kerberos kennen. Deze systemen zijn de zwakste schakel in een zero-trust-migratie.
De aanpak is gelaagd. Keycloak ondersteunt LDAP-federatie en kan bestaande Active Directory-omgevingen spiegelen zonder die te vervangen. Voor applicaties zonder OAuth-ondersteuning biedt een reverse proxy met Keycloak-integratie, zoals OAuth2 Proxy of Vouch Proxy, een tussenlaag die authenticatie afdwingt zonder de applicatie zelf aan te passen.
OpenZiti kan vervolgens de netwerktoegang tot die applicatie afsluiten voor al het verkeer dat niet door de zero-trust-overlay gaat. Het resultaat is dat een legacy systeem nooit direct bereikbaar is via het netwerk, ook niet intern, maar alleen via een geverifieerde tunnel. Dat is een fundamentele verbetering ten opzichte van een situatie waarbij interne systemen impliciet vertrouwd worden zodra iemand het bedrijfsnetwerk betreedt.
IBM rapporteerde in 2023 dat aanvallers gemiddeld 204 dagen onopgemerkt in een netwerk verblijven voordat ze worden gedetecteerd. Microsegmentatie via OpenZiti verkleint de bewegingsruimte van een aanvaller die toch binnenkomt drastisch, omdat laterale beweging door het netwerk per definitie nieuwe authenticatie vereist.
Post-kwantumcryptografie als fundament voor toekomstbestendige toegangscontrole
Zero trust steunt zwaar op cryptografie: TLS voor transportbeveiliging, certificaten voor apparaatidentiteit, digitale handtekeningen voor beleidsintegriteit. Al deze mechanismen zijn kwetsbaar voor een voldoende krachtige kwantumcomputer die Shor’s algoritme uitvoert.
NIST heeft in 2024 de eerste definitieve post-kwantumstandaarden gepubliceerd: ML-KEM (gebaseerd op CRYSTALS-Kyber) voor sleuteluitwisseling en ML-DSA (gebaseerd op CRYSTALS-Dilithium) voor digitale handtekeningen. Deze algoritmen zijn ontworpen om bestand te zijn tegen aanvallen met kwantumcomputers.
Voor een soevereine zero-trust-implementatie betekent dit concreet: de interne certificaatautoriteit (CA), bij voorkeur beheerd via HashiCorp Vault of Smallstep, moet worden uitgebreid met post-kwantumalgoritmen. TLS 1.3 biedt al hybride sleuteluitwisseling waarbij klassieke en post-kwantumalgoritmen gecombineerd worden, zodat ook huidige aanvallers die versleuteld verkeer opslaan voor later (“harvest now, decrypt later”) geen voordeel hebben.
OpenZiti gebruikt mTLS als basis voor alle tunnelauthenticatie. Het integreren van post-kwantumcertificaten in die mTLS-laag is technisch haalbaar zodra de onderliggende cryptobibliotheek, zoals liboqs van het Open Quantum Safe-project, geïntegreerd is. Dit vraagt om een expliciete roadmap die nu begint, niet wanneer kwantumcomputers de drempel bereiken.
Volwassenheidsvereisten voor open-source zero-trust-tooling
Open-source is niet hetzelfde als onbeheerd. Voor productiegebruik in een gereguleerde omgeving gelden minimale operationele vereisten: interne expertise of een Europese beheerpartner voor Keycloak-configuratie en upgrades, een gedefinieerd patchbeleid voor OpenZiti-componenten, en periodieke rotatie van Vault-sleutels met gedocumenteerde procedures.
Keycloak is in actieve ontwikkeling onder Red Hat-auspiciën en heeft een bewezen track record bij Europese overheidsinstanties. OpenZiti wordt onderhouden door een actieve community met commerciële ondersteuning beschikbaar via NetFoundry. HashiCorp Vault heeft een open-source-fork gekregen in de vorm van OpenBao, beheerd door de Linux Foundation, na de licentiewijziging van HashiCorp in 2023. Organisaties die langetermijncontinuïteit vereisen, doen er verstandig aan OpenBao te evalueren als alternatief.
De volwassenheidsvereiste is niet primair technisch maar organisatorisch: een zero trust soevereine infrastructuur vereist dat toegangsbeleid wordt gedocumenteerd, geauditeerd en periodiek herzien. Dat is een governance-opgave die technische tooling niet vervangt.
FAQ: Zero trust soevereine infrastructuur
Is zero trust hetzelfde als een VPN vervangen?
Nee. Een VPN controleert alleen of je het netwerk binnenkomt; daarna heb je vaak brede toegang. Zero trust controleert bij elke afzonderlijke toegangspoging opnieuw de identiteit, apparaatstatus en context, ongeacht netwerklocatie. VPN’s kunnen onderdeel blijven van de infrastructuur, maar vormen geen vervanging voor zero-trust-toegangscontrole.
Kan een kleine overheidsorganisatie zero trust implementeren zonder groot IT-team?
Ja, maar gefaseerd. Begin met gecentraliseerd identiteitsbeheer via Keycloak en multifactorauthenticatie, voeg daarna microsegmentatie toe via OpenZiti, en schaal op. NIST SP 1800-35 biedt referentie-implementaties die ook voor kleinere teams haalbaar zijn.
Voldoet een zero-trust-architectuur automatisch aan NIS-2 artikel 21?
Niet automatisch. Zero trust dekt grote delen van artikel 21, waaronder toegangscontrole, netwerksegmentatie en continue monitoring. Maar NIS-2 verplicht ook risicobeheer, incidentrespons en supply-chainveiligheid, die aanvullende maatregelen vereisen buiten de pure zero-trust-architectuur.
Zijn post-kwantumalgoritmen al stabiel genoeg voor productiegebruik?
NIST heeft in 2024 de eerste definitieve post-kwantumstandaarden gepubliceerd, waaronder ML-KEM voor sleuteluitwisseling en ML-DSA voor digitale handtekeningen. Deze zijn geschikt voor productie, maar vragen om zorgvuldige integratie in bestaande PKI en sleutelbeheerinfrastructuur zoals HashiCorp Vault of OpenBao.
Maakt het gebruik van Keycloak of OpenZiti mij afhankelijk van een externe leverancier?
Keycloak en OpenZiti zijn open-source projecten. Je kunt ze zelf hosten, de broncode inzien en aanpassen, en je bent niet afhankelijk van een enkele commerciële partij. Er zijn meerdere Europese beheerde hostingopties beschikbaar, en de projecten worden ondersteund door actieve communities, wat continuïteitsrisico’s beperkt ten opzichte van gesloten cloudoplossingen.
