Secure Web Gateway (SWG): wat het doet, hoe het werkt en waarom SASE de vergelijking verandert

Wat is een Secure web gateway?

Een secure web gateway (SWG) is een beveiligingsservice die zich tussen gebruikers en het internet bevindt en al het webverkeer in realtime inspecteert. Het dwingt het toegangsbeleid af, blokkeert schadelijke inhoud, voorkomt het lekken van gegevens en geeft IT-teams inzicht in hoe de organisatie het web gebruikt. In een SASE-platform deelt SWG één beleidsengine met ZTNA, FWaaS en SD-WAN, waardoor er geen standalone product meer nodig is.

Elk webverzoek van je team wordt ergens langs geleid. De vraag is of datgene wat terugkomt ook echt ergens wordt geïnspecteerd. Een beveiligde webgateway doet precies dat. Het onderschept uitgaand webverkeer, controleert de bestemming, decodeert en scant de inhoud, past uw beleid toe en staat het verzoek toe of blokkeert het voordat iets het eindpunt bereikt.

Voor IT-managers die hun beveiligingsstack evalueren, is SWG een van die componenten die eenvoudig klinkt, maar in het middelpunt staat van verschillende overlappende zorgen: levering van malware, schaduw-IT, data-exfiltratie, NIS2-compliance en gebruikersproductiviteit. In dit artikel wordt besproken wat een SWG doet, hoe het zich verhoudt tot firewalls, CASB en WAF, en waarom de standalone SWG snel aan het verdwijnen is in SASE-platforms.

Wat een beveiligde webgateway doet

Een SWG werkt op laag 7 van het OSI-model, de applicatielaag. Dit onderscheidt het van traditionele firewalls die op laag 3 en 4 werken. In plaats van enkel IP adressen en poorten te controleren, begrijpt een SWG de inhoud van HTTP en HTTPS sessies. Het kan onderscheid maken tussen een gebruiker die een LinkedIn-profiel bekijkt en diezelfde gebruiker die een vertrouwelijk document uploadt naar een persoonlijke cloudopslagaccount.

De kernfuncties zijn onderverdeeld in zes gebieden.

URL- en DNS-filtering controleert elk webverzoek aan de hand van categorisatiedatabases en informatiefeeds over bedreigingen. Bekende phishing-domeinen, command-and-control-servers en beleidsgebonden categorieën worden geblokkeerd voordat er inhoud wordt geladen.

TLS/SSL inspectie ontsleutelt versleuteld verkeer, scant het en versleutelt het dan opnieuw voor het doorgestuurd wordt naar de gebruiker. Zonder dit is de gateway blind voor alles binnen HTTPS sessies, die nu meer dan 90% van al het webverkeer uitmaken.

Malware scanning analyseert downloads en webinhoud in realtime. Geavanceerde gateways combineren detectie op basis van handtekeningen met sandboxing, waarbij verdachte bestanden in een geïsoleerde omgeving worden uitgevoerd voordat ze het eindpunt bereiken.

Contentcategorisatie deelt websites in categorieën in (sociale media, gokken, bestanden delen, AI-tools) en past beleidsregels toe per categorie, per gebruikersgroep of per apparaattype.

Data Loss Prevention (DLP) inspecteert uitgaand verkeer op gevoelige patronen: creditcardnummers, nationale ID-formaten, markeringen voor intellectueel eigendom. Als een gebruiker broncode in een niet-goedgekeurde AI-tool probeert te plakken, wordt dit door DLP opgemerkt.

Toepassingsbeheer identificeert specifieke webtoepassingen, ongeacht poort of protocol. Hierdoor kunnen IT-teams Slack toestaan maar het uploaden van bestanden blokkeren, of Google Workspace toestaan maar het delen naar externe domeinen beperken.

Hoe TLS-inspectie werkt (en waarom het belangrijk is)

Meer dan 90% van het webverkeer is nu versleuteld. Dat is goed voor de privacy, maar het creëert een enorme blinde vlek voor beveiligingstools die niet in HTTPS-sessies kunnen kijken. Onderzoek toont consequent aan dat een aanzienlijk deel van de malware wordt afgeleverd via versleutelde verbindingen. Als uw beveiligingspakket TLS-verkeer niet kan inspecteren, negeert het in feite de meerderheid van potentiële bedreigingen.

TLS-inspectie werkt via een gecontroleerd man-in-the-middle-proces dat de organisatie zelf beheert.

Wanneer een gebruiker een beveiligde website aanvraagt, onderschept de SWG de verbinding voordat deze de bestemming bereikt. De gateway zet zijn eigen TLS-sessie op met de doelserver, ontvangt het antwoord, decodeert het en haalt de inhoud door zijn inspectie-engines. Als de inhoud alle controles doorstaat, versleutelt de gateway het opnieuw met zijn eigen certificaat en stuurt het door naar de browser van de gebruiker.

Om dit te laten werken zonder browserwaarschuwingen te triggeren, moet het hoofdcertificaat van de organisatie op elk beheerd eindpunt worden geïnstalleerd. Dit is eenvoudig met een MDM-oplossing zoals Intune of Jamf, maar wordt complexer met BYOD-apparaten.

Er zijn legitieme privacygrenzen die gerespecteerd moeten worden. De meeste organisaties sluiten bepaalde verkeerscategorieën uit van inspectie: banksites, gezondheidszorgportals, overheidsdiensten. Een goed geconfigureerde omleidingslijst is niet optioneel. Het is een nalevingsvereiste in veel Europese rechtsgebieden.

Het prestatieprobleem is reëel, maar wordt vaak overschat. Oudere hardwarematige SWG-appliances hadden moeite met de CPU-belasting van het ontsleutelen van duizenden gelijktijdige sessies. Cloud-native SWG-diensten kunnen dit op schaal aan omdat de inspectiecapaciteit meegroeit met het platform, niet met een doos in uw serverruimte.

SWG vs firewall vs CASB vs WAF

Deze vier technologieën overlappen elkaar genoeg om verwarring te veroorzaken, maar ze dienen elk een duidelijk doel. De eenvoudigste manier om het verschil te begrijpen is door te kijken welk verkeer elk inspecteert en in welke richting.

SWG vs firewall. Een firewall ziet een uitgaande HTTPS-verbinding naar poort 443 en staat deze toe omdat de regel webverkeer toestaat. Een SWG ontcijfert diezelfde verbinding, herkent de bestemming als een nieuw geregistreerd phishingdomein en blokkeert de verbinding. Firewalls zijn noodzakelijk, maar niet voldoende voor webbeveiliging. Je hebt beide nodig.

SWG vs CASB. Een SWG blokkeert een gebruiker om een kwaadaardige website te bezoeken. Een CASB in SASE voorkomt dat diezelfde gebruiker een vertrouwelijke spreadsheet deelt via een persoonlijke Gmail-account in Google Drive. SWG handelt algemeen webverkeer af. CASB handelt gesanctioneerd en ongesanctioneerd gebruik van cloudapplicaties af. In een uniform platform delen beide engines hetzelfde beleidsraamwerk.

SWG vs WAF. De richting is omgekeerd. Een SWG beschermt je gebruikers die het internet op gaan. Een WAF beschermt je webapplicaties tegen aanvallen die binnenkomen. Als je klantgerichte portals of API’s beheert, heb je een WAF nodig. Als je team op het web surft en SaaS-tools gebruikt, heb je een SWG nodig. Veel organisaties hebben beide nodig.

Waarom standalone SWG verouderd raakt

Jarenlang kochten organisaties SWG als een apart product. Een speciale appliance of cloudproxy die onafhankelijk van de firewall, het VPN en de endpointbeveiliging webfiltering afhandelde. Dat model is aan het verdwijnen.

Gartner heeft het standalone SWG Magic Quadrant afgeschaft en de evaluatie van web gateways ondergebracht in de bredere categorieën Security Service Edge (SSE) en SASE. Dat was geen administratieve beslissing. Het weerspiegelde de realiteit in de markt: inspectie van webverkeer kan niet worden gescheiden van toegangscontrole, cloudbeveiliging en netwerkbeleid zonder hiaten te creëren en dubbel werk te doen.

De problemen met standalone SWG zijn praktisch, niet theoretisch.

Afzonderlijk beleid. Wanneer je SWG, firewall en ZTNA oplossing elk hun eigen console hebben, zijn inconsistenties in het beleid onvermijdelijk. Een gebruiker die geblokkeerd wordt van een risicovolle site in de SWG kan nog steeds dezelfde inhoud bereiken via een ander pad dat de gateway niet dekt.

Overbodige inspectie. In een service-chained architectuur wordt verkeer bij elk inspectiepunt gedecodeerd en opnieuw gecodeerd: één keer bij de firewall, nog een keer bij de SWG en nog een keer bij de DLP-engine. Elke stap voegt vertraging toe en verhoogt de kans op configuratiefouten.

Geen gedeelde context. Een standalone SWG weet niet dat het apparaat dat het verzoek doet net een houdingscontrole heeft gefaald. Het weet niet dat de ZTNA sessie van de gebruiker gemarkeerd is voor ongewoon gedrag. Zonder gedeelde context neemt elk hulpmiddel op zichzelf staande beslissingen.

Het alternatief is een geconvergeerd platform waarbij de SASE-architectuur SWG, ZTNA, FWaaS, CASB en SD-WAN levert via één enkele inspectiepijplijn. Voor een duidelijke uitsplitsing van hoe deze componenten zich tot elkaar verhouden, bevat de vergelijking van SASE vs SSE vs SD-WAN het onderscheid in detail.

Hoe SWG werkt binnen een SASE-platform

In een geconvergeerd SASE platform is SWG geen bolt-on. Het is een van de vele inspectie-engines die het verkeer in één keer verwerken.

Zo ziet dat er in de praktijk uit. Een gebruiker opent zijn browser en navigeert naar een website. De SASE agent op zijn apparaat stuurt het verzoek door naar het dichtstbijzijnde aanwezigheidspunt. Op het PoP voert het platform een enkele decryptie uit. De metadata van het verkeer, waaronder de identiteit van de gebruiker, de status van het apparaat, de geolocatie en de gevraagde URL, worden gelijktijdig in elke relevante engine ingevoerd: URL-filtering (SWG), toepassingsbeleid (CASB), firewallregels (FWaaS), preventie van gegevensverlies en malwarescanning. Eén ontsleuteling, één inspectieronde, één beleidsbeslissing. Het verkeer wordt eenmaal opnieuw versleuteld en doorgestuurd.

Het SASE-platform van Jimber werkt volgens precies dit principe. SWG-beleidsregels, ZTNA-toegangsregels en firewallbeleidsregels bevinden zich in dezelfde console. Een beleid dat de toegang van een marketingteam tot filesharing-sites beperkt, is consequent van toepassing, of de gebruiker nu op kantoor is, thuis werkt of vanuit een hotel in een ander land verbinding maakt. Er hoeft geen aparte SWG-portal te worden geconfigureerd.

Deze integratie vereenvoudigt ook het meten. Als uw SWG-, toegangscontrole- en endpointbeleidslijnen één loggingpijplijn delen, kunt u webactiviteit correleren met toegangsgebeurtenissen en apparaatcompliance in één overzicht. Als u wilt weten wat u moet meten en waarom, kunt u terecht in het bericht over SWG-metingen die er toe doen voor de operationele kant.

Het praktische voordeel voor IT-teams in het middensegment is minder consoles, minder configuratiefouten en snellere beleidswijzigingen. Wanneer je een nieuw ontdekte phishing-campagne moet blokkeren, werk je één beleid bij dat overal van toepassing is. Geen synchronisatie tussen producten, niet wachten op propagatie in verschillende tools.

Waarom organisaties in het middensegment een webgateway nodig hebben

Grote ondernemingen beschikken al jaren over SWG-mogelijkheden. Het middensegment van de markt heeft vaak vertrouwd op basis firewall URL-filtering of endpoint-gebaseerde webbescherming. Die kloof wordt kleiner, dankzij drie factoren.

De levering van malware via het web blijft de primaire aanvalsvector. Ransomware payloads komen binnen via drive-by downloads, gewapende documenten die worden gehost op gecompromitteerde sites en phishingpagina’s die gegevens verzamelen. Endpointbeveiliging vangt dit deels op, maar het stoppen van de download voordat deze het apparaat bereikt is fundamenteel effectiever dan het achteraf proberen in te dammen.

NIS2 creëert expliciete verplichtingen. Organisaties die onder de richtlijn vallen, moeten technische maatregelen implementeren die in verhouding staan tot hun risico. Inspectie van webverkeer, loggen van toegang en detectie van incidenten zijn direct relevant voor de vereisten van Artikel 21. Een SWG biedt de mogelijkheid tot inspectie, terwijl de logging de meldingsverplichtingen voor incidenten voedt die NIS2 binnen 24 en 72 uur oplegt.

Het gebruik van schaduw-IT en AI-tools neemt toe. Werknemers gebruiken tientallen SaaS-applicaties en AI-tools die nooit door IT zijn goedgekeurd. Sommige van die tools verwerken bedrijfsgegevens op servers buiten de EU. Een SWG met applicatiecontrole geeft IT zicht op wat er daadwerkelijk wordt gebruikt en de mogelijkheid om grenzen te stellen zonder alles te blokkeren.

Preventie van exfiltratie van gegevens. DLP-mogelijkheden binnen een SWG vangen gevoelige gegevens op die de organisatie verlaten via webkanalen. Voor organisaties die persoonlijke gegevens verwerken onder GDPR of financiële gegevens onder DORA, is dit geen nice-to-have. Het is een controle die auditors verwachten.

Platformen als Jimber hebben SWG als standaardcomponent in hun SASE-aanbod. Er is geen aparte licentie, geen extra apparaat. SWG is beschikbaar vanaf het moment dat het platform wordt ingezet. Voor organisaties die ook browserisolatie nodig hebben voor risicovolle browsingscenario’s, draait dat naast SWG in hetzelfde platform, waardoor een extra laag wordt toegevoegd zonder dat er een ander product nodig is.

Voor teams die een evenwicht willen vinden tussen beveiliging en bruikbaarheid, beschrijft de post over webfilteren zonder de productiviteit te blokkeren hoe beleidsregels kunnen worden ingesteld die bescherming bieden zonder gebruikers te frustreren.

FAQ

Wat is het verschil tussen SWG en CASB?

Een SWG inspecteert algemeen webverkeer van gebruikers naar het internet. Het blokkeert schadelijke sites, scant downloads en dwingt beleidsregels voor aanvaardbaar gebruik af. Een CASB richt zich specifiek op het gebruik van cloudapplicaties: het ontdekken van schaduw-IT, het afdwingen van regels voor het delen van gegevens binnen SaaS-tools en het monitoren van gebruikersgedrag in cloudservices waarvoor sancties gelden. In een SASE-platform delen beide dezelfde beleidsengine en inspectiepijplijn, zodat je niet tussen beide hoeft te kiezen.

Heb ik een SWG nodig als ik al een firewall heb?

Ja. Een firewall werkt voornamelijk op laag 3 en 4 en controleert het verkeer op basis van IP-adressen, poorten en protocollen. Hij kan de inhoud van versleutelde HTTPS-sessies, waar de meeste webbedreigingen zich schuilhouden, niet inspecteren. Een SWG werkt op laag 7, ontsleutelt en analyseert webinhoud in realtime. Ze dienen complementaire doelen.

Hoe beïnvloedt TLS-inspectie de prestaties?

Op oudere hardware-appliances zorgde TLS-inspectie voor merkbare knelpunten omdat decryptie CPU-intensief is. Cloud-native SWG-diensten verdelen deze belasting over een schaalbare infrastructuur, waardoor het prestatieprobleem voor eindgebruikers grotendeels verdwijnt. De impact op de browsersnelheid wordt meestal gemeten in milliseconden per verzoek. Goede bypass-lijsten voor zeer gevoelige categorieën (bankwezen, gezondheidszorg) zorgen voor een verdere vermindering van onnodige verwerking.

Is een standalone SWG nog steeds de moeite waard om te kopen?

Voor de meeste organisaties in het middensegment van de markt niet. Standalone SWG-producten vereisen aparte configuratie, apart beleid en aparte logging. Ze kunnen geen context delen met uw toegangscontrole- of endpointbeleid. Een SASE-platform dat SWG naast ZTNA, FWaaS en CASB in één console bevat, levert betere beveiligingsresultaten met minder operationele overhead.

Hoe helpt een SWG bij NIS2-compliance?

NIS2 vereist proportionele technische maatregelen voor risicobeheer, incidentafhandeling en beveiliging van de toeleveringsketen. Een SWG ondersteunt deze vereisten direct door webverkeer te inspecteren op bedreigingen, alle webactiviteiten te loggen voor incidentenonderzoek, toegangsbeleid af te dwingen dat blootstelling beperkt en exfiltratie van gegevens te voorkomen via DLP-controles. De mogelijkheid tot loggen is met name relevant voor de 24-uurs en 72-uurs meldplicht bij incidenten.

Kan een SWG het gebruik van AI-tools detecteren?

Ja. Moderne SWG-oplossingen met toepassingsbeheer kunnen AI-tools zoals ChatGPT, Gemini, Copilot en honderden andere identificeren en categoriseren. IT-teams kunnen granulaire beleidsregels instellen: toegang verlenen tot goedgekeurde AI-tools, niet-goedgekeurde tools blokkeren, of gebruik toestaan maar het uploaden van bestanden en het plakken van gegevens voorkomen via DLP-regels.

Klaar om te zien hoe SWG past in een uniform SASE-platform voor jouw organisatie? Boek een demo en krijg een walkthrough van hoe Jimber webbeveiliging, toegangscontrole en netwerkconnectiviteit combineert in één console.