Je kunt ZTNA neerzetten, een policy engine ophangen en nog steeds nauwelijks zero trust doen. Meestal komt dat niet doordat de techniek tekortschiet, maar doordat niemand scherp heeft gemaakt welke rollen echt bestaan en wat eigenlijk gevoelig of kritisch is.
Zero trust klinkt vaak technisch, maar het grootste deel van de kwaliteit zit vóór de techniek. Zodra classificatie en rollen vaag blijven, wordt beleid automatisch wollig. Dan krijg je regels als “finance mag erbij”, “IT moet overal kunnen”, “leveranciers soms ook” en “de rest via uitzonderingen”. Dat is geen fijnmazige controle, dat is oud toegangsbeheer in een nieuw jasje.
Daarom vind ik classificatie en rollen geen randvoorwaarde voor later, maar het begin van het gesprek. Anders kun je wel toegangsbeslissingen automatiseren, maar niet uitleggen waarom ze logisch zijn.
Als je niet kunt uitleggen welke data of applicatie waarom gevoelig is en welke rol daarom welke toegang nodig heeft, dan voeg je met zero-trust-tooling meestal vooral extra complexiteit toe.
Wat ik met classificatie bedoel
Niet per se een enorm classificatieprogramma met eindeloze labels. Wel genoeg onderscheid om beleid op te bouwen. In de praktijk gaat het vaak al mis als alles impliciet dezelfde zwaarte krijgt. Dan worden publieksportals, beheerinterfaces, klantdata, HR-informatie, SaaS-documenten en testomgevingen op ongeveer dezelfde manier behandeld, terwijl de impact van misbruik totaal anders is.
Referentiemodellen zoals FIPS 199 en NIST SP 800-60 zijn daarbij best bruikbaar, juist omdat ze dwingen om naar impact te kijken: wat betekent verlies van vertrouwelijkheid, integriteit of beschikbaarheid hier eigenlijk? Je hoeft die modellen niet letterlijk te kopiëren, maar de gedachte erachter helpt enorm.
Wat ik met rollen bedoel
Een rol is voor mij geen willekeurige AD-groep die ooit is blijven hangen. Een rol is een leesbare beschrijving van werk en verantwoordelijkheden. Helpdesk, netwerkbeheer, externe leverancier, HR-medewerker, finance controller, applicatiebeheerder, ontwikkelaar, SOC-analist: dat soort logische eenheden dus.
Pas daarna wordt het interessant om te verfijnen met attributen. Bijvoorbeeld: alleen vanaf beheerde devices, alleen tijdens een change window, alleen naar een specifieke app, alleen als de sessie geen datadownload toelaat. Dan kom je dicht bij hoe zero trust hoort te werken: expliciet, conditioneel en uitlegbaar.
Waarom het anders zo snel misloopt
- Policies worden te generiek. Dan kan bijna niemand uitleggen waarom iets geblokkeerd of toegestaan is.
- Uitzonderingen groeien sneller dan beleid. Omdat de basis te grof is, moet alles later met handwerk worden rechtgetrokken.
- ZTNA wordt een doorgeefluik. Je zet techniek vóór een applicatie, maar het toegangsmodel zelf blijft hetzelfde.
- CASB krijgt geen richting. Je ziet wel apps en data, maar weet niet goed welke sessies of acties echt anders behandeld moeten worden.
Dat is ook waarom ik liever eerst een klein, bruikbaar classificatiekader maak dan meteen te veel beleid in tooling probeer te gieten.
Hoe ik dit meestal aanpak
- Begin met een beperkt domein. Bijvoorbeeld één kritieke SaaS-app, één beheervlak of één set interne applicaties.
- Bepaal wat daar gevoelig is. Denk aan persoonsgegevens, financiële data, beheerfuncties of bedrijfskritieke processen.
- Benoem de echte rollen. Niet alle historische groepen, maar de rollen die je later ook aan business en audit kunt uitleggen.
- Vertaal dat naar voorwaarden. Welk device, welke sessie, welke locatie, welke downloadrechten, welke tijdvakken?
- Pas daarna techniek kiezen. ZTNA voor appgerichte toegang, CASB voor SaaS- en databeleid, of beide waar het logisch samenkomt.
Waarom dit ook helpt bij AVG, NIS2 en ISO 27001
Niet omdat die normen exact voorschrijven hoe jouw zero-trust-model eruit moet zien, maar omdat ze allemaal impliciet vragen om hetzelfde soort volwassenheid: weten wat belangrijk is, toegang beperken, keuzes kunnen verantwoorden en maatregelen kunnen beheren.
- AVG duwt je richting minimale toegang en passende bescherming rond persoonsgegevens.
- NIS2 verwacht serieuzere risicobeheersing en bestuurlijke grip op beveiligingsmaatregelen.
- ISO 27001 helpt om rollen, beleid, reviews en continue verbetering eromheen te organiseren.
Classificatie en rollen zijn dan ook niet alleen technisch handig, maar ook bestuurlijk gezond.
Een praktisch voorbeeld
Neem een organisatie waar medewerkers via Microsoft 365, een HR-systeem en een paar interne beheerportalen werken. Zonder classificatie is “SaaS-toegang” al snel één brede categorie. Zonder rollen blijft “IT” één groot blok. Het gevolg: te brede toegang, veel uitzonderingen voor downloads en nauwelijks verschil tussen gebruikers die vooral lezen en gebruikers die mogen beheren.
Met een simpele classificatie kun je al onderscheid maken tussen algemeen samenwerken, persoonsgegevens, financiële gegevens en beheervlakken. Met rollen kun je daarna bepalen wie alleen mag raadplegen, wie mag wijzigen, wie beheert en wie alleen tijdelijk toegang krijgt. Pas dán wordt CASB of ZTNA echt scherp in plaats van cosmetisch.
Verder lezen in deze zero-trust-reeks
- Bekijk de zero-trust-hub
- Zero trust begint niet met een tool
- CASB wordt interessant zodra je data, SaaS en shadow AI serieus neemt
Conclusie
Zero trust zonder classificatie en rollen klinkt modern, maar blijft meestal te vaag om echt goed te sturen. Dan groeit beleid scheef, nemen uitzonderingen het over en wordt tooling vooral een extra laag bovenop oud gedrag.
Als je eerst scherp krijgt wat belangrijk is en wie waarom toegang nodig heeft, wordt zero trust ineens een stuk minder theoretisch en veel beter uitvoerbaar.