Een medewerker werkt thuis, opent een SaaS-applicatie en wacht. Het verkeer gaat eerst naar de bedrijfsfirewall, vervolgens door een VPN-concentrator in het oude datacenter, maakt daar een omweg naar internet en komt uiteindelijk uit bij de cloudapplicatie. Op de architectuurplaat heet dat inmiddels SASE. In de praktijk is het vooral een moderne naam voor een oude verkeersfile.
Dat is de ongemakkelijke waarheid: een organisatie heeft geen modern netwerk omdat zij een SASE-platform heeft aangeschaft. Als al het verkeer nog steeds langs hetzelfde datacenter moet, blijft de oude netwerklogica bepalend. De locatie van de firewall is veranderd, de marketingpresentatie is vernieuwd, maar de afhankelijkheid is intact.
SASE kan een goede architectuur zijn. Het kan netwerkconnectiviteit en security dichter bij gebruikers, apparaten en applicaties brengen. Maar dat werkt alleen als de verkeersstromen, beleidsregels en verantwoordelijkheden werkelijk opnieuw worden ontworpen. Wie uitsluitend een nieuwe laag toevoegt boven op een oud netwerk, bouwt geen moderne infrastructuur. Die bouwt een modern dashboard voor een verouderde topologie.
De omweg verraadt het echte netwerk
De kern van het probleem zit vaak in wat netwerkbeheerders een hairpin noemen. Verkeer dat rechtstreeks van een gebruiker naar een cloudapplicatie zou kunnen gaan, wordt eerst teruggestuurd naar een centraal datacenter. Daar wordt het geïnspecteerd, voorzien van beleid en soms opnieuw gerouteerd. Dat klinkt beheerst. Het is vooral voorspelbaar duur en kwetsbaar.
De omweg vergroot de vertraging, maakt de gebruikerservaring afhankelijk van een centrale locatie en voegt extra componenten toe aan ieder gesprek. Bij een storing in het datacenter, de internetverbinding of de centrale securityvoorziening raakt niet alleen de lokale infrastructuur verstoord. Ook cloudgebruikers, externe medewerkers en vestigingen kunnen hun toegang verliezen tot diensten die helemaal niet in dat datacenter staan.
De ironie is dat SASE juist wordt omarmd omdat organisaties minder afhankelijk willen zijn van fysieke locaties. Vervolgens blijft het datacenter de verplichte doorgang voor vrijwel ieder pakket. Dat is geen transformatie. Dat is centralisatie met een nieuw etiket.
SASE is meer dan een securitydienst op afstand
SASE wordt vaak teruggebracht tot een verzameling functies: secure web gateway, firewalling, zero trust access, cloud access security en soms software-defined networking. Die functies kunnen nuttig zijn, maar de aanwezigheid ervan zegt niets over de kwaliteit van de architectuur. Een organisatie kan alle juiste producten hebben en toch de verkeerde verkeersstromen afdwingen.
De wezenlijke vraag is daarom niet welke SASE-functies zijn ingekocht, maar waar een toegangsbeslissing wordt genomen. Kan een gebruiker vanaf een beheerd apparaat rechtstreeks en gecontroleerd naar een SaaS-dienst? Kan toegang tot een interne applicatie worden toegestaan op basis van identiteit, apparaatstatus, context en applicatiebeleid, zonder eerst het hele netwerk open te zetten? En kan het beleid worden toegepast zonder dat een verouderde firewall in het datacenter de uiteindelijke scheidsrechter blijft?
Dat sluit aan bij de bredere les van Zero Trust: vertrouwen hoort niet automatisch voort te vloeien uit een netwerkpositie. Maar ook daar geldt dat een principe niet vanzelf werkelijkheid wordt. Een proxy met een moderne naam maakt een organisatie niet contextbewust. De besluitvorming, identiteit en handhaving moeten daadwerkelijk op elkaar aansluiten.
Het oude datacenter is vaak geen technische noodzaak
Er zijn legitieme redenen om verkeer via het datacenter te laten lopen. Een organisatie kan daar nog bedrijfskritische systemen hebben staan, specifieke inspectie nodig hebben of afhankelijk zijn van lokale koppelingen. Soms is directe cloudtoegang ook niet wenselijk vanwege gegevensstromen, operationele eisen of een gebrek aan volwassen beheer.
Maar “alles moet door het datacenter” is zelden een architectuurprincipe. Meestal is het een historisch gegroeide beheersmaatregel die nooit opnieuw is getoetst. De centrale firewall werd ooit de plek waar men controle kon organiseren. Daarna kwamen cloudapplicaties, thuiswerk, mobiele apparaten en externe partners erbij. De verkeersstromen veranderden sneller dan het ontwerp. De oude centrale route bleef staan omdat niemand eigenaar was van het geheel.
Daarmee ontstaat een merkwaardige vorm van schijncontrole. Het datacenter ziet het verkeer wel, maar dat betekent nog niet dat de organisatie begrijpt wat er gebeurt. Een centrale plek kan veel logdata verzamelen en toch weinig zicht bieden op de relatie tussen identiteit, apparaat, applicatie en handeling. Controle is niet hetzelfde als inzicht. Een inspectiepunt is niet automatisch een goede beslissing.
De rekening komt niet alleen op de netwerkfactuur
De gevolgen van zo’n hybride schijnarchitectuur zijn breder dan een paar milliseconden extra vertraging. Centrale verkeersstromen vragen capaciteit in verbindingen, firewalls, proxy’s, VPN-platforms en beheer. Als cloudgebruik groeit, groeit ook de druk op voorzieningen die oorspronkelijk voor een ander verkeersmodel zijn ontworpen. Dan wordt er opgeschaald om de omweg in stand te houden.
Daar komt operationele complexiteit bij. Een gebruiker die een probleem meldt met een SaaS-applicatie kan te maken hebben met lokaal netwerk, wifi, endpoint, tunnel, datacenterfirewall, DNS, proxy, internetkoppeling en de dienst zelf. Iedere schakel heeft een eigenaar, maar niemand bezit noodzakelijkerwijs de gebruikerservaring. Bij incidenten ontstaat dan het bekende ritueel: iedereen toont dashboards, niemand kan het volledige pad verklaren.
Ook security kan hierdoor verslechteren. Een centraal apparaat wordt een aantrekkelijk doelwit en een geconcentreerd storingspunt. Bovendien ontstaat de verleiding om uitzonderingen te stapelen: bypasses voor applicaties, tijdelijke routes voor leveranciers en speciale regels voor legacy-systemen. Het beleid wordt dan niet eenvoudiger, maar ondoorzichtiger. De organisatie noemt dat maatwerk wanneer zij eigenlijk haar ontwerp niet meer beheerst.
Moderniseren begint met verkeersstromen, niet met licenties
De eerste stap naar een geloofwaardig SASE-model is geen aanbesteding. Het is het zichtbaar maken van de werkelijke verkeersstromen. Welke gebruikers en apparaten praten met welke applicaties? Welke verbindingen lopen via het datacenter, welke via internet en welke rechtstreeks naar cloudplatforms? Waar wordt identiteit gecontroleerd, waar wordt versleuteling beëindigd en waar wordt beleid afgedwongen?
Dat onderzoek maakt meestal duidelijk dat niet al het verkeer hetzelfde behandeld hoeft te worden. SaaS-verkeer kan een andere route en beleidslogica krijgen dan toegang tot een intern systeem. Een legacy-applicatie kan voorlopig via een gecontroleerde toegangsdienst bereikbaar blijven, zonder dat iedere medewerker daarvoor een brede netwerkverbinding krijgt. Verkeer tussen vestigingen kan anders worden ontworpen dan verkeer van een thuiswerker naar een publieke dienst.
Daarbij hoort een ongemakkelijke opruimvraag: welke datacenterfuncties zijn nog werkelijk noodzakelijk? Niet welke apparatuur nog aanstaat, maar welke afhankelijkheid nog waarde toevoegt. Een organisatie die haar oude netwerk niet durft af te bouwen, zal SASE vooral gebruiken om twee werelden permanent naast elkaar te beheren. Dat is geen tussenfase meer zodra niemand een einddatum of afbouwbesluit durft te formuleren.
Ook de besturing moet veranderen. Netwerk, security, endpointbeheer, identity en applicatie-eigenaren kunnen dit niet ieder vanuit hun eigen console oplossen. Er moeten duidelijke keuzes komen over wie beleid vaststelt, wie uitzonderingen goedkeurt en wie verantwoordelijk is voor de totale toegangsketen. Leveranciers leveren componenten. Zij ontwerpen niet automatisch de bedrijfsarchitectuur, hoe overtuigend hun referentiearchitectuur ook klinkt.
De uitzondering mag niet opnieuw de standaard worden
De grootste valkuil is dat organisaties beginnen met een modern doelbeeld en eindigen met een lange lijst uitzonderingen. “Dit systeem kan niet.” “Deze leverancier gebruikt nog een vast IP-adres.” “Deze applicatie moet via de oude tunnel.” “Deze afdeling wil dezelfde route als vroeger.” Voor iedere uitzondering kan een goede reden bestaan. Het probleem ontstaat wanneer niemand nog onderscheid maakt tussen tijdelijk noodzakelijk en structureel gemak.
Daarom moet iedere uitzondering een eigenaar, een reden en een herzieningsmoment hebben. Niet als bureaucratische exercitie, maar om te voorkomen dat het oude netwerk zich vermomt als randgeval en vervolgens de hele architectuur blijft bepalen. Een uitzondering die jarenlang blijft bestaan, is geen uitzondering. Het is een ontwerpkeuze waar men de verantwoordelijkheid niet voor wil nemen.
Wat is dan de echte IT-realiteit?
SASE is geen productcategorie die een netwerk vanzelf modern maakt. Het is een architectuurkeuze die pas betekenis krijgt wanneer verkeer niet langer automatisch naar de plek wordt gestuurd waar toevallig ooit de meeste controle is ingericht. De juiste route hangt af van gebruiker, apparaat, applicatie, identiteit, risico en bedrijfscontext. Soms leidt die route nog door het datacenter. Maar dan moet dat een bewuste keuze zijn, geen reflex.
De echte test is eenvoudig: kan de organisatie uitleggen waarom een verkeersstroom een bepaalde route volgt, waar de beslissing wordt genomen en wat er gebeurt als het datacenter uitvalt? Kan zij een oude afhankelijkheid afbouwen zonder dat de dienstverlening instort? En kan zij aantonen dat securitybeleid niet alleen centraal wordt verzameld, maar ook effectief en begrijpelijk wordt toegepast?
Wie die vragen niet kan beantwoorden, heeft waarschijnlijk geen modern netwerk maar een oud netwerk met nieuwe terminologie. SASE begint daarom niet bij de aanschaf van een platform, maar bij de moed om de omweg zichtbaar te maken en hem daarna niet langer vanzelfsprekend te vinden.
Ontdek meer van IT realiteit
Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.
