Passerelle Web sécurisée vs protection DNS : que choisir
Comparez les passerelles Web sécurisées aux protections au niveau DNS pour le WiFi invité et public. Découvrez les fonctionnalités, les compromis de performance et la place de chacune dans votre infrastructure.
Published 19 octobre 2026
Si un invité rejoint votre réseau WiFi avec un ordinateur portable compromis, qu'est-ce qui empêche le rappel vers son serveur de commande, et que pouvez-vous prouver par la suite ? C'est cette question, et non une simple liste de fonctionnalités, qui doit déterminer si vous avez besoin d'un secure web gateway, d'une protection au niveau DNS, ou des deux.
Table des matières
- Pourquoi le bon niveau de protection Web est essentiel
- Ce que fait réellement une passerelle Web sécurisée
- Comment fonctionne la protection au niveau DNS
- Comparaison des fonctionnalités et des performances
- Où chaque approche s'intègre dans votre architecture
- Comment choisir la bonne approche
- Tester et vérifier votre protection
Pourquoi le choix de la bonne couche de protection web est essentiel
Un visiteur arrive dans un hôtel, ouvre un ordinateur portable et se connecte au SSID. L'appareil semble tout à fait ordinaire. Il s'authentifie, obtient une adresse et commence à résoudre des domaines, dont l'un appartient à un service de commande et de contrôle que le logiciel malveillant présent sur la machine tente de joindre depuis des jours.
À ce moment précis, vous ne contrôlez pas l'équipement terminal. Vous ne pouvez pas vérifier si son antivirus est à jour, déployer un agent ou installer un certificat pour l'inspection TLS. Vous devez intervenir sur le parcours réseau, et le niveau auquel vous appliquez la politique détermine ce que vous pouvez bloquer ainsi que les preuves dont vous disposerez ultérieurement.
La question sous-jacente à l'achat
Les opérateurs se demandent souvent quelle solution est la meilleure. C'est poser le problème à l'envers. Une passerelle web sécurisée et un service de niveau DNS appliquent les règles à des points différents, voient des éléments différents et échouent de façon différente. La véritable question est donc de savoir quel point d'application correspond à la diversité de vos équipements, à vos sites et à votre obligation de diligence.
Prenons trois situations courantes sur un même parc. La tablette d'un élève nécessite un filtrage par catégorie et Safe Search. Le téléphone d'un prestataire nécessite une protection contre le phishing sans que personne ne touche à l'appareil. Un ordinateur portable géré du personnel peut nécessiter une inspection complète des envois vers un espace de stockage non autorisé. Un seul niveau gère rarement ces trois cas de figure avec la même efficacité.
Règle pratique : Commencez par la propriété de l'appareil. Moins vous contrôlez l'équipement terminal, plus votre application doit se faire tôt et de manière native au réseau.
Se tromper à ce sujet a des conséquences visibles. Déployez une inspection en profondeur là où vous ne pouvez pas gérer les certificats et vous bloquerez des applications ou contournerez le trafic que vous vouliez inspecter. Ne comptez que sur les requêtes là où vous avez besoin de visibilité sur la charge utile et vous manquerez des menaces véhiculées au sein de sessions autrement autorisées. L'une ou l'autre erreur laisse une faille que vous découvrirez lors d'un incident, et non lors de l'achat.
L'expérience utilisateur compte tout autant. Les visiteurs jugent votre réseau en quelques secondes. Des contrôles qui ajoutent un délai perceptible, imposent des contournements au niveau du Captive Portal ou bloquent des services légitimes sans explication claire génèrent des appels au support et incitent à assouplir la politique. Les contrôles qui interviennent dès l'établissement de la connexion résistent mieux aux contraintes des sites réels.
Le choix n'est pas non plus binaire. De nombreux parcs ont besoin d'une ligne de base globale couvrant chaque appareil, associée à une inspection plus approfondie pour la population plus restreinte d'équipements gérés où cette inspection est techniquement et légalement faisable. La défense en profondeur n'est pas un simple slogan ici. C'est admettre que chaque couche prouve quelque chose de différent, et vous devez savoir exactement quoi avant de signer.
Ce que fait réellement une Secure Web Gateway
Une passerelle web sécurisée doit être comprise comme un point d'inspection et d'application des politiques pour le trafic web sortant, et non comme une simple liste noire élargie. Le NIST décrit cette fonction comme la protection du trafic utilisateur sortant via l'inspection HTTP et HTTPS, tout en centralisant le contrôle, la visibilité et le reporting pour le siège, les succursales, les bureaux à domicile et les sites distants, comme vous pouvez le lire dans le guide du NIST sur les fonctions des passerelles web sécurisées.
En pratique, le trafic est orienté vers la passerelle, soit de manière explicite via des paramètres de proxy, soit par un tunnel depuis une filiale, soit au moyen d'un agent installé sur un appareil géré. La passerelle évalue la requête par rapport à la politique définie, inspecte les données retournées et enregistre la décision. Si ce modèle de proxy ne vous est pas familial, il est utile de comprendre d'abord les concepts de redirection associés, notamment le fonctionnement des reverse proxies, avant de comparer les architectures des différents fournisseurs.
Fonctionnalités clés à évaluer
- Filtrage d'URL et de catégories : Bloque ou autorise les destinations selon la réputation et la classe de contenu, plutôt que par le seul domaine.
- Détection des logiciels malveillants et du phishing : Analyse les téléchargements et les pages, y compris le contenu des sessions autorisées où l'inspection est activée.
- Contrôles d'applications : Fait la distinction entre les services autorisés et non autorisés partageant la même infrastructure sous-jacente.
- Inspection TLS : Déchiffre et rechiffre le trafic là où vous pouvez déployer une relation de confiance, ce qui est simple sur un parc géré et délicat sur les appareils invités.
- Journalisation d'audit et portée des politiques : Enregistre qui ou quoi a demandé une ressource, quelle règle s'est appliquée et quelle action a suivi.
Ce dernier point distingue une passerelle d'une liste de blocage. Vous achetez une politique et des preuves cohérentes, appliquées de la même manière sur l'ensemble des sites, et pas seulement un flux de domaines malveillants.
Contexte de marché et de déploiement
Cette catégorie constitue désormais un domaine d'investissement majeur en matière de sécurité. Le marché des passerelles web sécurisées était estimé à 14,75 milliards USD en 2024, avec des prévisions atteignant 75,54 milliards USD d'ici 2033, soit un CAGR de 20,6 %. L'Amérique du Nord représentait 37,4 % des revenus mondiaux en 2024, d'après les estimations du marché des passerelles web sécurisées de Grand View Research. Considérez ces chiffres comme des estimations d'analystes et non comme des totaux audités, car les fournisseurs et les chercheurs définissent les limites des produits différemment.
Le déploiement s'est orienté de manière décisive vers le cloud. Le déploiement basé sur le cloud a représenté 76,32 % des revenus SWG en 2025, avec des prévisions de croissance à un CAGR de 22,05 % jusqu'en 2031, selon l'analyse des modèles de déploiement SWG par Mordor Intelligence. Cela a son importance sur le plan opérationnel. Une passerelle cloud peut appliquer une politique sans équipement physique sur chaque site, ce qui convient aux réseaux distribués, bien que cela introduise une dépendance à l'égard du routage et de la proximité des points d'inspection.
Le compromis est constant. Vous gagnez en profondeur, en visibilité sur la charge utile et en contrôle applicatif granulaire. En contrepartie, vous payez en complexité de déploiement, en gestion des certificats et en travail continu d'orientation du trafic pour assurer l'inspection.
Comment fonctionne la protection au niveau du DNS
Chaque connexion commence par une question. Avant qu'un navigateur, une application ou un programme malveillant ne puisse atteindre un service, il résout généralement un nom, et le DNS protecteur répond à cette résolution en fonction de votre politique avant même le début de la connexion.
Si le domaine est connu pour le phishing, la distribution de logiciels malveillants ou le command-and-control, le résolveur refuse ou redirige la recherche. L'appareil n'obtient jamais de destination exploitable, la tentative de connexion échoue donc le plus tôt possible. Il s'agit d'une intervention plus ciblée que l'inspection du contenu, mais qui fonctionne sans toucher à l'équipement terminal.
Ce qui se passe lors de la résolution DNS
La politique par catégorie fonctionne de la même manière. Une requête pour un domaine pour adultes ou de jeux d'argent sur un SSID familial peut être bloquée, tandis que la même recherche sur un réseau réservé au personnel suit une règle différente. L'application de Safe Search sur Google, Bing et YouTube peut être mise en œuvre via le comportement de résolution, et les domaines de publicitaires ou de traqueurs peuvent être restreints afin que les pages soient plus légères en éléments tiers.
La granularité des politiques est ce qui rend cette approche particulièrement utile sur l'ensemble d'un parc. Vous pouvez adapter les règles selon le SSID, le VLAN, le site et le calendrier, afin qu'un établissement scolaire applique un filtrage plus strict pendant les heures de cours, qu'un hôtel sépare le trafic des clients de celui des services internes, et qu'un groupe de brasseries conserve un socle commun tout en autorisant des exceptions locales. Les rapports indiquent ensuite quel domaine a été demandé, quelle politique s'est appliquée et sur quel segment réseau.
Un blocage DNS prouve qu'une résolution a été stoppée selon une politique définie à un moment enregistré. Il ne prouve pas que le contenu derrière ce domaine a été inspecté, et des rapports honnêtes ne devraient pas prétendre le contraire.
Pourquoi elle s'adapte aux appareils non gérés
Le déploiement constitue l'avantage décisif. Il n'y a aucun achat de matériel, aucune modification de pare-feu et rien à installer sur les appareils clients, de sorte que la couverture s'étend aux téléphones, aux consoles de jeu, aux téléviseurs connectés et à l'ensemble des équipements que les agents n'atteignent jamais. Un invité qui se connecte pendant vingt minutes bénéficie du même niveau de protection de base qu'un résident qui reste un trimestre.
Cette simplicité comporte des limites qu'il convient de présenter clairement. Le DNS identifie le nom en cours de résolution, mais pas le chemin d'accès URL complet ni la charge utile retournée sur une connexion autorisée. Un fichier malveillant hébergé sur un service autorisé et réputé ne sera pas détecté par la seule requête de résolution. De plus, les clients qui contournent votre résolveur via un DNS chiffré, une résolution codée en dur ou un VPN peuvent réduire la visibilité, à moins que le réseau ne gère activement ces voies d'accès.
La protection au niveau du DNS vous offre donc un contrôle étendu, précoce et étayé par des preuves, avec une friction minimale. Elle ne fournit pas d'inspection en profondeur. Savoir de quoi vous avez réellement besoin constitue l'ensemble de la décision.
Comparaison des capacités et des performances
La manière la plus claire de comparer ces niveaux est d'examiner ce que chacun peut observer. Une passerelle située sur le parcours du trafic peut inspecter les requêtes et les réponses, y compris l'intégralité des charges utiles HTTPS lorsque l'inspection TLS est légitimement déployable. La protection DNS observe la recherche qui précède la connexion. Tout le reste découle de cette différence.
Cela signifie que les menaces dissimulées dans des sessions HTTPS autorisées, les téléchargements malveillants et la perte de données via des services d'apparence légitime nécessitent des contrôles au niveau de la passerelle ou du point d'accès. Cela signifie également qu'une passerelle qui ne peut pas être placée sur le parcours d'un appareil invité n'inspecte absolument rien, quelle que soit la puissance de son moteur. Une couverture que vous pouvez appliquer sur le terrain surpasse une capacité théorique inexploitable.
Aperçu comparatif : SWG et protection au niveau du DNS
| Critère | Passerelle Web sécurisée | Protection au niveau DNS |
|---|---|---|
| Profondeur d'inspection | Requête et réponse complètes lorsqu'il est sur le chemin d'accès | Résolution de domaine avant la connexion |
| Couverture des appareils | Optimum sur les appareils gérés | Chaque appareil utilisant le résolveur |
| Impact sur les performances | Dépend de l'inspection et de la distance au point de présence | Minime, limité à la résolution |
| Complexité de déploiement | Routage, tunnels, agents ou certificats | Configuration du résolveur par réseau |
| Qualité des éléments de preuve | URL, utilisateur, action et verdicts sur le contenu | Domaine, politique, segment, horodatage, action |
| Point aveugle principal | Trafic qui contourne le chemin du proxy | Charges utiles à l'intérieur des sessions autorisées |
La qualité des flux sous-tend les deux lignes de ce tableau. L'exactitude des catégories, leur fraîcheur et la vitesse de re-catégorisation déterminent si l'un ou l'autre contrôle bloque les bons éléments. Il convient donc de comprendre comment les flux de threat intelligence façonnent les décisions de filtrage avant de comparer les affirmations des fournisseurs.
Des performances mesurables
Ne comparez pas un chiffre de débit de fiche technique avec le chargement de page d'un invité. Les recommandations indépendantes relatives aux SWG font état d'environ 40 à 80 ms de latence supplémentaire lorsque les utilisateurs sont proches d'un point de présence cloud, et d'environ 150 à 400 ms lorsqu'ils en sont éloignés, tandis qu'une fiche technique d'équipement publiée indique jusqu'à 110 Gbit/s de débit de pare-feu et plus de 25 Gbit/s de débit IPS dans des conditions de laboratoire, des chiffres détaillés dans la fiche technique des équipements Check Point et le guide de performance SWG. Ces chiffres décrivent des éléments différents. Le débit en laboratoire ne vous apprend pas grand-erreur sur le temps de poignée de main TLS sur un site rural congestionné aux heures de pointe. p>
Mesurez plutôt ce que ressentent les visiteurs. Comparez la sécurité activée par rapport à la sécurité désactivée sur des sites représentatifs, pendant les heures de pointe, et indiquez la médiane ainsi que la latence p95 et p99 pour la résolution DNS, l'établissement TLS et le temps d'affichage des contenus utiles. Les moyennes masquent les pires sites, qui sont précisément ceux dont proviennent les réclamations.
L'écart lié à QUIC et au DNS chiffré
QUIC fonctionne sur UDP, exige le chiffrement TLS 1.3 et prend en charge la migration de connexion entre le réseau WiFi et les réseaux cellulaires. Cela crée une lacune dans l'application des règles pour les passerelles conventionnelles, comme le décrit une étude sur le relais et le transfert de trafic adaptés à QUIC. Le blocage d'UDP sur le port 443 peut forcer un basculement vers TCP inspectable, mais cela peut dégrader les performances ou perturber les applications modernes. Autoriser QUIC préserve l'expérience utilisateur tout en réduisant ce qu'une passerelle traditionnelle peut analyser.
La politique DNS s'applique toujours au moment de la résolution si le client utilise votre résolveur, c'est pourquoi ces deux contrôles répondent à des questions différentes. Demandez aux fournisseurs de définir précisément la notion de « bloqué ». La résolution a-t-elle été interrompue, la connexion a-t-elle été empêchée ou le contenu a-t-il réellement été inspecté ? Il s'agit de trois affirmations bien distinctes.
Où chaque approche s'intègre dans votre architecture
Le type d'établissement permet de prédire la réponse bien mieux que la taille de l'organisation. Un bon point de départ consiste à examiner la propriété des appareils sur chaque SSID, puis à mapper les besoins d'inspection sur cette réalité, une approche également reflétée dans les conseils de sécurité de Nerds 2 You Edmonton pour les petits réseaux qui évaluent les contrôles multicouches.
Le secteur de l'hôtellerie, les aéroports, les bibliothèques et les sites touristiques gèrent des réseaux où presque tous les appareils sont temporaires et non gérés. La protection au niveau du DNS est idéale car elle couvre immédiatement les visiteurs, gère les accès gratuits ou payants via des politiques par SSID, et apporte la preuve du filtrage sans inspecter le contenu personnel. Une passerelle n'apporte pas grand-chose si vous ne pouvez pas orienter ou déchiffrer le trafic des visiteurs de manière responsable.
Les écoles, les campus et les logements étudiants se situent au milieu. Les obligations de protection exigent un filtrage par catégorie cohérent et l'activation de Safe Search sur chaque appareil, y compris les téléphones personnels et les consoles. Les appareils d'enseignement gérés peuvent toutefois justifier une inspection au niveau de la passerelle pour le contrôle des applications et l'analyse des téléchargements, c'est pourquoi de nombreux établissements superposent les deux et les appliquent à des segments différents.
Il est intéressant d'observer en pratique la logique opérationnelle qui sous-tend cette séparation.
Les hôpitaux et les établissements de santé sont confrontés à une division similaire. Le WiFi pour les patients et les visiteurs nécessite un filtrage large et fluide. Les systèmes cliniques et administratifs reposent quant à eux sur des contrôles plus stricts et régis séparément ; mélanger ces populations sous un seul modèle d'inspection ne sert généralement bien ni l'un ni l'autre.
Où une passerelle justifie son coût
Les bureaux d'entreprise et les structures multi-sites gérant des flottes d'équipements constituent le terrain de prédilection de la passerelle. Vous pouvez déployer des agents ou des tunnels, gérer des certificats, associer la politique de sécurité à l'identité et inspecter les envois de données vers des services non autorisés. Les segments BYOD dans ces mêmes bureaux nécessitent toujours une réflexion distincte, car les appareils personnels résistent précisément aux contrôles qui font l'efficacité d'une passerelle, une tension examinée dans les recommandations sur la sécurité BYOD pour les parcs d'équipements mixtes.
- SSID invités et publics : niveau de référence au niveau DNS, pages de blocage transparentes, rapports par site.
- Réseaux étudiants et résidents : filtrage DNS global, contrôles par passerelle sur les appareils gérés.
- Segments personnel et entreprise : inspection par passerelle liée à l'identité, avec le DNS comme premier niveau de blocage.
- Technologies opérationnelles et affichage : politique DNS pour les appareils ne pouvant pas exécuter d'agents, listes d'autorisations strictement définies.
Le modèle hybride n'est pas une hésitation. Il s'agit d'attribuer chaque couche à la population d'utilisateurs où son application est effective.
Comment choisir la bonne approche
Trois questions permettent de trancher la plupart des évaluations. À qui appartiennent les équipements, quel niveau d'inspection votre posture de risque ou de conformité exige-t-elle, et de quelle capacité opérationnelle disposez-vous pour exécuter correctement le contrôle ? Répondez-y par segment de réseau, et non pour l'organisation dans son ensemble.
Si les appareils non gérés prédominent, commencez par une protection au niveau du DNS par défaut. Elle couvre chaque tentative de connexion utilisant votre résolveur, se déploie sans intervention sur les équipements, et vous fournit des preuves auditables de ce qui a été bloqué, où et quand. Pour les hôtels, les pubs, les aéroports et le WiFi public, c'est le contrôle qui continuera de fonctionner un samedi chargé quand personne n'est disponible pour dépanner une exception de proxy.
Si les appareils gérés prédominent et que vous avez besoin d'inspection de la charge utile, de contrôle des applications ou de prévention contre la perte de données, choisissez une passerelle web sécurisée et financez le travail opérationnel qu'elle exige. Cela inclut l'orientation du trafic, le cycle de vie des certificats, la gestion des exceptions pour les applications avec verrouillage de certificat (certificate pinning) et la planification de la capacité pour les points d'inspection. Acheter la licence sans ce travail d'accompagnement ne vous offre qu'une couverture partielle.
La fiabilité plutôt que les listes de fonctionnalités
Méfiez-vous des affirmations de détection que vous ne pouvez pas vérifier. Des recherches indépendantes évaluant les outils de contrôle parental ont révélé une protection inégale selon les fournisseurs, aucun outil n'offrant une couverture complète, tandis que le filtrage par résolveur DNS s'est avéré plus constant que plusieurs alternatives. De plus, Cloudflare a signalé que les liens trompeurs représentaient 52 % des e-mails malveillants analysés en 2025, contre 43 % en 2024, selon une étude indépendante sur la couverture des outils de filtrage et les tendances des liens trompeurs.
Test de sélection : Demandez à chaque fournisseur avec quelle rapidité un nom de domaine nouvellement enregistré est classé, comment fonctionnent les recours en re-catégorisation, et quelles preuves un simple blocage produit. Des réponses vagues préfigurent des difficultés opérationnelles.
Pour la plupart des parcs mixtes, la recommandation la plus honnête est de combiner les deux, dans un ordre logique. Déployez d'abord le socle DNS car il est rapide, couvre les appareils qu'aucun autre outil ne touche, et crée immédiatement des preuves à l'échelle de l'ensemble du parc. Ajoutez l'inspection par passerelle là où la propriété des appareils et le niveau de risque le justifient. Cet ordre comble d'abord la plus grande faille au lieu de perfectionner la protection des appareils les plus faciles à gérer.
Tester et vérifier votre protection
N'acceptez pas une simple capture d'écran de tableau de bord comme preuve. Exécutez un test d'acceptation sur vos propres SSIDs, avec votre propre éventail d'équipements, avant de vous engager. Structurez-le en fonction du comportement réel du trafic plutôt que des schémas commerciaux. Pour concevoir des tests plus larges, consultez les recommandations de ThreatExploit AI sur la mise en place de routines de tests de sécurité répétables.
Un test de recette vrai et significatif
Mesurez le filtrage séparément pour le DNS, HTTP, HTTPS, QUIC, le DNS chiffré et IPv6, puis vérifiez que les résultats restent uniformes sur l'ensemble des SSIDs, VLANs, sites et plages horaires. Un blocage qui fonctionne sur le réseau du personnel mais pas sur le VLAN visiteur, ou pendant la journée mais pas sous une politique du soir, constitue un problème majeur, pas une simple remarque.
- Recherches malveillantes connues : Confirmez que les domaines de test de phishing, de logiciels malveillants et de commande et contrôle sont bloqués et enregistrés avec la politique et le segment.
- Vérifications de catégories : Vérifiez les catégories pour adultes, de jeux d'argent et autres catégories restreintes sur chaque SSID, ainsi que le comportement de Safe Search sur les principaux services de recherche et vidéo.
- Tentatives de contournement : Essayez le DNS chiffré, un VPN grand public, l'accès IP direct et les navigateurs compatibles QUIC, puis enregistrez ce que chaque contrôle continue de voir.
- Nouveaux domaines : Testez les domaines récents non catégorisés et notez si la politique par défaut autorise, bloque ou avertit.
- Services légitimes : Confirmez que les applications de paiement, de conférence et critiques pour le site fonctionnent toujours sans que les exceptions manuelles ne s'accumulent.
Comportement en cas de panne et performances
Testez délibérément le comportement fail-open par rapport au fail-closed en interrompant le service ou le tunnel. Vous devez savoir si une panne entraîne une navigation bloquée ou un réseau non filtré, et ce que votre devoir de diligence peut tolérer. Documentez ce comportement dans votre registre des risques, car les auditeurs vous le demanderont. La même rigueur en matière de preuves soutient des travaux d'assurance plus larges, notamment les contrôles décrits dans le guide sur les exigences de la certification Cyber Essentials.
Effectuez des tests comparatifs sur des sites représentatifs pendant les heures de pointe. Enregistrez le temps de chargement des contenus utiles, le temps de résolution DNS, le temps de négociation TLS et le débit en présence d'utilisateurs simultanés, en comparant la sécurité activée par rapport à la sécurité désactivée et en indiquant la médiane ainsi que p95 et p99. Incluez la perte de tunnel ou de point de présence afin d'observer le comportement de reconnexion avant que les visiteurs ne le fassent.
Enfin, inspectez les preuves elles-mêmes. Chaque blocage doit conserver l'horodatage, la politique, le segment réseau, le domaine demandé, l'action et le motif. Un compteur global ne satisfera ni un responsable de la protection, ni un assureur, ni votre propre examen d'incident. Si le rapport ne permet pas de reconstruire une décision individuelle, le contrôle n'est pas abouti, peu importe ce qu'il a bloqué.
Purple Shield fournit un DNS protecteur et un filtrage de contenu conçus pour le WiFi invité, public et d'établissement, en vérifiant chaque requête avant le début d'une connexion et en appliquant la politique par SSID, VLAN, site et calendrier, sans aucun agent sur les appareils des utilisateurs. Si vous souhaitez disposer de ces éléments de preuve de référence sur l'ensemble de votre parc tout en déterminant où une inspection plus approfondie par passerelle s'impose, rendez-vous sur Purple Shield pour découvrir comment le déployer sur votre réseau existant.