Zero Trust voorbij de marketing: een werkbare architectuur
Zero Trust is inmiddels zo vaak herhaald dat het bijna niets meer zegt. Iedere firewall-leverancier heeft het in zijn whitepaper staan. Toch is het model achter de hype solide, als je het losmaakt van de marketing.
Het uitgangspunt is simpel: vertrouw niets, verifieer alles. Een gebruiker op het interne netwerk krijgt geen automatisch vertrouwen. Een laptop die lid is van het domein ook niet. Elke toegangspoging wordt opnieuw beoordeeld op basis van identiteit, apparaatstaat en context.
Dat klinkt logisch, maar in de praktijk vereist het keuzes. Hieronder de drie pijlers die je concreet moet inrichten.
Pijler 1: identiteit
Elke toegangspoging begint met de vraag: wie is dit, en klopt dat op dit moment?
Dat betekent minimaal multi-factor authenticatie voor alle accounts, inclusief service accounts waar mogelijk. Maar MFA alleen is niet genoeg. Je wilt ook conditionals: een gebruiker die inlogt vanuit een onbekend land om 3 uur ‘s nachts krijgt een andere behandeling dan iemand die gewoon op kantoor werkt.
Microsoft Entra ID (voorheen Azure AD) doet dit via Conditional Access-beleid. Je definieert signalen (locatie, apparaatstatus, risicoscore, app gevoeligheid) en koppelt daar acties aan (blokkeren, extra verificatie, beperkte sessie). Het werkt goed als je diep in het Microsoft-ecosysteem zit.
Buiten Microsoft is er geen echte concurrent die dit niveau van conditionals biedt voor enterprise-schaal, maar Okta en Ping Identity komen in de buurt voor organisaties die vendor-neutraal willen blijven.
Pijler 2: apparaten
Een gebruiker mag je kunnen vertrouwen; diens laptop hoeft dat niet.
In een Zero Trust-model controleer je of een apparaat voldoet aan je beveiligingsbeleid voordat je toegang verleent. Dat heet device compliance: is de schijf versleuteld, draait er een goedgekeurde antivirus, zijn patches actueel?
Microsoft Intune koppelt dit direct aan Conditional Access. Een apparaat dat niet compliant is, krijgt geen toegang tot bedrijfsdata, ongeacht wie erachter zit. Voor managed bring-your-own-devices kun je app-bescherming zonder volledig beheer inschakelen via MAM-beleid.
Google BeyondCorp hanteert hetzelfde principe maar via Chrome Enterprise en de BeyondCorp Enterprise-proxy. Het werkt goed in Google Workspace-omgevingen, maar is moeilijker te integreren als je veel legacy Windows-applicaties hebt.
Pijler 3: netwerk
Het traditionele perimetermodel gaat ervan uit dat alles achter de firewall veilig is. Zero Trust gooit dat idee weg.
In de praktijk betekent dit twee dingen. Ten eerste: segmenteer je netwerk zo dat een gecompromitteerd systeem niet zomaar lateraal kan bewegen. Micro-segmentatie op basis van werklasten, niet op basis van VLAN-grenzen.
Ten tweede: vervang je VPN door een Zero Trust Network Access-oplossing (ZTNA). Een VPN geeft een gebruiker toegang tot het netwerk. ZTNA geeft toegang tot een specifieke applicatie, op basis van identiteit en apparaatstatus, zonder dat de gebruiker het netwerk ziet.
Cloudflare Access is hier een sterke optie, zeker voor organisaties met veel SaaS en web-apps. Je plaatst Cloudflare voor je applicaties en definieert per app wie toegang heeft. Voor on-premises apps werkt het via een connector die een uitgaande tunnel opzet, zonder inkomende poorten te openen.
Waar Zero Trust tekortschiet
Zero Trust werkt goed voor moderne, webgebaseerde applicaties. Voor legacy-apps is het een ander verhaal.
Een ERP-systeem uit 2008 dat draait op een eigen protocol begrijpt geen OIDC, geen SAML, geen moderne authenticatieflows. Je kunt er een proxy voor zetten, maar dat is een pleister. De onderliggende authenticatie blijft zwak.
Organisaties met veel on-premises infrastructuur en legacy-applicaties lopen hier constant tegenaan. Zero Trust als volledig model is dan niet haalbaar op korte termijn. Wat je dan doet: je pakt de hoogste risico’s aan (admin toegang, internet-facing systemen, gevoelige data) en bouwt stap voor stap.
Hoe begin je
Het meest praktische startpunt is identiteit. Rol MFA uit voor alle accounts, zet Conditional Access-beleid op voor je kritische applicaties, en blokkeer legacy authenticatieprotocollen (Basic Auth, NTLM waar mogelijk).
Stap twee is apparaatbeheer: zorg dat je weet welke apparaten toegang hebben en of ze compliant zijn. Dat alleen al haalt een groot deel van het aanvalsoppervlak weg.
Netwerksegmentatie en ZTNA zijn stap drie, en die vereisen meer architectuurwerk. Begin daar niet mee als stap één en twee nog niet op orde zijn.
Wil je dit onderbouwen met een certificering of training? Kijk dan naar Zero Trust en security-architectuurtrainingen.