Contrôler Sophos Firewall chaque jour : checklist d'exploitation

Une Sophos Firewall peut rester techniquement accessible tout en présentant des signes avant-coureurs : une connexion WAN devient instable, l’utilisation du disque augmente, un service signale une erreur ou les échecs de connexion administrateur se multiplient. Un contrôle d’exploitation court et reproductible rend ces changements visibles avant qu’ils ne provoquent une interruption prolongée ou un incident de sécurité.

Cette procédure concerne le fonctionnement actuel. Le Health Check de Sophos Firewall détermine en revanche si certaines configurations respectent les recommandations Sophos et CIS. Les deux contrôles se complètent, mais ne se remplacent pas.

Le contrôle en dix minutes

Une procédure fixe suffit pour la vue quotidienne :

1. Dans le Control Center, noter le modèle, la version du firmware et le build, ouvrir les nouveaux messages et cliquer sur les icônes d’état des services, du WAN, des interfaces et des VPN.
2. Sous Diagnostics > System graphs, comparer le CPU, la mémoire, la charge moyenne, le disque et les interfaces importantes à la baseline habituelle.
3. Contrôler les tableaux de bord de sécurité et les rapports utilisés sur la dernière période entièrement disponible afin de détecter de nouveaux événements IPS, web, application, zero-day ou Active Threat Response.
4. Ouvrir le Log Viewer en haut à droite, sélectionner le module et la période, puis contrôler les échecs de connexion administrateur, les sources inhabituelles et les services associés.
5. En HA, tenir compte du nœud ayant traité le trafic et, pour le reporting central, de la source de données attendue.
6. Documenter chaque écart pertinent avec l’heure, le firmware, le nœud, la source, le service concerné et l’étape suivante.
7. Ne pas redémarrer de services, supprimer de logs ou élargir de règles à cause d’un seul pic. Corréler d’abord la tendance, les logs et le fonctionnement réel.

Ce contrôle court ne doit pas déclencher une modification de configuration chaque matin. Il sert à détecter rapidement les changements et à décider clairement si une observation, un diagnostic ou une escalade est nécessaire.

Quatre vues, quatre informations différentes

Les vues principales ne montrent pas la même chose :

• Control Center : vue actuelle du système, des services, du WAN, des interfaces, des VPN, de l’uptime et des messages nécessitant une action.
• System graphs : évolution dans le temps du CPU, de la mémoire, de la charge moyenne, du disque, du transfert WAN et des compteurs d’interface.
• Reports : évaluation consolidée d’une période terminée. Certains widgets et certaines données de rapports ne sont pas actualisés en temps réel.
• Log Viewer : événements individuels avec heure, module, action, informations de source et de destination et, selon le type de log, Rule ID ou autres détails.

Un widget rouge est un signal, pas encore un diagnostic complet. De même, un état vert actuel ne prouve pas qu’aucune erreur brève ne s’est produite pendant la nuit. Seule la combinaison de l’état actuel, de l’évolution, du rapport et de l’événement individuel donne une image fiable.

Contrôler l’état et la disponibilité du système

Lire d’abord le Control Center

Dans le Control Center, le contrôle commence par les nouveaux messages. Sophos y affiche notamment des problèmes d’enregistrement, de licence, de reporting, de WAN ou de mise à niveau. Certains messages disparaissent automatiquement après correction et ne peuvent pas simplement être supprimés manuellement. Chaque message pertinent nécessite donc un responsable et une étape suivante traçable.

Un message Registration apparaît lorsque Sophos Firewall n’est pas enregistré. Un message Licenses apparaît lorsque des modules du pare-feu n’ont pas de licence.

Certains compteurs des widgets du Control Center sont remis à zéro après un redémarrage du pare-feu. Une valeur faible après le redémarrage ne prouve donc pas qu’aucun événement ne s’est produit auparavant. Pour l’interpréter, corréler l’uptime avec les logs conservés durablement pour la période concernée, par exemple des exports CSV ou des logs centralisés dans les limites de leur rétention. La console d’administration web n’affiche pas d’informations de température.

Messages affiche aussi le temps écoulé depuis la création d’un message. Selon le type ou la gravité, ce widget utilise les indicateurs Alert, Warning et Available firmware versions. Consigner ensemble l’indicateur, le temps écoulé et le texte du message ; les décomptes de Services et du WAN/VPN décrits ci-dessous ne s’appliquent pas à Messages.

La couleur doit toujours être interprétée avec les détails. Pour Services, Warning signifie qu’au moins un service s’est arrêté, tandis qu’Alert signifie qu’au moins un service n’a pas pu démarrer. Pour le WAN et les VPN, Warning signifie que la moitié au maximum des connexions configurées est indisponible, et Alert que plus de la moitié l’est. Ces compteurs ne tiennent pas compte de l’importance métier. Un seul tunnel principal en panne peut donc être plus urgent que plusieurs connexions volontairement inactives. Cliquer sur l’icône correspondante affiche les éléments concernés.

Les services, connexions WAN, interfaces et VPN réellement utilisés sont ensuite comparés à l’état attendu. Une interface rouge ne signifie pas automatiquement une panne : un port inutilisé sans adresse IP ou une interface physique parente d’un VLAN peut apparaître rouge comme prévu. L’écart par rapport au design documenté est le critère pertinent.

Si des LAG sont utilisés, sous SFOS 23, ouvrir l’icône Interfaces et vérifier également si des câbles sont débranchés sur les différents membres des LAG. L’aide de SFOS 23 mentionne explicitement cette vue détaillée ; l’aide correspondante de SFOS 22 ne le fait pas. Sur le plan opérationnel, un agrégat qui reste accessible ne prouve pas que tous ses membres, et donc la redondance et la capacité prévues, sont disponibles. Consigner dans le ticket le membre concerné et l’écart par rapport à l’état attendu.

Si des tunnels RED et des Wireless APs sont utilisés, comparer les widgets d’état des connexions à l’état attendu : RED compte les tunnels établis par rapport aux tunnels configurés, et Wireless APs les points d’accès actifs par rapport aux points d’accès configurés. Les points d’accès en attente apparaissent également entre parenthèses rouges et ne doivent pas être comptés comme actifs. RED ouvre la liste des tunnels, tandis que Wireless APs mène à Wireless > Access points. Connected remote users compte les utilisateurs connectés via SSL VPN et ouvre Current activities > Remote users ; Live users, en revanche, compte tous les utilisateurs actuels et ouvre Current activities > Live users. Ces nombres d’utilisateurs ne remplacent pas une vérification de la disponibilité des tunnels RED ou des points d’accès.

Si DNS Protection est prévu, vérifier son état de configuration dans le widget System. L’aide de SFOS 22 indique cinq états : Not subscribed signifie qu’une licence est manquante ; Xstream Protection est requis. Not configured renvoie à la saisie des adresses IP de DNS Protection. En cas d’état Unrecognized source, vérifier l’adresse IP publique du pare-feu et son association à une localisation dans Sophos Fusion. Active indique que DNS Protection est actif ; une icône d’information signale l’absence d’enregistrement dans Fusion. En cas d’état IP address conflict, vérifier l’adresse IP renseignée dans la localisation et faire remonter à Sophos Support tout conflit impossible à résoudre.

L’aide de SFOS 23 mentionne Not subscribed, Not configured et Active et renvoie à Configure DNS servers en l’absence de configuration ; pour l’icône d’information de l’état Active, elle mentionne l’enregistrement dans Sophos Central. Cela ne signifie pas que les deux états supplémentaires documentés dans SFOS 22 ont été supprimés à l’exécution. La procédure de configuration et de dépannage adaptée à la version est décrite dans Configurer DNS Protection avec Sophos Firewall : ne pas transposer telle quelle la procédure DNS traditionnel/localisation de SFOS 22 à la procédure intégrée de SFOS 23.

Pour les événements DNS Protection, sélectionner le module System dans Log Viewer et filtrer sur DNS Protection. Consigner la version, l’état du widget et les lignes de journal pertinentes dans le ticket. Cette vérification de la configuration et des événements ne remplace ni le contrôle du fonctionnement de la résolution de noms et de l’efficacité du filtrage, ni les rapports DNS Protection ; les rapports de sécurité généraux ne suffisent pas, à eux seuls, à prouver que DNS Protection est opérationnel.

Le widget Messages doit être traité comme une liste d’actions, et non comme un flux général d’événements. Lorsqu’il demande de créer la Secure Storage Master Key, la créer afin d’apporter la protection supplémentaire aux données sensibles telles que les mots de passe. Un message WAN access signifie que WebAdmin (HTTPS) et la CLI (SSH) sont accessibles depuis la zone WAN : si l’administration distante est nécessaire, utiliser un VPN ou une Local Service ACL Exception strictement limitée à des hôtes ou réseaux de gestion précis plutôt qu’un accès WAN étendu. Pour un message concernant le disque des rapports, ramener l’utilisation sous le seuil inférieur ; repasser seulement sous le seuil supérieur ne suffit pas. Les messages liés à une exigence disparaissent une fois celle-ci satisfaite et ne peuvent pas être supprimés manuellement.

Pour un message d’échec de mise à niveau sur les pare-feu logiciels, virtuels et cloud, vérifier d’abord si le pare-feu a été revendiqué dans Sophos Central (Claim). Cette revendication est un prérequis avant la mise à niveau, pas seulement une mesure après un échec. La documentation SFOS 22 nomme le portail « Sophos Fusion (previously Sophos Central) », tandis que celle de SFOS 23 indique « Sophos Central » ; le prérequis reste identique. Consigner le statut de revendication et le message d’échec dans le ticket avant de planifier une nouvelle tentative avec le runbook firmware.

Lire Active threat response par flux et par action. MDR et Sophos X-Ops indiquent le nombre de menaces bloquées, NDR Essentials les menaces surveillées, et les flux tiers leur état de synchronisation ainsi que les menaces bloquées. Configure mène à la configuration de la protection, Reports au rapport correspondant et More details développe le widget. L’action Reports n’apparaît pas sur les modèles sans reporting local. Une menace surveillée n’est pas nécessairement bloquée, et un défaut de synchronisation tiers doit être distingué du nombre de menaces.

Le widget Reports est un raccourci vers un maximum de cinq rapports critiques, choisis selon les modules souscrits, et non une liste complète d’événements en direct. La correspondance est la suivante :

• High-risk applications — Web Protection
• Objectionable websites — Web Protection
• Web users — Web Protection
• Intrusion attacks — Network Protection
• Web server protection — Web Server Protection
• Email usage — Email Protection
• Email protection — Email Protection
• Traffic dashboard — Web Protection ou Network Protection
• Security dashboard — Web Protection ou Network Protection

High-risk applications, Objectionable websites, Intrusion attacks, Web server protection et Email protection portent sur la veille ; Web users classe les dix utilisateurs ayant transféré le plus d’octets web la veille. Email usage indique les octets d’e-mails transférés, tandis que Traffic dashboard et Security dashboard résument respectivement les catégories de trafic et les activités refusées. Une tuile absente peut donc refléter l’abonnement plutôt qu’une activité nulle. Cliquer sur le nom pour consulter le rapport ou sur l’icône de téléchargement pour le conserver. Pour les périodes et drill-downs distincts des signaux endpoint, utilisateur, Zero-day, TLS et session, poursuivre avec Bien interpréter User & Device Insights.

Traffic insight résume le trafic traité au cours des dernières 24 heures. Web activity présente la tendance ainsi que la moyenne et le maximum d’octets transférés ; Cloud applications indique les applications détectées et les octets entrants et sortants, avec au survol les états New, Sanctioned, Unsanctioned et Tolerated. Les autres graphiques classent les cinq premières catégories d’applications et de sites autorisées par octets, les catégories d’applications bloquées par hits, et les hôtes privés d’accès réseau en raison de leur état de sécurité. Cliquer sur un graphique cloud ou une barre de catégorie ouvre la page Cloud applications ou le rapport filtré correspondant ; effectuer ce drill-down avant de qualifier un pic ou une entrée du top cinq d’incident.

Un contrôle quotidien comprend au minimum :

• les services arrêtés ou dégradés de manière inattendue ;
• les liens WAN down ou dont l’état change régulièrement ;
• les interfaces de production présentant de nouvelles erreurs, pertes ou collisions ;
• les connexions VPN importantes déconnectées contrairement au plan d’exploitation ;
• un redémarrage inattendu ou une uptime anormalement courte ;
• les nouveaux messages sans responsable ni ticket.

Lire les System graphs par rapport à une baseline

Sous Diagnostics > System graphs, il faut rechercher des tendances plutôt que de simples pics. Le CPU, la mémoire et la charge moyenne sont évalués avec le nombre de cœurs, le trafic et la période concernée. Un pic court pendant une sauvegarde, un reporting ou une mise à jour de patterns n’a pas la même signification qu’une charge durablement élevée avec un trafic normal.

Pour Disk Usage, la tendance compte avant tout. Une utilisation élevée ponctuelle et une croissance constante représentent deux problèmes différents. Pour les interfaces, le trafic, les erreurs, les pertes et les collisions permettent de distinguer la charge de la firewall d’un problème de lien, duplex, câble ou switch.

Pour obtenir une preuve comparable, consigner le type de graphique et la période, et utiliser la même période dans le ticket. Les graphiques d’interface n’affichent un graphique distinct pour un VLAN que s’il se trouve dans la zone WAN. SFOS agrège les VLAN des autres zones dans le graphique de leur interface physique parente. Il ne faut donc pas attendre un graphique LAN VLAN distinct et sans anomalie lorsque SFOS n’en fournit pas.

L’explication détaillée de la charge moyenne, de l’offloading, de TLS Inspection et des System graphs figure dans Interpréter les performances de Sophos Firewall. Pour les limites de stockage et les rapports sur l’appliance, consulter Contrôler le stockage et les rapports de Sophos Firewall.

⚠️ Une seule valeur élevée ne justifie pas encore le redémarrage d’un service. L’heure, la durée, le caractère récurrent, le trafic concerné et les logs doivent d’abord être corrélés. Avant un redémarrage, les logs pertinents et, lors d’un incident, un CTR sont sauvegardés.

Contrôler les événements de sécurité et les connexions administrateur

Lire les rapports pour détecter les changements

La revue quotidienne de sécurité se concentre sur les tendances nouvelles ou nettement modifiées. Selon les fonctions activées, les zones suivantes sont particulièrement pertinentes :

• Reports > Dashboards > Security dashboard pour la vue consolidée ;
• Reports > Network & threats > Intrusion attacks pour les événements IPS ;
• Reports > Network & threats > Active threat response pour les IoC bloqués ;
• Reports > Applications & web pour l’utilisation web et applicative risquée, indésirable ou bloquée ;
• les rapports zero-day, Security Heartbeat ou Wireless si ces fonctions sont utilisées en production.

Dans le rapport sélectionné, définir d’abord la plage de dates, puis cliquer sur Generate. Filter permet de limiter les résultats à la source, l’action ou la règle pertinente. Les formats de téléchargement disponibles conservent les données affichées comme preuve pour le ticket. Joindre la période et le fuseau horaire à l’export afin qu’une comparaison ultérieure ne porte pas sur deux fenêtres différentes.

Chaque événement n’est pas un incident. La source, la destination, l’utilisateur, la règle, l’action, la fréquence et le contexte temporel sont déterminants. Un seul accès provenant d’un pays ne justifie pas un blocage global de ce pays. Des attaques répétées contre un service exposé ou un nouveau trafic à haut risque autorisé méritent en revanche une analyse précise.

Pour évaluer les sources et les pays en toute sécurité, consulter Bloquer les adresses IP et les pays malveillants. Si un paquet a été rejeté, Analyser les paquets rejetés sur Sophos Firewall mène du Log Viewer et de la Rule ID à la cause réelle du rejet.

Évaluer les échecs de connexion administrateur

Les échecs de connexion administrateur sont examinés selon l’heure, l’adresse IP source, le service de destination, le nom d’utilisateur et la répétition. Une faute de frappe depuis le réseau de gestion doit être traitée autrement que des tentatives distribuées depuis Internet ou des connexions répétées à un compte désactivé.

Le Log Viewer s’ouvre en haut à droite de n’importe quelle page WebAdmin, dans une nouvelle fenêtre plein écran. Sélectionner le module approprié, définir la période avec Timer filter, puis préciser le champ, la condition et la valeur avec Add filter. La recherche en texte libre convient à une adresse IP, un nom d’utilisateur, un port ou une règle. Avant toute autre modification, conserver les entrées filtrées au format CSV avec Export ; Reset efface ensuite tous les filtres. L’absence d’une entrée de session ne prouve pas toujours l’absence de trafic, car les règles de pare-feu journalisent normalement une session seulement lorsque le pare-feu reçoit l’événement de destruction de la connexion.

Pour les tentatives suspectes, contrôler d’abord l’exposition et l’identité :

1. WebAdmin, SSH, User Portal ou VPN Portal doit-il être accessible depuis la zone concernée ?
2. La source appartient-elle à un réseau de gestion autorisé ou à une Local Service ACL Exception ciblée ?
3. La MFA est-elle active pour l’accès administratif concerné ?
4. CAPTCHA, le délai d’expiration de session et Block login fonctionnent-ils comme prévu ?
5. Existe-t-il des modifications de configuration simultanées ou des connexions réussies avec le même compte ?

L’accès réseau se contrôle sous Device Access et Local Service ACL sur Sophos Firewall. Pour les comptes, les profils et l’offboarding, consulter Administrateurs locaux et profils d’accès aux appareils, et pour le second facteur, Activer la MFA sur Sophos Firewall.

⚠️ Block login peut bloquer l’adresse IP source pour plusieurs services après des échecs. Ne pas durcir agressivement les valeurs pendant un incident tant qu’aucun accès administrateur alternatif et aucune procédure de récupération testés ne sont disponibles.

Comprendre les limites de HA, du reporting et des modèles

Dans un cluster HA, chaque nœud ne stocke que les logs et rapports du trafic qu’il a lui-même traité. Pour un événement, il faut donc identifier le nœud actif ou ayant traité le trafic à ce moment. Un rapport local vide sur un nœud ne prouve pas qu’aucun événement ne s’est produit dans le cluster.

Central Firewall Reporting dans Sophos Fusion (anciennement Sophos Central) peut fournir une vue consolidée et une rétention plus longue. Les vues locale et centrale ne sont toutefois pas considérées comme des sources temps réel identiques. Activer et exploiter Central Firewall Reporting explique la sélection, l’arrivée et la rétention des logs.

Limites supplémentaires :

• Les rapports du Control Center sont mis à jour périodiquement et ne constituent pas une vue temps réel des événements.
• Après une mise à niveau de SFOS 20.0 ou antérieur vers SFOS 21.0 ou ultérieur, le widget Reports peut afficher zéro ou une valeur inférieure jusqu’à la prochaine mise à jour de 24 heures, car Sophos stocke les rapports antérieurs et postérieurs à la mise à niveau dans des bases de données distinctes.
• Les XGS 87/87w et XGS 88/88w ne prennent pas en charge les rapports on-appliance. Les logs centralisés, le SIEM et le monitoring sont donc plus importants sur ces modèles.
• L’absence de données peut être due au logging, à la période du rapport, à la licence, à la rétention, au disk watermark ou au mauvais nœud HA. Elle ne prouve pas automatiquement l’absence de trafic.

Comparer le build du firmware aux problèmes connus

Lorsque l’observation ne correspond pas à l’état attendu, suivre le runbook Avanet de décision sur le firmware. Comparer le build installé exact et le symptôme précis, pas seulement la version majeure. Consigner dans le ticket l’ID du problème, les builds affectés et corrigés ainsi que tout workaround, puis corréler le résultat avec les détails du Control Center, les System graphs, les logs et un test fonctionnel avant de modifier le système. Exemples pour le contrôle quotidien :

• NC-181971 : sous SFOS 22.0 GA et versions ultérieures, le service IPS peut, dans de rares circonstances, passer à l’état Dead et ne plus redémarrer. Sophos ne publie pas de contournement en libre-service et demande de contacter le Support pour l’appliquer.
• NC-181748 : sous SFOS 22.0 GA Build 411, aucun e-mail Web Instant Alert n’est généré pour les catégories bloquées par des stratégies Web. Sur ce build, l’absence d’alerte ne prouve donc pas l’absence de blocage.
• NC-180066, NC-180110, NC-178745 et NC-172912 : les notes de publication répertorient dans SFOS 22.0 MR2 Build 546 des corrections concernant l’arrêt des services antivirus, le mode failsafe provoqué par le daemon de journalisation, les redémarrages HA dus à une mémoire insuffisante et le scintillement des System graphs. Si le symptôme correspond sur un build antérieur, consigner l’ID et la voie de mise à niveau dans le ticket. Ne mettre à jour le firmware que dans une fenêtre de maintenance approuvée, avec une sauvegarde et un plan de retour arrière.

Les problèmes connus peuvent évoluer indépendamment de cet article. Avant l’escalade, rouvrir l’entrée et conserver son état actuel. Un ID correspondant peut expliquer un symptôme, mais ne remplace ni l’évaluation de l’impact ni la vérification fonctionnelle.

Documenter et escalader les écarts

Un contrôle quotidien n’est terminé que lorsque les écarts pertinents ont une étape suivante. Pour un ticket ou un journal d’exploitation, les champs suivants suffisent généralement :

• date, heure et fuseau horaire ;
• nom de la firewall, modèle, version SFOS et build ;
• en HA : nœud, rôle et dernier changement d’état ;
• fonction, zone, interface, VPN ou règle concernés ;
• état observé et état attendu ;
• capture d’écran, période du rapport, filtre de logs ou Rule ID ;
• impact sur les utilisateurs ou les services ;
• responsable, priorité, prochain contrôle et voie d’escalade.

Avant toute action modifiant l’état, conserver l’état détaillé du Control Center, le graphique avec sa période visible et les lignes de log filtrées ou l’export CSV. Pour un dossier de support, aller dans Diagnostics > Tools > Consolidated troubleshooting report afin de créer un CTR avec un System snapshot et les fichiers de log nécessaires : saisir la raison, sélectionner Generate, puis télécharger le fichier chiffré une fois prêt. Le mode debug et la purge des logs ne font pas partie du contrôle quotidien : ils modifient l’état de diagnostic ou détruisent les preuves et ne doivent être utilisés que de manière ciblée sur instruction du Support.

Une escalade immédiate est pertinente lorsqu’un lien WAN de production ou un chemin VPN critique tombe en panne de manière inattendue, qu’un service de protection est arrêté, que l’utilisation du disque continue d’augmenter, que la charge reste élevée, que des attaques administrateur répétées coïncident avec une connexion réussie ou qu’un nouvel événement de sécurité correspond à un trafic malveillant autorisé.

Une observation suffit plutôt pour un pic bref et explicable, une interface volontairement inutilisée ou un événement connu qui possède déjà un responsable documenté et une validation fonctionnelle stable.

Choisir une fréquence de contrôle utile

Sophos ne prescrit pas un rythme quotidien universel pour chaque vue. La fréquence dépend donc du risque, des horaires d’exploitation et du monitoring existant :

• Chaque jour ou à chaque équipe : nouveaux messages, services arrêtés, WAN/VPN/HA, uptime, événements de sécurité critiques et échecs de connexion administrateur.
• Chaque semaine : tendances des graphiques, erreurs d’interface, croissance du disque, tendances des rapports, sources récurrentes et tickets ouverts.
• Après une modification, une mise à niveau ou un failover : valider à nouveau la fonction concernée, les logs, les rapports, le chemin d’alerte et le trafic réel.
• Régulièrement en dehors du contrôle court : Health Check, revue des règles, test de restauration de sauvegarde, expiration des licences et certificats et planification des capacités.

Les notifications par e-mail ou le monitoring réduisent le délai de réaction, mais ne remplacent pas la revue. Un chemin d’alerte n’est fiable qu’après avoir testé le transport, la sélection des événements, le destinataire et la réaction. La procédure complète figure dans Configurer et tester les notifications e-mail de Sophos Firewall.

Checklist d’exploitation

• Contrôler le Control Center pour détecter les nouveaux messages et les changements d’état inattendus.
• Comparer les services, les liens WAN de production, les interfaces, les VPN et l’uptime avec l’état attendu.
• Lire le CPU, la mémoire, la charge moyenne, le disque et les compteurs d’interface importants par rapport à la baseline.
• Contrôler les rapports de sécurité pour la dernière période entièrement disponible.
• Définir la période du rapport, sélectionner Generate et exporter les résultats notables si nécessaire.
• Dans le Log Viewer, sélectionner le module, Timer filter et Add filter ; corréler la source, la destination, l’utilisateur, l’action et la Rule ID, puis conserver les lignes pertinentes au format CSV.
• Évaluer les échecs de connexion administrateur selon la source, le service et la répétition.
• En HA, tenir compte du nœud ayant traité le trafic et des logs locaux à chaque nœud.
• Comparer le build et le symptôme correspondant aux notes de publication et aux problèmes connus actuels ; consigner l’ID dans le ticket.
• Ne pas déclencher de redémarrage, de suppression de logs ou de modification large des règles sans préserver les preuves et disposer d’une procédure de retour.
• Documenter chaque écart pertinent avec un responsable, une priorité et une étape suivante.
• Après une correction, tester à nouveau non seulement l’état, mais aussi le fonctionnement réel.

FAQ