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 \u00e9\u00e9n beleidsengine met ZTNA, FWaaS en SD-WAN, waardoor er geen standalone product meer nodig is. <\/p>\n
Elk webverzoek van je team wordt ergens langs geleid. De vraag is of datgene wat terugkomt ook echt ergens wordt ge\u00efnspecteerd. 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. <\/p>\n
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. <\/p>\n
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. <\/p>\n
De kernfuncties zijn onderverdeeld in zes gebieden.<\/p>\n
URL- en DNS-filtering<\/strong> controleert elk webverzoek aan de hand van categorisatiedatabases en informatiefeeds over bedreigingen. Bekende phishing-domeinen, command-and-control-servers en beleidsgebonden categorie\u00ebn worden geblokkeerd voordat er inhoud wordt geladen. <\/p>\n TLS\/SSL inspectie<\/strong> 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. <\/p>\n Malware scanning<\/strong> analyseert downloads en webinhoud in realtime. Geavanceerde gateways combineren detectie op basis van handtekeningen met sandboxing, waarbij verdachte bestanden in een ge\u00efsoleerde omgeving worden uitgevoerd voordat ze het eindpunt bereiken. <\/p>\n Contentcategorisatie<\/strong> deelt websites in categorie\u00ebn in (sociale media, gokken, bestanden delen, AI-tools) en past beleidsregels toe per categorie, per gebruikersgroep of per apparaattype.<\/p>\n Data Loss Prevention (DLP)<\/strong> 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. <\/p>\n Toepassingsbeheer<\/strong> 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. <\/p>\n Meer dan 90% van het webverkeer is nu versleuteld. Dat is goed voor de privacy, maar het cre\u00ebert 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\u00eble bedreigingen. <\/p>\n TLS-inspectie werkt via een gecontroleerd man-in-the-middle-proces dat de organisatie zelf beheert.<\/p>\n 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. <\/p>\n Om dit te laten werken zonder browserwaarschuwingen te triggeren, moet het hoofdcertificaat van de organisatie op elk beheerd eindpunt worden ge\u00efnstalleerd. Dit is eenvoudig met een MDM-oplossing zoals Intune of Jamf, maar wordt complexer met BYOD-apparaten. <\/p>\n Er zijn legitieme privacygrenzen die gerespecteerd moeten worden. De meeste organisaties sluiten bepaalde verkeerscategorie\u00ebn uit van inspectie: banksites, gezondheidszorgportals, overheidsdiensten. Een goed geconfigureerde omleidingslijst is niet optioneel. Het is een nalevingsvereiste in veel Europese rechtsgebieden. <\/p>\n Het prestatieprobleem is re\u00ebel, 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. <\/p>\n Deze vier technologie\u00ebn 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. <\/p>\nHoe TLS-inspectie werkt (en waarom het belangrijk is)<\/h2>\n
SWG vs firewall vs CASB vs WAF<\/h2>\n