Aller au contenu
Avanet

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 Pending ou In Progress
  • une tâche est Failed, Skipped, Invalid license ou 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 QueueStatut des politiques de groupe de pare-feu appliquées via Sophos Central sur les pare-feux
Firewall Task QueueTâ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

StatutSignification pratique
PendingLa 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 ProgressCentral traite encore la tâche. Ne pas lancer plusieurs corrections en parallèle lorsque la tâche est en cours.
SuccessCentral signale la tâche comme réussie. Ensuite, valider sur le pare-feu si l’effet attendu est visible.
Partial SuccessUne partie a été appliquée, une autre non. C’est particulièrement important pour les groupes ou plusieurs objets.
FailedLa modification n’a pas été complétée avec succès. Documenter le message d’erreur et le pare-feu concerné.
SkippedLa tâche a été délibérément ignorée. Un contrôle technique est nécessaire par la suite.
Invalid licenseLa 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.

  1. Ouvrir My Products > Firewall Management > Tasks Queue dans Sophos Central.
  2. Délimiter la période et le pare-feu ou groupe de pare-feux concerné.
  3. Déplier la tâche et vérifier les pare-feux concernés.
  4. Documenter le statut, le message d’erreur, l’entité, la sous-entité et le moment.
  5. Vérifier sur le pare-feu si la modification est visible ou seulement enregistrée dans Central.
  6. Pour les modifications de configuration, vérifier également les Audit Trail Logs.
  7. En cas de problèmes de trafic, évaluer le Log Viewer, le Policy Test et les journaux de service pertinents.
  8. 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.

ActionPertinent siVérifier avant
Retryla cause a été corrigée, par exemple connexion, licence, conflit d’objet ou perturbation temporaire de CentralEst-il clair pourquoi la tâche a échoué ?
Skipune tâche échouée ou non pertinente bloque des tâches ultérieures et l’impact technique est comprisCela empêche-t-il une modification de politique planifiée d’être appliquée ?
Attendrela tâche est en cours ou Central traite de nombreux pare-feuxY a-t-il des indices de véritable blocage ou seulement un retard normal ?
Cas de supportl’erreur se répète, concerne plusieurs pare-feux en production ou le message n’est pas clairLes 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 Success comme 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.

FAQ

Que montre la file d'attente des tâches Sophos Central ?

La file d’attente des tâches montre le statut des politiques de groupe de pare-feu appliquées via Sophos Central sur les pare-feux. On y voit notamment les groupes concernés, les pare-feux, le statut, l’administrateur, l’entité, la sous-entité et le moment.

Qu'est-ce que la file d'attente des tâches de pare-feu ?

La file d’attente des tâches de pare-feu montre les tâches de pare-feu issues des paramètres MDR, des IOCs MDR ou de l’API de configuration du pare-feu. Les éléments pertinents incluent le statut, l’ID d’identification, l’entité, l’action et le moment.

Peut-on ignorer une tâche échouée ?

Oui, techniquement, il est possible d’ignorer certaines tâches. Opérationnellement, cela ne devrait être fait que si l’on sait clairement quelle modification n’a pas été appliquée et comment le pare-feu concerné sera vérifié par la suite.

Quand Retry est-il pertinent ?

Retry est pertinent lorsque la cause de l’erreur a été corrigée. Des exemples incluent une connexion Central rétablie, une licence corrigée, un conflit d’objet résolu ou une erreur temporaire qui n’existe plus.

La file d'attente des tâches remplace-t-elle le Log Viewer ?

Non. La file d’attente des tâches montre si Central a traité une modification. Le Log Viewer montre les événements locaux du pare-feu et reste nécessaire pour l’analyse du trafic, des politiques et des services.