Een zero trust soevereine infrastructuur on-premise is een beveiligingsarchitectuur waarbij alle beleidscomponenten, identiteitsverificatie en toegangscontrole uitsluitend draaien op infrastructuur die de organisatie zelf beheert, zonder tussenkomst van cloudservices die onder vreemde jurisdictie vallen. Dit onderscheidt zich fundamenteel van commerciële zero trust-diensten waarbij de policy engine bij een Amerikaanse hyperscaler is ondergebracht.
Cloudgebaseerde versus on-premise zero trust: het soevereiniteitsdilemma
Zero trust is geen locatiekeuze, maar een architectuurprincipe. Toch maakt het voor gegevenssouvereiniteit veel uit waar de beslissende componenten draaien.
Volgens NIST SP 800-207 (Zero Trust Architecture) bestaat elke ZTA uit een Policy Decision Point (PDP), een Policy Enforcement Point (PEP) en een Policy Administrator (PA). Bij producten als Microsoft Entra (voorheen Azure AD) of Google BeyondCorp draait de PDP volledig in de cloud van de leverancier. Elke authenticatie, elke autorisatiebeslissing en elk toegangsverzoek passeert de servers van die leverancier, inclusief alle contextinformatie over wie, wanneer en vanaf welk apparaat toegang wordt gevraagd.
Dit is geen theoretisch risico. De Amerikaanse CLOUD Act (2018) verplicht Amerikaanse bedrijven om op rechterlijk bevel gegevens te overhandigen, ook als die zich buiten de VS bevinden. De Patriot Act bevat vergelijkbare bepalingen voor inlichtingendoeleinden. Wie zijn PDP bij Microsoft of Google onderbrengt, aanvaardt impliciet dat een Amerikaanse rechtbank toegang kan vorderen tot zijn autorisatielogboeken, gebruikerscontext en toegangspatronen, ongeacht de vestigingsplaats van de organisatie.
De statistieken onderstrepen de urgentie: 83 procent van de datalekken in 2023 betrof gegevens in cloudomgevingen (IBM Cost of a Data Breach Report 2023). Een on-premise soevereine ZTA verplaatst het aanvalsoppervlak terug naar infrastructuur die volledig controleerbaar is.
De kerncomponenten on-premise implementeren
Een volledig soevereine ZTA vereist dat PDP, PEP en identity broker op eigen infrastructuur of een Europese soevereine cloud (zoals Hetzner, OVHcloud of een gecertificeerde Swiss-hosted omgeving) draaien.
Identity broker: Keycloak als on-premise IAM
Keycloak is een volwassen open-source Identity and Access Management-platform, oorspronkelijk ontwikkeld door Red Hat en nu een zelfstandig community-project. Het ondersteunt OpenID Connect, OAuth 2.0, SAML 2.0 en koppelt aan bestaande LDAP- of Active Directory-directories. Organisaties installeren Keycloak op eigen hardware of in een Europese private cloud, waarna alle tokenuitgifte en authenticatiestappen lokaal plaatsvinden. Er is geen enkel authenticatiemoment dat een Amerikaans datacenter bereikt.
Policy Enforcement Point en network fabric: OpenZiti en SPIFFE/SPIRE
OpenZiti implementeert een zero trust network overlay waarbij elke workload een eigen cryptografische identiteit krijgt via het SPIFFE-standaard (Secure Production Identity Framework For Everyone). De bijbehorende runtime SPIRE (SPIFFE Runtime Environment) wijst elke service een kortlevend SVID-certificaat (SPIFFE Verifiable Identity Document) toe dat automatisch roteert. Dit maakt laterale beweging door aanvallers die een sessietoken hebben gestolen praktisch onmogelijk: het gestolen credential is binnen uren verlopen.
Scott Rose, hoofdauteur van NIST SP 800-207, formuleert het kernprincipe als volgt: “Zero trust is geen product dat je koopt, maar een strategie die je implementeert. De locatie van de policy engine bepaalt uiteindelijk wie werkelijk de controle heeft.”
Secrets management: HashiCorp Vault self-hosted
Encryptiesleutels, API-tokens en certificaten mogen niet in een externe secrets manager belanden. HashiCorp Vault (self-hosted, open-source licentie via Mozilla Public License 2.0 tot versie 1.14) biedt een volledig on-premise sleutelbeheeroplossing met hardware security module (HSM)-integratie. De overstap naar de Business Source License in nieuwere versies maakt OpenBao (een community fork) een goed alternatief voor organisaties die licentievrij willen blijven.
| Component | Cloudgebaseerde optie (risico) | Soevereine on-premise optie |
|---|---|---|
| Identity broker / PDP | Microsoft Entra, Google BeyondCorp (CLOUD Act-risico) | Keycloak (open-source, self-hosted) |
| Network overlay / PEP | Zscaler Private Access, Cloudflare Access (VS-jurisdictie) | OpenZiti met SPIFFE/SPIRE |
| Secrets management | AWS Secrets Manager, Azure Key Vault | HashiCorp Vault self-hosted of OpenBao |
| Certificate Authority | DigiCert (VS), Let’s Encrypt (VS non-profit) | Step-CA (self-hosted) of eigen PKI |
NIS-2 artikel 21 en de zero trust-verplichting
NIS-2 artikel 21 schrijft voor essentiële en belangrijke entiteiten een reeks technische en organisatorische beveiligingsmaatregelen voor. De richtlijn noemt zero trust niet bij naam, maar de vereisten corresponderen er nauwkeurig mee.
Artikel 21 lid 2 omvat onder andere: toegangscontrolebeleid, netwerksegmentatie, beleid voor gebruik van cryptografie, en procedures voor het beheren van toegangsrechten. Dit zijn precies de vier pijlers van een ZTA zoals beschreven in NIST SP 1800-35 (Implementing a Zero Trust Architecture). ENISA stelt in zijn Zero Trust Guidelines expliciet: “Organisaties die artikel 21 van NIS-2 serieus nemen, komen al snel uit bij een zero trust-model: continue verificatie, minimale privileges en gesegmenteerde toegang zijn precies de maatregelen die de richtlijn voorschrijft.”
Toezichthouders zoals het Agentschap Telecom (in Nederland belast met NIS-2-toezicht voor bepaalde sectoren) of het BSI in Duitsland beoordelen de volwassenheid van een ZTA-implementatie aan de hand van aantoonbare controlemechanismen: zijn er logboeken van toegangsbeslissingen, wordt microsegmentatie daadwerkelijk afgedwongen, en is er bewijs van continue verificatie in plaats van eenmalige perimeterbescherming? Een cloudgebaseerde ZTA waarbij de logs bij een Amerikaanse leverancier staan, bemoeilijkt deze aantoonbaarheid.
Post-kwantumcryptografie integreren in een soevereine ZTA
Een ZTA die vandaag wordt gebouwd, moet rekening houden met kwantumdreiging. Het NIST schat op basis van NIST IR 8413 dat een cryptografisch relevante kwantumcomputer binnen 10 tot 15 jaar bestaande RSA- en ECC-encryptie kan breken (2022). Dit maakt “harvest now, decrypt later”-aanvallen actueel: tegenstanders onderscheppen nu versleuteld verkeer om het later te ontsleutelen zodra kwantumhardware beschikbaar is.
In 2024 heeft NIST drie post-kwantumalgoritmen gestandaardiseerd: ML-KEM (voorheen Kyber, voor sleuteluitwisseling), ML-DSA (voorheen Dilithium, voor digitale handtekeningen) en SLH-DSA (voorheen SPHINCS+, alternatieve handtekening). Deze algoritmen zijn direct relevant voor mTLS binnen een ZTA, waarbij elke workload-tot-workload-verbinding met een PQC-compatibel handshakeprotocol kan worden beveiligd.
Het Open Quantum Safe-project biedt liboqs, een open-source C-bibliotheek die hybride TLS-implementaties mogelijk maakt: klassieke algoritmen (zoals ECDHE) worden gecombineerd met PQC-algoritmen, zodat de verbinding veilig blijft tegen zowel klassieke als kwantumtegenstanders. OpenSSL 3.x ondersteunt via de OQS-provider al experimentele hybride handshakes. Organisaties die hun mTLS-infrastructuur op SPIFFE/SPIRE baseren, kunnen hiermee de certificaatuitgifte en de TLS-verbindingen kwantumbestendig inrichten, volledig on-premise en zonder externe afhankelijkheden.
De aanbeveling is een gelaagde aanpak: vervang eerst de sleuteluitwisselingsmechanismen (meest urgente kwantumkwetsbaarheid), daarna de handtekeningschema’s voor certificaatverlening. Koppel dit aan automatische certificaatrotatie via SPIRE, zodat PQC-certificaten proactief worden ververst zonder menselijke tussenkomst.
Praktische migratierichting voor compliance officers en IT-beslissers
Organisaties in de overheid, juridische sector en kritieke infrastructuur die nu afhankelijk zijn van Microsoft 365 of vergelijkbare cloudsuites, kunnen stapsgewijs migreren. De first principles zijn: breng de PDP als eerste on-premise, want daarmee verlaat geen autorisatiemetadata meer het eigen netwerk. Vervang vervolgens cloudgebaseerde identity federation stap voor stap door Keycloak-instances die de bestaande Active Directory-directory als backend gebruiken, zonder directe Entra-connectie.
De NIST SP 1800-35-gids biedt hiervoor concrete referentiearchitecturen met zeven varianten, variërend van een initiële ZTA naast bestaande perimeters tot een volledig gemigreerde omgeving. Dit maakt de overgang planbaar zonder “big bang”-migratie.
Een aandachtspunt bij de ENISA Zero Trust Guidelines is de eis dat organisaties hun ZTA-model documenteren als onderdeel van hun risicomanagementraamwerk: wie beheert de trust anchors, hoe worden PDP-beslissingen gelogd, en wat is het revocatieproces bij een gecompromitteerd certificaat? Dit documentatieniveau is ook precies wat NIS-2-toezichthouders zullen opvragen bij een audit.
Veelgestelde vragen
Kan een organisatie Microsoft Entra gebruiken als identity provider binnen een soevereine zero trust-architectuur?
Niet zonder soevereiniteitsrisico. Microsoft Entra verwerkt tokenuitgifte en policy-evaluatie op Amerikaanse servers en valt onder de CLOUD Act. Wie volledige controle wil, vervangt Entra door een on-premise identity broker zoals Keycloak, gekoppeld aan een lokale LDAP- of Active Directory-directory.
Wat is het verschil tussen SPIFFE/SPIRE en een traditioneel PKI-systeem binnen zero trust?
Een traditionele PKI geeft statische certificaten uit met lange looptijden. SPIFFE/SPIRE wijst elke workload een cryptografische identiteit (SVID) toe die automatisch roteert, vaak elke paar uur. Dit maakt laterale beweging door aanvallers die een certificaat stelen aanzienlijk moeilijker.
Vereist NIS-2 artikel 21 expliciet een zero trust-architectuur?
De tekst van artikel 21 noemt zero trust niet bij naam, maar de vereisten zoals netwerksegmentatie, toegangsbeheer op basis van minimale privileges en continue monitoring corresponderen direct met de kernprincipes van ZTA zoals gedefinieerd in NIST SP 800-207. Toezichthouders beoordelen de volwassenheid via dit soort functionele criteria.
Welke post-kwantumalgoritmen zijn al bruikbaar voor mTLS in een on-premise ZTA?
NIST heeft in 2024 ML-KEM (Kyber), ML-DSA (Dilithium) en SLH-DSA (SPHINCS+) gestandaardiseerd. Libraries zoals liboqs van het Open Quantum Safe-project bieden al hybride TLS-implementaties die klassieke en PQC-algoritmen combineren, geschikt voor experimentele productie-inzet.
Hoe verhoudt een on-premise ZTA zich tot de eisen van de AVG?
Een on-premise ZTA elimineert doorgifte van authenticatie- en autorisatiegegevens naar derde landen buiten de EU, wat een directe risicoreductie is onder de artikelen 44 tot 49 AVG. Bovendien maakt granulaire toegangslogging het eenvoudiger om te voldoen aan de verantwoordingsplicht van artikel 5 lid 2 AVG.
