Een zero trust on-premise soevereine netwerkarchitectuur is een beveiligingsmodel waarbij geen enkel apparaat, gebruiker of netwerksegment standaard wordt vertrouwd, en waarbij het controlevlak volledig op eigen infrastructuur draait, buiten het bereik van Amerikaanse jurisdictie via de CLOUD Act of de Patriot Act. Voor overheidsorganisaties, advocatenkantoren en andere gereguleerde sectoren is dit onderscheid niet theoretisch: het bepaalt of buitenlandse autoriteiten rechtmatig toegang kunnen vorderen tot uw sleutels en verificatiesystemen.
Waarom perimeterbeveiliging onvoldoende is voor soevereine organisaties
Perimeterbeveiliging veronderstelt een vertrouwde binnenste zone. Die aanname is al jaren achterhaald, maar voor organisaties die gevoelige data beheren is het risico acuter.
Wanneer uw identity provider in een Amerikaanse clouddienst zoals Azure Active Directory of Okta draait, beheert een derde partij feitelijk de sleutels tot uw gehele infrastructuur. Een CLOUD Act-vordering bij Microsoft of Okta kan resulteren in toegang tot authenticatietokens, auditlogs en gebruikersidentiteiten, zonder dat uw organisatie daar direct van op de hoogte wordt gesteld. Dit is geen hypothetisch scenario: het is de kern van waarom NIST SP 800-207 stelt dat elke toegangsaanvraag behandeld moet worden alsof het netwerk al gecompromitteerd is.
“Zero trust is geen product maar een strategie: elke toegangsaanvraag moet worden geverifieerd alsof het netwerk al gecompromitteerd is.” (NIST SP 800-207 Zero Trust Architecture)
De statistieken ondersteunen de urgentie. Volgens het Verizon Data Breach Investigations Report 2023 betrof 81% van de wereldwijde datalekken gestolen of zwakke inloggegevens. Perimeterbeveiliging beschermt daar niet tegen zodra een aanvaller valide credentials heeft. Zero trust beperkt de laterale beweging die daarna volgt.
De wettelijke basis: NIS-2 artikel 21 en BIO2
NIS-2 en de Nederlandse BIO2 leggen concrete architectuurverplichtingen op die direct aansluiten bij zero-trust principes.
NIS-2 artikel 21 lid 2 sub e verplicht organisaties die onder de richtlijn vallen tot het treffen van maatregelen voor de beveiliging van netwerken en informatiesystemen, met expliciete aandacht voor netwerksegmentatie en toegangscontrole. Dit is geen open norm: de richtlijn vraagt aantoonbare technische maatregelen, gedocumenteerde beleidsprocessen en periodieke verificatie.
De BIO2 (Baseline Informatiebeveiliging Overheid versie 2) vertaalt vergelijkbare eisen naar de Nederlandse overheidscontext. BIO2 vereist onder meer strikte scheiding van netwerksegmenten, logging van toegangspogingen en minimale toegangsprivilegies per rol. Architectureel zijn dit exact de controlemechanismen die een zero-trust model formaliseert.
“Organisaties moeten ervan uitgaan dat een aanvaller al binnen het netwerk aanwezig is; microsegmentatie en continue verificatie zijn geen optionele lagen maar de kern van een weerbare architectuur.” (ENISA Zero Trust Guidelines 2023)
Soevereine identiteits- en toegangsinfrastructuur zonder externe cloudproviders
De kern van een soevereine zero-trust stack is een on-premise identity provider die OIDC, SAML en OAuth 2.0 ondersteunt.
Keycloak als vervanging van Azure AD
Keycloak is de meest volwassen open-source identity- en access-managementoplossing voor dit doel. Het draait volledig on-premise of in een Europese privécloud, ondersteunt multifactor-authenticatie, federatie met bestaande LDAP- en Active Directory-directories, en biedt een volledige OIDC-implementatie voor applicatieintegratie. Organisaties die Microsoft 365 verlaten in de richting van een Nextcloud-omgeving, gebruiken Keycloak als centrale authenticatiedienst voor alle werkplektoepassingen.
Belangrijk is dat Keycloak de volledige token-levenscyclus beheert op uw eigen hardware. Er is geen afhankelijkheid van externe certificate authorities of clouddiensten voor het uitschrijven van toegangstokens. Dit elimineert de jurisdictionele kwetsbaarheid die ontstaat wanneer een Amerikaanse provider het root-certificaat beheert.
HashiCorp Vault voor geheimenbeheer
Naast identiteitsbeheer vereist zero trust centraal beheer van geheimen: API-sleutels, certificaten, databasewachtwoorden en encryptiesleutels. HashiCorp Vault (open-source editie) voorziet hierin on-premise. Het integreert met Keycloak via OIDC voor autorisatie, wat een aaneengesloten beleidslaag oplevert zonder externe SaaS-afhankelijkheid.
OpenZiti voor netwerkoverlap zonder inbound firewall-regels
OpenZiti is een open-source zero-trust netwerkoverlap die applicatiegerichte connectiviteit biedt via wederzijds geverifieerde TLS-tunnels (mTLS). Het kenmerkende voordeel voor soevereine omgevingen is dat er geen inbound firewall-regels nodig zijn: diensten zijn niet zichtbaar op het netwerk totdat een geverifieerde identiteit toegang vraagt. Het controlevlak (de OpenZiti controller) draait volledig on-premise, waardoor er geen extern cloudcomponent in de kritieke pad zit.
| Functie | Traditionele perimeter | Soevereine zero-trust stack |
|---|---|---|
| Identity provider | Azure AD / Okta (VS-jurisdictie) | Keycloak (on-premise, EU-jurisdictie) |
| Netwerktoegang | VPN met breed toegestane subnets | OpenZiti mTLS-overlay, per-applicatie |
| Geheimenbeheer | Azure Key Vault (VS-cloudservice) | HashiCorp Vault (on-premise) |
| Controlevlak | Extern, cloudgebaseerd | Volledig lokaal, auditeerbaar |
| Microsegmentatie | VLAN-gebaseerd, statisch | Beleidsgestuurd, per identiteit |
Microsegmentatie en SDN in een soeverein controlevlak
Software-defined networking (SDN) en network access control (NAC) zijn de twee mechanismen waarmee microsegmentatie operationeel wordt zonder afhankelijkheid van een extern cloudcontrolevlak.
SDN scheidt het dataplane (het feitelijke verkeer) van het controlevlak (de beleidsbeslissingen). In een soevereine architectuur draait de SDN-controller, bijvoorbeeld gebaseerd op OpenDaylight of een commerciële Europese equivalent, uitsluitend op eigen infrastructuur. Dit geeft de netwerkbeheerder volledige controle over verkeersstromen en segmentatiebeleid zonder dat een derde partij in dat pad zit.
NAC voegt de apparaatdimensie toe. Voor elke verbinding wordt niet alleen de gebruikersidentiteit geverifieerd (via Keycloak/OIDC), maar ook de apparaatstatus: is het apparaat geregistreerd, zijn certificaten geldig, voldoet het aan het patchbeleid? Tooling zoals PacketFence (open-source NAC) kan deze verificatie on-premise uitvoeren en integreert met RADIUS voor bestaande netwerkinfrastructuur.
Volgens de ENISA Threat Landscape 2023 stegen supply-chain aanvallen op netwerksoftware met 17% ten opzichte van 2022. Een cloudgebaseerd controlevlak vergroot het aanvalsoppervlak precies op dit punt: een aanval op de SaaS-leverancier van uw SDN-controller raakt direct uw segmentatiebeleid. Een on-premise controller beperkt dit risico tot uw eigen beheercapaciteit.
Continue verificatie in hybride omgevingen met Europese clouddiensten
Volledig on-premise is voor veel organisaties een einddoel, niet de beginsituatie. De tussenperiode, waarbij on-premise systemen naast Europese clouddiensten zoals een Zwitserse Nextcloud-instantie of een EUCS-gecertificeerde opslag draaien, vereist een coherente identiteitslaag die beide werelden bedient.
De oplossing is een federatieve identiteitsarchitectuur waarbij Keycloak fungeert als de authoritative identity provider en Europese clouddiensten als OIDC-relying parties worden geconfigureerd. De clouddienst vertrouwt dan op uw on-premise Keycloak voor authenticatie, maar bewaart zelf geen inloggegevens. Tokenverificatie verloopt via uw eigen JWKS-endpoint (JSON Web Key Set), dat on-premise draait.
Dit model garandeert continue verificatie omdat elk token een korte levensduur heeft (doorgaans vijftien tot zestig minuten) en bij verlenging opnieuw door Keycloak wordt beoordeeld. Apparaatcertificaten, uitgeschreven door een on-premise certificate authority, voegen de apparaatdimensie toe conform de NIST SP 800-207-aanbevelingen voor device identity.
Architectuur- en operationele risico’s bij de transitie
De overgang van perimeterbeveiliging naar zero trust is een meerjarig traject met concrete risico’s die vooraf moeten worden geadresseerd.
Het eerste risico is een onvolledig apparatenregister. Zero trust functioneert alleen als elke entiteit die toegang vraagt, bekend en geclassificeerd is. Organisaties onderschatten structureel het aantal onbeheerde apparaten, IoT-sensoren en serviceaccounts dat niet in het initiële inventarisatieproces wordt meegenomen. Gartner stelde in 2022 vast dat minder dan 1% van de grote ondernemingen in 2023 een volwassen zero-trust programma had, juist door deze implementatiecomplexiteit.
Het tweede risico is beleidsexplosie. In een zero-trust model worden toegangsrechten per identiteit, per applicatie en per context gedefinieerd. Zonder een geautomatiseerde policy-as-code aanpak groeien beleidssets snel onbeheersbaar. Het gebruik van tools zoals Open Policy Agent (OPA) om beleid als versiebeheerde code te beheren, beperkt dit risico.
Het derde risico is de legacy-kloof. Oudere toepassingen ondersteunen geen OIDC of mTLS. Voor die systemen zijn tussenoplossingen nodig, zoals een authenticerende reverse proxy (bijvoorbeeld OAuth2 Proxy) voor webapplicaties of een service mesh voor microservices. Deze tussenlagen moeten zelf ook worden opgenomen in het zero-trust model, anders vormen ze de zwakste schakel.
Een gefaseerde aanpak die begint met identiteitsconsolidatie in Keycloak, vervolgens microsegmentatie uitrolt voor de meest kritieke systemen, en pas daarna legacy-applicaties adresseert, is operationeel beheersbaar en sluit aan bij de fasering die ENISA aanbeveelt in de Zero Trust Guidelines 2023.
FAQ
Kan zero trust on-premise worden geïmplementeerd zonder enige clouddienst?
Ja. Met tooling zoals Keycloak voor identity management, OpenZiti voor netwerkoverlap en HashiCorp Vault voor geheimenbeheer is een volledig lokale zero-trust stack mogelijk. Het controlevlak, de certificate authority en de policy engine draaien dan uitsluitend op eigen infrastructuur.
Wat is het verschil tussen zero trust en traditionele perimeterbeveiliging?
Perimeterbeveiliging gaat ervan uit dat alles binnen het netwerk vertrouwd is. Zero trust kent geen vertrouwde zone: elke verbinding, elk apparaat en elke gebruiker wordt continu geverifieerd, ongeacht netwerklocatie. Dit beperkt de schade bij een inbraak aanzienlijk, omdat laterale beweging wordt geblokkeerd door microsegmentatie en beleidshandhaving per sessie.
Voldoet een zero-trust architectuur automatisch aan NIS-2 artikel 21?
Niet automatisch. NIS-2 artikel 21 lid 2 sub e vereist concrete maatregelen voor netwerk- en systeembeveiliging, waaronder segmentatie en toegangsbeheer. Zero trust levert de technische basis, maar organisaties moeten ook aantoonbaar beleid, logging, toegangsbeoordelingen en incidentrespons documenteren die bij een audit beschikbaar zijn.
Hoe lang duurt een migratie van perimeterbeveiliging naar zero trust gemiddeld?
Een gefaseerde migratie voor een middelgrote overheidsorganisatie duurt doorgaans twee tot vier jaar. De eerste fase, identiteits- en apparaatbeheer centraliseren, is in zes tot twaalf maanden haalbaar. Microsegmentatie en volledige beleidshandhaving vereisen meer tijd vanwege legacy-systemen en de noodzaak tot uitgebreide inventarisatie.
Is OpenZiti geschikt voor productieomgevingen bij overheidsorganisaties?
OpenZiti wordt actief doorontwikkeld onder de Apache 2.0-licentie en wordt ingezet in kritieke omgevingen. Voor overheidstoepassing is een gedegen security review, een formeel patchbeleid en bij voorkeur een ondersteund enterprise-distributiekanaal vereist om aantoonbaar aan BIO2-eisen te voldoen. Bespreek met uw CISO welke audittrail en supportgaranties noodzakelijk zijn voor uw risicocategorie.
