Documenter efficacement les règles Sophos Firewall

Une règle de pare-feu n’est pas seulement une autorisation technique, mais aussi une décision d’exploitation : qui peut accéder à quoi, via quel service et pour quelle raison ? Sans ce contexte, d’anciennes règles de test, de partenaire ou de migration restent souvent actives pendant des années, car personne ne peut déterminer avec certitude à quoi elles servent.

Les informations essentielles doivent donc figurer directement dans Rule name et Description. Un ticket ou un wiki contient les détails, tandis que la règle elle-même fournit le contexte nécessaire à l’exploitation quotidienne. Pour effectuer un nettoyage fiable, la description ne suffit toutefois pas : il faut également prendre en compte la Rule ID, le logging, les données d’utilisation, la confirmation du responsable et une période d’observation contrôlée.

Pour comprendre la structure technique, consultez l’article de référence Comprendre et configurer les règles Sophos Firewall en toute sécurité. Le présent guide se concentre sur la dénomination, la documentation et la révision.

Où saisir la documentation

Le chemin est Rules and policies > Firewall rules. Sélectionnez d’abord IPv4 ou IPv6, puis modifiez une règle existante ou créez-en une via Add firewall rule > New firewall rule.

Dans les paramètres généraux, les champs suivants sont particulièrement importants pour la documentation :

• Rule name : nom court et facile à repérer pour identifier la connexion.
• Rule position : position dans la liste des règles, évaluée de haut en bas.
• Rule group : regroupement organisationnel de la règle.
• Description : objectif, responsable, ticket, révision et exception volontaire.
• Log firewall traffic : génère des logs et des données de rapport pour les connexions correspondantes.

Rule group améliore la lisibilité, mais ne modifie pas la logique d’évaluation. Sophos Firewall examine chaque règle de haut en bas et s’arrête à la première correspondance. Après la création, le clonage ou la génération automatique d’une règle, il faut donc contrôler sa Rule position effective.

Que faut-il indiquer dans la Description ?

Source, Destination, Services, Action et les Security Profiles sont déjà visibles dans la règle. La Description ne doit pas recopier ces champs, mais apporter les informations qui manqueraient ultérieurement.

Un standard minimal adapté à la pratique comprend les éléments suivants :

• Objectif : quel processus métier ou opérationnel nécessite cette autorisation ?
• Responsable : quelle équipe est responsable de l’application et de la décision ?
• Changement ou ticket : où se trouvent l’autorisation, le test et les détails techniques ?
• Révision ou date d’expiration : quand la règle doit-elle être réexaminée ou supprimée ?
• Exception : quelle dérogation ou restriction volontaire l’administrateur doit-il connaître ?

Il n’est pas nécessaire de consigner manuellement le créateur et la date de modification si Configuration Audit et le processus de changement fournissent ces informations de manière fiable. Le nom d’une personne devient rapidement obsolète dans la Description ; une équipe ou un rôle pérenne constitue généralement un meilleur responsable.

Modèle compact

Pour de nombreuses règles, une seule ligne structurée suffit :

Objectif=Accès-ERP; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

En cas d’exception volontaire, ajoutez une brève indication :

Objectif=Upload-partenaire; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Exception=uniquement les réseaux partenaires définis

Exemple pratique détaillé

Pour une équipe qui utilise une convention plus détaillée, une règle DNAT documentée peut par exemple se présenter ainsi :

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

AUTHOR et LAST MODIFIED ne sont utiles que si l’équipe les tient à jour de manière cohérente. Si Configuration Audit fournit un historique fiable, l’objectif, le responsable, le ticket et la date de révision suffisent dans la Description ; l’exemple détaillé peut alors rester dans la demande de changement ou le Runbook.

La Description sert de repère, pas de CMDB complète. Les longs protocoles de test, les décisions d’architecture et les instructions de rollback doivent figurer dans le ticket ou le Runbook associé.

Nommer les règles de manière cohérente

Un bon nom doit être compréhensible dans la liste des règles sans devoir ouvrir la règle. Le schéma ne doit pas nécessairement être identique dans toutes les entreprises, mais il doit rester cohérent au sein d’un même environnement.

Le modèle suivant a par exemple fait ses preuves :

TYPE_SOURCE_DESTINATION_SERVICE

Exemples :

• ALLOW_VLAN12_WAN_HTTPS
• ALLOW_VPNUSERS_SRVERP_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• TEMP_PARTNER_SRVAPP_SFTP
• DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP ou DROP facilitent la lecture rapide. La source, la destination et le service rendent la direction visible. Les abréviations doivent être expliquées dans une convention de nommage interne ; sinon, un nom compact ne fait que créer une nouvelle énigme.

Évitez les noms génériques tels que Rule1, Test, Allow, Internet ou Temp. Les noms composés uniquement d’un ticket sont également peu utiles. CHG-1842 peut certes être recherché, mais n’indique ni la direction ni le service en cas d’incident.

Accès temporaires et publiés

Les règles temporaires nécessitent une véritable date d’expiration et un responsable. Un préfixe tel que TEMP facilite la recherche, mais ne remplace pas un processus de retrait. La date doit figurer à la fois dans la Description et dans le ticket ou le système de gestion des changements, afin qu’une révision arrivée à échéance ne dépende pas uniquement d’un contrôle visuel du pare-feu.

Pour un serveur publié, la règle de pare-feu seule ne suffit pas à la documentation. La règle DNAT, la Firewall Rule ID, le service public, l’hôte cible interne et l’autorisation doivent être consignés ensemble dans le ticket. Dans la Description du pare-feu, il suffit d’indiquer le changement et l’objectif ; il ne faut pas dupliquer les détails NAT sous la forme d’une seconde configuration textuelle difficile à lire.

Pour la mise en œuvre technique, consultez Publier un serveur avec DNAT sur Sophos Firewall et Comprendre le NAT sur Sophos Firewall.

Ce qui ne doit pas figurer dans la Description

La description de la règle est visible par les administrateurs et ne constitue pas un coffre-fort de secrets. N’y inscrivez pas :

• de mots de passe, de clés API ou de jetons,
• de clés privées ou de clés prépartagées,
• de données personnelles ou de données client confidentielles sans raison impérative,
• d’instructions d’accès complètes destinées à des personnes externes,
• d’URL longues contenant des paramètres de session, de jeton ou des paramètres confidentiels.

Un identifiant de ticket interne tel que CHG-1842 suffit. Le lien proprement dit et les informations sensibles restent dans le système prévu à cet effet, avec son propre contrôle d’accès.

Vérifier les règles existantes de manière contrôlée

L’absence de Description justifie une révision, mais pas une suppression immédiate. Le statut SFOS Unused n’est lui aussi qu’un indicateur à court terme : il signifie que la règle n’a trouvé aucun trafic correspondant au cours des dernières 24 heures. Des tâches mensuelles, des accès d’urgence ou des applications saisonnières peuvent néanmoins être légitimes.

Une révision sûre se déroule comme suit :

1. Marquez les règles sans Description, avec un nom générique, le préfixe TEMP ou une date de révision dépassée.
2. Relevez la Rule ID, la position, Source, Destination, Services, Action et les Security Profiles.
3. Sous More options, sélectionnez si nécessaire Reset data transfer count, puis observez la règle pendant une période représentative de l’application.
4. Sous Reports > Dashboards > Traffic dashboard, vérifiez les données transférées dans Allowed policies.
5. Dans Log viewer, recherchez la Rule ID, la source, la destination et le service.
6. Vérifiez le responsable et le ticket par rapport au besoin métier actuel.
7. Désactivez d’abord les règles devenues inutiles, observez-les pendant la période convenue, puis supprimez-les.
8. Documentez la décision, le test et le retrait dans la demande de changement.

Un compteur à zéro ne constitue pas une preuve si la période d’observation était trop courte. De même, l’absence d’une entrée de log ne prouve rien si Log firewall traffic était auparavant désactivé ou si les destinations de logs locales ou externes n’étaient pas configurées correctement. Sous System services > Log settings, vous définissez quels logs du pare-feu sont stockés localement, envoyés à Sophos Central ou transmis à des serveurs Syslog.

Retracer les modifications et leur effet

La Description explique pourquoi une règle est censée exister. Elle ne prouve pas qui l’a réellement modifiée. SFOS 22 peut enregistrer les modifications apportées aux règles de pare-feu via Configuration Audit, avec la configuration précédente et la nouvelle configuration, l’horodatage, l’administrateur et l’adresse IP source. Vérifiez son statut avec system configuration-audit show ; cette fonction est activée par défaut.

Pour l’exploitation, trois éléments de preuve doivent être combinés :

• Description et ticket : objectif, responsable, autorisation et révision.
• Configuration Audit : qui a modifié quelle configuration et à quel moment.
• Log Viewer et Reports : quelles connexions la règle a réellement traitées.

L’article Examiner les logs Audit Trail de Sophos Firewall décrit plus précisément Configuration Audit et son analyse. Après chaque modification de règle, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture permet de vérifier si la Rule ID attendue est effectivement appliquée.

Standard minimal pour les nouvelles règles

Avant de clôturer une demande de changement, une nouvelle règle doit remplir les critères suivants :

• Rule name cohérent,
• Rule position et Rule group contrôlés explicitement,
• Source, Destination et Services sans utilisation inutilement large de Any,
• Description avec objectif, responsable, changement et révision,
• Log firewall traffic configuré selon les besoins d’exploitation et de protection des données,
• aucun secret ni aucune donnée personnelle dans le nom ou la Description,
• test fonctionnel avec la Rule ID attendue,
• processus d’expiration et de retrait pour les règles temporaires.

FAQ