Veel teams praten over segmentatie alsof het vooral een ontwerpvraag is. In de praktijk gaat het vaker mis op iets anders: te weinig zicht op het landschap, oude aannames die als waarheid blijven hangen en uitzonderingen die later het hele model krom trekken. Dan ziet een segmentatietekening er misschien netjes uit, maar bouw je verder op informatie die al niet meer klopt.
Voor mij begint segmentatie daarom niet bij een VLAN-lijst of een bestaande policy. Het begint bij inzicht. Wat staat er eigenlijk, wat hoort functioneel bij elkaar, welke paden zijn echt nodig en hoe ver komt een aanvaller als één segment geraakt wordt? Als je dat niet scherp hebt, kies je bijna vanzelf te breed of juist veel te fijnmazig.
Netwerksegmentatie loopt meestal niet als eerste stuk op het ontwerp, maar op gebrek aan actueel inzicht, oude segmentatie die als startpunt wordt misbruikt en uitzonderingen die later beheer en policy vervuilen. Segmentatie begint voor mij met lezen, niet met tekenen.
Segmentatie begint niet bij je bestaande policy
Dat is een fout die ik vaak terugzie. Teams pakken de huidige policy of bestaande segmentatie erbij en behandelen die alsof het al een bruikbaar fundament is. Maar die laag is meestal gebouwd op oude informatie, tijdelijke keuzes en uitzonderingen die ooit logisch leken. Als je daarop doorbouwt, neem je de scheefgroei gewoon mee naar de volgende ronde.
Een bestaande policy kan best nuttig zijn als bron van vragen. Niet als bron van waarheid. Ik wil eerst weten waarom iets nu bij elkaar staat, of dat nog steeds klopt en welke logs of verkeerspatronen dat onderbouwen.
Te breed en te fijnmazig zijn dezelfde fout
De ene kant is te breed segmenteren. Dan gooi je teveel systemen bij elkaar en blijft het aanvalsoppervlak onnodig groot. De andere kant is microsegmentatie als reflex. Dat klinkt strak, maar wordt operationeel snel duur als je voor elk klein ding weer apart beleid, uitzonderingen en beheerlast organiseert.
De uitdaging zit dus niet in maximaal opdelen. De uitdaging is een vorm vinden die logisch genoeg is om risico kleiner te maken en simpel genoeg om later nog te beheren.
Werk op doeleinde, niet op gewoonte
Ik probeer segmentatie altijd te lezen vanuit functie en doeleinde. Wat hoort functioneel bij elkaar en wat juist niet? Domain controllers kunnen prima samen in een logisch segment passen. Een RDS-server hoort daar voor mij niet automatisch naast, ook al praat die er veel mee. Dat zijn andere rollen, andere risico’s en vaak ook andere redenen om verkeer toe te staan.
Daarom begin ik meestal met de standaard vragen. Wie praat met wat? Waarom? Hoe vaak? Vanaf waar? Is dat structureel of historisch gegroeid? En welke logs, flows of andere signalen laten zien dat dat beeld ook echt klopt?
Segmentatie gaat over aanvalsoppervlak, niet alleen over netheid
De echte test is voor mij vrij simpel: als dit segment geraakt wordt, hoe ver komt een aanvaller dan nog? Dát is waar segmentatie waarde krijgt. Niet omdat de tekening mooier wordt, maar omdat je beweging begrenst en afhankelijkheden explicieter maakt.
Als je teveel bij elkaar gooit, zie je ook minder. Verkeer blijft dan vaak rechtstreeks en ruim toegestaan tussen systemen die je liever wat harder had begrensd. Dan bouw je later wel policy erbovenop, maar de basis is al te plat. En juist die basis bepaalt hoeveel grip je daarna nog kunt krijgen.
Waarom platte netwerken mij weinig rust geven
Ik kom nog vaak omgevingen tegen waar een plat netwerk of een handvol VLANs als “lekker beheersbaar” wordt verdedigd. Alsof meer segmenten automatisch onnodig ingewikkeld zijn omdat je dan vaker moet patchen, poorten moet herconfigureren of beter moet nadenken over beleid. Daar zit natuurlijk een kern van waarheid in: segmentatie vraagt beheerdiscipline. Maar dat is voor mij geen reden om het dan maar vlak te houden.
In deze tijd kun je niet meer doen alsof het interne netwerk per definitie vertrouwd is. Aanvallers komen niet alleen van buiten. Ze komen ook via endpoints, accounts, tooling, leveranciers en dingen die ooit als veilig zijn weggezet. Juist daarom wil ik dat de basis al begrenst wat er kan bewegen.
Waar teams zich vaak op verkijken
- ze beginnen met een tekening voordat ze het landschap echt gelezen hebben;
- ze nemen oude segmentatie over zonder opnieuw te toetsen waarom iets bij elkaar staat;
- ze kiezen ofwel hele brede zones of duiken meteen richting microsegmentatie;
- ze behandelen uitzonderingen als restwerk in plaats van als signaal dat het model nog niet scherp genoeg is.
Daar gaat het voor mij meestal mis. Niet omdat segmentatie als idee fout is, maar omdat de onderbouwing te dun blijft en beheer daarna de rekening krijgt.
Mijn werkvolgorde
- Maak het landschap leesbaar. Verzamel de W-vragen, praat met beheerders en gebruik logs of flow-data om aannames te toetsen.
- Bepaal het doeleinde per groep systemen. Niet alleen wat technisch praat, maar wat functioneel echt bij elkaar hoort.
- Test de grens van elk segment. Past dit echt bij elkaar of hoort iets elders thuis?
- Kijk naar blast radius. Als dit segment geraakt wordt, welke beweging blijft dan nog mogelijk?
- Bouw daarna pas de policylaag uit. Dan is beleid een vertaling van een helder model en niet een pleister op oude rommel.
Mijn vuistregel
Eerst inzicht, dan segmentatie. Als ik nog niet goed kan uitleggen wat ik precies aan het begrenzen ben, ga ik ook nog niet doen alsof de segmentatie al logisch staat.
Verder lezen
- Bekijk alle artikelen over netwerksegmentatie op lumiosa.com
- Waarom remote access rommelig wordt zodra VPN, ZTNA en uitzonderingen naast elkaar blijven bestaan
- ZTNA vs VPN: wanneer is het echt de betere route?
- Begrippenlijst: zero trust, classificatie, ZTNA, CASB en meer
Conclusie
Goede segmentatie begint niet met een oude policy, een mooie tekening of de drang om meteen heel fijnmazig te worden. Het begint met scherp krijgen wat er staat, waarom dingen bij elkaar horen en hoe klein je het aanvalsoppervlak echt wilt maken zonder het beheer te slopen.
Ik heb liever een segmentatiemodel dat uitlegbaar en toetsbaar is dan een strak schema dat op oude aannames leunt. Want als de basis niet klopt, wordt de policylaag daarboven vanzelf ook troebel.