Toegangscontrolelijsten vormen al tientallen jaren de ruggengraat van netwerkbeveiliging. Op elke router en switch in uw omgeving staan er waarschijnlijk tientallen. Maar de netwerken waarvoor ze ontworpen waren, vaste kantoren met voorspelbare verkeersstromen, bestaan niet meer. Gebruikers zwerven tussen thuis, bijkantoren en klantlocaties. Applicaties bevinden zich in meerdere clouds. Apparaten die nooit een IP-stack hebben gehad, bevinden zich nu op uw netwerk.
Deze gids legt uit hoe ACL’s werken, waar ze nog zinvol zijn en waarom IT-teams die hybride omgevingen beheren statische regelsets vervangen door identiteitsgebaseerde toegangsbeleidsregels. Als je honderden ACL regels gebruikt op meerdere locaties en moeite hebt om ze accuraat te houden, dan biedt dit artikel een praktische oplossing.
Hoe over te stappen van statische ACL’s naar identiteitsgebaseerde toegang
- Controleer je huidige ACL en markeer regels die gekoppeld zijn aan systemen of gebruikers die uit gebruik zijn genomen.
- Classificeer resterende regels op functie: perimeterfiltering, interne segmentatie of toegang tot toepassingen.
- Bewaar ACL’s voor basishygiëne op routers en switches.
- Vervang toegangsregels voor applicaties door Zero Trust Network Access-beleidsregels die zijn gekoppeld aan de identiteit van de gebruiker en de toestand van het apparaat.
- Consolideer interne segmentatie in één beleidsconsole met centrale registratie.
- Stel verweesde en schaduwregels gefaseerd buiten gebruik, te beginnen met de minst kritieke segmenten.
Wat is een toegangscontrolelijst in netwerken?
Een ACL is een verzameling regels op een router of switch die beslist of een gegevenspakket wordt toegestaan of geweigerd. Wanneer verkeer op een netwerkinterface komt, controleert het apparaat elke regel in volgorde, van boven naar beneden. De eerste regel wint: het apparaat stuurt het pakket door of laat het vallen en slaat alles daaronder over. Als geen enkele regel overeenkomt, wordt het verkeer standaard geblokkeerd door een impliciete weigering onderaan.
Deze sequentiële, deny-by-default logica is de basis van traditionele netwerksegmentatie. Een veelvoorkomend voorbeeld is het scheiden van een Wi-Fi gastnetwerk van interne servers, zodat een gecompromitteerd gastapparaat niet bij je bestandshares of ERP-systeem kan komen.
De criteria die ACL’s evalueren
| Criterium | Wat het controleert | OSI-laag |
|---|---|---|
| Bron IP-adres | Waar het pakket vandaan komt | Laag 3 (netwerk) |
| Bestemming IP-adres | Waar het pakket naartoe gaat | Laag 3 (netwerk) |
| Type protocol | TCP, UDP, ICMP of andere transportprotocollen | Laag 3/4 |
| Poortnummers | Specifieke servicepoorten, bijv. 443 voor HTTPS, 22 voor SSH | Laag 4 (transport) |
Deze vier parameters geven netwerkbeheerders een basis gereedschapskist om verkeer te filteren. Het probleem is dat ze alle vier statische eigenschappen van een pakkethoofding zijn. Geen enkele vertelt je wie het verkeer verstuurt, of hun apparaat veilig is, of welke applicatie ze eigenlijk proberen te bereiken.
Drie soorten traditionele ACL’s
Niet alle ACL’s bieden dezelfde mate van controle. Het begrijpen van de verschillen is belangrijk wanneer je beslist welke regels je moet behouden en welke je moet vervangen.
Standaard ACL’s
Standaard ACL’s filteren verkeer alleen op basis van het bron IP adres. Ze zijn snel en licht, maar bot. Een standaard ACL kan geen onderscheid maken tussen webverkeer en SSH vanaf hetzelfde IP-adres, dus het laat alles van die bron toe of blokkeert het. In oudere Cisco-omgevingen gebruiken deze genummerde bereiken 1-99.
Uitgebreide ACL’s
Uitgebreide ACL’s voegen IP, protocol en poortnummers van de bestemming toe aan de evaluatie. Hierdoor kun je nauwkeurige regels schrijven zoals “sta SSH toe van het admin werkstation naar de database server op poort 22, weiger al het andere”. Uitgebreide ACL’s geven veel fijnere controle maar introduceren ook meer complexiteit. Elke extra parameter is weer iets om fout te doen.
ACL’s op naam
ACL’s met een naam vervangen cryptische nummerreeksen door beschrijvende labels. In plaats van “ACL 101” krijg je “FINANCE-TO-ERP” of “GUEST-WIFI-RESTRICT”. Dit verbetert de leesbaarheid, vooral in omgevingen met honderden regels op meerdere apparaten. ACL’s met een naam zijn de huidige standaard in moderne netwerkapparatuur, maar de onderliggende logica blijft hetzelfde: statische regels die van boven naar beneden worden geëvalueerd.
Waarom ACL’s niet werken op schaal
ACL’s werken goed in kleine, stabiele netwerken. De problemen beginnen wanneer je omgeving groeit, gebruikers mobiel worden en IP adressen geen betrouwbare identificatiemiddelen meer zijn.
Regelophoping en menselijke fouten
Elke keer als er een nieuwe applicatie wordt gelanceerd, een teamlid van rol verandert of een aannemer tijdelijke toegang nodig heeft, voegt iemand ACL regels toe. In de loop van maanden en jaren zorgt dit voor een overdaad aan regels. Drie specifieke problemen duiken herhaaldelijk op.
Rule shadowing gebeurt wanneer een brede toestemmingsregel hoger in de lijst een meer specifieke weigeringsregel eronder overschrijft. De specifieke regel vuurt nooit af, maar blijft in de configuratie staan, wat een vals gevoel van controle creëert. Verweesde regels zijn entries voor gebruikers, servers of subnetten die niet langer bestaan. Ze veroorzaken geen directe schade, maar ze vormen allemaal een onnodig toegangspad dat een aanvaller zou kunnen misbruiken. Complexiteitsgaten ontstaan wanneer overlappende regels op meerdere apparaten het bijna onmogelijk maken om te traceren wat er eigenlijk is toegestaan van begin tot eind.
Als je ACL’s beheert op tien routers van bijkantoren met elk meer dan 200 regels, dan kan alleen al de auditlast dagen werk per kwartaal kosten.
IP-adressen zijn niet langer betrouwbare identificatiemiddelen
Traditionele ACL’s gaan ervan uit dat een IP adres overeenkomt met een bekend apparaat op een bekende locatie. Die aanname hield stand toen iedereen werkte vanaf een bureau op kantoor. Dit geldt niet wanneer dezelfde werknemer ’s ochtends vanuit huis verbinding maakt met een DHCP toegewezen adres, ’s middags vanuit een hotel en tussendoor vanaf een mobiele hotspot. Cloud workloads maken dit nog erger: virtuele machines schalen op en af, pikken nieuwe adressen op en verdwijnen weer, soms binnen enkele minuten.
Het onderhouden van ACL’s voor dit soort omgevingen betekent constante handmatige updates. Als je er één mist, blokkeer je legitieme gebruikers of laat je een gat achter waar een aanvaller doorheen kan lopen.
Geen context, geen intelligentie
Een ACL ziet een pakkethoofding. Het weet niet of de persoon achter het bron IP een financieel manager is of een stagiair. Het weet niet of het apparaat een gepatcht besturingssysteem gebruikt of een drie jaar oude versie met bekende kwetsbaarheden. Het weet niet of dit verzoek om toegang routine is of een teken dat een account gecompromitteerd is.
Dit gebrek aan context maakt ACL’s ontoereikend als primaire beveiligingscontrole in hybride en cloudomgevingen.
Het echte risico: zijwaartse beweging na initiële toegang
Statische ACL’s zijn ontworpen om aanvallers buiten de perimeter te houden. Maar de perimeter is niet waar de meeste schade gebeurt. Het echte probleem is wat er gebeurt nadat een aanvaller binnenkomt.
Een phishing e-mail belandt in de inbox van een werknemer. Ze klikken op een link en de aanvaller krijgt voet aan de grond op een enkel werkstation. Met een VPN of een plat intern netwerk heeft dat werkstation vaak brede toegang tot gedeelde schijven, interne applicaties en andere segmenten. Er bestaan interne ACL’s, maar die zijn geschreven om zakelijk verkeer mogelijk te maken, niet om een indringer in te sluiten. De aanvaller beweegt zich zijdelings, verzamelt referenties en bereikt gevoelige systemen zonder ACL-weigeringen te veroorzaken, omdat hij dezelfde toegestane paden gebruikt als legitieme gebruikers.
Dit is geen theoretisch scenario. Het is de operationele realiteit achter de meeste ransomware-incidenten. Netwerksegmentatie helpt de ontploffingsradius te beperken, maar alleen als het granulair genoeg is en continu wordt onderhouden. Traditionele op ACL gebaseerde segmentatie voldoet in de praktijk zelden aan die norm.
Van statische regels naar identiteitsgebaseerde toegang
De verschuiving weg van IP-centrische ACL’s gaat niet over het volledig afschaffen ervan. Routers hebben nog steeds elementaire pakketfiltering nodig. De verschuiving gaat over het verplaatsen van toegangsbeslissingen op applicatieniveau van statische regelsets naar dynamisch, identiteitsbewust beleid.
Wat verandert er met toegang op basis van identiteit
| Kenmerk | Statische laag 3 ACL | Op identiteit gebaseerde toegang |
|---|---|---|
| Primaire identificator | IP-adressen en subnetten | Gebruikers, rollen en apparaten |
| Flexibiliteit | Laag, handmatige updates vereist | Hoog, beleid past zich dynamisch aan |
| Contextbewustzijn | Geen | Locatie, gedrag, apparaatstatus |
| Beheerbaarheid op schaal | Degradeert snel | Centraal beheerd |
| Beveiligingsmodel | Perimeter-gebaseerd | Nul vertrouwen |
Met toegang op basis van identiteit zegt een beleid “leden van het financiële team, op beheerde apparaten die voldoen aan de posture-controles, mogen toegang krijgen tot de factureringsapplicatie”. Dat beleid volgt de gebruiker ongeacht zijn IP-adres, locatie of netwerksegment. Als een apparaat de posture check niet doorstaat, wordt de toegang geweigerd voordat het verkeer de applicatie bereikt.
De rol van ZTNA in het vervangen van ACL-gebaseerde toegang tot applicaties
Zero Trust Network Access is het praktische mechanisme voor deze verschuiving. In plaats van netwerkpaden te openen en te hopen dat ACL’s granulair genoeg zijn, publiceert ZTNA individuele applicaties aan geauthentiseerde, geautoriseerde gebruikers. Het netwerk zelf wordt onzichtbaar voor iedereen die niet geslaagd is voor identiteitsverificatie en apparaatstatuscontroles.
Dit elimineert het probleem van “brede netwerktoegang” dat VPN’s en ACL-afhankelijke architecturen plaagt. Een gebruiker die zich authentiseert om de facturatie-app te bereiken, kan de HR-database niet zien of bereiken, zelfs als beide zich op hetzelfde fysieke netwerk bevinden. Elke applicatie is zijn eigen microsegment, beheerst door beleid in plaats van pakketfilters.
Een praktisch migratiepad voor IT-teams
Van de ene op de andere dag elke ACL eruit halen is niet realistisch en ook niet aan te raden. De migratie werkt het beste in fasen die snelle voordelen opleveren en tegelijkertijd de operationele risico’s beperken.
Fase 1: controleren en classificeren
Haal je ACL-configuraties van alle routers, switches en firewalls. Deel elke regel in in een van de drie emmers: perimeterfiltering (behouden), interne segmentatie (consolideren) of toegang tot toepassingen (vervangen). Markeer verweesde regels en schaduwregels om ze onmiddellijk op te ruimen. Deze stap alleen al verwijdert vaak 20-30% van het aantal regels.
Fase 2: identiteitsgebaseerde toegang introduceren voor hoogwaardige toepassingen
Kies twee of drie applicaties die momenteel afhankelijk zijn van ACL-gebaseerde toegang, idealiter applicaties met duidelijke gebruikersgroepen en een grote zakelijke impact. Publiceer ze via ZTNA met identiteitsverificatie en apparaatstatuscontroles. Voer zowel het oude ACL-pad als het nieuwe ZTNA-pad parallel uit voor een wijzigingscyclus en schakel de ACL-regels uit zodra de gebruikers zijn gemigreerd.
Fase 3: uitbreiden naar agentless en industriële apparaten
Printers, IoT-sensoren en industriële apparatuur kunnen geen agents uitvoeren, wat precies de reden is waarom ze vaak op vlakke netwerksegmenten zitten met brede ACL-vergunningen. Zet NIAC-hardware in om deze apparaten te isoleren en hun verkeersstromen te regelen zonder hun firmware aan te raken. Dit creëert een veilige brug tussen IT- en OT-omgevingen zonder de productie te verstoren.
Fase 4: segmentatie consolideren in één console
Vervang de lappendeken van ACL’s per apparaat door gecentraliseerd beleidsbeheer. Eén console voor ZTNA, Secure Web Gateway en SD-WAN betekent één plek om beleidsregels te definiëren, logs te bekijken en compliance aan te tonen. Voor teams die meerdere sites beheren, is dit waar de operationele tijdsbesparing aanzienlijk wordt.
Fase 5: ACL’s alleen behouden waar ze horen
Basis pakketfiltering op randrouters, regels voor bescherming van de infrastructuur voor beheerinterfaces en controle op protocolniveau op switches hebben nog steeds baat bij ACL’s. Bewaar deze, documenteer ze duidelijk en herzie ze op een vast schema. Al het andere, vooral toegangsbeslissingen op applicatieniveau, zouden in je identiteitsgebaseerde beleidslaag moeten zitten.
Veelgemaakte fouten tijdens migratie
ACL-logica repliceren in ZTNA. Als uw eerste ZTNA beleidsregels uw oude subnet-gebaseerde regels weerspiegelen, dan hebt u niets veranderd behalve de tool. Definieer beleidsregels per toepassing en rol, niet per IP-bereik.
Apparaathouding overslaan. Identiteit alleen is niet genoeg. Een gecompromitteerd apparaat met geldige referenties is nog steeds een risico. Vereisen een beheerde apparaatstatus, huidige OS-versies en schijfversleuteling als minimale houdingssignalen.
Negeren van agentloze apparaten. Printers en IoT endpoints zijn de apparaten die het meest waarschijnlijk op permissieve ACL regels zitten. Isoleer ze met inline hardware die toestaan van verkeersstromen afdwingt.
Poging tot een enkele cutover. Faseer de migratie per applicatie en gebruikersgroep. Met parallel draaien kun je randgevallen opvangen voordat ze uitvallen.
Hoe Jimber de overgang vereenvoudigt
Jimber levert Real SASE in één platform dat door de cloud wordt beheerd en vervangt de lappendeken van ACL’s, VPN’s en punttools door uniforme, identiteitsgebaseerde beveiliging.
ZTNA biedt toegang per applicatie met identiteitsverificatie en controle van de apparaatstatus, waardoor brede ACL-regels op netwerkniveau niet meer nodig zijn. Secure Web Gateway en Firewall-as-a-Service handelen het beleid voor webverkeer centraal af, zodat u geen afzonderlijke ACL-sets nodig hebt voor uitgaande filtering op elke site. SD-WAN verbindt vestigingen op een veilige manier zonder de MPLS-contracten en per-site firewallconfiguraties die traditioneel gepaard gaan met multi-locatie ACL-beheer.
Voor apparaten die geen agents kunnen draaien, biedt NIAC-hardware inline isolatie met default-deny gedrag. Printers, IoT-sensoren en industriële apparatuur krijgen gecontroleerde toegangspaden zonder handmatig ACL-onderhoud.
Alles wordt uitgevoerd vanaf één beheerconsole met transparante prijzen en API-first integratie. Voor MSP’s die meerdere klantomgevingen beheren, betekent de multi-tenant architectuur één platform in plaats van tientallen te onderhouden ACL-landgoederen per klant.
FAQ
Zijn ACL’s nog steeds relevant in moderne netwerken?
Ja, voor basis pakketfiltering op routers en switches. ACL’s blijven nuttig voor bescherming van de infrastructuur en controle op protocolniveau. Ze zijn niet langer voldoende als het primaire mechanisme voor toegang tot applicaties of interne segmentatie in hybride omgevingen.
Wat is het verschil tussen een ACL en ZTNA?
Een ACL filtert pakketten op basis van statische headervelden zoals IP-adres en poortnummer. ZTNA verleent toegang op basis van geverifieerde identiteit, apparaathouding en toepassingscontext. ZTNA werkt op de applicatielaag en past zich dynamisch aan, terwijl ACL’s vaste regels zijn die handmatig moeten worden bijgewerkt.
Kan ik ACL’s en ZTNA parallel uitvoeren?
Ja, en dit is de aanbevolen aanpak tijdens de migratie. Houd ACL’s actief op oudere segmenten terwijl u geleidelijk applicaties publiceert via ZTNA. Schakel ACL-regels per applicatie uit zodra ZTNA-toegang is bevestigd en stabiel is.
Hoe helpt identiteitsgebaseerde toegang bij NIS2-compliance?
NIS2 vereist aantoonbaar toegangsbeheer, handhaving van de laagste rechten en het indammen van incidenten. Identiteitsgebaseerd beleid met centrale registratie biedt duidelijk bewijs van wie wat wanneer en vanaf welk apparaat heeft benaderd. Dit is moeilijk te realiseren met gedistribueerde ACL configuraties over meerdere netwerkapparaten.
Hoe zit het met apparaten die geen ZTNA agent kunnen draaien?
Printers, IoT-sensoren en industriële controllers hebben inline isolatie nodig. NIAC-hardware bevindt zich tussen het apparaat en het netwerk en dwingt toegestane verkeersstromen af zonder dat hiervoor software op het apparaat zelf nodig is. Dit brengt agentless apparatuur onder Zero Trust controle.
Hoe lang duurt een typische migratie voor een organisatie in het middensegment?
De meeste teams kunnen de eerste twee fasen, het auditen van ACL’s en het publiceren van initiële applicaties via ZTNA, binnen vier tot zes weken afronden. Een volledige migratie van alle applicaties en sites neemt doorgaans drie tot zes maanden in beslag, afhankelijk van het aantal legacy systemen en agentless apparaten.
Statische ACL’s vervangen door identiteitsgebaseerde toegang
Klaar om over te stappen van handmatig regelbeheer naar één beleidsconsole? Boek een demo en ontdek hoe Jimber de overgang van ACL’s naar identiteitsgebaseerde ZTNA praktisch maakt voor jouw team.
