Zero trust soevereine architectuur: principes en implementatie

Een zero trust soevereine architectuur is een beveiligingsmodel waarbij geen enkel netwerkknooppunt, gebruiker of toepassing standaard wordt vertrouwd, gecombineerd met de eis dat alle componenten van die architectuur uitsluitend onder de juridische en technische controle van de eigen organisatie vallen. Dat laatste onderscheidt een soevereine implementatie fundamenteel van een cloudgebaseerde zero trust aanpak waarbij identiteitscontrole en beleidshandhaving zijn uitbesteed aan partijen die onder buitenlandse rechtsmacht vallen.

Kernprincipes van NIST SP 800-207 en de soevereine afwijking

NIST SP 800-207, gepubliceerd in 2020 door het National Institute of Standards and Technology, is het meest gehanteerde referentiekader voor zero trust architectuur. Het document beschrijft zeven basisprincipes, waaronder continue verificatie van elke toegangsaanvraag, minimale toegangsrechten per sessie en dynamische beleidshandhaving op basis van actuele contextdata.

Scott Rose, hoofdauteur van NIST SP 800-207, stelt: “Zero trust is geen product dat je koopt, maar een strategie die je implementeert op basis van verificatie van elke toegangsaanvraag, ongeacht de herkomst.” Die formulering is bewust technologieneutraal. Het framework schrijft niet voor waar de policy decision point (PDP) of de policy enforcement point (PEP) draaien. Dat is precies de opening die organisaties benutten voor een soevereine variant.

Een cloudgebaseerde zero trust implementatie, zoals Google BeyondCorp als referentiemodel heeft laten zien, centraliseert identiteitsbeheer en beleidscontrole in een cloudplatform. BeyondCorp verving het traditionele VPN door contextuele toegangsbeslissingen op basis van apparaatcertificaten en gebruikersidentiteit, maar de PDP draait in Googles eigen infrastructuur. Voor een Europese overheidsinstelling of advocatenkantoor dat gevoelige dossiers beheert, introduceert dat een jurisdictierisico: de Amerikaanse CLOUD Act verplicht Amerikaanse aanbieders om op rechtelijk bevel data te overhandigen, ook wanneer die data in Europa is opgeslagen.

Een soevereine zero trust architectuur verplaatst de PDP, de identity provider, de certificaatautoriteit en alle logbestanden naar infrastructuur die uitsluitend onder de eigen rechtsmacht valt, bijvoorbeeld een on-premise server of een datacenter in Zwitserland met een Zwitserse rechtspersoon als beheerder. NIST SP 800-207A, de implementatiegids uit 2023, biedt concrete architectuurpatronen voor deze hybride en volledig on-premise scenario’s.

On-premise componenten zonder externe identiteitsaanbieders

Een volledige zero trust stack kan worden gebouwd zonder enige afhankelijkheid van Microsoft, Google of andere Amerikaanse aanbieders. De sleutelcomponenten zijn vervangbaar door open-source alternatieven die volledig zelfbeheerd kunnen worden ingezet.

OpenZiti verdient bijzondere aandacht voor gereguleerde sectoren. Het platform implementeert software-defined networking met wederzijdse TLS-authenticatie per verbinding. Elke verbinding vereist een geldig identiteitscertificaat dat wordt uitgegeven door de eigen certificaatautoriteit. Er is geen centraal cloudnetwerk bij betrokken. De broncode is volledig openbaar en auditeerbaar, wat aansluit bij de transparantie-eisen die toezichthouders steeds vaker stellen.

Integratie met NIS-2 zorgplicht en dataclassificatie

NIS-2 artikel 21 legt essentiële en belangrijke entiteiten een expliciete zorgplicht op voor technische en organisatorische beveiligingsmaatregelen. De richtlijn noemt concreet: toegangscontrolebeleid, netwerksegmentatie, encryptie en incidentdetectie. Een zero trust soevereine architectuur adresseert al deze punten in samenhang.

ENISA benadrukt in haar Zero Trust Guidelines dat organisaties moeten uitgaan van een vijandig netwerk: “Organisaties moeten ervan uitgaan dat netwerken per definitie vijandig zijn en dat interne segmentatie zonder continue verificatie een illusie van veiligheid biedt.” Die aanname ligt ten grondslag aan het dataclassificatiebeleid dat NIS-2 impliciet vereist.

Praktisch betekent dit dat dataclassificatielagen worden vertaald naar toegangsbeleid in de beleidsengine. Een document geclassificeerd als “vertrouwelijk” mag bijvoorbeeld alleen worden geopend vanaf een beheerd apparaat met een geldig apparaatcertificaat, via een versleuteld OpenZiti-kanaal, door een gebruiker die zich de afgelopen vier uur heeft geauthenticeerd via de interne Keycloak-instantie met meerfactorauthenticatie. Die beleidsregel wordt gehandhaafd door de PEP, ongeacht of de gebruiker zich binnen of buiten het kantoor bevindt.

Voor de NIS-2-audittrail genereert elke toegangsbeslissing een logbericht dat lokaal wordt opgeslagen en niet via externe SIEM-diensten wordt gerouteerd. Dat is essentieel: wanneer logdata naar een Amerikaans cloudsysteem stroomt, vallen die logs ook onder de CLOUD Act.

Micro-segmentatie en policy enforcement in een Nextcloud-omgeving

Nextcloud Hub fungeert als het samenwerkingsplatform in een soevereine werkplek, maar de zero trust beveiligingslaag bestaat uit infrastructuur die om Nextcloud heen wordt gebouwd. De volgende stappen beschrijven een concrete implementatievolgorde.

Stap 1: netwerksegmentatie op hypervisorniveau. Alle servers worden geplaatst in afzonderlijke netwerksegmenten: een segment voor de Nextcloud-applicatielaag, een segment voor de databaselaag, een segment voor de identity provider en een beheerderssegment. Firewallregels staan uitsluitend noodzakelijk verkeer toe tussen segmenten, gedefinieerd als allowlist, niet als blocklist.

Stap 2: OpenZiti als overlay-netwerk. Clients verbinden niet rechtstreeks met Nextcloud, maar via een OpenZiti-tunnel die per sessie een nieuw certificaat vereist. Nextcloud zelf is niet bereikbaar vanaf het publieke internet, ook niet via een traditionele VPN. Dit elimineert een aanvalsoppervlak dat bij veel organisaties onbewust open staat.

Stap 3: Keycloak als centrale identiteitsbron. Nextcloud, OpenZiti en alle overige diensten authenticeren via dezelfde Keycloak-instantie met OpenID Connect. Rollen in Keycloak worden direct vertaald naar Nextcloud-groepen en toegangsrechten. Wanneer een medewerker de organisatie verlaat, volstaat het deactiveren van het Keycloak-account om alle toegang tegelijk te beëindigen.

Stap 4: Open Policy Agent als beleidsengine. OPA evalueert bij elke toegangsaanvraag de combinatie van gebruikersidentiteit, apparaatstatus, tijdstip en gevraagde resource. Beleidsregels worden geschreven in de OPA-eigen taal Rego en worden versiebeheerd als code, wat auditability en reproduceerbare naleving van NIS-2 artikel 21 mogelijk maakt.

Bescherming tegen insider threats en lateral movement

Ransomware-aanvallen verlopen in 2023 steeds vaker via lateral movement: na initiële toegang tot één systeem verspreiden aanvallers zich door het netwerk om zo veel mogelijk data te versleutelen. Volgens het ENISA Threat Landscape 2023 werd lateral movement ingezet in meer dan 70 procent van de geanalyseerde ransomware-incidenten.

Tegelijk blijft de insider threat een onderschat risico. Een medewerker met brede toegangsrechten kan bewust of onbewust grote hoeveelheden data exfiltreren. IBM rapporteerde in de Cost of a Data Breach Report 2023 dat 82 procent van de datalekken betrekking had op data in cloudomgevingen, en dat organisaties met een volledig uitgerolde zero trust architectuur gemiddeld 1,76 miljoen dollar minder schade leden per incident dan organisaties zonder zero trust.

Een zero trust soevereine architectuur beperkt beide risico’s via hetzelfde mechanisme: geen impliciete vertrouwensrelaties. Een geïnfecteerd eindpunt kan geen verbinding leggen met een databasesegment, omdat het geen geldig sessiecertificaat bezit voor dat segment. Een kwaadwillende medewerker kan niet buiten zijn eigen geautoriseerde resources, omdat OPA elke aanvraag op resourceniveau evalueert. Detectie van afwijkend gedrag vindt lokaal plaats via de SIEM die is gekoppeld aan de OpenZiti-logs en de Keycloak-audittrail.

Migratie van Microsoft 365 naar een soevereine werkplek

Een migratie van Microsoft 365 naar een Nextcloud-gebaseerde soevereine werkplek is geen puur technische operatie, maar vereist een gedocumenteerde architectuurkeuze die aansluit bij het zero trust beleid. De juridische grondslag voor de migratie, de risicoanalyse van de huidige Microsoft 365-omgeving en het nieuwe toegangsbeheerbeleid worden vastgelegd voordat de eerste data wordt verplaatst.

Tijdens de migratie worden bestaande Microsoft-identiteiten overgebracht naar Keycloak, inclusief groepsindeling en rolstructuur. Bestanden worden gemigreerd via versleutelde kanalen naar de eigen Nextcloud-instantie, waarbij de classificatie van documenten wordt gehandhaafd als metadata. Na de migratie wordt de Microsoft 365-tenant gedeactiveerd, wat ook de CLOUD Act-blootstelling van die data elimineert.

De combinatie van Nextcloud als platform, OpenZiti als netwerktoegangslaag, Keycloak als identity provider en OPA als beleidsengine vormt een volledig soevereine zero trust architectuur die voldoet aan de NIS-2 zorgplicht, GDPR-vereisten over verwerkingslocaties en de beveiligingsprincipes van NIST SP 800-207 en NIST SP 800-207A, zonder enige afhankelijkheid van partijen die onder de CLOUD Act of de Patriot Act vallen.

Veelgestelde vragen

Kan een zero trust architectuur volledig on-premise worden ingezet, zonder enige cloudafhankelijkheid?

Ja. Componenten zoals een zelfbeheerde identity provider (bijvoorbeeld Keycloak), een interne certificate authority, een open-source ZTNA-oplossing zoals OpenZiti en een firewalllaag met micro-segmentatie kunnen allemaal on-premise draaien. De NIST SP 800-207-principes schrijven geen cloudgebruik voor.

Wat is het verschil tussen een soevereine zero trust implementatie en een implementatie via Microsoft Entra of Okta?

Bij Microsoft Entra of Okta liggen identiteitsdata en beleidscontrole buiten de organisatie, bij een cloudaanbieder die onder de Amerikaanse CLOUD Act valt. Een soevereine implementatie draait de volledige policy decision point en policy enforcement point binnen de eigen juridische controlesfeer, waardoor geen derde partij toegang kan eisen zonder medeweten van de organisatie.

Hoe draagt zero trust bij aan NIS-2-naleving?

NIS-2 artikel 21 vereist onder meer toegangscontrole, netwerksegmentatie en incidentdetectie. Zero trust adresseert al deze punten structureel: continue authenticatie vervangt verouderde perimeterbescherming, micro-segmentatie beperkt de impact van incidenten, en gedetailleerde logs voorzien in de audittrail die toezichthouders verwachten.

Hoe voorkomt zero trust lateral movement bij een ransomware-aanval?

Doordat elke verbinding per sessie opnieuw wordt geverifieerd en netwerksegmenten strikt van elkaar zijn gescheiden, kan malware die één eindpunt infecteert niet automatisch communiceren met andere segmenten. Zonder geldig certificaat of token wordt de verbinding geweigerd door de policy enforcement point, wat de uitbraak inperkt tot het gecompromitteerde segment.

Is OpenZiti geschikt voor een Nextcloud-omgeving in een gereguleerde sector?

OpenZiti biedt een volledig open-source, zelfbeheerde zero trust network access-laag die voor Nextcloud kan worden ingezet zonder externe afhankelijkheden. Organisaties in gereguleerde sectoren kunnen de broncode auditen, de infrastructuur in eigen beheer houden en voldoen aan GDPR-eisen over dataverwerkingslocaties.