SASE: de plek waar netwerk en security eindelijk volwassen samenwerken

Er komt een moment waarop je voelt dat het oude model niet meer klopt. Niet omdat het ooit “fout” was, maar omdat de wereld eromheen veranderd is. Jarenlang bouwden we netwerken alsof werk één vaste plek was. Alsof gebruikers ’s ochtends binnenkwamen via één deur (het kantoor), daar hun werk deden (het datacenter), en ’s avonds weer vertrokken. In dat beeld was security vooral een muur: stevig, zichtbaar, en gericht op het bewaken van een perimeter. Maar werk is allang geen gebouw meer. Werk is een activiteit. Mensen werken thuis, onderweg, bij klanten, in shared offices — en soms vanaf een campingtafel met matige wifi. Ondertussen verhuisden applicaties naar SaaS, data naar cloudplatformen en omgevingen naar hybride landschappen waar “binnen” en “buiten” eigenlijk verouderde begrippen zijn. Die realiteit vraagt om iets anders dan nóg een appliance, nóg een tunnel, of nóg een uitzonderingsregel. En precies daar past SASE. Niet als hype, maar als een volwassen antwoord op een volwassen probleem.

1. Wat SASE eigenlijk is (zonder marketingtaal)‍

SASE staat voor Secure Access Service Edge. Gartner definieert het als een geconvergeerde combinatie van netwerk- én security-capabilities als dienst: SD‑WAN, SWG, CASB, (NG)FW en ZTNA. Service-based, centraal geleverd en gericht op veilige toegang voor vestigingen, remote medewerkers en on‑premises omgevingen — met beleid gebaseerd op identiteit en context. In normale taal betekent dat eigenlijk dit: SASE verschuift de focus van “we beveiligen het netwerk” naar “we beveiligen de toegang tot applicaties en data, waar die ook staan, en waar de gebruiker ook is.”Belangrijk: SASE is niet één productdoos die je neerzet. Het is een architectuurbenadering die netwerk- en securityfunctionaliteit dichter bij de gebruiker brengt en centraal als dienst levert. Het effect is concreet: minder omwegen, minder losse oplossingen, en meer consistente policies.

2. Waarom het klassieke model kraakt (en soms breekt)

In het traditionele model trek je verkeer van gebruikers terug naar een centraal punt (datacenter of hoofdkantoor) via VPN of MPLS, waar het door securitylagen heen moet voordat het naar internet of de cloud mag. Dat werkte prima toen bijna alles intern stond. Maar zodra je belangrijkste applicaties SaaS zijn, voelt dit als elke dag dezelfde dure omweg maken: meer latency, hogere complexiteit, meer incidenten en meer frustratie bij gebruikers. Securityteams stapelen oplossingen: VPN-hier, proxy-daar, een half geïntegreerde CASB, een firewallcluster dat tegen z’n limieten aanloopt, en een logginglandschap dat op papier klopt maar in de praktijk gaten heeft. Het resultaat lijkt regelmatig eerder op archeologie dan architectuur: lagen uit verschillende periodes, verschillende leveranciers, verschillende policy‑modellen en uitzonderingen die ooit logisch waren maar inmiddels vooral risico’s vormen.

3. SASE probeert in de kern één vraag te beantwoorden:

Hoe geef ik gebruikers veilige, snelle en gecontroleerde toegang tot applicaties en data, zonder te doen alsof alles zich nog in één gebouw bevindt? Zero Trust: geen slogan, maar fundament. SASE en Zero Trust worden vaak samen genoemd — terecht. Als je netwerklocatie niet langer als primaire vertrouwensfactor beschouwt, heb je iets anders nodig om beslissingen op te baseren. NIST beschrijft Zero Trust als een paradigma waarin vertrouwen nooit impliciet is, maar continu wordt geëvalueerd. Niet het netwerksegment staat centraal, maar de resource die je wilt beschermen. In NIST SP 800-207 staat ook heel expliciet dat Zero Trust uitgaat van een netwerk dat als gecompromitteerd kan worden beschouwd, toegang wordt per verzoek en op basis van least privilege afgedwongen.

Wat ik daar zo sterk aan vind, is dat het de discussie volwassen maakt. Niet meer: “zit je op het interne netwerk, dan zal het wel goed zijn.” Maar: “wie ben je, wat is je device-status, waar vraag je om, wat is de gevoeligheid van de resource, en klopt het risicoprofiel op dit moment?” NIST maakt het ook praktisch door te werken met concepten zoals een Policy Decision Point en Policy Enforcement Point: je hebt een ‘brein’ dat beslist en een ‘poort’ die afdwingt. Dat klinkt technisch, maar het idee is intuïtief: beleid is alleen waardevol als het consistent, realtime en afdwingbaar is.

4. De bouwstenen van SASE, zonder het jargon te laten overheersen

Gartner en Cisco noemen onder andere:

• SWG – de moderne cloud-native webproxy
• CASB – grip op SaaS-gebruik en datastromen
• FWaaS – firewallfuncties vanuit de cloud, zonder individuele clusters
• ZTNA – de volwassen opvolger van VPN: toegang tot apps, niet tot netwerken
• SD-WAN – slim routeren, optimaliseren en verbinden van locaties

Laat me die onderdelen even “menselijk” maken:

Een Secure Web Gateway (SWG) is in feite de moderne opvolger van de webproxy: bescherming tegen webdreigingen en handhaving van webbeleid, maar dan cloud-native en dicht bij de gebruiker. Een CASB (Cloud Access Security Broker) draait om grip op SaaS-gebruik: welke apps worden gebruikt, welke data gaat waarheen, en welke policies horen daarbij. Het is de laag die shadow IT minder schimmig maakt.

Firewall as a Service (FWaaS) brengt firewall functionaliteit naar een cloudplatform, zodat je niet per se overal fysieke of virtuele firewalls hoeft te beheren om basisbescherming en segmentatie af te dwingen. ZTNA (Zero Trust Network Access) is misschien wel de meest tastbare vervanger van “de klassieke VPN”: je geeft geen brede netwerktoegang, maar gecontroleerde toegang tot specifieke applicaties op basis van identiteit, device posture en context. En SD-WAN is de netwerkpoot: slim kiezen van routes, performance verbeteren, en verbindingen tussen locaties en cloud optimaliseren, maar dan met beleid dat past bij moderne appstromen. De kracht zit niet in deze onderdelen afzonderlijk, want die bestonden al. De kracht zit in de samenhang: één beleid, één deliverymodel, één manier van afdwingen.

5. SASE vs. SSE: waarom dat onderscheid bestaat

Je hoort tegenwoordig ook vaak SSE: Security Service Edge. Dat is niet zomaar een ander woord, maar een expliciete afsplitsing. Gartner definieert SSE als het deel dat toegang beveiligt tot web, cloud services en private applicaties, met capabilities zoals access control, threat protection, data security, monitoring en acceptable-use control, vooral cloud-based geleverd. SSE (Security Service Edge) is de ‘security-helft’ van SASE. Zonder SD-WAN. Heb je al SD-WAN en wil je vooral je cloud security moderniseren? → SSE past. Heb je een versnipperd netwerklandschap en wil je én performance én security verbeteren? → SASE is logischer. Waarom is dat nuttig? Omdat niet elke organisatie hetzelfde startpunt heeft. Sommige organisaties hebben SD-WAN al staan en zoeken vooral modernisering van cloud security. Andere organisaties hebben juist een versnipperd netwerklandschap en willen én performance én security in één architectuurbenadering trekken. Het SSE/SASE-onderscheid helpt om het gesprek realistischer te maken: Het helpt organisaties om modulair te denken zonder de samenhang te verliezen.

6. Wat je wint met SASE (en wat niet automatisch wordt opgelost)

Ik ben altijd voorzichtig met beloftes als “SASE lost alles op”. Dat is niet eerlijk en ook niet nodig. De echte waarde zit meestal in drie gebieden. Ten eerste: consistente policies. Niet meer per locatie of per appliance andere regels, maar één centrale policy die overal geldt, omdat enforcement vanuit de cloud plaatsvindt. Ten tweede: betere gebruikerservaring. Als je security dichter bij de gebruiker brengt en niet al het verkeer onnodig terughaalt naar één centraal punt, daalt latency en stijgt stabiliteit. Dat is security die mensen minder vaak proberen te omzeilen. Ten derde: meer grip op cloud- en webverkeer. Waar vroeger “internet” vooral een uitgang was, is het nu het primaire werkplatform. Je wilt inzicht, controle en data-bescherming, zonder het werk onmogelijk te maken. Maar wat je níet automatisch krijgt, is volwassen identity governance, goede dataclassificatie, of een incident response-proces dat aansluit op je nieuwe telemetry. SASE kan dat faciliteren, maar niet vervangen. Ook NIST is daar duidelijk over in de Zero Trust-context: het is een reis en geen wholesale technologievervanging; organisaties werken vaak een tijd in een hybride situatie terwijl ze stapsgewijs verbeteren.

7. Een nuchtere adoptie-aanpak: begin bij de use case, niet bij de vendor

Als ik één patroon zie dat steeds terugkomt, dan is het dit: organisaties die starten met “welke SASE-vendor is de beste?” zijn vaak later teleurgesteld dan organisaties die starten met “welke toegangsvragen moeten wij oplossen?” Praktisch gezien betekent dit dat je eerst scherp maakt welke stromen je wilt beveiligen en optimaliseren. Remote access naar private apps? SaaS-toegang met data policies? Internet egress vanuit vestigingen? Third parties die tijdelijk bij systemen moeten? De antwoorden bepalen je route. Daarna kijk je naar je identitylaag. SASE leunt zwaar op identiteit en context. Als je IAM rommelig is, MFA inconsistent is of device posture onbetrouwbaar is, dan bouw je een modern huis op een fundament dat scheurt. Het oplossen daarvan voelt misschien als vertraging, maar het voorkomt technische schuld en versnelt je security– en netwerktransformatie juist op de lange termijn. Vervolgens ga je iteratief. Niet alles tegelijk, maar stap voor stap. Cloud Security Alliance beschrijft SASE ook nadrukkelijk als een manier om te moderniseren in een wereld waarin werk “een activiteit, geen plek” is, en waarin dreigingen meebewegen met die werkelijkheid. Dat past bij een gefaseerde aanpak: je moderniseert waar het meest te winnen valt., en je voorkomt een big-bang die iedereen uitput.

8. Waar het vaak misgaat (en hoe je dat voorkomt)

De eerste valkuil is dat SASE wordt behandeld als “VPN 2.0”. Dan verplaats je tunnels, maar je verandert niet het model. ZTNA is pas waardevol als je echt per applicatie en per context autoriseert, met least privilege, en niet alsnog brede netwerktoegang uitdeelt “omdat het makkelijk is”. De tweede valkuil is policy-chaos in een nieuw jasje. Als je nu al tientallen uitzonderingen hebt, en je migreert die één-op-één, dan krijg je in de cloud dezelfde spaghetti, maar dan sneller. Je wilt juist rationaliseren: welke regels zijn er echt nodig, welke zijn historische ballast, en welke risico’s accepteer je bewust?De derde valkuil is dat je alleen naar security kijkt en performance vergeet, of andersom. SASE is juist een convergentie. Als je de netwerk- en securityteams apart laat selecteren, krijg je vaak een compromis dat niemand gelukkig maakt. De mooiste implementaties ontstaan wanneer beide disciplines samen één verhaal bouwen richting business: dit is wat we beschermen, dit is hoe we het toegankelijk houden, en dit is wat de gebruiker ervan merkt. De vierde valkuil is onderschatting van data residency, compliance en logging. Cloud-geleverde security is fantastisch, maar je moet weten waar inspectie plaatsvindt, hoe logging wordt ontsloten, en hoe je aantoonbaarheid regelt. Niet als papieren exercitie, maar omdat je bij een incident binnen minuten wilt kunnen begrijpen wat er gebeurt.

9. Waar je op kunt letten bij selectie, zonder een vinkjesfeest te maken

Ik hou niet van eindeloze requirementlijsten die uiteindelijk niemand leest. Toch zijn er een paar punten die ik bijna altijd terug laat komen, omdat ze het verschil maken tussen “mooie demo” en “goede werkelijkheid”. Je wilt weten hoe het platform policies modelleert en afdwingt, want dat bepaalt je dagelijkse beheer. Je wilt begrijpen hoe identity en device posture worden geïntegreerd, want dat bepaalt of je echt richting Zero Trust beweegt. Je wilt inzicht in het wereldwijde PoP-netwerk en de performance, want gebruikers vergeven een trage security laag zelden. En je wilt helderheid over integraties: met je IdP, je endpoint tooling, je SIEM, je CASB-achtige behoeften, en je bestaande netwerkcomponenten. SASE is een architectuurkeuze, dus vendor lock-in is een reëel onderwerp. Dat betekent niet dat je het per definitie moet vermijden, maar wel dat je het bewust moet managen: contractueel, technisch (export van logs/policies), en organisatorisch (kennisopbouw).

10. Wat SASE betekent voor architectuur (en waarom het stiekem ook een cultuurverandering is)

De meest interessante verschuiving vind ik dat SASE de klassieke grens tussen “netwerk” en “security” minder hard maakt. In het oude model kon het netwerkteam zeggen: “wij zorgen dat het werkt”, en het securityteam: “wij zorgen dat het veilig is”, en daarna werd er onderhandeld in tickets. In een SASE-model is die scheiding onhandig. Toegang is tegelijk een performancevraag én een risicovraag. Routekeuze beïnvloedt inspectie. Inspectie beïnvloedt latency. Identity beïnvloedt policy. Policy beïnvloedt gebruikersgedrag. Het is één keten. Voor organisaties die dat omarmen, ontstaat iets moois: security wordt minder een blokkade en meer een ontwerpprincipe. Iets wat je meeneemt aan de voorkant, zodat je later minder hoeft te repareren.

Tot slot: SASE als volwassen stap, niet als modewoord

SASE is wat mij betreft het bewijs dat we als IT-wereld eindelijk toegeven wat al langer waar is: de rand van het netwerk is overal, applicaties zijn overal, en gebruikers zijn overal. Dan heeft het weinig zin om security te blijven organiseren alsof alles door één centrale poort moet. Met SASE breng je netwerk en security samen als dienst, gebaseerd op identiteit en context, met een duidelijke lijn richting Zero Trust. Gartner vat die convergentie helder samen in de definitie, inclusief de typische bouwstenen zoals SD-WAN, SWG, CASB en ZTNA. En NIST geeft de onderliggende filosofie stevig fundament: vertrouwen niet impliciet geven, maar per verzoek afdwingen, met beleid dat echt wordt toegepast. Als je het goed aanpakt, voelt SASE na verloop van tijd niet als “een nieuwe oplossing”, maar als een rustiger landschap. Minder losse knoppen. Minder uitzonderingen. Meer samenhang. En eerlijk gezegd: dat is precies wat we nodig hebben.

Bij Deltics proberen we dit soort keuzes altijd terug te brengen naar de vraag achter de vraag. Niet: “willen we SASE?”, maar: welk probleem willen we oplossen, welke risico’s willen we beheersen, en wat moet de gebruiker er in de praktijk van merken? Vanuit die insteek kijken we nuchter naar wat past bij de situatie: soms is dat een (deel van) SASE, soms juist SSE, soms een verbetering in identity, segmentatie, endpoint of logging, en soms een combinatie. Het doel is voor ons altijd om gefundeerd tot een goede oplossing te komen die technisch klopt én organisatorisch uitvoerbaar is. En eerlijk is eerlijk: in sommige omgevingen kom je er gaandeweg achter dat SASE simpelweg niet past — bijvoorbeeld omdat de architectuur, compliance-eisen, legacy-afhankelijkheden of het volwassenheidsniveau van identity en beheer er (nog) niet klaar voor zijn. Dan is “nee” ook een professioneel antwoord, zolang je dat kunt onderbouwen en er wél een alternatief ligt dat het echte probleem beter oplost.