Zero Trust eenvoudig uitgelegd: ZTNA in plaats van klassieke VPN
Zero Trust betekent niet dat niemand meer wordt vertrouwd. Het betekent dat toegang niet meer breed wordt verleend alleen omdat een gebruiker zich in het interne netwerk, in de VPN of op een bekende locatie bevindt. Elke toegang wordt bewust gecontroleerd: wie krijgt toegang? Vanaf welk apparaat? Tot welke applicatie? Onder welke voorwaarden?
Zero Trust Network Access, kort ZTNA, is een concrete toepassing van dit idee voor remote access en private applicaties. In plaats van een volledig netwerk via VPN te openen, krijgt een gebruiker alleen toegang tot de applicaties of resources die bij zijn rol horen.
Dit artikel legt de basis bewust leveranciersneutraal uit. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access en andere oplossingen passen vergelijkbare principes op verschillende manieren toe. De eerste keuze is daarom niet het product, maar het toegangsmodel.
Zero Trust en ZTNA plaatsen
Zero Trust is een beveiligingsarchitectuur. ZTNA is een technisch toegangspad binnen die architectuur.
Zero Trust is een principe
Klassieke netwerken werken vaak met een stille aanname: binnen is betrouwbaarder dan buiten. Die aanname is vandaag gevaarlijk. Gebruikers werken mobiel, applicaties staan in SaaS, datacenter en cloud, apparaten wisselen voortdurend van locatie en gecompromitteerde credentials zijn realistisch.
Zero Trust verschuift de focus van netwerkgrenzen naar identiteit, apparaat, applicatie, data en context. NIST beschrijft Zero Trust als een architectuur die impliciet vertrouwen vermindert en toegang per aanvraag beoordeelt. In de praktijk is een succesvolle login alleen niet meer genoeg.
ZTNA is toegang tot concrete resources
ZTNA vervangt brede netwerktoegang door resourcegebaseerde toegang. Een gebruiker ziet niet automatisch een volledig subnet, maar alleen de applicaties waarvoor een policy past.
Typische ZTNA-resources zijn:
- interne webapplicaties,
- adminportalen,
- RDP- of SSH-toegang via gecontroleerde paden,
- individuele TCP-applicaties,
- ontwikkel-, support- of partnertoegang,
- SaaS-applicaties met extra toegangscontrole.
Daarmee wordt remote access fijner te sturen. Een gecompromitteerd account mag niet meteen het hele interne netwerk kunnen bereiken.
Waarom ZTNA anders is dan VPN
VPN is niet automatisch slecht. Veel omgevingen hebben nog steeds site-to-site VPN, admin-VPN, speciale protocollen of noodtoegang nodig. Het verschil zit in het vertrouwensmodel.
VPN opent vaak een netwerk
Een klassieke remote access VPN verbindt een apparaat met een intern netwerk. Daarna bepalen routing, firewallregels, DNS en segmentatie wat bereikbaar is. Als de omgeving netjes is gebouwd, kan dat werken. In de praktijk zijn VPN-netwerken vaak te breed, historisch gegroeid of lastig te controleren.
Typische risico’s zijn:
- Gebruikers krijgen toegang tot meer systemen dan nodig.
- Oude VPN-groepen blijven bestaan.
- Split tunnel, DNS en routes zijn onduidelijk.
- Malware op een VPN-client kan interne doelen bereiken.
- Admin-toegang gebruikt dezelfde tunnel als gebruikerstoegang.
ZTNA controleert dichter bij de applicatie
ZTNA beslist per applicatie of resource. Een policy kan gebruikersgroep, MFA, apparaat, locatie, risico, clientstatus en andere voorwaarden meenemen. Pas als de voorwaarden kloppen, wordt toegang tot precies die resource toegestaan.
Dat verkleint het aanvalsoppervlak, maar vervangt geen veilige applicatieontwikkeling. Een onveilige applicatie blijft onveilig, ook achter ZTNA. ZTNA controleert de toegang, niet automatisch de applicatie zelf.
Bouwstenen van een goede Zero Trust-omgeving
Zero Trust is zwak als het alleen als nieuwe toegangstool wordt ingevoerd. De waarde ontstaat pas wanneer meerdere bouwstenen bij elkaar passen.
Identiteit en MFA
Identiteit is het belangrijkste startpunt. Gebruikers, groepen, rollen en externe accounts moeten netjes worden onderhouden. MFA moet verplicht zijn voor kritieke toegang. In Microsoft-omgevingen is Microsoft Entra ID vaak de centrale identiteitsbron; in andere omgevingen kunnen andere Identity Providers dezelfde rol vervullen.
Ook offboarding is belangrijk. Wanneer een gebruiker het bedrijf verlaat, moet toegang niet alleen in één applicatie verdwijnen, maar in de centrale identiteit en alle relevante policies.
Apparaat en context
ZTNA wordt sterker wanneer niet alleen de gebruiker, maar ook het apparaat wordt beoordeeld. Afhankelijk van de oplossing kunnen besturingssysteem, apparaatstatus, certificaat, EDR-status, beheerstatus, locatie of risico meewegen.
Dit is vooral relevant voor:
- privéapparaten,
- externe dienstverleners,
- geprivilegieerde admin-toegang,
- toegang tot finance-, HR- of productiesystemen,
- apparaten zonder actuele beschermingsstatus.
Gateway, connector of clouddienst
ZTNA heeft een datapad nodig tussen gebruiker en applicatie. Afhankelijk van de aanbieder zijn er gateways, connectors, tunnels of cloud-PoPs. Dit onderdeel bepaalt waar verkeer binnenkomt, wie het datapad beheert en welke DNS-, certificaat- en firewallregels nodig zijn.
Cloudflare werkt vaak met Cloudflare Tunnel en Access Policies. Sophos ZTNA gebruikt Sophos Central, ZTNA Gateways en resource policies. De architectuur verschilt, maar de basisvraag blijft gelijk: hoe komt een gebruiker gecontroleerd bij de applicatie zonder het hele netwerk te openen?
Policies, logging en beheer
Een ZTNA-policy moet later nog begrijpelijk zijn. Daarom moeten namen, groepen, voorwaarden en uitzonderingen worden gedocumenteerd. Logging is verplicht, omdat anders niet zichtbaar is of een policy te breed is, gebruikers worden geblokkeerd of toegang onverwacht vaak wordt gebruikt.
Wanneer ZTNA zinvol is
ZTNA past vooral goed wanneer individuele applicaties gecontroleerd bereikbaar moeten zijn. Het is geen doel op zich en geen automatische vervanging voor elke verbinding.
Goede use cases
ZTNA is meestal zinvol voor:
- interne webapplicaties voor medewerkers,
- partner- of dienstverlenertoegang,
- adminportalen die niet publiek bereikbaar mogen zijn,
- RDP of SSH via gecontroleerde toegangspaden,
- applicaties met duidelijke gebruikersgroepen,
- omgevingen waarin VPN-toegang te breed is geworden,
- stapsgewijze vervanging van oude remote access-modellen.
Voor externe dienstverleners is ZTNA vaak prettiger dan VPN. Er hoeft geen volledig netwerk te worden vrijgegeven; één concrete applicatie kan met een duidelijke policy worden gepubliceerd.
Waar VPN nog past
VPN blijft nuttig wanneer volledige netwerken verbonden moeten worden, wanneer speciale protocollen niet goed via ZTNA werken of wanneer noodtoegang onafhankelijk van clouddiensten nodig is. Site-to-site-verbindingen, sommige OT-omgevingen, legacy-applicaties en complexe admin-scenario’s kunnen nog steeds VPN vereisen.
De juiste vraag is dus niet: “VPN of ZTNA?” Beter is: “Welke resource heeft welk toegangspad nodig?”
Leveranciers neutraal beoordelen
ZTNA-oplossingen verschillen sterk. Sommige zijn erg goed voor browsergebaseerde applicaties, andere voor clientgebaseerde toegang en weer andere als onderdeel van een bredere SSE- of SASE-platform.
Belangrijke selectiecriteria
Voor de productkeuze moeten deze punten duidelijk zijn:
- Welke applicaties moeten bereikbaar zijn?
- Is browsertoegang, clienttoegang of beide nodig?
- Welke Identity Provider staat vast?
- Moeten apparaten posture-gebaseerd worden gecontroleerd?
- Waar loopt het datapad: eigen locatie, providercloud of beide?
- Hoe werken logs, SIEM-export en audit?
- Zijn nood- en break-glass-processen duidelijk?
- Hoe goed past de oplossing bij bestaande firewalls, EDR, MDM en DNS?
Cloudflare is vaak sterk wanneer Access, Tunnel, DNS, web security en globale edge-infrastructuur moeten samenwerken. Sophos ZTNA past vaak goed in omgevingen die al intensief Sophos Central, Sophos Endpoint of Sophos Firewall gebruiken. Dit is geen geloofskwestie, maar architectuurwerk.
Niet elke Zero Trust is automatisch beter
Slecht onderhouden ZTNA is alleen een moderner risico. Als groepen te breed zijn, oude uitzonderingen blijven bestaan, niemand logs leest of apparaatcontrole alleen op papier bestaat, ontstaat geen sterke Zero Trust-omgeving.
Invoeren in verstandige volgorde
Een goede invoering begint niet met de productklik, maar met een kleine, goed begrepen applicatie.
- Applicaties inventariseren en op risico sorteren.
- Gebruikersgroepen en externe rollen opschonen.
- Identity Provider en MFA stabiliseren.
- Een pilotapplicatie kiezen die belangrijk maar beheersbaar is.
- Datapad, DNS, certificaat en logging plannen.
- Policy met een kleine gebruikersgroep testen.
- Logs controleren, supportcases verzamelen en gebruikerservaring verbeteren.
- Verdere applicaties stap voor stap migreren.
- VPN-toegang pas verminderen wanneer ZTNA operationeel werkt.
Voor Sophos-specifieke omgevingen is Sophos ZTNA instellen: overzicht en volgorde de volgende stap. Als het concreet om de gateway gaat, helpt Sophos ZTNA Gateway plannen en maken.
Typische fouten
ZTNA behandelen als puur VPN-vervangingsproject
Als alleen de tunnel wordt vervangen, maar groepen, applicaties, apparaten en logs gelijk blijven, is de beveiligingswinst klein. ZTNA moet per resource worden gepland.
Te veel applicaties tegelijk migreren
Een grote big-bang-rollout is riskant. Beter is een pilot met een echte applicatie, duidelijke succescriteria en een schoon fallback-pad.
Noodtoegang vergeten
Identity Provider, DNS, clouddienst of gateway kunnen uitvallen. Admins hebben gedocumenteerde break-glass-toegang nodig die sterk beschermd, zelden gebruikt en regelmatig gecontroleerd wordt.
Logs niet beheren
ZTNA zonder logging is moeilijk te ondersteunen. Men moet kunnen zien welke gebruiker welke resource benadert, welke policy geldt, waarom toegang werd geblokkeerd en of ongebruikelijke patronen ontstaan.
Operationele checklist
- Applicaties en owners documenteren.
- Gebruikersgroepen klein en begrijpelijk houden.
- MFA afdwingen voor kritieke toegang.
- Apparaatcontrole actief gebruiken als de oplossing dit netjes ondersteunt.
- Policies regelmatig tegen werkelijk gebruik controleren.
- Logs naar SIEM of centrale logging sturen als toegang kritisch is.
- Break-glass-toegang documenteren en testen.
- Oude VPN-rechten verwijderen na succesvolle migratie.
- Dienstverlenertoegang voorzien van vervaldatum of reviewdatum.