SWG vs. Firewall : Principales différences et meilleures pratiques

Ce guide SWG vs Firewall présente les principales différences, avantages et meilleures pratiques pour aider les organisations à choisir la bonne approche de sécurité réseau.

Qu'est-ce qu'une passerelle web sécurisée (SWG) et un pare-feu ?

Un utilisateur clique sur un lien dans un navigateur. En quelques millisecondes, un trafic chiffré s'écoule vers un domaine inconnu, et une charge utile commence à être téléchargée. Deux technologies différentes se trouvent entre ce clic et une éventuelle compromission, chacune inspectant des couches différentes de la connexion. Comprendre le rôle de chacune et leurs limites permet de distinguer une architecture de sécurité résiliente d'une architecture présentant des angles morts.

• Une passerelle web sécurisée (SWG) filtre votre trafic web au niveau de la couche applicative (couche 7). Selon la définition de Gartner, une SWG est « une solution qui filtre les logiciels indésirables/malveillants du trafic web/Internet initié par l'utilisateur et applique la conformité aux politiques d'entreprise et réglementaires ». Elle inspecte les sessions HTTP/HTTPS, catégorise les URL, analyse les téléchargements à la recherche de logiciels malveillants et applique les politiques d'utilisation acceptable avec une connaissance complète de l'identité de l'utilisateur.
• Votre pare-feu fonctionne aux couches réseau et transport (couches 3 et 4). La présentation du pare-feu par la CISA décrit les pare-feux comme des systèmes de sécurité qui « offrent une protection contre les cyberattaquants externes en protégeant votre ordinateur ou réseau contre le trafic réseau malveillant ou inutile ». Votre pare-feu contrôle le flux de trafic à l'aide de règles basées sur les adresses IP, les ports et les protocoles, en maintenant des tables d'état pour suivre les connexions actives.

La distinction est importante car chaque technologie voit des éléments différents. Votre pare-feu valide si une connexion doit exister sur la base d'attributs réseau. Votre SWG examine ce qui transite à l'intérieur de cette connexion au niveau applicatif, y compris le contenu des pages web, la réputation des URL et l'identité de l'utilisateur à l'origine de la requête.

Relation entre SWG, pare-feu et cybersécurité

Les deux technologies servent de points d'application dans votre architecture de sécurité, mais elles couvrent des catégories de risques différentes. NIST SP 800-207 classe les pare-feux et les SWG comme des points d'application de politique (PEP) dans l'architecture Zero Trust. Chaque PEP « permet, surveille et termine éventuellement les connexions entre un sujet et une ressource de l'entreprise ».

Aucune de ces technologies ne fournit une couverture suffisante à elle seule. Des recherches analysant des milliards d'événements réseau ont montré que les passerelles web présentent une perméabilité notable lorsqu'elles sont déployées isolément. Votre pare-feu, quant à lui, manque de visibilité approfondie sur la couche applicative sans des fonctionnalités telles que l'inspection SSL/TLS.

Des incidents réels confirment ce constat. Dans son avis sur Colonial Pipeline, la CISA détaille comment un incident de ransomware en 2021 a perturbé la distribution de carburant, montrant que les contrôles périmétriques seuls ne stoppent pas les chemins d'intrusion liés à l'identité. Dans le dépôt SEC de MGM Resorts (2023), l'entreprise a signalé un incident de cybersécurité ayant entraîné un impact sur le chiffre d'affaires d'environ 100 millions de dollars, illustrant comment le phishing et l'ingénierie sociale peuvent contourner de simples règles réseau d'autorisation/interdiction.

Ces exemples montrent pourquoi aucun des deux outils ne couvre à lui seul l'ensemble de la surface d'attaque. Avant d'approfondir le fonctionnement de chaque technologie, voici un aperçu comparatif.

SWG vs. pare-feu : aperçu

Dimension	Pare-feu	Passerelle web sécurisée
Couche OSI	Couches 3-4 (Réseau/Transport)	Couche 7 (Application)
Focus de l'inspection	Adresses IP, ports, protocoles, contexte de connexion avec état, analyse du quintuple	URLs, contenu web, téléchargements de fichiers, identité utilisateur, déchiffrement SSL/TLS, analyse de charge utile spécifique à l'application
Couverture des protocoles	Tous les protocoles IP (TCP, UDP, ICMP, GRE, IPSec, SSH, SMB, RDP, DNS, SMTP, protocoles personnalisés)	Protocoles centrés web (HTTP/HTTPS, WebSocket, API SaaS, REST, SOAP)
Modèle de politique	Centré réseau : basé sur IP, ports, zones et topologie réseau	Centré identité : basé sur utilisateurs, groupes, posture des appareils, contexte de localisation et contrôles spécifiques à l'application
Déploiement principal	Périmètre réseau, datacenter, agence, segmentation interne ; sur site ou FWaaS	Livré dans le cloud ou basé proxy avec PoP mondiaux ; centré utilisateur avec élasticité

La suite de ce guide détaille chaque ligne : comment le trafic circule à travers chaque outil, quels composants pilotent chaque capacité, et où apparaissent les écarts dans la réalité.

Fonctionnement des SWG et des pare-feux

Votre SWG et votre pare-feu sont tous deux placés en ligne avec le trafic, mais ils le traitent différemment et voient des éléments différents.

Traitement du trafic web par un SWG

Votre SWG fonctionne comme un proxy direct entre les utilisateurs et Internet. Lorsqu'un utilisateur ouvre un navigateur et demande une URL, la requête passe par le SWG avant d'atteindre la destination. La passerelle évalue la requête en plusieurs étapes : elle résout l'URL via des bases de réputation et des listes de catégories, vérifie l'identité de l'utilisateur demandeur dans votre annuaire (Active Directory, LDAP ou SSO), et applique vos politiques d'utilisation acceptable. Si la destination est autorisée, le SWG établit la connexion sortante au nom de l'utilisateur.

Pour le trafic HTTPS, qui représente plus de 95 % des requêtes web sur Google, le SWG effectue le déchiffrement SSL/TLS. Il termine la session chiffrée, inspecte le contenu en clair à la recherche de signatures de logiciels malveillants, de schémas de fuite de données et de menaces intégrées, puis rechiffre et transfère le trafic. Cette inspection de type « homme du milieu » donne au SWG une visibilité sur les charges utiles que les outils de couche réseau ne peuvent pas voir.

Les SWG cloud étendent ce modèle proxy aux utilisateurs distants sans nécessiter de tunnels VPN. Le trafic est acheminé vers le point de présence (PoP) le plus proche, où les mêmes politiques d'inspection s'appliquent quel que soit l'emplacement de l'utilisateur.

Traitement du trafic réseau par un pare-feu

Votre pare-feu évalue le trafic à la frontière du réseau à l'aide d'attributs au niveau des paquets. Lorsqu'un paquet arrive, le pare-feu lit son en-tête : IP source, IP destination, port source, port destination et protocole. Un pare-feu à états vérifie ensuite ces informations dans sa table d'état pour déterminer si le paquet appartient à une session établie ou représente une nouvelle tentative de connexion.

Pour les nouvelles connexions, le pare-feu parcourt sa base de règles de haut en bas. La première règle correspondante détermine l'action : autoriser, refuser ou abandonner. Si aucune règle ne correspond, la politique par défaut (généralement refuser) s'applique. Cela se produit en microsecondes, ce qui explique pourquoi les pare-feux gèrent efficacement des débits élevés. Ils prennent des décisions binaires sur la base de métadonnées structurées, sans analyse de contenu.

Les pare-feux de nouvelle génération (NGFW) étendent ce modèle en ajoutant l'identification des applications et la prévention des intrusions. Un NGFW peut classifier le trafic par application même lorsqu'il utilise des ports communs, et applique des signatures IPS pour détecter des schémas d'exploitation connus. Cela confère aux NGFW une conscience partielle de la couche 7, mais leur inspection reste basée sur des modèles et non sur le contenu. Un NGFW peut identifier que le trafic concerne Slack ou Salesforce, mais il ne catégorise pas les URL, n'analyse pas les téléchargements de fichiers en ligne, ni n'applique de politiques d'utilisation acceptable basées sur l'identité comme le fait votre SWG.

Divergence de l'inspection

La différence opérationnelle devient évidente lorsqu'on suit un événement unique à travers les deux contrôles. Un utilisateur clique sur un lien de phishing dans un navigateur. Votre pare-feu voit une connexion HTTPS sortante vers le port 443 et l'autorise, car l'IP de destination n'est pas sur une liste de blocage et les connexions HTTPS sortantes sont permises. Votre SWG intercepte la même requête, déchiffre la session TLS, vérifie l'URL dans des flux de cybermenaces, et bloque la connexion car le domaine a été enregistré il y a 12 heures et héberge une page de collecte d'identifiants.

Ce n'est pas un échec de l'un ou l'autre outil. Votre pare-feu a fait exactement ce pour quoi il est conçu : évaluer les attributs réseau et appliquer la politique de connexion. Votre SWG a fait ce pour quoi il est conçu : inspecter le contenu et le contexte de cette connexion. L'écart entre ces deux périmètres est l'endroit où opèrent les attaquants.

Comprendre ces mécanismes vous aide à évaluer la contribution réelle de chaque composant à votre posture de sécurité.

Composants clés des SWG et des pare-feux

Maintenant que vous comprenez comment le trafic circule à travers chaque outil, il est utile d'examiner leur composition. Les composants ci-dessous déterminent ce que chaque technologie peut inspecter, appliquer et reporter, et expliquent pourquoi les deux outils se comportent différemment en pratique.

Composants clés d'un SWG

Selon la spécification SWG de Gartner, votre SWG doit inclure au minimum trois capacités obligatoires :

• Filtrage et catégorisation des URL : Évaluation en temps réel de la réputation des URL, filtrage de contenu basé sur les catégories et application dynamique des politiques alignées sur les usages acceptables.
• Détection et filtrage de code malveillant : Analyse en ligne du trafic web, moteurs antimalware pour les fichiers téléchargés et protection contre les téléchargements furtifs.
• Contrôles applicatifs : Politiques granulaires pour les applications web telles que les plateformes SaaS, la messagerie web et les réseaux sociaux, incluant la gestion de la bande passante et la visibilité sur le shadow IT.

Ces capacités constituent la base. Les résultats réels dépendent généralement de la capacité à les étendre à l'inspection du trafic chiffré et au contexte d'identité.

Au-delà de ces exigences, votre SWG moderne inclut également :

• Inspection SSL/TLS : Déchiffrement et rechiffrement du trafic HTTPS pour une analyse en ligne, la grande majorité du trafic web étant désormais chiffrée.
• Prévention de la perte de données (DLP) : Inspection du contenu sortant pour identifier les schémas de données sensibles et bloquer les tentatives d'exfiltration via les canaux web.
• Connaissance de l'identité et de l'utilisateur : Intégration avec Active Directory, LDAP et SSO pour l'application de politiques par utilisateur/groupe selon le rôle et le contexte, en accord avec les principes de Zero Trust.

Ensemble, ces composants permettent à votre SWG de prendre des décisions tenant compte du contenu et de l'identité pour chaque session web, ce qui diffère fondamentalement du modèle de votre pare-feu.

Composants clés d'un pare-feu

Les composants clés de votre pare-feu incluent des tables d'état qui maintiennent les enregistrements de connexions actives, des moteurs d'inspection qui valident les paquets selon le contexte de connexion établi, et des moteurs de politique basés sur des règles traitant les politiques de sécurité de haut en bas. Les NGFW ajoutent l'identification applicative et la prévention des intrusions à ces fondations, tandis que le pare-feu en tant que service (FWaaS) fournit la même inspection sous forme de service cloud managé. Selon les recommandations SSE de la CISA, le FWaaS est l'un des quatre composants clés du Security Service Edge (SSE) avec ZTNA, Cloud SWG et CASB.

Comprendre ces éléments de base permet de saisir pourquoi les deux outils produisent des résultats de sécurité différents, même lorsqu'ils sont placés sur le même chemin réseau.

Bénéfices clés des SWG et des pare-feux

Les composants n'ont d'intérêt que s'ils se traduisent par des résultats mesurables. Cette section détaille ce que chaque technologie apporte réellement lorsqu'elle est bien configurée, et ce que vous gagnez à les utiliser ensemble.

Bénéfices des SWG

Vous obtenez des avantages spécifiques en sécurisant le trafic web à la couche 7 :

• Visibilité sur le trafic chiffré : Vous obtenez une visibilité sur le contenu des sessions web chiffrées, un angle mort pour les pare-feux opérant aux couches 3-4.
• Application de politiques tenant compte de l'utilisateur : Vos politiques SWG cloud appliquent des contrôles d'accès basés sur l'identité utilisateur et le contexte de l'appareil, permettant la sécurité des travailleurs à distance sans retour VPN.
• Contrôle des applications cloud : Vous découvrez le shadow IT et appliquez des politiques SaaS spécifiques avec une grande précision.
• Prévention des menaces en ligne : Vous bloquez les logiciels malveillants, les URL malveillantes et le phishing avant que le contenu n'atteigne vos terminaux.

Les SWG offrent des contrôles tenant compte de l'identité pour le web, là où commencent le phishing, le vol d'identifiants et les téléchargements de malwares.

Bénéfices des pare-feux

Les pare-feux assurent le contrôle global du réseau et la segmentation :

• Couverture multiprotocole : Votre pare-feu inspecte tous les protocoles réseau, y compris les connexions aux bases de données, les transferts de fichiers, les sessions SSH et les applications personnalisées.
• Segmentation réseau : La CISA recommande la séparation logique du réseau via une séparation physique ou virtuelle pour isoler les appareils sur des segments réseau.
• Inspection à haut débit : Vous bénéficiez d'un filtrage réseau de tous les types de trafic avec une prise de décision tenant compte de l'état des connexions.
• Protection de l'infrastructure : Votre pare-feu protège les équipements réseau eux-mêmes, y compris routeurs, commutateurs et concentrateurs VPN, contre l'exploitation directe.

Les pare-feux limitent les destinations et les communications possibles, ce qui est fondamental pour réduire le rayon d'impact.

Bénéfices combinés

En déployant les deux technologies ensemble, vous créez une défense en profondeur avec application à plusieurs couches. Votre pare-feu bloque les connexions réseau non autorisées avant qu'elles n'atteignent les ressources internes. Votre SWG inspecte le contenu des sessions web autorisées.

Cette approche en couches est essentielle car de nombreux incidents majeurs commencent par une compromission d'identité et une livraison web, puis se poursuivent par des mouvements latéraux internes. Par exemple, la divulgation Change Healthcare (2024) décrit une cyberattaque ayant perturbé les services et entraîné un impact déclaré de 872 millions de dollars au premier trimestre 2024, illustrant la nécessité de disposer à la fois de contrôles d'accès robustes et d'une inspection approfondie pour empêcher qu'une chaîne d'intrusion web ne devienne une panne à l'échelle de l'entreprise.

Superposer les contrôles ajoute également de la complexité opérationnelle, ce qui est souvent source de friction pour les équipes.

Défis et limites des SWG et des pare-feux

Chaque contrôle de sécurité présente des angles morts, et connaître les vôtres permet d'éviter qu'ils ne deviennent des vecteurs d'attaque. Les limites ci-dessous ne sont pas des raisons d'éviter l'une ou l'autre technologie ; ce sont des contraintes de conception à prendre en compte lors de l'architecture de votre pile.

Limites des SWG

Votre SWG présente de réelles contraintes à intégrer dans votre conception :

• Couverture limitée au web : Votre SWG inspecte HTTP/HTTPS et les protocoles web associés. Le trafic non web échappe totalement à sa visibilité.
• Surcharge liée à l'inspection SSL : Déchiffrer et rechiffrer le trafic HTTPS ajoute de la latence. À grande échelle, cela crée un compromis performance/sécurité nécessitant une planification de capacité rigoureuse.
• Complexité de gestion des certificats : L'inspection SSL requiert le déploiement de certificats racine de confiance sur tous les appareils gérés, ce qui complique l'exploitation dans les environnements BYOD.

Ces contraintes montrent où il est nécessaire de compléter la couche web par des contrôles endpoint et identité.

Limites des pare-feux

Votre pare-feu présente également des limites, notamment dans les scénarios cloud et de trafic chiffré :

• Absence de visibilité sur le contenu : Votre pare-feu ne peut pas inspecter les charges utiles applicatives à l'intérieur des connexions autorisées. Un fichier malveillant téléchargé via une session HTTPS autorisée passe sans être examiné.
• Dégradation des performances dans le cloud : Les pare-feux peuvent rencontrer des limitations de performance dans les environnements cloud, et le retour du trafic des utilisateurs distants peut ajouter de la latence et des goulets d'étranglement.
• Modèles de politique statiques : Les règles centrées sur les IP ont du mal à s'adapter aux environnements cloud dynamiques. Selon NIST SP 800-215, les approches basées sur des appliances présentent des « limites de sécurité des solutions d'accès réseau actuelles » dans les architectures hybrides.
• Prolifération des règles : Les pare-feux d'entreprise accumulent des milliers de règles au fil du temps, générant une complexité de gestion et des risques de mauvaise configuration.

Ensemble, la portée limitée au web du SWG et l'absence de visibilité sur le contenu du pare-feu créent un écart que les attaquants exploitent régulièrement . Le combler nécessite des pratiques opérationnelles délibérées plutôt qu'un produit ponctuel supplémentaire.

Bonnes pratiques SWG vs. pare-feu

Les limites ci-dessus révèlent un point commun : aucun outil n'échoue par ce qu'il fait, mais par ce que les équipes supposent qu'il couvre. Ces sept pratiques comblent les écarts les plus fréquents observés en production.

1. Déployer les deux comme couches d'application complémentaires

Considérez vos pare-feux et SWG comme des points d'application de politique complémentaires selon NIST SP 800-207. Vos pare-feux appliquent la segmentation réseau et les contrôles d'accès multiprotocole. Vos SWG appliquent le filtrage web tenant compte de l'identité, la sécurité web et l'inspection de contenu. Aucun ne remplace l'autre.

2. Privilégier l'intégration à la liste des fonctionnalités

Avant d'évaluer de nouveaux produits, analysez la coordination de votre SWG et de votre pare-feu existants avec votre SIEM, votre infrastructure d'identité et votre plateforme de protection des endpoints. Les analyses sectorielles montrent que l'intégration à votre architecture compte plus que la recherche de la dernière fonctionnalité.

3. Adopter SASE/SSE pour les effectifs distribués

Les recommandations conjointes CISA/FBI positionnent SASE comme l'architecture cible fusionnant SWG, CASB, ZTNA et FWaaS en services cloud. Si votre organisation prend en charge des travailleurs distants ou hybrides, évaluez l'architecture SASE pour éliminer la latence liée au retour VPN.

4. Mettre en œuvre des politiques centrées sur l'identité

Allez au-delà des règles statiques basées sur IP et ports. Configurez votre SWG avec des politiques par utilisateur et groupe liées à votre fournisseur d'identité. L'architecture Zero Trust de NIST établit que les décisions d'accès doivent suivre l'identité utilisateur, la posture de l'appareil et le contexte applicatif, et non la localisation réseau. Associer la politique SWG à la sécurité de l'identité réduit le risque qu'un identifiant compromis donne un accès total.

5. Centraliser la supervision et la gestion des configurations

Les recommandations de durcissement CISA préconisent la mise en place d'une supervision qui « applique la gestion des configurations, gère les fonctions administratives courantes de façon autonome et alerte sur les changements dans l'environnement ». Appliquez cela à votre infrastructure pare-feu et SWG :

• Stockez les configurations dans des référentiels sous contrôle de version
• Activez l'identification des changements avec alerte en cas de modification non autorisée
• Exigez l'authentification multifacteur pour tout accès administratif
• Réalisez des audits réguliers de conformité par rapport aux référentiels de sécurité

Ces contrôles réduisent la dérive opérationnelle, cause fréquente d'échec des pare-feux et proxys lors des réponses à incident.

6. Tester l'inspection SSL dans des conditions réalistes

Effectuez des tests de validation avec vos flux et volumes réels avant un déploiement complet. Portez une attention particulière à l'impact sur la latence, aux cas limites de gestion des certificats et à la compatibilité applicative.

7. Durcir l'infrastructure de sécurité elle-même

Vos pare-feux et SWG sont des cibles de grande valeur. Suivez les recommandations NIST pour durcir les équipements : sécurisez les interfaces de gestion, appliquez rapidement les correctifs de sécurité des fournisseurs et séparez le trafic administratif du trafic de production.

Avec ces pratiques, vous pouvez prendre des décisions plus éclairées sur le déploiement de chaque contrôle et leur emplacement.

Quand utiliser un SWG, un pare-feu ou les deux

Votre choix de déploiement dépend de ce que vous protégez et de l'origine de connexion de vos utilisateurs.

• Déployez un pare-feu lorsque vous avez besoin : d'une défense périmétrique pour les datacenters et campus, de segmentation est-ouest entre zones internes, d'une inspection multiprotocole et de la protection de l'infrastructure pour routeurs, commutateurs et serveurs.
• Déployez un SWG lorsque vous avez besoin : de visibilité sur le contenu du trafic web chiffré, de politiques d'accès web basées sur l'identité utilisateur, de gouvernance des applications cloud et de contrôle du shadow IT, et de la protection des utilisateurs distants sans retour VPN.
• Déployez les deux lorsque vous avez besoin : d'une défense en profondeur, d'une couverture sur les protocoles web et non web, et d'une application aux couches réseau et applicative, notamment dans les environnements hybrides.

Alignez ces choix sur votre modèle Zero Trust et validez-les par rapport aux chemins d'attaque les plus fréquents dans votre environnement. Quelle que soit la combinaison choisie, les contrôles sont plus efficaces lorsqu'ils alimentent une couche unifiée d'opérations de sécurité capable de corréler les signaux réseau, endpoint et identité.

Points clés à retenir

Les SWG et les pare-feux sont des technologies complémentaires, et non des alternatives concurrentes. Vos pare-feux appliquent la segmentation réseau aux couches 3 et 4. Vos SWG inspectent le contenu du trafic web et appliquent des politiques tenant compte de l'identité à la couche 7. 

Les cadres de cybersécurité modernes exigent les deux, idéalement intégrés dans des architectures SASE/SSE alignées sur les principes Zero Trust du NIST. La plateforme Singularity de SentinelOne étend la protection à vos couches endpoint, cloud et identité via une architecture unifiée.

FAQ

Qu’est-ce qu’un Secure Web Gateway (SWG) ?

Un Secure Web Gateway est une solution de sécurité qui filtre et inspecte le trafic web au niveau de la couche applicative (couche 7). Il examine les sessions HTTP/HTTPS, catégorise les URL, analyse les téléchargements à la recherche de malwares et applique les politiques d’utilisation acceptable liées à l’identité de l’utilisateur. 

Les SWG protègent les utilisateurs contre les menaces web telles que le phishing, le vol d’identifiants et les téléchargements furtifs, tout en offrant une visibilité sur le trafic chiffré et l’utilisation de shadow IT dans l’organisation.

Un SWG peut-il remplacer complètement un Firewall ?

Pas complètement. Votre SWG inspecte le trafic web (HTTP/HTTPS) à la couche 7, tandis que votre firewall contrôle la connectivité multi-protocole aux couches 3-4 pour la segmentation et le contrôle d’accès de base. 

Un SWG ne couvre pas les protocoles non-web comme SMB, RDP ou de nombreux flux de bases de données. NIST SP 800-207 considère les deux comme des points d’application de politique à des emplacements différents, c’est pourquoi la plupart des architectures déploient les deux.

Comment les SWG et les Firewalls s’intègrent-ils dans une architecture SASE ?

SASE combine des services réseau et de sécurité délivrés dans le cloud afin que la politique suive l’utilisateur. Votre SWG gère le filtrage web, la protection contre le phishing et l’inspection des téléchargements au plus près de l’endpoint. FWaaS applique la politique réseau et la segmentation pour une couverture protocolaire plus large. 

Ensemble, ils réduisent le backhaul VPN et assurent une politique cohérente pour les utilisateurs distants. Pour plus d’informations, consultez cette présentation de SASE.

Le déploiement simultané d’un SWG et d’un firewall génère-t-il des alertes en double ?

Cela peut arriver si vous ne corrélez pas la télémétrie. Votre firewall rapporte les flux réseau, ports et états de connexion, tandis que votre SWG rapporte les catégories d’URL, les résultats d’inspection SSL/TLS et l’activité des utilisateurs. 

La centralisation des événements dans une couche d’analyse unique et l’alignement des politiques réduisent les doublons et accélèrent le triage. L’association avec  XDR améliore généralement la corrélation.

Quelle est la plus grande erreur opérationnelle lors du déploiement de SWG ?

Considérer votre SWG comme une couche de sécurité autonome. Les web gateways peuvent manquer le trafic non-web et être contournés si les appareils évitent les proxys. Les études sectorielles ont constaté une perméabilité mesurable lorsque les web gateways étaient déployés sans mesures complémentaires. 

Les résultats sont meilleurs lorsque vous associez les contrôles SWG à des couches endpoint, identité et segmentation.

Comment l’inspection SSL/TLS dans un SWG affecte-t-elle les performances ?

L’inspection SSL/TLS ajoute de la latence car le SWG doit déchiffrer, inspecter et rechiffrer le trafic. L’impact est généralement réduit en utilisant des politiques d’inspection sélective (contournement des applications à certificats épinglés), en priorisant les catégories à haut risque et en augmentant la capacité avant d’atteindre la saturation CPU. 

Il est important de tester avec votre propre mix de trafic, car les applications web varient fortement en comportement de handshake et en exigences de certificat.