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.

Le point de contrôle approprié dépend de l’objectif :

• Si l’ensemble du chemin réseau ne doit être ouvert qu’à certaines heures, la planification doit être placée dans la règle de pare-feu.
• Si seule une action web ou d’application doit changer au sein d’un chemin ouvert, la planification est affectée à la règle de stratégie concernée.
• Si l’accès Internet d’un utilisateur ou d’un groupe doit être autorisé ou bloqué selon l’heure, une stratégie de temps d’accès est généralement plus claire.
• Une planification One-time ne peut être affectée qu’à une règle de pare-feu.

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. Dans l’exemple récurrent pour les invités, la zone et le réseau sont des champs de correspondance distincts :

• Recurring : Guest_BusinessHours, du lundi au vendredi, de 07:30 à 18:00
• Règle de pare-feu : Guest_to_WAN_BusinessHours
• Source zones : la zone dédiée aux invités, ici Guest
• Source networks and devices : net_Guest_10.50.0.0_24
• Destination zones : WAN
• Destination networks : 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. L’exemple de maintenance suppose qu’un chemin entrant fonctionnel a déjà été testé. Si le serveur interne est publié sur Internet, le DNAT et la règle de pare-feu associée doivent être correctement configurés indépendamment de la planification ; voir Publier un serveur avec DNAT ou PAT.

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.

Après l’enregistrement, affecter la planification au point de contrôle prévu. Jusque-là, elle n’a aucun effet.

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 et sélectionner IPv4.
2. Pour une nouvelle règle, ouvrir Add firewall rule > New firewall rule, ou modifier une règle existante déjà documentée.
3. Définir Action sur Accept, puis limiter Source zones et Source networks and devices au réseau invité.
4. Définir Destination zones sur WAN et Destination networks sur Any. Si seules certaines destinations sont nécessaires, utiliser un objet de destination plus restrictif.
5. Sélectionner uniquement les Services nécessaires, HTTP et HTTPS.
6. Sous During scheduled time, sélectionner Guest_BusinessHours.
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.

Pour un réseau invité privé, une règle SNAT appropriée doit également exister, sauf si l’équipement en amont route les adresses source privées. Vérifier la règle NAT séparément, car Sophos Firewall évalue aussi les règles NAT selon le principe de la première correspondance. Une correspondance NAT absente ou incorrecte n’est pas corrigée par la planification. Cet exemple n’autorise que HTTP et HTTPS ; la résolution DNS nécessaire aux accès par nom doit fonctionner par un chemin autorisé et testé séparément.

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, créer une planification ponctuelle dédiée :

1. Ouvrir Profiles > Schedule > Add.
2. Définir Name sur Vendor_Maintenance_2026-09-15 et consigner le ticket, le responsable et l’objectif dans Description.
3. Définir Recurrence type sur One-time.
4. Définir les dates de début et de fin sur le 15 septembre 2026.
5. Définir Start time sur 22:00 et Stop time sur 23:30.
6. Vérifier de nouveau les valeurs par rapport à la fenêtre approuvée et au fuseau horaire du pare-feu, puis enregistrer avec Save.
7. Affecter la planification sous During scheduled time à la règle de maintenance restrictive déjà testée.

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 doit 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 DNAT, l’autorisation comprend Source zones WAN, l’adresse confirmée sous Source networks and devices, la zone interne DMZ sous Destination zones, Destination networks 10.20.30.40, le service HTTPS, la journalisation et la bonne position de règle. La règle de pare-feu vérifie la destination interne traduite après le DNAT. Any comme réseau source ou comme service reste inutilement risqué, 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 : une règle de la stratégie web peut être limitée dans le temps.
• Application policy : une règle de filtre d’application peut recevoir une planification.
• Traffic shaping policy : sous System services > Traffic shaping > Add > Add schedule, affecter une planification à la règle de bande passante. Elle peut ensuite agir par l’intermédiaire d’un utilisateur, d’une règle de pare-feu, d’une catégorie web ou d’une entrée d’application.
• Access time policy : une planification récurrente détermine quand Allow ou Deny s’applique aux utilisateurs et groupes affectés.
• Rogue AP scan : sur les appareils dotés du Wi-Fi intégré, sélectionner la planification sous Wireless > Rogue AP scan > General settings > Schedule system-triggered scan at. L’analyse déconnecte brièvement les clients ; la plage horaire doit tenir compte de cette interruption.

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 pour la sécurité, 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. Après Sync now, Current time ne s’actualise pas immédiatement dans la vue ; recharger WebAdmin avant de conclure que l’heure reste incorrecte. L’évaluation des planifications repose sur l’heure et le fuseau affichés par le 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. All the time n’est pas une solution de retour arrière universelle, car ce choix supprime entièrement la restriction temporelle.

Le retour arrière dépend de la modification effectuée. Si seule la planification a changé, réaffecter la précédente. Désactiver ou supprimer de manière contrôlée toute nouvelle règle de pare-feu ; pour une règle existante, rétablir l’action, les champs de correspondance, les stratégies, la journalisation et la position aux valeurs antérieures documentées. Si le DNAT ou le SNAT du chemin a été modifié, ces règles et leur position font également partie du retour arrière.

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. Selon la situation initiale, réaffecter la planification précédente, désactiver la nouvelle règle ou restaurer tous les champs de règle modifiés.
3. Comparer les règles NAT associées, la position de la règle et son état aux valeurs antérieures documentées.
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