Configurer la protection Web de Sophos Firewall avec des politiques Web

La protection Web de Sophos Firewall contrôle les sites Web, les catégories et les contenus Web auxquels les utilisateurs peuvent accéder. En pratique, la protection Web n’est pas simplement un paramètre à cocher. Une politique Web doit être planifiée de manière professionnelle, activée dans une règle de pare-feu appropriée, puis testée avec un trafic réel.

De nombreuses erreurs surviennent parce qu’une politique Web existe mais n’est appliquée à aucune règle de pare-feu active. D’autres problèmes sont liés à HTTPS, à l’inspection TLS, à QUIC, à la reconnaissance des utilisateurs, à l’ordre des règles ou à des exceptions trop larges. Le processus logique est donc : planifier la politique, construire la règle, l’activer, la tester et la surveiller en fonctionnement.

Quel article sur la protection Web est adapté ?

La protection Web chevauche les règles de pare-feu, l’inspection TLS, QUIC, le reporting et les exceptions. Selon la tâche, un article plus spécifique peut être plus approprié :

• Configurer fondamentalement la protection Web et les politiques Web: Cet article.
• Évaluer les catégories Web, les groupes d’URL et les alertes instantanées: Utiliser les catégories Web et les alertes instantanées de Sophos Firewall.
• Déchiffrer et examiner le trafic HTTPS: Introduire correctement l’inspection TLS de Sophos Firewall.
• Distribuer le certificat CA pour les clients gérés: Distribuer le certificat CA de Sophos Firewall pour l’inspection TLS.
• Classer QUIC et HTTP/3 en cas de problèmes de filtrage Web: Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall.
• Découvrir quelle règle de pare-feu et quelle politique s’appliquent réellement: Tester les règles de Sophos Firewall avec Log Viewer, Policy tester et Packet Capture.
• Analyser les événements Web et de sécurité sur une plus longue période: Central Firewall Reporting ou Envoyer Syslog à SIEM.

Ainsi, l’analyse reste claire : il faut d’abord s’assurer que la règle de pare-feu correspond. Ensuite, on vérifie la politique Web, la catégorie, le contexte utilisateur, QUIC, l’inspection TLS et la journalisation.

Ce que contrôle la protection Web

La protection Web se compose de plusieurs éléments. Tous les éléments ne doivent pas être utilisés dans chaque environnement, mais les relations doivent être claires.

• Politique Web: Règles pour les accès Web autorisés, avertis, bloqués ou basés sur des quotas.
• Catégories Web: Catégories Sophos et catégories personnalisées pour les sites Web.
• Groupes d’URL: Listes de domaines personnalisées pour des règles d’autorisation ou de blocage ciblées.
• Types de fichiers: Contrôle de certains types de téléchargements ou de fichiers.
• Filtres de contenu: Termes ou modèles pour le contrôle du contenu.
• Exceptions: Exceptions ciblées au comportement Web, TLS ou de scan.
• Paramètres généraux: SafeSearch, restrictions YouTube, Google Apps et restrictions de locataire Microsoft Entra ID.
• Journalisation et reporting: Traçabilité dans Log Viewer, Reporting, Central ou SIEM.

La protection Web ne remplace pas une base de règles de pare-feu propre. La règle de pare-feu décide d’abord quel trafic est autorisé de quelle zone à quelle zone cible. La politique Web complète cette règle par un contrôle Web. Les bases de l’ordre des règles, de la source, de la destination, des services et des profils de sécurité sont expliquées dans Comprendre et construire proprement les règles de Sophos Firewall.

Prérequis

Avant le déploiement, ces points doivent être clarifiés :

• La protection Web est sous licence ou incluse dans le bundle utilisé.
• Les réseaux clients concernés ont leurs propres règles de pare-feu.
• La journalisation est activée dans les règles pertinentes.
• Le DNS et l’heure du pare-feu fonctionnent correctement.
• La reconnaissance des utilisateurs est clarifiée si des politiques s’appliquent par utilisateur ou groupe.
• L’inspection TLS est planifiée si le contenu HTTPS doit être examiné plus en détail.
• QUIC/HTTP/3 est consciemment autorisé ou bloqué.
• Il existe un groupe pilote et un plan de secours pour les sites critiques pour l’entreprise.

Il est particulièrement important de séparer les groupes cibles. Une politique Web pour les clients normaux, les serveurs, les invités, les utilisateurs VPN et les systèmes de gestion ne devrait pas être la même. Les serveurs ont souvent besoin de moins de contrôle de navigation, mais de listes de cibles et de mises à jour plus strictes. Les invités ont souvent besoin de catégories et de limitations de bande passante, mais pas d’accès aux ressources internes.

Si les politiques Web doivent réagir aux utilisateurs ou aux groupes, la reconnaissance des utilisateurs doit fonctionner. AD SSO, Captive Portal, STAS, SATC ou d’autres méthodes ne devraient pas être découverts seulement pendant le déploiement de la politique Web. Dans le Log Viewer, il doit être visible si une requête a été évaluée comme utilisateur connu, comme groupe ou comme Anybody ou utilisateur inconnu.

Planifier la politique Web

Une bonne politique Web ne commence pas dans l’interface, mais par quelques décisions professionnelles.

Définir les groupes cibles

Tout d’abord, il est déterminé pour qui la politique s’applique :

• Clients standard dans le LAN
• Ordinateurs portables gérés via VPN
• Wi-Fi invité
• Salles de formation ou environnements scolaires
• Serveurs avec accès HTTP/HTTPS sortant
• Postes de travail administratifs privilégiés

Si la même règle de pare-feu contient plusieurs groupes très différents, la protection Web devient difficile à comprendre. Il est préférable d’avoir des règles et des politiques séparées, par exemple LAN_USERS_WEB, GUEST_WEB ou SERVER_UPDATES_WEB.

Définir les catégories et les groupes d’URL

Les catégories Web Sophos sont bonnes pour un contrôle large : Malware, Phishing, Contenu adulte, Anonymiseurs, Streaming, Réseaux sociaux ou Jeux. Les groupes d’URL sont meilleurs lorsque des domaines individuels doivent être autorisés ou bloqués de manière ciblée.

Utilisation typique :

• Bloquer les catégories de risques connues: Catégorie Web.
• Autoriser certains domaines SaaS: Groupe d’URL.
• Traiter un domaine mal catégorisé: Groupe d’URL ou catégorie personnalisée.
• Limiter le streaming dans le temps: Politique Web avec horaire ou quota.
• Page d’avertissement au lieu de blocage dur: Politique Web avec action d’avertissement.

Les groupes d’URL ne doivent pas devenir une liste de collecte non triée. Si de nombreux domaines sont inscrits, la liste a besoin d’un propriétaire, d’un objectif et d’une date de révision. Pour des listes très grandes ou dynamiques, les Sophos Firewall Threat Feeds ou d’autres éléments d’architecture sont souvent plus appropriés.

Pour les correspondances purement par domaine, les groupes d’URL sont généralement préférables aux catégories Web personnalisées. Sophos indique que les groupes d’URL sont plus performants et peuvent générer moins de faux positifs. Les catégories personnalisées sont utiles lorsqu’un domaine doit aussi apparaître dans une logique de politique propre en plus de sa catégorie Sophos standard.

Les mots-clés dans les catégories personnalisées doivent être utilisés avec beaucoup de prudence. Les mots-clés sont vérifiés sur l’URL complète, y compris le chemin et la requête. Une autorisation basée sur un mot-clé peut donc s’appliquer involontairement si ce mot apparaît dans un paramètre de requête sur un autre domaine. Pour les décisions d’autorisation, des domaines concrets ou des groupes d’URL sont généralement plus propres ; les règles par mot-clé conviennent plutôt à des cas de blocage étroits.

Définir prudemment les règles d’autorisation

Les règles d’autorisation dans les politiques Web doivent être strictes. Une règle d’autorisation en haut peut rendre inefficaces les règles de blocage ultérieures, car les règles de politique Web de Sophos sont évaluées de haut en bas. Cela est particulièrement pertinent si un groupe d’URL, une règle de type de fichier ou une exception de catégorie se trouve au-dessus d’autres règles.

En pratique, il est recommandé de :

1. Exceptions commerciales spécifiques autorisées en haut.
2. Catégories de blocage critiques ensuite.
3. Règles d’avertissement ou de quota pour les zones grises.
4. Trafic Web généralement autorisé seulement à la fin.

Créer une politique Web

La politique Web est créée dans le menu suivant :

Web > Policies

Processus de base :

1. Sélectionner Add policy.
2. Donner un nom explicite, par exemple LAN_USERS_STANDARD_WEB.
3. Ajouter des règles.
4. Vérifier search engine enforcement, par exemple SafeSearch ou YouTube restrictions.
5. Définir policy quota status si des actions Quota sont utilisées.
6. Vérifier Advanced settings, notamment logging, reporting, les gros téléchargements, Google Apps et Microsoft Entra ID Tenant Restrictions.
7. Enregistrer la politique.

Une règle au sein de la politique Web est créée avec Add rule. Le pare-feu crée d’abord une règle par défaut désactivée qui bloque HTTP pour Anybody. Les champs sont ensuite ajustés de manière ciblée :

1. Ouvrir Users et définir délibérément Anybody, des utilisateurs précis ou des groupes.
2. Ouvrir Activities et sélectionner All web traffic, User activities, Categories, URL Groups, File types ou Content filters.
3. Ajouter des Content filters si nécessaire. Pour les Content filters, le pare-feu utilise la même action pour HTTPS que pour HTTP.
4. Définir Action pour HTTP : Allow, Warn, Block ou Quota.
5. Vérifier l’action HTTPS : Use action, Allow HTTPS, Warn HTTPS, Block HTTPS ou Quota HTTPS.
6. Définir Constraints si la règle ne doit s’appliquer qu’à un horaire.
7. Vérifier la position de la règle au sein de la politique.
8. Activer l’état de la règle.
9. Enregistrer la politique.

Une politique Web seule n’a pas d’effet. La politique doit ensuite être utilisée dans une règle de pare-feu. C’est l’une des erreurs de configuration les plus courantes.

Les règles d’une politique Web sont évaluées de haut en bas. Une règle Allow pour All web traffic placée au-dessus d’une règle Block rend cette dernière pratiquement inefficace. Après chaque modification, il faut donc vérifier non seulement le contenu de la règle, mais aussi l’ordre et le commutateur d’état.

Activer la politique Web dans la règle de pare-feu

La règle de pare-feu se trouve sous :

Rules and policies > Firewall rules

Pour le trafic Internet client normal, une règle de LAN ou d’une zone client vers WAN est généralement responsable. Dans la section Web filtering, la politique Web appropriée est sélectionnée.

Points de vérification dans la règle de pare-feu :

• La zone source et les réseaux source correspondent au réseau client.
• La zone de destination est généralement WAN.
• Les services incluent HTTP/HTTPS ou les services Web souhaités.
• Log firewall traffic est activé.
• Dans la section Web filtering, la bonne politique Web est définie.
• Scan HTTP and decrypted HTTPS est activé lorsque le scan des malwares Web ou du contenu doit s’appliquer.
• Use Zero-day protection n’est utile que si les fichiers sont scannés via HTTP ou HTTPS déchiffré.
• Block QUIC protocol est consciemment défini.
• Use web proxy instead of DPI engine est activé ou désactivé consciemment.
• L’inspection TLS est planifiée séparément et non confondue avec la politique Web.

Sophos Firewall active Block QUIC protocol par défaut lorsqu’une politique Web est sélectionnée dans la règle ou lorsque Scan HTTP and decrypted HTTPS est activé. C’est souvent judicieux, car QUIC ne peut pas être scanné comme le trafic HTTPS classique. Il ne faut toutefois pas simplement accepter cette option sans test : les navigateurs, les services Google, les outils de collaboration et certaines applications SaaS peuvent changer de comportement lorsque QUIC est bloqué.

Si Application Control est aussi utilisé dans la même règle de pare-feu, il existe un chevauchement important : certaines Micro Apps, par exemple les chargements ou téléchargements dans Dropbox ou Gmail, sont reconnues via des détails d’URL. Dans les environnements DPI, cette détection nécessite une règle SSL/TLS Inspection adaptée avec déchiffrement. Application Control peut alors évaluer ces Micro Apps même si la politique Web elle-même n’est pas le point de décision principal.

Si une règle plus générale au-dessus de la règle Web souhaitée correspond, le trafic n’atteint pas la politique Web. Dans de tels cas, Tester les règles de Sophos Firewall avec Log Viewer et Packet Capture peut aider.

Classer HTTPS, l’inspection TLS et QUIC

Une grande partie du trafic Web est HTTPS. Sans inspection TLS, le pare-feu voit moins de contenu. Les catégories, SNI, certificats, IP de destination, informations de domaine et métadonnées aident, mais ne remplacent pas une inspection complète du contenu.

DPI ou Web Proxy ?

Avec la protection Web, il faut décider tôt si la règle de pare-feu concernée utilise le DPI Engine ou le Web Proxy. Cette décision influence quelles fonctions s’appliquent et quels journaux sont pertinents par la suite.

• Mode DPI: Standard moderne pour de nombreuses règles Internet client. L’inspection TLS fonctionne via les règles d’inspection SSL/TLS, le quota n’est pas pris en charge.
• Mode Web Proxy: Environnements avec comportement de proxy explicite ou quota de politique. Vérifier le comportement du proxy, la compatibilité navigateur/client et les journaux du proxy.

Dans de nombreuses installations, le mode DPI est le meilleur point de départ. Cependant, si des quotas de temps sont nécessaires, une règle purement DPI ne suffit pas. Dans ce cas, le mode Web Proxy doit être planifié et testé consciemment. Cette décision doit être prise avant le déploiement, car un changement ultérieur peut entraîner d’autres problèmes, journaux et expériences utilisateur.

Le Web Proxy ne filtre dans la règle de pare-feu que les ports classiques 80 et 443. Le DPI Engine peut inspecter le trafic HTTP et SSL/TLS sur d’autres ports également, à condition que la règle et les règles SSL/TLS Inspection correspondent. Dans les conceptions avec proxy direct, il faut aussi savoir clairement si les clients utilisent explicitement le proxy ou si le trafic client transparent normal passe par la règle. Sinon, on teste facilement le mauvais chemin.

Inspection TLS

Si les téléchargements, le scan des malwares, certaines catégories Web ou les contrôles de contenu doivent être vérifiés de manière fiable, l’inspection TLS doit être planifiée. Cela nécessite un certificat CA de confiance sur les clients, des règles TLS appropriées, des exceptions et un pilote propre.

Le déploiement est décrit dans Déployer progressivement l’inspection TLS sur Sophos Firewall. Pour distribuer et valider le certificat CA, consultez Installer le certificat CA de Sophos Firewall pour le scan HTTPS.

QUIC et HTTP/3

Les navigateurs modernes utilisent souvent QUIC ou HTTP/3 via UDP 443. Cela peut perturber les attentes de filtrage Web, d’inspection TLS et de scan si l’on souhaite examiner le trafic HTTPS classique via TCP.

Dans de nombreux environnements d’entreprise, il est judicieux de bloquer QUIC dans les règles Internet client, afin que les navigateurs reviennent à HTTPS via TCP. Les détails sont expliqués dans Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall.

SafeSearch, YouTube et restrictions de locataire

Sophos Firewall peut définir des contrôles de recherche et de cloud supplémentaires dans les politiques Web.

Options typiques :

• Enforce SafeSearch pour Google, Yahoo et Bing.
• Enforce YouTube restrictions pour les contenus YouTube restreints.
• Restrict login domains for Google Apps pour les domaines Google autorisés.
• Apply Microsoft Entra ID tenant restrictions pour le contrôle des locataires cloud Microsoft.

Ces fonctions sont utiles, mais pas magiques. Avec HTTPS, leur efficacité dépend partiellement du scan HTTPS ou de l’inspection TLS. De plus, elles ne remplacent pas la gouvernance des identités et des applications cloud dans Microsoft 365 ou Google Workspace. Pour les environnements de production, il est conseillé de tester leur efficacité avec de vrais utilisateurs de test et les navigateurs concernés.

Pour Bing et Yahoo, SafeSearch ne peut être imposé sur les connexions HTTPS que si HTTPS scanning est actif dans la règle de pare-feu concernée. Les restrictions de connexion Google Apps ne s’appliquent qu’aux domaines hébergés par Google. Les Microsoft Entra ID Tenant Restrictions nécessitent des valeurs de tenant propres et doivent être testées avec de vraies connexions au cloud Microsoft, pas seulement avec une URL d’exemple.

Quota et pages d’avertissement

Les politiques Web peuvent non seulement bloquer ou autoriser. Avec des actions d’avertissement ou de quota, on peut informer consciemment les utilisateurs ou permettre un accès limité dans le temps.

Exemples pertinents :

• Les utilisateurs peuvent confirmer consciemment un avertissement pour certaines zones grises.
• Le streaming ou le shopping est autorisé uniquement de manière limitée dans le temps.
• Les environnements scolaires ou de laboratoire autorisent certaines catégories uniquement pendant des périodes définies.

Important : le quota de politique n’est pas pris en charge en mode DPI. Si des quotas de temps sont nécessaires, le mode Web Proxy doit être utilisé. Cela doit être décidé tôt, car DPI et Web Proxy ont des caractéristiques et des limites différentes.

L’allowed time quota est défini au niveau de la politique Web et s’applique à toutes les règles de cette politique qui utilisent une action Quota. Si deux catégories nécessitent des quotas de temps différents, des politiques Web séparées sont plus propres qu’une seule politique avec des attentes de quota mélangées. Les quotas sont réinitialisés localement à minuit et ne peuvent pas être définis sur zéro.

Les Policy Overrides sont un autre outil que les quotas. Ils permettent à des utilisateurs autorisés dans le User Portal de créer un accès temporaire à des sites Web normalement bloqués. Cela peut être utile pour les écoles ou les scénarios de support, mais nécessite des limites claires : catégories non contournables, personnes autorisées, fenêtres de temps et révision des overrides.

Web Exceptions et exceptions TLS

Les Web Exceptions sont puissantes et donc dangereuses lorsqu’elles sont utilisées comme correction rapide. Une exception sous Web > Exceptions peut ignorer des contrôles de protection pour le trafic correspondant, indépendamment de la politique Web qui s’applique actuellement. Selon la sélection, HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection ou Policy checks sont ignorés.

Dans les environnements DPI, une restriction importante s’applique : les Web Exceptions ne prennent effet que lorsqu’une politique Web est définie, que Malware and content scanning est actif ou qu’ATP est actif. Les SSL/TLS Exclusion Rules sont en revanche le bon endroit lorsqu’il s’agit uniquement de ne pas déchiffrer certaines connexions TLS. La différence opérationnelle est importante :

• SSL/TLS Exclusion Rule: exclut de manière ciblée les connexions TLS du déchiffrement, typiquement à cause du Certificate Pinning ou d’une incompatibilité.
• Web Exception: peut ignorer les contrôles de politique Web, le scan des malwares, l’analyse Zero-Day ou la validation des certificats.
• URL Group in Web Policy: contrôle Allow, Warn, Block ou Quota dans la logique normale de la politique.

Pour les exceptions, il faut éviter les domaines racine et les motifs URL regex trop larges. Un motif comme example.com peut aussi apparaître dans les chemins ou les paramètres de requête d’autres domaines. De meilleurs choix sont des noms d’hôte concrets, des groupes d’URL adaptés et un périmètre clair par source, destination, catégorie ou groupe d’utilisateurs.

Les exceptions combinent leurs différents critères avec AND. Au sein d’un même type de critère, par exemple plusieurs URL Patterns, OR s’applique. C’est pratique, mais sujet aux erreurs : une exception avec URL Pattern et Source IP ne s’applique que si les deux correspondent. Une exception avec de nombreux URL Patterns peut en revanche agir beaucoup plus largement que prévu.

Il faut être particulièrement prudent avec Policy checks. Si une Web Exception ignore les Policy checks, cela peut affaiblir indirectement d’autres décisions de règles. En combinaison avec Synchronized Security Heartbeat, une telle exception peut faire que des requêtes Web ne soient pas bloquées comme prévu, même si les contrôles Heartbeat sont définis dans la règle de pare-feu.

Tester la protection Web

Après l’enregistrement, il ne suffit pas de vérifier si la politique existe. Ce qui est crucial, c’est de savoir si elle s’applique au trafic réel.

1. Utiliser le Policy Tester

Sous Web > Policies, le Policy tester est disponible. Il permet de vérifier quelle décision de politique est attendue pour un utilisateur, une URL et un contexte.

Le Policy Tester est un bon pré-test, mais ne remplace pas un flux de paquets réel. Une règle de pare-feu, un NAT, une inspection TLS, un QUIC ou un routage peuvent toujours empêcher que la politique attendue s’applique au trafic réel.

2. Test réel avec un client pilote

Avec un client pilote, vérifier :

• Site commercial autorisé
• Catégorie bloquée
• Catégorie avertissante
• Autorisation de groupe d’URL
• Blocage de groupe d’URL
• Page HTTPS avec et sans inspection TLS
• Téléchargement d’un type de fichier de test inoffensif
• Comportement avec QUIC activé ou bloqué

3. Vérifier le Log Viewer

Dans le Log Viewer, il devrait être visible :

• Quelle règle de pare-feu a été atteinte
• Quel utilisateur a été reconnu, si pertinent
• Quelle catégorie Web ou groupe d’URL a été impliqué
• Si HTTPS, l’inspection TLS ou le scan des malwares ont été impliqués
• Si l’action a été autorisée, avertie ou bloquée
• Si une Web Exception ou une TLS Exclusion s’est appliquée
• Si un téléchargement a été traité différemment en raison de sa taille, d’une erreur de scan des malwares ou d’une analyse Zero-Day

Pour Syslog ou SIEM, l’URL et l’action ne suffisent pas. Une analyse fiable nécessite aussi Firewall Rule ID, utilisateur, catégorie, politique Web, méthode HTTP, statut, résultat de scan, indication d’exception et relation SSL/TLS. Si ces champs manquent dans le SIEM ou sont mal normalisés, la protection Web paraît vite moins claire dans le reporting qu’elle ne l’est réellement sur le pare-feu.

Pour un dépannage plus approfondi, les fichiers journaux sont également pertinents. La correspondance est expliquée dans Dépannage de Sophos Firewall : Services et journaux.

Alertes instantanées et reporting

Si certaines catégories ne doivent pas seulement être bloquées, mais signalées activement, les alertes instantanées peuvent être utiles. Cela est particulièrement utile dans les écoles, les environnements strictement réglementés ou les zones avec une politique claire d’utilisation d’Internet.

Les trois voies d’évaluation répondent à différentes questions :

• E-mail rapide pour quelques catégories Web sensibles: Alertes instantanées.
• Rapports récurrents, tendances et évaluations par utilisateur ou catégorie: Central Firewall Reporting.
• Conservation à long terme, corrélation avec d’autres systèmes ou processus SOC: Syslog ou SIEM.

Avant les alertes instantanées, il doit être clair qui reçoit l’alerte, quelles catégories déclenchent réellement une réaction, comment les faux positifs sont traités et quand la sélection des catégories est vérifiée. Une liste d’alertes large sans propriétaire génère rapidement du bruit par e-mail, mais pas une meilleure sécurité.

Pour l’activation technique et le triage, consultez Utiliser les catégories Web et les alertes instantanées de Sophos Firewall. Pour des évaluations à plus long terme, Central Firewall Reporting ou Envoyer Syslog à SIEM devraient être examinés.

Gérer les changements et les exceptions en fonctionnement

La protection Web évolue constamment en fonctionnement. De nouveaux services SaaS apparaissent, des domaines individuels sont mal catégorisés, des départements ont besoin d’un accès temporaire et le comportement des navigateurs change. Sans processus clair, des exceptions larges apparaissent rapidement, que personne ne peut plus expliquer par la suite.

Pour chaque changement, il faut au moins noter :

• Qui a besoin de l’accès ? Empêche les exceptions globales pour quelques utilisateurs.
• Quel domaine, catégorie ou type de fichier est concerné ? Sépare proprement le groupe d’URL, la catégorie Web et le type de fichier.
• Est-ce une exception temporaire ou permanente ? Implique une révision au lieu de libérations d’ombre permanentes.
• Quelle règle de pare-feu et quelle politique Web sont concernées ? Empêche les modifications sur la mauvaise règle.
• Comment sera-t-il testé ? Rend le succès traçable dans le Log Viewer.

Un petit processus de changement a fait ses preuves :

1. Enregistrer la demande avec l’utilisateur, l’URL, le moment, la raison commerciale et une capture d’écran ou un message d’erreur.
2. Dans le Log Viewer, vérifier quelle règle de pare-feu, politique Web, catégorie et action ont été appliquées.
3. Décider si la catégorie est fondamentalement incorrecte, si seul un domaine individuel doit être autorisé ou si la demande est rejetée.
4. Si une exception est nécessaire, travailler aussi étroitement que possible : groupe d’URL individuel au lieu de catégorie entière, groupe d’utilisateurs individuel au lieu de tout le LAN.
5. Tester le changement dans une règle de test ou un groupe pilote.
6. Après l’enregistrement, effectuer un test réel et documenter le Log Viewer, la catégorie, l’ID de règle et le contexte utilisateur.
7. Fixer une date de révision, surtout pour les exceptions commerciales temporaires.

Les exceptions temporaires doivent être clairement nommées, par exemple TMP_ALLOW_vendor-portal_until_2026-07-31. Les exceptions commerciales permanentes ont également besoin d’un propriétaire. Si personne n’est responsable d’une exception, elle ne devrait pas rester dans la politique de manière permanente.

Si de nombreux domaines individuels apparaissent pour le même service, le problème n’est souvent pas la politique Web, mais l’architecture du service. Il faut alors vérifier si une règle de pare-feu distincte, une politique Web distincte, un groupe d’URL soigneusement entretenu ou un autre point de contrôle est plus approprié. Pour les listes IOC ou de blocage dynamiques, les exceptions de politique Web sont généralement le mauvais endroit ; les Sophos Firewall Threat Feeds sont souvent plus adaptés.

Rollback et autorisation d’urgence

Un changement de politique Web peut affecter immédiatement le travail productif. Il est donc important de définir comment restaurer l’état précédent avant d’effectuer des modifications importantes.

Options de rollback pratiques :

• Dupliquer ou documenter la politique Web concernée avant la modification
• Tester le changement d’abord dans une règle pilote ou un petit groupe d’utilisateurs
• Ne pas supprimer immédiatement l’ancienne règle de pare-feu ou l’ancienne politique Web
• Définir une fenêtre de temps, des utilisateurs de test et un critère de retour
• Après l’enregistrement, vérifier le Log Viewer, l’ID de règle et la décision de catégorie

Pour les blocages aigus, il ne faut pas insérer réflexivement une règle d’autorisation large en haut. Il est préférable d’avoir une exception étroite et limitée dans le temps avec un groupe d’URL clair, un groupe d’utilisateurs et une date de révision. Si la pression est forte, une exception temporaire peut stabiliser le fonctionnement, mais elle doit être réévaluée par la suite.

Erreurs typiques

La politique Web ne s’applique pas

La plupart du temps, la politique n’est pas activée dans la bonne règle de pare-feu, la règle n’est pas atteinte, une règle plus haut autorise le trafic ou le contexte utilisateur ne correspond pas. Vérifiez d’abord le Log Viewer et l’ID de règle.

HTTPS n’est pas bloqué comme prévu

Sans inspection TLS, le pare-feu voit moins de détails. Selon la cible, une décision de domaine ou de catégorie peut fonctionner, tandis que l’inspection du contenu, les types de fichiers ou certaines fonctions de recherche restent limitées.

Si la connexion n’est pas déchiffrée, le pare-feu peut tout de même utiliser des informations SNI ou de domaine pour les décisions de politique. Les pages de blocage, les pages d’avertissement, les types de fichiers, les Content Filters, le scan des malwares et l’analyse Zero-Day nécessitent toutefois plus de visibilité. Dans le Log Viewer, il faut donc vérifier non seulement l’action de la politique Web, mais aussi le statut SSL/TLS Inspection.

QUIC contourne l’attente

Si les navigateurs utilisent UDP 443, le trafic peut être traité différemment du HTTPS classique via TCP. Dans les règles client, il faut décider consciemment si QUIC est bloqué.

La règle d’autorisation est trop haute

Une règle d’autorisation large au début de la politique Web peut neutraliser les règles de blocage ultérieures. L’ordre des règles au sein de la politique Web est aussi important que l’ordre des règles dans la liste des règles de pare-feu.

Trop d’exceptions

Les exceptions résolvent rapidement un problème individuel, mais peuvent réduire l’efficacité de la protection. Chaque exception a besoin d’un objectif, d’un propriétaire et d’une date de révision. Si de nombreuses exceptions apparaissent, la structure de la politique est souvent incorrecte ou une application commerciale nécessite une règle distincte.

Les Web Exceptions qui ignorent Policy checks ou Malware and content scanning sont particulièrement risquées. Si seul HTTPS decryption pose problème, une SSL/TLS Exclusion est généralement plus étroite et plus compréhensible.

Le reporting n’affiche rien

Dans ce cas, il faut vérifier la journalisation, le reporting, la règle de pare-feu, le choix de la politique ou la redirection des journaux. Une politique sans journalisation est difficile à évaluer en fonctionnement.

Liste de vérification opérationnelle

• Statut de licence de la protection Web vérifié.
• Trafic client, serveur, invité et VPN évalué séparément.
• Politique Web créée avec un nom explicite.
• Catégories critiques et groupes d’URL planifiés consciemment.
• Ordre des règles au sein de la politique Web vérifié.
• Politique Web activée dans la règle de pare-feu appropriée.
• Log firewall traffic, journalisation de la politique Web et Reporting actifs.
• Règles de politique Web activées et dans le bon ordre.
• Inspection TLS et certificat CA vérifiés pour le groupe pilote.
• Stratégie QUIC définie.
• Web Exceptions et TLS Exclusions documentées séparément.
• Policy Tester et tests réels effectués.
• Log Viewer et reporting contrôlés.
• Processus de changement pour les exceptions de politique Web défini.
• Exceptions temporaires avec date d’expiration.
• Exceptions documentées avec propriétaire et date de révision.

FAQ