Veel segmentatietrajecten beginnen nog steeds op de verkeerde plek. Er wordt getekend, beleid wordt bedacht en VLANs worden verschoven, terwijl niemand eerst goed heeft uitgezocht wat er precies draait, welke applicatiepaden echt nodig zijn en welke afhankelijkheden je later alsnog terug de policy in trekken. Dan noem je het netwerksegmentatie, maar bouw je vooral verder op aannames.
Voor mij begint goede netwerksegmentatie daarom met classificatie. Niet als papieren exercitie, maar als manier om de omgeving leesbaar te maken. Wat is dit systeem eigenlijk, welk verkeer hoort er functioneel bij, hoe belangrijk is de data of dienst, en hoe ver kom je als dit onderdeel geraakt wordt? Pas als dat helder is, heeft begrenzen zin.
Netwerksegmentatie werkt pas echt als je eerst systemen classificeert, applicatiepaden en afhankelijkheden zichtbaar maakt en kijkt naar laterale beweging in plaats van alleen naar netheid. Zonder die stap giet je oude aannames rechtstreeks in nieuw beleid.
Een LAN is op papier misschien een segment, maar inhoudelijk zegt dat nog weinig
Dat is precies waar het vaak misgaat. Een VLAN, subnet of bestaande zone wordt behandeld alsof het al een logisch segment is. Maar zo’n grens vertelt op zichzelf weinig over functie, gevoeligheid of risico. Een handvol servers in hetzelfde netwerk kan nog steeds compleet verschillende rollen hebben, andere afhankelijkheden meenemen en een totaal andere blast radius veroorzaken.
Een domain controller, een managementserver en een applicatieserver zijn voor mij niet zomaar “drie servers in hetzelfde stuk netwerk”. Dat zijn drie verschillende rollen. Als je die te vroeg als één blok behandelt, voelt segmentatie misschien overzichtelijk, maar ben je vooral nuance aan het weggooien.
Classificatie is voor mij geen spreadsheet, maar een leesbril
Ik wil bij classificatie meestal drie dingen scherp hebben. Wat is dit object? Denk aan client, server, beheercomponent, identity-laag, IoT, OT, third party of SaaS-koppeling. Welk verkeer hoort er echt bij? Niet historisch, maar functioneel. En hoe gevoelig of kritisch is dit? Voor operatie, data en impact als het misgaat.
Die drie samen helpen meer dan alleen een technisch label. Want een fileserver met saaie kantoorbestanden vraagt iets anders dan een systeem waar identity op leunt. Een webapp die alleen via een broker bereikbaar hoort te zijn, vraagt iets anders dan een beheervlak waar admins nog breed bij moeten kunnen. Als je dat onderscheid niet eerst maakt, ga je later vanzelf corrigeren met uitzonderingen.
Teken eerst applicatiepaden, dan pas grenzen
Ik vertrouw segmentatie pas als iemand kan laten zien hoe een applicatie echt leeft. Welke gebruikers of systemen praten ermee, via welk pad, met welke afhankelijkheden, en of dat verkeer structureel is of gewoon ooit zo gegroeid. Dat hoeft niet meteen in een dure CMDB. Een whiteboard of mindmap is vaak al genoeg om de eerste scheefgroei zichtbaar te maken.
Juist daar vallen de eerste verrassingen eruit. Een applicatie die “alleen intern” lijkt, blijkt ineens afhankelijk van Entra ID, een externe API, een SaaS-platform, een package repo of een certificaatketen buiten je eigen datacenter. Dan kun je wel stoer segmenteren op interne netwerkgrenzen, maar het echte pad liep al veel breder.
Moderne edge sloopt oude segmentatie-aannames
De klassieke gedachte was overzichtelijk: users op kantoor, apps intern, verkeer noord-zuid door een firewall en klaar. Die tijd is gewoon voorbij. Nu heb je BYOD, thuiswerk, SaaS, third parties, Entra ID, brokers, reverse proxies en apparaten die half binnen en half buiten je eigen domein vallen. Dan is “intern” vaak meer een gevoel dan een technisch harde lijn.
Dat betekent niet dat segmentatie minder nuttig is. Juist niet. Het betekent dat je vooraf beter moet begrijpen waar je grens nu eigenlijk nog zin heeft. Soms ligt die tussen identities en apps. Soms tussen beheer en productie. Soms tussen managed en unmanaged devices. En soms blijkt een SaaS-koppeling operationeel kritischer dan een halve interne serverzone.
De afhankelijkheden die teams het vaakst vergeten
Ik zie bij dit soort trajecten steeds weer dezelfde blinde vlekken terug. Niet de hoofdapplicatie, maar de dingen eromheen die wel nodig zijn om het geheel werkend te houden.
- DNS en naamresolutie, intern en extern;
- domain controllers, LDAP, Kerberos en andere identity-afhankelijkheden;
- certificaatketens, OCSP of CRL-checks en TLS-verwachtingen;
- monitoring, logging en backupverkeer dat ineens ook een pad nodig heeft;
- package repositories, updatebronnen en externe API’s;
- jump hosts, beheervlakken en tooling voor leveranciers of third parties.
Als je die dingen niet vroeg zichtbaar maakt, zie je ze later terug als losse policy-uitzonderingen. En dan lijkt het alsof segmentatie ingewikkeld is, terwijl het probleem eigenlijk was dat de dependency-kaart te laat kwam.
Kijk niet alleen naar verkeer, maar naar laterale beweging
Voor mij is de belangrijkste vraag nog steeds simpel: als dit onderdeel geraakt wordt, hoe ver kom je dan nog? Dát is waar netwerksegmentatie waarde krijgt. Niet omdat het schema netter oogt, maar omdat je laterale beweging begrenst en beter kunt uitleggen wat er wel en niet mag doorslaan.
Daarom kijk ik liever naar blast radius per rol of keten dan naar een generiek netwerkplaatje. Een gecompromitteerde laptop, een overgenomen service-account of een kwetsbare applicatielaag geven allemaal een andere vorm van risico. Dat wil ik terugzien in hoe ik segmenteer. Anders bouw je één nette grens voor drie totaal verschillende problemen.
Mijn startpunt is meestal een whiteboard met rollen, paden en afhankelijkheden
Ik begin vaak klein. Pak één rol, bijvoorbeeld een domain controller, een kritieke applicatie of een beheervlak. Daaromheen zet ik wie ermee praat, wat ervoor nodig is en welke nevenpaden vaak vergeten worden. Pas daarna ga ik groeperen. Wat hoort logisch bij elkaar, wat juist niet, en waar zijn we verkeer aan het toestaan omdat het echt nodig is in plaats van omdat niemand het ooit heeft opgeruimd?
Die oefening klinkt simpel, maar hij doet precies wat nodig is. Hij haalt segmentatie uit de abstractie. Je ziet sneller of iets echt één keten is of een verzameling van gewoontes. En je merkt ook sneller waar een bestaande zone eigenlijk meerdere veiligheids- of beheerlagen door elkaar trekt.
Mijn werkvolgorde
- Classificeer eerst de objecten en rollen. Niet alles wat in hetzelfde subnet staat, hoort automatisch functioneel bij elkaar.
- Maak de echte applicatiepaden zichtbaar. Wie praat met wat, via welk pad, met welke identity- of SaaS-afhankelijkheden?
- Teken de dependencies mee. DNS, identity, certificaten, monitoring, backups, updates en externe API’s horen meteen op het bord.
- Kijk daarna pas naar grenzen en beleid. Dan segmenteer je op basis van begrip in plaats van op basis van hoop.
- Toets steeds op blast radius. Als dit geraakt wordt, hoeveel laterale beweging blijft er dan nog over?
Verder lezen
- Bekijk alle artikelen over netwerksegmentatie op lumiosa.com
- Waarom netwerksegmentatie vaak stukloopt op uitzonderingen en beheer, niet op het ontwerp
- ZTNA vs VPN: wanneer is het echt de betere route?
- Begrippenlijst: zero trust, classificatie, ZTNA, CASB en meer
Conclusie
Netwerksegmentatie begint voor mij niet met een policyset of een VLAN-plan. Het begint met classificatie, applicatiepaden en afhankelijkheden. Pas dan kun je eerlijk bepalen welke grens logisch is en welke vooral goed voelt op een slide.
Als je die voorbereiding overslaat, krijg je later vanzelf een verzameling uitzonderingen die oude aannames in leven houdt. Dan heb je misschien wel segmentatie op papier, maar nog steeds te weinig grip op het verkeer dat er echt toe doet.