Qu’est-ce qu’une passerelle web sécurisée ?
Une passerelle web sécurisée (SWG) est un service de sécurité qui s’interpose entre les utilisateurs et l’internet, inspectant tout le trafic web en temps réel. Elle applique les politiques d’accès, bloque les contenus malveillants, empêche les fuites de données et donne aux équipes informatiques une visibilité sur la manière dont l’organisation utilise le web. Dans une plateforme SASE, SWG partage un moteur de politique unique avec ZTNA, FWaaS et SD-WAN, éliminant ainsi le besoin d’un produit autonome.
Chaque requête web de votre équipe passe par un endroit. La question est de savoir si cet endroit inspecte réellement ce qui revient. C’est exactement ce que fait une passerelle web sécurisée. Elle intercepte le trafic web sortant, vérifie la destination, décrypte et analyse le contenu, applique vos politiques et autorise ou bloque la demande avant qu’elle n’atteigne le point final.
Pour les responsables informatiques qui évaluent leur pile de sécurité, le GTS est l’un de ces composants qui semblent simples mais qui se trouvent au centre de plusieurs préoccupations qui se chevauchent : diffusion de logiciels malveillants, informatique fantôme, exfiltration de données, conformité NIS2 et productivité des utilisateurs. Cet article explique ce que fait un SWG, comment il se compare aux pare-feu, CASB et WAF, et pourquoi le SWG autonome disparaît rapidement dans les plates-formes SASE.
Ce que fait une passerelle web sécurisée
Un GTS fonctionne à la couche 7 du modèle OSI, la couche application. C’est ce qui le différencie des pare-feu traditionnels qui fonctionnent aux niveaux 3 et 4. Au lieu de se contenter de vérifier les adresses IP et les ports, un GTS comprend le contenu des sessions HTTP et HTTPS. Il peut faire la distinction entre un utilisateur qui consulte un profil LinkedIn et ce même utilisateur qui télécharge un document confidentiel sur un compte personnel de stockage en nuage.
Les fonctions essentielles sont réparties en six domaines.
Le filtrage des URL et des DNS vérifie chaque requête web par rapport aux bases de données de catégorisation et aux flux de renseignements sur les menaces. Les domaines d’hameçonnage connus, les serveurs de commande et de contrôle et les catégories restreintes par des politiques sont bloqués avant le chargement du contenu.
L’inspection TLS/SSL décrypte le trafic crypté, l’analyse, puis le recrypte avant de le transmettre à l’utilisateur. Sans cela, la passerelle n’a aucune visibilité sur les sessions HTTPS, qui représentent aujourd’hui plus de 90 % de l’ensemble du trafic web.
La recherche de logiciels malveillants analyse les téléchargements et le contenu web en temps réel. Les passerelles avancées combinent la détection basée sur les signatures avec le sandboxing, où les fichiers suspects s’exécutent dans un environnement isolé avant d’atteindre le point final.
La catégorisation des contenus classe les sites web en catégories (médias sociaux, jeux d’argent, partage de fichiers, outils d’intelligence artificielle) et applique des politiques par catégorie, par groupe d’utilisateurs ou par type d’appareil.
La prévention des pertes de données (DLP) inspecte le trafic sortant à la recherche de schémas sensibles : numéros de cartes de crédit, formats d’identification nationaux, marqueurs de propriété intellectuelle. Si un utilisateur tente de coller un code source dans un outil d’IA non approuvé, la prévention des pertes de données le détecte.
Le contrôle des applications identifie des applications web spécifiques, indépendamment du port ou du protocole. Les équipes informatiques peuvent ainsi autoriser Slack mais bloquer les téléchargements de fichiers, ou autoriser Google Workspace mais restreindre le partage à des domaines externes.
Comment fonctionne l’inspection TLS (et pourquoi elle est importante)
Plus de 90 % du trafic web est désormais crypté. C’est une bonne chose pour la vie privée, mais cela crée un énorme angle mort pour les outils de sécurité qui ne peuvent pas voir à l’intérieur des sessions HTTPS. Les recherches montrent régulièrement qu’une part importante des logiciels malveillants est diffusée par le biais de connexions cryptées. Si votre pile de sécurité ne peut pas inspecter le trafic TLS, elle ignore en fait la majorité des menaces potentielles.
L’inspection TLS s’effectue par le biais d’un processus contrôlé de type « man-in-the-middle » que l’organisation gère elle-même.
Lorsqu’un utilisateur consulte un site web sécurisé, le SWG intercepte la connexion avant qu’elle n’atteigne sa destination. La passerelle établit sa propre session TLS avec le serveur cible, reçoit la réponse, la décrypte et fait passer le contenu par ses moteurs d’inspection. Si le contenu passe toutes les vérifications, la passerelle le recrypte à l’aide de son propre certificat et le transmet au navigateur de l’utilisateur.
Pour que cela fonctionne sans déclencher d’avertissements du navigateur, le certificat racine de l’organisation doit être installé sur chaque terminal géré. Cette opération est simple avec une solution MDM comme Intune ou Jamf, mais devient plus complexe avec les appareils BYOD.
Il y a des limites légitimes à respecter en matière de protection de la vie privée. La plupart des organisations excluent certaines catégories de trafic de l’inspection : sites bancaires, portails de soins de santé, services gouvernementaux. Une liste de contournement bien configurée n’est pas facultative. Il s’agit d’une exigence de conformité dans de nombreuses juridictions européennes.
Le problème des performances est réel, mais souvent surestimé. Les anciennes appliances matérielles de SWG avaient du mal à supporter la charge de travail de l’unité centrale pour décrypter des milliers de sessions simultanées. Les services SWG en nuage gèrent ce problème à l’échelle, car la capacité d’inspection augmente avec la plateforme, et non avec un boîtier dans votre salle de serveurs.
SWG vs firewall vs CASB vs WAF
Ces quatre technologies se chevauchent suffisamment pour prêter à confusion, mais chacune d’entre elles remplit une fonction distincte. La manière la plus simple de comprendre la différence est d’examiner le trafic que chacune inspecte et dans quelle direction.
| GTS | Pare-feu | CASB | WAF | |
|---|---|---|---|---|
| Couche primaire | Couche 7 (application) | Couche 3-4 (réseau/transport) | Couche 7 (application) | Couche 7 (application) |
| Sens du trafic | Sortie : de l’utilisateur vers l’internet | Les deux : sur la base de règles | Sortie : de l’utilisateur vers les applications SaaS | Inbound : internet vers vos applications web |
| Ce qu’il protège | Les utilisateurs contre les menaces web | Périmètre du réseau | Les données des applications en nuage | Vos applications web contre les attaquants |
| Principales fonctionnalités | Filtrage d’URL, inspection TLS, DLP | Règles de port/protocole, NAT, VPN | Découverte du Shadow IT, politique SaaS | Injection SQL, XSS, protection contre les robots |
| Sensibilisation à l’identité | Politiques relatives aux utilisateurs et aux groupes | Limité (basé sur l’IP) | Contexte utilisateur SaaS approfondi | Généralement au niveau de l’application |
SWG vs firewall. Un pare-feu voit une connexion HTTPS sortante sur le port 443 et l’autorise parce que la règle autorise le trafic web. Un GTS décrypte cette même connexion, reconnaît la destination comme un domaine d’hameçonnage nouvellement enregistré et la bloque. Les pare-feu sont nécessaires, mais ils ne sont pas suffisants pour assurer la sécurité du web. Vous avez besoin des deux.
SWG vs CASB. Un SWG empêche un utilisateur de visiter un site web malveillant. Un CASB dans SASE empêche ce même utilisateur de partager une feuille de calcul confidentielle via un compte Gmail personnel dans Google Drive. Le SWG gère le trafic web général. Le CASB gère l’utilisation sanctionnée et non sanctionnée des applications en nuage. Dans une plateforme unifiée, les deux moteurs partagent le même cadre stratégique.
SWG vs WAF. Le sens est inversé. Un SWG protège vos utilisateurs qui se connectent à l’internet. Un WAF protège vos applications web contre les attaques entrantes. Si vous gérez des portails ou des API orientés vers la clientèle, vous avez besoin d’un WAF. Si votre équipe navigue sur le web et utilise des outils SaaS, vous avez besoin d’un SWG. De nombreuses organisations ont besoin des deux.
Pourquoi les groupes de travail autonomes deviennent-ils obsolètes ?
Pendant des années, les organisations ont acheté le SWG comme un produit distinct. Une appliance dédiée ou un proxy dans le nuage qui gérait le filtrage web indépendamment du pare-feu, du VPN et de la protection des points d’extrémité. Ce modèle est en train de s’effondrer.
Gartner a supprimé son quadrant magique SWG autonome et a intégré l’évaluation des passerelles web dans les catégories plus larges Security Service Edge (SSE) et SASE. Il ne s’agit pas d’une décision administrative. Elle reflétait la réalité du marché : l’inspection du trafic web ne peut être séparée du contrôle d’accès, de la sécurité du cloud et de la politique de réseau sans créer des lacunes et dupliquer les efforts.
Les problèmes posés par les groupes de travail autonomes sont d’ordre pratique et non théorique.
Politiques distinctes. Lorsque votre GTS, votre pare-feu et votre solution ZTNA ont chacun leur propre console, les incohérences de politique sont inévitables. Un utilisateur bloqué sur un site à risque dans le SWG peut toujours accéder au même contenu par un chemin différent que la passerelle ne couvre pas.
Inspection redondante. Dans une architecture en chaîne de services, le trafic est décrypté et recrypté à chaque point d’inspection : une fois au niveau du pare-feu, une autre fois au niveau du SWG, une autre fois au niveau du moteur DLP. Chaque saut ajoute un temps de latence et augmente le risque d’erreurs de configuration.
Pas de contexte commun. Un GTS autonome ne sait pas que l’appareil qui fait la demande vient d’échouer à un contrôle de posture. Il ne sait pas que la session ZTNA de l’utilisateur a été signalée pour un comportement inhabituel. Sans contexte partagé, chaque outil prend des décisions de manière isolée.
L’alternative est une plateforme convergente où l ‘architecture SASE fournit SWG, ZTNA, FWaaS, CASB et SD-WAN par le biais d’un seul pipeline d’inspection. Pour une analyse claire de la manière dont ces composants sont liés, la comparaison SASE vs SSE vs SD-WAN couvre les distinctions en détail.
Comment fonctionne le SWG dans une plateforme SASE
Dans une plateforme SASE convergente, le SWG n’est pas un ajout. Il s’agit d’un moteur d’inspection parmi d’autres qui traitent le trafic en un seul passage.
Voici à quoi cela ressemble en pratique. Un utilisateur ouvre son navigateur et se rend sur un site web. L’agent SASE de son appareil achemine la demande vers le point de présence le plus proche. Au point de présence, la plateforme effectue un seul décryptage. Les métadonnées du trafic, y compris l’identité de l’utilisateur, l’état de l’appareil, la géolocalisation et l’URL demandée, alimentent simultanément tous les moteurs pertinents : Filtrage d’URL (SWG), politique d’application (CASB), règles de pare-feu (FWaaS), prévention de la perte de données et analyse des logiciels malveillants. Un seul décryptage, un seul passage d’inspection, une seule décision politique. Le trafic est recrypté une fois et transféré.
La plateforme SASE de Jimber fonctionne exactement selon ce principe. Les politiques SWG, les règles d’accès ZTNA et les politiques de pare-feu se trouvent dans la même console. Une politique qui restreint l’accès d’une équipe de marketing à des sites de partage de fichiers s’applique de manière cohérente, que l’utilisateur soit au bureau, qu’il travaille à domicile ou qu’il se connecte depuis un hôtel dans un autre pays. Il n’y a pas de portail SWG séparé à configurer.
Cette intégration simplifie également les mesures. Lorsque votre SWG, votre contrôle d’accès et vos politiques de point de terminaison partagent un seul pipeline de journalisation, vous pouvez corréler l’activité web avec les événements d’accès et la conformité des appareils dans une seule vue. Pour savoir ce qu’il faut mesurer et pourquoi, l’article sur les mesures SWG qui comptent couvre l’aspect opérationnel.
L’avantage pratique pour les équipes informatiques du marché intermédiaire est la réduction du nombre de consoles et d’erreurs de configuration, ainsi que l’accélération des changements de politique. Lorsque vous devez bloquer une campagne de phishing récemment découverte, vous mettez à jour une politique qui s’applique partout. Pas de synchronisation entre les produits, pas d’attente de propagation entre les différents outils.
Pourquoi les entreprises de taille moyenne ont-elles besoin d’une passerelle web ?
Les grandes entreprises disposent depuis des années d’une capacité de SWG. Le marché intermédiaire s’est souvent appuyé sur un filtrage d’URL de pare-feu de base ou sur une protection web basée sur les points d’extrémité. Ce fossé est en train de se combler, sous l’effet de trois facteurs.
La diffusion de logiciels malveillants par le web reste le principal vecteur d’attaque. Les charges utiles des ransomwares arrivent par le biais de téléchargements » drive-by « , de documents militarisés hébergés sur des sites compromis et de pages d’hameçonnage qui recueillent des informations d’identification. La protection des points d’extrémité permet d’en attraper une partie, mais il est fondamentalement plus efficace d’arrêter le téléchargement avant qu’il n’atteigne l’appareil que d’essayer de le contenir par la suite.
Le NIS2 crée des obligations explicites. Les organisations qui tombent sous le coup de la directive doivent mettre en œuvre des mesures techniques proportionnelles à leur risque. L’inspection du trafic web, l’enregistrement des accès et la détection des incidents sont directement liés aux exigences de l’article 21. Un GTS fournit la capacité d’inspection, tandis que l’enregistrement alimente les obligations de rapport d’incident que NIS2 impose dans les 24 et 72 heures.
L’utilisation de l’informatique fantôme et des outils d’IA s’accélère. Les employés utilisent des dizaines d’applications SaaS et d’outils d’IA que le service informatique n’a jamais approuvés. Certains de ces outils traitent les données de l’entreprise sur des serveurs situés en dehors de l’UE. Un SWG avec contrôle des applications donne au service informatique une visibilité sur ce qui est réellement utilisé et la possibilité de fixer des limites sans tout bloquer.
Prévention de l’exfiltration des données. Les capacités DLP d’un GTS permettent d’intercepter les données sensibles qui quittent l’organisation par le biais de canaux web. Pour les organisations qui traitent des données personnelles dans le cadre du GDPR ou des données financières dans le cadre de la DORA, il ne s’agit pas d’un avantage. Il s’agit d’un contrôle que les auditeurs attendent.
Des plateformes telles que Jimber incluent SWG en tant que composant standard de leur offre SASE. Il n’y a pas de licence séparée, ni d’appareil supplémentaire. La capacité de SWG est disponible dès le déploiement de la plateforme. Pour les organisations qui ont également besoin d’une isolation du navigateur pour les scénarios de navigation à haut risque, cela fonctionne parallèlement à SWG dans la même plateforme, ajoutant une couche supplémentaire sans autre produit.
Pour les équipes qui souhaitent concilier sécurité et convivialité, l’article sur le filtrage du web sans bloquer la productivité explique comment définir des politiques qui protègent sans frustrer les utilisateurs.
FAQ
Quelle est la différence entre SWG et CASB ?
Un GTS inspecte le trafic web général qui circule entre les utilisateurs et l’internet. Il bloque les sites malveillants, analyse les téléchargements et applique des politiques d’utilisation acceptable. Un CASB se concentre spécifiquement sur l’utilisation des applications en nuage : il découvre l’informatique fantôme, applique les règles de partage des données dans les outils SaaS et surveille le comportement des utilisateurs dans les services en nuage sanctionnés. Dans une plateforme SASE, les deux partagent le même moteur de politique et le même pipeline d’inspection, de sorte que vous n’avez pas besoin de choisir entre les deux.
Ai-je besoin d’un GTS si j’ai déjà un pare-feu ?
Oui. Un pare-feu opère principalement aux niveaux 3 et 4, contrôlant le trafic en fonction des adresses IP, des ports et des protocoles. Il ne peut pas inspecter le contenu des sessions HTTPS cryptées, alors que c’est là que se cachent la plupart des menaces en ligne. Un GTS travaille à la couche 7, décryptant et analysant le contenu web en temps réel. Ils ont des objectifs complémentaires.
Comment l’inspection TLS affecte-t-elle les performances ?
Sur les anciennes appliances matérielles, l’inspection TLS créait des goulets d’étranglement notables car le décryptage est gourmand en ressources processeur. Les services SWG natifs dans le nuage répartissent cette charge sur une infrastructure évolutive, ce qui élimine en grande partie les problèmes de performance pour les utilisateurs finaux. L’impact sur la vitesse de navigation se mesure généralement en millisecondes à un chiffre par requête. Des listes de contournement appropriées pour les catégories très sensibles (banques, soins de santé) réduisent encore le traitement inutile.
Un SWG autonome vaut-il encore la peine d’être acheté ?
Pour la plupart des entreprises de taille moyenne, non. Les produits SWG autonomes nécessitent une configuration, des politiques et une journalisation distinctes. Ils ne peuvent pas partager le contexte avec vos politiques de contrôle d’accès ou de point final. Une plateforme SASE qui inclut SWG, ZTNA, FWaaS et CASB dans une console unique offre de meilleurs résultats en matière de sécurité avec moins de charges opérationnelles.
Comment un GTS contribue-t-il à la conformité NIS2 ?
Le NIS2 exige des mesures techniques proportionnées pour la gestion des risques, le traitement des incidents et la sécurité de la chaîne d’approvisionnement. Un GTS soutient directement ces exigences en inspectant le trafic web pour détecter les menaces, en enregistrant toutes les activités web pour les enquêtes sur les incidents, en appliquant des politiques d’accès qui limitent l’exposition et en empêchant l’exfiltration des données grâce à des contrôles DLP. La capacité d’enregistrement est particulièrement importante pour les obligations de notification des incidents dans les 24 et 72 heures.
Un GTS peut-il détecter l’utilisation d’outils d’IA ?
Oui. Les solutions modernes de SWG avec contrôle des applications peuvent identifier et classer les outils d’IA tels que ChatGPT, Gemini, Copilot et des centaines d’autres. Les équipes informatiques peuvent définir des politiques granulaires : autoriser l’accès aux outils d’IA approuvés, bloquer ceux qui ne le sont pas, ou autoriser l’utilisation mais empêcher le téléchargement de fichiers et le collage de données par le biais de règles DLP.
Prêt à voir comment SWG s’intègre dans une plateforme SASE unifiée pour votre organisation ? Réservez une démonstration et découvrez comment Jimber combine la sécurité web, le contrôle d’accès et la connectivité réseau dans une seule console.
