Zero trust soevereine cloud verwijst naar een beveiligingsarchitectuur waarbij geen enkele gebruiker, apparaat of netwerkverbinding automatisch wordt vertrouwd, gecombineerd met dataopslag die juridisch en fysiek buiten het bereik valt van extraterritoriale wetgeving zoals de Amerikaanse CLOUD Act. Voor compliance officers en IT-beslissers in gereguleerde sectoren is deze combinatie geen luxe maar een noodzaak, zeker nu NIS-2 en de bijbehorende Implementing Regulation (EU) 2024/2690 concrete technische verplichtingen opleggen.
Waarom zero trust het juiste model is bij een migratie weg van Big Tech
De klassieke perimeter-aanpak, waarbij alles binnen het bedrijfsnetwerk als veilig wordt beschouwd, is fundamenteel onverenigbaar met hybride werkomgevingen en soevereine cloudopslag. Zero trust, zoals gedefinieerd in NIST SP 800-207 Zero Trust Architecture, vervangt dit door het principe: verifieer altijd, vertrouw nooit, en beperk toegang tot het absolute minimum dat een taak vereist.
Scott Rose en medeauteurs van NIST SP 800-207 formuleren het als volgt: “Zero trust is geen product dat je koopt, maar een strategie die je uitvoert. De kern is: ga er altijd van uit dat een breach al heeft plaatsgevonden.”
Bij een migratie weg van Microsoft 365 of Google Workspace naar een soevereine Nextcloud-omgeving vervalt de gecentraliseerde identiteitslaag die de hyperscaler leverde. Dat is geen zwakte, maar een kans: je kunt nu een identiteitsinfrastructuur bouwen die volledig onder eigen beheer staat, zonder dat een Amerikaanse provider op grond van de CLOUD Act verplicht kan worden je gegevens te verstrekken aan Amerikaanse autoriteiten.
“Organisaties moeten aannemen dat hun netwerk al gecompromitteerd is en toegang tot resources uitsluitend verlenen op basis van continue verificatie van identiteit, apparaat en context.” (ENISA, Zero Trust Guidance)
Statistisch onderbouwt dit de urgentie: volgens het Verizon Data Breach Investigations Report 2023 had 74% van alle datalekken een menselijke factor, waaronder misbruik van gestolen inloggegevens. Zero trust adresseert dit direct door elke sessie opnieuw te verifiëren, ook voor interne gebruikers.
Zero trust en NIS-2: overlap en aanvulling
NIS-2 (Richtlijn (EU) 2022/2555) en de uitvoeringsverordening (EU) 2024/2690 leggen via artikel 21 concrete technische maatregelen op: toegangsbeheersing, netwerksegmentatie, monitoring en incidentrespons. Zero trust levert het architecturele raamwerk om al deze eisen tegelijk te adresseren.
| NIS-2 vereiste (art. 21 / Reg. 2024/2690) | Zero trust-principe (NIST SP 800-207) | Praktische maatregel |
|---|---|---|
| Toegangsbeheersing en authenticatie | Verificatie van identiteit bij elke aanvraag | MFA, continue sessiebeoordeling via IAM |
| Netwerksegmentatie | Microsegmentatie per workload | Software-defined networking, policy engines |
| Continue monitoring | Inspectie en logging van alle verkeersstromen | SIEM, anomaliedetectie, auditlogs |
| Beveiliging toeleveringsketen | Geen impliciet vertrouwen voor externe partijen | Contractuele en technische verificatie leveranciers |
Voor Nederlandse overheidsorganisaties geldt bovendien de BIO2 (Baseline Informatiebeveiliging Overheid versie 2), die van toepassing is op Rijk, provincies, gemeenten en waterschappen. De technische eisen in BIO2 overlappen sterk met zowel NIS-2 als NIST SP 800-207, waardoor een gecombineerde implementatie efficiënter is dan twee separate trajecten.
ENISA rapporteerde in 2023 dat ransomware en datadiefstal samen goed zijn voor meer dan 50% van alle cyberdreigingen gericht op Europese organisaties (ENISA Threat Landscape 2023). Een zero trust-architectuur beperkt de laterale beweging van aanvallers na een initiële compromittering, wat dit risico direct reduceert.
Concrete implementatiestappen voor hybride en soevereine omgevingen
Een volledig zero trust-model bereik je niet in één stap. NIST SP 1800-35 (Implementing a Zero Trust Architecture) beschrijft een gefaseerde aanpak die ook voor hybride on-premise en co-locatieomgevingen geschikt is.
Fase 1: inventarisatie en beleidsdefinitie
Begin met een volledige inventarisatie van alle assets, gebruikers, datastromen en vertrouwensrelaties. Stel per categorie een toegangsbeleid op dat het principe van minimale privileges (least privilege) afdwingt. Documenteer dit in een formeel Zero Trust Policy Framework dat aansluit op de risicoklassifficatie uit NIS-2 artikel 21.
Fase 2: identiteits- en toegangsbeheer zonder externe providers
De kern van zero trust is een robuuste IAM-laag. In een soevereine omgeving zonder afhankelijkheid van Microsoft Entra ID of Google Identity implementeer je een eigen identity provider. Open standaarden als OpenID Connect en OAuth 2.0 zijn daarvoor de aangewezen basis. Open-source implementaties zoals Keycloak of Authentik ondersteunen deze standaarden volledig en draaien on-premise of in een door jou beheerde co-locatie.
Koppel hieraan hardware-gebaseerde eindpuntverificatie via certificaten (mTLS) en apparaatbeheer via een Mobile Device Management-systeem dat ook on-premise kan draaien. Zo weet de policy engine bij elke toegangspoging niet alleen wie de gebruiker is, maar ook of het apparaat voldoet aan de beveiligingseisen.
Fase 3: microsegmentatie en netwerkbeleid
Segmenteer het netwerk tot op het niveau van individuele workloads, niet alleen op VLAN-niveau. Gebruik software-defined networking of host-gebaseerde firewalls om oost-westverkeer (intern verkeer tussen servers) te beperken tot wat expliciet is toegestaan. Dit voorkomt dat een aanvaller die één systeem compromitteert, zich zijwaarts door de omgeving kan bewegen.
Fase 4: continue monitoring en respons
Implementeer centrale logging van alle authenticatie-events, toegangsverzoeken en beleidsafwijkingen. Koppel dit aan een SIEM-oplossing die je zelf beheert, zoals Wazuh of OpenSearch Security Analytics. Stel drempelwaarden in voor automatische alerting en koppel incidentresponsprocessen aan de meldplicht onder NIS-2.
Valkuilen en vendor lock-in bij zero trust-tooling
Een veelgemaakte fout is het kopen van een “zero trust-platform” van één leverancier, waarna alle beleidslogica, identiteitsbeheer en monitoring in die propriëtaire omgeving terechtkomen. Dit vervangt afhankelijkheid van Microsoft door afhankelijkheid van een andere commerciële partij, zonder de onderliggende juridische of technische soevereiniteitsrisico’s weg te nemen.
Gebruik in plaats daarvan een architectuur op basis van open standaarden: OpenID Connect voor federatieve identiteit, OAuth 2.0 voor autorisatie, en open beleidsengines zoals Open Policy Agent (OPA) voor toegangscontrole. Zo blijft de architectuur leveranciersonafhankelijk en migreerbaar.
Een tweede valkuil is het gelijktijdig willen implementeren van alle zero trust-componenten. De ENISA Zero Trust Guidance adviseert uitdrukkelijk een gefaseerde aanpak waarbij organisaties beginnen met de hoogste risico’s en meest kritieke systemen, en daarna stapsgewijs uitbreiden. Dit voorkomt dat een complex implementatietraject vastloopt.
Documentatie en auditbewijs voor NIS-2-inspecties
Toezichthouders die NIS-2 handhaven, verwachten geen perfecte techniek maar aantoonbaar beleid, continue verbetering en adequate documentatie. De Implementing Regulation (EU) 2024/2690 specificeert dat organisaties technische en organisatorische maatregelen moeten kunnen aantonen, inclusief de risicobeoordeling die tot die maatregelen heeft geleid.
Bouw je auditdossier op uit de volgende componenten: het Zero Trust Policy Framework (inclusief versiegeschiedenis), toegangsmatrixen per rol en systeem, logboeken van authenticatie- en autorisatiegebeurtenissen, resultaten van periodieke penetratietests, en verslagen van interne audits en managementreviews. NIST SP 1800-35 biedt een auditsjabloon dat je direct kunt gebruiken als basis voor dit dossier.
Koppel dit aan een formele risicoclassificatie per asset en een aantoonbare incidentrespons-oefening. Toezichthouders beoordelen niet alleen of je maatregelen hebt, maar ook of je organisatie in staat is adequaat te reageren wanneer een incident plaatsvindt.
FAQ: zero trust soevereine cloud en NIS-2
Is zero trust hetzelfde als een VPN of firewall?
Nee. Een VPN of firewall verleent toegang tot een netwerksegment zodra je eenmaal bent ingelogd. Zero trust verleent nooit standaard vertrouwen op basis van netwerklocatie, maar verifieert elke toegangspoging opnieuw op basis van identiteit, apparaatstatus en context.
Kan een organisatie zero trust implementeren zonder cloudafhankelijkheid van Microsoft of Google?
Ja. Zero trust is een architectuurmodel, geen productmerk. Met open standaarden zoals OpenID Connect en OAuth 2.0, gecombineerd met on-premise identity providers zoals Keycloak of FreeIPA, bouw je een volledige zero trust-omgeving zonder afhankelijkheid van Amerikaanse hyperscalers.
Welke NIS-2 artikelen verplichten concreet tot zero trust-maatregelen?
NIS-2 zelf noemt zero trust niet bij naam, maar artikel 21 verplicht onder meer tot toegangsbeheersing, netwerksegmentatie en continue monitoring. De Implementing Regulation (EU) 2024/2690 werkt deze verplichtingen technisch uit en sluit nauw aan bij de zero trust-principes van NIST SP 800-207.
Hoe bewijs je zero trust-compliance bij een NIS-2-inspectie?
Via een combinatie van beleidsdocumentatie, technische logboeken, toegangsmatrixen, resultaten van penetratietests en aantoonbare beleids- en auditcycli. ENISA en NIST SP 1800-35 geven beide concrete auditsjablonen en meetcriteria die je direct kunt gebruiken als bewijslast.
Geldt de BIO2 alleen voor de Rijksoverheid of ook voor gemeenten en provincies?
De BIO2 geldt voor alle Nederlandse overheidslagen: Rijk, provincies, gemeenten en waterschappen. Organisaties die onder zowel BIO2 als NIS-2 vallen, kunnen de zero trust-eisen uit beide kaders grotendeels gecombineerd implementeren, omdat de technische vereisten sterk overlappen.
