Configurer des planifications pour les règles et stratégies Sophos Firewall

Une planification rend une règle ou une stratégie Sophos Firewall effective uniquement pendant une plage horaire définie. Elle est utile pour les heures ouvrées, les accès invités ou une fenêtre de maintenance approuvée. La solution n’est sûre que si l’heure du pare-feu est correcte, si le type de planification approprié est choisi et si aucune règle plus large ne reprend le même trafic hors de cette plage.

La procédure rapide pour une règle de pare-feu limitée dans le temps est la suivante :

1. Sous Administration > Time, contrôler l’heure actuelle et le fuseau horaire.
2. Sous Profiles > Schedule > Add, créer une planification récurrente ou ponctuelle.
3. Ouvrir la règle de pare-feu concernée et sélectionner la planification sous During scheduled time.
4. Vérifier à nouveau la position de la règle, la source, la destination, le service et la journalisation.
5. Tester une nouvelle connexion avant, pendant et après la plage horaire.
6. Dans Log Viewer, vérifier quelle Firewall Rule ID traite réellement le trafic.

⚠️ Une planification ne sécurise pas une règle trop large. Elle limite uniquement le moment où cette règle ou stratégie précise est effective. La source, la destination, les services, les utilisateurs, les fonctions de protection et l’ordre des règles doivent toujours être planifiés de manière restrictive.

Ce que contrôle une planification

Sophos Firewall utilise les planifications comme objets horaires réutilisables. Elles peuvent limiter dans le temps les règles de pare-feu, les stratégies web, les stratégies d’application, les stratégies de traffic shaping, les stratégies de temps d’accès et les analyses de points d’accès non autorisés.

La planification elle-même n’autorise et ne bloque aucun trafic. Elle ne prend effet qu’après son affectation à une règle, une stratégie ou une analyse. All the time signifie qu’aucune restriction temporelle n’est prévue.

Récurrente ou ponctuelle

Deux modèles sont disponibles sous Recurrence type :

• Recurring : se répète les jours de la semaine et aux heures sélectionnés. Ce type convient par exemple aux heures de bureau ou aux fenêtres de maintenance régulières.
• One-time : s’applique entre une date de début et une date de fin aux heures définies. Ce type convient à une conférence unique, à un accès invité temporaire ou à une maintenance ponctuelle.

Une planification One-time ne peut être appliquée qu’aux règles de pare-feu. Les stratégies web, d’application et de traffic shaping, les stratégies de temps d’accès et les analyses de points d’accès non autorisés nécessitent une planification récurrente.

Avec Expand, une planification récurrente peut utiliser des heures de début et de fin différentes selon les jours de la semaine. Cette solution est plus claire que plusieurs règles presque identiques, tant que l’autorisation fonctionnelle reste la même tous les jours.

Schedule et Access Time ne sont pas identiques

Une planification décrit uniquement des jours et des heures. Une Access time policy combine en revanche une planification récurrente avec l’action Allow ou Deny et est affectée à des utilisateurs, des groupes ou des utilisateurs invités.

Configurer Access Time pour les utilisateurs et les groupes explique l’attribution complète, la priorité de l’utilisateur sur le groupe et la limite du groupe principal AD.

Pour un chemin réseau limité dans le temps, la planification doit être placée directement dans la règle de pare-feu. Pour un accès Internet dépendant de l’heure pour un utilisateur ou un groupe, une stratégie de temps d’accès peut être plus appropriée. Les deux mécanismes ne doivent pas être superposés sans raison claire, car il devient alors difficile d’identifier le niveau qui met fin à l’accès.

Planifier la base horaire et les valeurs d’exemple

Les planifications suivent l’horloge et le fuseau horaire du pare-feu. Avant la configuration, contrôler au minimum Current time et Time zone sous Administration > Time. Configurer l’heure système et NTP sur Sophos Firewall explique comment vérifier correctement NTP et le fuseau horaire.

Le changement de serveurs NTP n’est pas une étape anodine de dépannage : Sophos indique que toutes les connexions IPsec sont alors rétablies. Pour la validation initiale d’une planification, un contrôle en lecture seule de la base horaire existante suffit.

Les valeurs d’exemple suivantes rendent la procédure concrète :

• Recurring : Guest_BusinessHours, du lundi au vendredi, de 07:30 à 18:00
• Règle de pare-feu : Guest_to_WAN_BusinessHours
• Source : net_Guest_10.50.0.0_24
• Destination : WAN et Any
• Services : HTTP et HTTPS
• One-time : Vendor_Maintenance_2026-09-15, le 15 septembre 2026 de 22:00 à 23:30
• Source externe d’exemple : 198.51.100.25
• Destination interne d’exemple : 10.20.30.40
• Service : HTTPS

198.51.100.25 est une adresse de documentation qui doit être remplacée par l’adresse publique fixe du prestataire. Les noms, réseaux, date et heures sont également des valeurs d’exemple. Il faut utiliser la source réellement approuvée, la destination la plus restrictive, les services nécessaires et la plage horaire autorisée.

Créer une planification récurrente

Pour l’exemple des invités, créer une planification récurrente :

1. Ouvrir Profiles > Schedule.
2. Sélectionner Add.
3. Définir Name sur Guest_BusinessHours.
4. Sous Description, documenter l’objectif, le responsable et le fuseau horaire, par exemple Accès web invités, Lun-Ven 07:30-18:00 Europe/Zurich, Responsable IT.
5. Définir Recurrence type sur Recurring.
6. Sélectionner du lundi au vendredi.
7. Définir Start time sur 07:30 et Stop time sur 18:00.
8. Laisser le samedi et le dimanche désactivés.
9. Pour des horaires quotidiens différents, utiliser Expand et vérifier chaque jour séparément.
10. Enregistrer avec Save.

La planification enregistrée n’a pas encore d’effet. Le contrôle temporel du chemin correspondant n’est activé qu’après son affectation à une règle ou une stratégie.

Affecter une planification à une règle de pare-feu

L’autorisation elle-même reste une règle de pare-feu normale. Comprendre et configurer les règles Sophos Firewall en toute sécurité explique l’interaction entre les critères de correspondance, les fonctions de protection et l’ordre des règles.

Pour l’exemple des invités :

1. Ouvrir Rules and policies > Firewall rules.
2. Créer la règle Guest_to_WAN_BusinessHours ou modifier une règle existante déjà documentée.
3. Limiter Source zones et Source networks and devices au réseau invité.
4. Sous During scheduled time, sélectionner Guest_BusinessHours.
5. Définir Destination zones sur WAN et exclure les destinations internes.
6. Sélectionner uniquement les Services nécessaires.
7. Affecter des stratégies web, d’application et IPS appropriées.
8. Activer Log firewall traffic.
9. Vérifier la position de la règle et enregistrer.

Sophos Firewall évalue les règles de pare-feu de haut en bas. Si la règle planifiée n’est pas effective hors de sa plage, une règle ultérieure plus large peut autoriser le même trafic. Une règle Allow limitée dans le temps nécessite donc soit une correspondance clairement séparée, soit une logique de blocage ultérieure planifiée délibérément. La solution est validée à l’aide de la Firewall Rule ID réelle, et pas seulement par le chargement réussi d’une page.

Règle de maintenance ponctuelle

Pour une seule fenêtre d’accès d’un prestataire, sélectionner plutôt One-time sous Profiles > Schedule > Add. Reprendre la date de début, la date de fin et les heures de la fenêtre de maintenance approuvée. Affecter ensuite la planification à la règle de pare-feu restrictive sous During scheduled time.

La règle reste présente comme objet de configuration après la plage horaire, mais elle ne correspond plus hors de la planification. Le ticket et le responsable doivent donc aussi définir si la règle sera désactivée, supprimée ou réutilisée avec une nouvelle planification après l’intervention.

Une règle ponctuelle ne remplace pas des critères restrictifs. Dans l’exemple, l’autorisation contient uniquement l’adresse source confirmée, l’hôte de destination 10.20.30.40, le service HTTPS nécessaire, la journalisation et la bonne position de règle. Une source WAN large ou Any comme service reste inutilement risquée, même pendant une courte plage.

Utiliser les planifications dans les stratégies

Les planifications récurrentes peuvent aussi être utilisées dans d’autres domaines :

• Web policy : Constraints détermine quand une règle de stratégie s’applique.
• Application policy : une règle de filtre d’application peut recevoir une planification.
• Traffic shaping policy : la règle de bande passante ne s’applique que pendant la planification sélectionnée.
• Access time policy : une planification récurrente détermine quand Allow ou Deny s’applique aux utilisateurs et groupes affectés.
• Rogue AP scan : l’analyse peut s’exécuter à des heures récurrentes.

Le contrôle temporel de la stratégie et l’affectation de la stratégie sont deux étapes distinctes. Une stratégie web ou d’application ne prend effet que par l’intermédiaire de la règle de pare-feu associée. Configurer et tester Application Control sur Sophos Firewall explique entièrement le contrôle des applications, tandis que Configurer Sophos Firewall Web Protection avec des stratégies web couvre la logique du filtrage web.

Les différentes couches horaires d’une même connexion doivent être documentées délibérément. Une planification dans la règle de pare-feu et une autre dans une stratégie web ou d’application peuvent produire des résultats techniques différents : le chemin réseau peut rester ouvert alors que seule une action web ou d’application particulière change.

Tester les limites horaires de manière fiable

Une configuration enregistrée n’est pas encore une preuve. La validation utilise une nouvelle connexion et les mêmes valeurs de test avant, pendant et après la plage horaire :

1. Documenter Current time et Time zone sur le pare-feu.
2. Vérifier le type de planification, les jours de la semaine, l’heure de début et l’heure de fin.
3. Vérifier la position de la règle et During scheduled time.
4. Peu avant le début, générer un flux de test défini et relever le comportement de blocage ou de repli attendu.
5. Ouvrir une nouvelle connexion après le début.
6. Dans Log Viewer, comparer la source, la destination, le service, la Firewall Rule ID, l’action et l’horodatage.
7. Après la fin, ouvrir une autre nouvelle connexion et vérifier quelle règle s’applique maintenant.
8. Pour les stratégies web ou d’application, vérifier également la stratégie, l’utilisateur et l’action de la stratégie.

La procédure complète avec Log Viewer, Packet Capture et Rule ID est décrite dans Tester proprement une règle Sophos Firewall.

Sophos ne documente pas de manière générale que chaque session existante est immédiatement interrompue à la fin d’une planification. Pour un accès critique, observer donc à la fois une nouvelle connexion après la limite et une session déjà active. Si les sessions existantes doivent impérativement se terminer immédiatement, la planification ne doit pas être considérée comme l’unique mesure de protection sans preuve réelle.

Délimiter méthodiquement les erreurs

La règle s’applique à la mauvaise heure

Ouvrir d’abord Administration > Time et comparer Current time et Time zone avec l’heure d’exploitation documentée. Vérifier ensuite le jour de la semaine, l’heure de début, l’heure de fin et les éventuelles valeurs quotidiennes configurées avec Expand. Le fuseau horaire du navigateur de l’administrateur ne modifie pas l’heure du pare-feu.

Le trafic fonctionne hors de la plage

Dans Log Viewer, identifier la Firewall Rule ID qui a réellement traité le trafic. Une règle Allow générale placée plus bas prend souvent le relais. Dans ce cas, corriger l’ordre des règles et la logique de correspondance au lieu d’élargir la planification. En l’absence de journal de règle correspondant, Packet Capture et la règle implicite de rejet total #0 aident à délimiter la cause.

One-time n’est pas disponible dans une stratégie

Il s’agit de la limite documentée du produit : les planifications One-time peuvent uniquement être affectées aux règles de pare-feu. Les stratégies web, d’application, de traffic shaping et de temps d’accès nécessitent une planification récurrente.

La planification ne peut pas être supprimée

Une planification utilisée ne peut pas être supprimée directement. Identifier d’abord toutes les règles, stratégies et analyses qui en dépendent. Affecter ensuite une autre planification appropriée à chaque dépendance ou la supprimer de manière contrôlée. Supprimer seulement ensuite la planification devenue inutilisée.

La stratégie change, mais le chemin réseau reste ouvert

Une planification de stratégie contrôle uniquement la règle de stratégie correspondante. Si l’ensemble du chemin réseau doit être fermé hors de la plage, la règle de pare-feu doit elle aussi être limitée dans le temps et testée face aux règles de repli ultérieures.

Planifier les modifications et le retour arrière

Avant une modification, documenter le nom, le type, les jours, les heures et le fuseau horaire de la planification, toutes ses utilisations et la position des règles de pare-feu concernées. Pour un retour sûr, réaffecter la planification précédente au lieu de sélectionner aveuglément All the time.

Un retour arrière typique se déroule comme suit :

1. Garder ouvertes la session d’administration existante et une voie d’administration alternative.
2. Affecter la planification précédente documentée à la règle ou à la stratégie concernée.
3. Vérifier que la position et l’état de la règle restent inchangés.
4. Tester avec une nouvelle connexion et la Rule ID attendue.
5. Supprimer la nouvelle planification uniquement lorsqu’il ne reste plus aucune dépendance.
6. Mettre à jour le ticket, le responsable et le résultat du test.

Pour une autorisation de maintenance ponctuelle, le retrait prévu doit figurer dans le ticket avant l’activation. Ainsi, aucune règle inactive mais non documentée ne subsiste après l’intervention.

Questions fréquentes