Vérification de la file d'attente des tâches de gestion du pare-feu Sophos Central
Lorsqu’une modification est enregistrée dans Sophos Central mais n’arrive pas sur le Sophos Firewall, le pare-feu local n’est pas toujours la première source d’erreur. Pour les pare-feux gérés de manière centralisée, il convient également de vérifier la file d’attente des tâches dans Sophos Central. Cela permet de voir si Central traite encore une politique de groupe, une tâche de pare-feu basée sur l’API ou une autre modification centralisée, si elle a été partiellement appliquée, ignorée ou terminée avec une erreur.
C’est particulièrement important lorsque plusieurs pare-feux sont gérés dans un groupe. Une seule tâche échouée peut retarder des modifications ultérieures ou compliquer le dépannage, car la configuration dans Sophos Central peut sembler différente de celle du pare-feu concerné.
Quand la file d’attente des tâches est-elle pertinente ?
La file d’attente des tâches est pertinente dès que les modifications ne sont pas effectuées directement localement sur le pare-feu, mais via Sophos Central. Cela concerne principalement les environnements où les pare-feux sont connectés à Sophos Central et où la gestion centralisée des pare-feux est activement utilisée.
Situations typiques :
- une politique de groupe a été modifiée dans Sophos Central
- une modification est arrivée sur certains pare-feux, mais pas sur d’autres
- une mise à jour du firmware a été planifiée ou lancée via Sophos Central
- les tâches de pare-feu basées sur MDR ou API ne semblent pas entièrement mises en œuvre
- une tâche reste longtemps sur
PendingouIn Progress - une tâche est
Failed,Skipped,Invalid licenseou seulement partiellement réussie - après une erreur, les modifications ultérieures ne sont pas traitées comme prévu
Pour le dépannage en direct local, le Log Viewer du pare-feu reste important. Cependant, la file d’attente des tâches répond à une autre question : Sophos Central a-t-il réussi à transmettre la modification jusqu’au pare-feu ?
Où trouver la file d’attente des tâches
Le chemin dans Sophos Central est :
My Products > Firewall Management > Tasks Queue
Sophos distingue entre Task Queue et Firewall Task Queue.
| Vue | À quoi elle sert |
|---|---|
| Task Queue | Statut des politiques de groupe de pare-feu appliquées via Sophos Central sur les pare-feux |
| Firewall Task Queue | Tâches de pare-feu issues des paramètres MDR, des IOCs MDR et de l’API de configuration du pare-feu |
Pour les problèmes classiques de gestion centralisée des pare-feux, la Task Queue est généralement la plus intéressante. La Firewall Task Queue devient plus importante lorsque des modifications sont déclenchées via l’API de configuration du pare-feu ou des fonctions de pare-feu liées à MDR.
Quelles informations sont importantes
Une tâche individuelle n’est utile que si elle est correctement classée. Avant une modification ou une nouvelle tentative, il est conseillé de noter au moins ces champs :
- Numéro de tâche
- Groupe ou pare-feu concerné
- Statut
- Moment
- Administrateur ou ID d’identification
- Entité et sous-entité
- Message d’erreur affiché
- Nombre de pare-feux réussis et échoués
Le moment n’est pas toujours synonyme de début de traitement sur chaque pare-feu. Pour les politiques de groupe, Sophos Central affiche d’abord le moment de la création ou de la modification et le met à jour plus tard lorsque la politique est appliquée aux pare-feux. Par conséquent, lors de déploiements plus longs, il ne faut pas se fier uniquement à la première heure.
Interpréter correctement le statut
| Statut | Signification pratique |
|---|---|
Pending | La tâche attend encore d’être traitée. En cas de longue durée, vérifier la connectivité, la licence et la connexion Central. |
In Progress | Central traite encore la tâche. Ne pas lancer plusieurs corrections en parallèle lorsque la tâche est en cours. |
Success | Central signale la tâche comme réussie. Ensuite, valider sur le pare-feu si l’effet attendu est visible. |
Partial Success | Une partie a été appliquée, une autre non. C’est particulièrement important pour les groupes ou plusieurs objets. |
Failed | La modification n’a pas été complétée avec succès. Documenter le message d’erreur et le pare-feu concerné. |
Skipped | La tâche a été délibérément ignorée. Un contrôle technique est nécessaire par la suite. |
Invalid license | La licence ou l’autorisation ne correspond pas à l’action prévue. Ne pas essayer de résoudre par des tentatives répétées. |
Sophos Central peut supprimer automatiquement les tâches avec le statut Pending après plusieurs semaines. Pour la documentation opérationnelle, les cas de support ou les revues de changement, il est donc conseillé de sécuriser rapidement les erreurs pertinentes.
Processus de vérification propre
En cas de modification centralisée bloquée, un processus calme est plus utile que de cliquer à répétition sur Retry.
- Ouvrir
My Products > Firewall Management > Tasks Queuedans Sophos Central. - Délimiter la période et le pare-feu ou groupe de pare-feux concerné.
- Déplier la tâche et vérifier les pare-feux concernés.
- Documenter le statut, le message d’erreur, l’entité, la sous-entité et le moment.
- Vérifier sur le pare-feu si la modification est visible ou seulement enregistrée dans Central.
- Pour les modifications de configuration, vérifier également les Audit Trail Logs.
- En cas de problèmes de trafic, évaluer le Log Viewer, le Policy Test et les journaux de service pertinents.
- Décider ensuite si Retry, Skip ou un cas de support est approprié.
Si l’on ne sait pas quel journal local est pertinent, Dépannage Sophos Firewall : Services et journaux peut aider. Pour l’analyse des règles et du trafic, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est également adapté.
Ignorer ou réessayer ?
Sophos Central propose selon le statut les actions Skip et Retry. Les deux sont utiles, mais ne doivent pas être considérées comme de simples actions de nettoyage.
| Action | Pertinent si | Vérifier avant |
|---|---|---|
| Retry | la cause a été corrigée, par exemple connexion, licence, conflit d’objet ou perturbation temporaire de Central | Est-il clair pourquoi la tâche a échoué ? |
| Skip | une tâche échouée ou non pertinente bloque des tâches ultérieures et l’impact technique est compris | Cela empêche-t-il une modification de politique planifiée d’être appliquée ? |
| Attendre | la tâche est en cours ou Central traite de nombreux pare-feux | Y a-t-il des indices de véritable blocage ou seulement un retard normal ? |
| Cas de support | l’erreur se répète, concerne plusieurs pare-feux en production ou le message n’est pas clair | Les détails de la tâche, l’heure, le nom du pare-feu et les journaux sont-ils sécurisés ? |
⚠️ Une tâche échouée ne doit pas être ignorée simplement pour que la file d’attente soit propre. Skip est une décision opérationnelle : la modification non appliquée doit ensuite être vérifiée ou mise en œuvre séparément.
Scénarios d’erreurs typiques
La modification est visible dans Central, mais pas sur le pare-feu
Dans ce cas, vérifier d’abord si la tâche correspondante a été complétée avec succès. Si la tâche est encore Pending, In Progress, Failed ou Partial Success, le problème ne réside pas nécessairement dans la règle locale du pare-feu. Ce n’est que lorsque Central signale la tâche comme réussie qu’il faut approfondir l’analyse des politiques, des objets ou des journaux locaux.
Seuls certains pare-feux d’un groupe sont concernés
Pour les politiques de groupe, une modification peut réussir sur plusieurs pare-feux et échouer sur un. Il ne faut alors pas modifier tout le groupe de manière générale, mais déplier le pare-feu concerné et vérifier les différences : licence, version du firmware, connexion Central, conflits d’objets locaux, plateforme et problèmes connus.
La tâche de firmware via Central ne démarre pas correctement
Si une mise à jour du firmware Sophos Firewall a été planifiée via Sophos Central, la file d’attente des tâches doit faire partie du contrôle après coup. Si le pare-feu reste sur l’ancienne version, vérifier d’abord si Central a déclenché et terminé la tâche. Pour les versions majeures, le SFOS 22 Upgrade Check fait partie de la préparation.
La synchronisation de la politique Web ou TLS échoue
Pour la protection Web, les groupes d’URL ou les exclusions TLS, une synchronisation Central peut sembler particulièrement déroutante, car Central a accepté une modification que le pare-feu n’a pas entièrement traitée. Il convient alors de comparer l’entité concernée de la file d’attente des tâches avec la configuration locale. Pour l’interprétation technique, Introduction correcte de l’inspection TLS Sophos Firewall et Création d’une politique de protection Web Sophos Firewall sont adaptés.
XGS 88/w et liste d’exclusion TLS locale
Dans la liste des problèmes connus, un problème spécifique aux modèles XGS 88/w est documenté : lors de la synchronisation d’une politique Sophos Central, le traitement de la liste d’exclusion TLS locale peut échouer. Le message d’erreur affiché se réfère à un groupe d’URL qui n’a pas pu être mis à jour. Dans ce cas, on peut ignorer la transaction échouée de la file d’attente des tâches pour que les tâches ultérieures continuent.
En pratique, il ne faut pas simplement continuer après cela. Un contrôle après coup est important :
- L’exception TLS souhaitée est-elle présente localement sur le pare-feu ?
- Les politiques Web et TLS sur le pare-feu sont-elles encore techniquement correctes ?
- Le problème concerne-t-il uniquement un XGS 88/w ou plusieurs pare-feux ?
- La modification doit-elle être mise en œuvre temporairement localement ou reportée ?
- Existe-t-il une version de maintenance ou un avis Sophos pour la version concernée ?
Contrôle après coup sur le pare-feu
Une tâche Central réussie est un bon signal, mais pas encore un test opérationnel complet. Selon la modification, il convient de vérifier localement :
- La règle, la politique, la liste ou la version du firmware modifiée est-elle visible ?
- Le Log Viewer affiche-t-il les événements attendus ?
- La modification a-t-elle été consignée dans l’Audit Trail ?
- La connexion Central et le reporting sont-ils toujours actifs ?
- Les utilisateurs concernés, les VPN, les accès Web ou les applications fonctionnent-ils ?
Pour les modifications liées à la sécurité, il est conseillé de définir un point de retour rapide. Cela est particulièrement vrai pour la protection Web, l’inspection TLS, les règles de pare-feu, les VPN, les clusters HA et les mises à jour du firmware.
Liste de vérification opérationnelle
- Avant les modifications via Sophos Central, clarifier quels pare-feux ou groupes sont concernés.
- Après les modifications Central, vérifier la file d’attente des tâches.
- Documenter les tâches échouées avec le message d’erreur, l’heure et le nom du pare-feu.
- Ne pas traiter
Partial Successcomme entièrement terminé. - Utiliser Retry uniquement après vérification des causes.
- Utiliser Skip uniquement si l’impact technique est compris.
- Pour les tâches de firmware, planifier une fenêtre de maintenance, une sauvegarde et un accès local.
- En cas d’erreurs répétées, sécuriser les informations de l’Audit Trail, du Log Viewer et du support Sophos.