Configurer Access Time pour les utilisateurs sur Sophos Firewall

Une politique Access Time limite l’accès Internet d’un utilisateur, d’un groupe ou d’utilisateurs invités à des horaires définis. La politique associe un Schedule récurrent à Allow ou Deny. Elle ne s’applique toutefois qu’à une identité réellement reconnue par le firewall et à laquelle la politique est attribuée directement ou par l’intermédiaire de son groupe principal.

La procédure rapide pour autoriser l’accès Internet pendant les heures de bureau est la suivante :

1. Sous Administration > Time, contrôler l’heure et le fuseau horaire du firewall.
2. Sous Profiles > Schedule, créer un Schedule récurrent, par exemple Internet_OfficeHours.
3. Sous Profiles > Access time > Add, créer la politique Employees_OfficeHours_Allow avec Action: Allow.
4. Sous Authentication > Groups, attribuer la politique à un petit groupe pilote.
5. Sous Current activities > Live users, contrôler l’utilisateur et l’adresse source, puis sous Authentication > Users, vérifier le groupe principal attendu.
6. Tester une nouvelle connexion Internet à l’intérieur et à l’extérieur de la plage horaire.
7. N’ajouter d’autres utilisateurs qu’après la réussite des tests positif et négatif.

⚠️ Selon Sophos, les modifications d’une politique Access Time prennent effet immédiatement. Une politique partagée ne doit donc pas être modifiée de manière improvisée. Il faut d’abord recenser les utilisateurs et groupes concernés, documenter un compte pilote et l’état précédent, puis tester les limites horaires de manière contrôlée.

Ce que contrôle réellement Access Time

Access Time détermine si un utilisateur authentifié obtient un accès Internet à une heure donnée. La politique ne crée ni règle firewall ni Web Policy et n’authentifie aucun utilisateur. Le chemin réseau, l’identification de l’utilisateur, la correspondance de la règle et les fonctions de protection doivent donc déjà fonctionner.

Quatre éléments sont nécessaires à l’évaluation :

• un Schedule récurrent contenant les jours et les heures ;
• une politique Access Time avec Allow ou Deny ;
• une attribution à un utilisateur, un groupe ou un utilisateur invité ;
• une identité reconnue, par exemple via Captive Portal, STAS, SATC ou une autre méthode d’authentification adaptée.

Choisir délibérément Allow ou Deny

• Allow : l’accès Internet est autorisé pendant le Schedule sélectionné et bloqué en dehors de cette plage. Ce modèle convient aux collaborateurs, aux salles de formation ou aux comptes de prestataires dont les heures d’utilisation sont clairement définies.
• Deny : l’accès Internet est bloqué pendant le Schedule et autorisé en dehors. Ce modèle convient à une période de blocage ciblée, par exemple un cours récurrent ou une période de repos.

Pour un nouvel accès restreint, Allow est généralement plus facile à comprendre : la plage autorisée est directement visible dans l’objet et peut être testée positivement et négativement avec un petit groupe pilote. Deny est pertinent lorsque l’état normal doit explicitement rester ouvert et qu’une seule plage de blocage précisément définie est nécessaire.

Schedule, quota et heure de connexion sont des niveaux différents

Des fonctions aux noms similaires répondent à des besoins différents :

• Un Schedule contient uniquement des jours et des heures. Il ne produit un effet qu’à travers une règle firewall, une politique ou une politique Access Time. Les Schedules Sophos Firewall pour les règles et les politiques expliquent leur configuration complète.
• Surfing quota limite la durée d’utilisation d’Internet disponible pour un utilisateur. Il s’agit d’un contingent de consommation, et non d’une plage horaire fixe.
• Network traffic quota limite le volume de données transféré.
• La validité d’un compte invité détermine la durée d’existence des identifiants. Elle ne remplace pas une Access Time récurrente.
• Les Clientless Users ne prennent pas en charge les politiques Access Time. Si un appareil fixe ne doit communiquer qu’à certaines heures, le Schedule est appliqué à une règle firewall étroitement délimitée. Configurer les Clientless Users sur Sophos Firewall explique l’identité basée sur l’adresse IP.
• Schedule for device access dans les paramètres administrateur limite les connexions à WebAdmin. L’option Access time normale n’est pas prévue à cet effet.

Surfing Quota et Network Traffic Quota sur Sophos Firewall explique comment créer et attribuer les deux crédits de consommation, les contrôler sous View usage et les réinitialiser en sécurité.

Plusieurs niveaux horaires ne doivent être combinés qu’avec une intention documentée. Le Schedule d’une règle firewall peut fermer tout le chemin réseau, tandis qu’Access Time ne concerne que les utilisateurs auxquels elle est attribuée. Si les deux niveaux utilisent des plages différentes, chaque limite doit être testée séparément.

Planifier l’exemple et les prérequis

L’exemple suivant autorise un groupe de collaborateurs à accéder à Internet du lundi au vendredi entre 07:30 et 18:00 :

• Schedule : Internet_OfficeHours
• Politique Access Time : Employees_OfficeHours_Allow
• Action : Allow
• Groupe : Internet_OfficeHours
• Utilisateur de test : access-time-pilot
• Fuseau horaire : Europe/Zurich
• Plage horaire : du lundi au vendredi, de 07:30 à 18:00

Les noms et les heures sont des valeurs d’exemple. Dans l’environnement réel, le nom du groupe, le responsable, le fuseau horaire et les heures d’exploitation autorisées sont repris de la demande d’accès effective. Un groupe ne doit contenir que des utilisateurs soumis au même modèle horaire.

Avant la modification, vérifier les prérequis suivants :

1. Sous Administration > Time, les valeurs Current time et Time zone sont correctes. Configurer l’heure système et NTP sur Sophos Firewall explique la configuration NTP.
2. L’utilisateur pilote peut s’authentifier avec la méthode prévue.
3. Sous Current activities > Live users, le nom d’utilisateur et l’adresse source apparaissent ; sous Authentication > Users, le champ Group est correct.
4. Une règle utilisateur ou réseau adaptée autorise le chemin Internet prévu et journalise le trafic de test.
5. L’attribution Access Time précédente, le groupe principal et les éventuelles exceptions utilisateur sont documentés.

Si l’utilisateur n’est pas identifiable comme Live User, il faut d’abord corriger l’authentification. Une politique Access Time ne peut pas contrôler de manière fiable une identité inconnue par utilisateur ou par groupe.

Créer le Schedule et la politique Access Time

Préparer un Schedule récurrent

Les politiques Access Time n’acceptent que des Schedules récurrents. Un Schedule One-time n’est pas disponible ici.

Pour l’exemple :

1. Ouvrir Profiles > Schedule > Add.
2. Définir Name sur Internet_OfficeHours.
3. Définir Recurrence type sur Recurring.
4. Sélectionner du lundi au vendredi.
5. Définir Start time sur 07:30 et Stop time sur 18:00.
6. Documenter l’objectif, le fuseau horaire et le responsable dans Description.
7. Enregistrer avec Save.

Le Schedule seul ne modifie encore aucun accès. Il s’agit d’un objet horaire réutilisable qui peut également servir ailleurs. Avant toute modification ultérieure, il faut donc toujours contrôler toutes ses utilisations.

Créer la politique Access Time

L’objet horaire est ensuite associé à l’action d’accès :

1. Ouvrir Profiles > Access time.
2. Sélectionner Add.
3. Définir Name sur Employees_OfficeHours_Allow.
4. Dans Description, saisir par exemple Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT.
5. Définir Action sur Allow.
6. Sous Schedule, sélectionner Internet_OfficeHours.
7. Enregistrer avec Save.

Cette politique n’a elle non plus aucun effet tant qu’elle n’est pas attribuée à un utilisateur, un groupe ou un utilisateur invité.

Attribuer la politique à un groupe ou à un utilisateur

Utiliser un groupe comme modèle d’exploitation normal

Pour les utilisateurs soumis au même modèle horaire, un groupe est plus clair que de nombreuses attributions individuelles :

1. Ouvrir Authentication > Groups.
2. Créer le groupe pilote Internet_OfficeHours ou modifier un groupe existant correctement délimité.
3. Dans la section des politiques, sélectionner Employees_OfficeHours_Allow pour Access time.
4. Ne pas modifier au passage d’autres paramètres de quota, de Traffic Shaping ou de Remote Access.
5. Enregistrer les modifications.
6. Authentifier un seul utilisateur de test dans ce groupe et contrôler le groupe principal réel.

Gérer les groupes d’utilisateurs Sophos Firewall en sécurité explique l’interaction entre les groupes locaux et importés, le groupe principal et les exceptions utilisateur. L’importation AD proprement dite reste décrite dans Connecter Active Directory à Sophos Firewall.

N’utiliser une exception utilisateur que délibérément

Sous Authentication > Users, une Access time distincte peut être sélectionnée pour un utilisateur donné. Cette valeur utilisateur a priorité sur la politique du groupe.

Une exception est utile pour un cas documenté, mais elle peut donner l’impression que les modifications du groupe sont sans effet. Si un groupe est correctement configuré mais qu’un utilisateur se comporte différemment, il faut donc commencer par contrôler l’objet de cet utilisateur. Pour revenir à la politique du groupe, il ne faut pas sélectionner arbitrairement une nouvelle politique individuelle, mais rétablir de manière contrôlée l’état d’héritage précédent.

Seul le groupe principal compte avec Active Directory

Pour les utilisateurs AD, Access Time n’évalue pas les Other group memberships. Le groupe principal affiché sous Group dans l’objet utilisateur s’applique, sauf si une politique a été explicitement sélectionnée pour cet utilisateur.

L’ordre défini sous Authentication > Groups > Reorder détermine quel groupe importé devient le groupe principal. Une modification de cet ordre peut donc affecter non seulement Access Time, mais aussi d’autres fonctions. Il ne faut pas l’utiliser comme correction rapide pour un seul utilisateur. Un ordre de groupes planifié délibérément ou une exception utilisateur documentée est préférable.

Les modifications des groupes AD, de leur ordre et des politiques associées sont appliquées lors de la prochaine connexion de l’utilisateur. Pour obtenir un test propre, il faut donc créer une nouvelle session d’authentification, puis contrôler à nouveau le groupe principal.

Contrôler les utilisateurs invités par l’intermédiaire de leur groupe

Les utilisateurs invités sur Sophos Firewall reçoivent un groupe sous Authentication > Guest user settings et héritent de ses politiques. Pour appliquer aux invités une plage récurrente d’accès Internet, la politique Access Time est attribuée à ce groupe d’invités clairement délimité.

La Validity period du compte invité reste une limite supplémentaire : elle détermine la durée de validité du compte. Access Time détermine, au sein de cette validité, les heures récurrentes autorisées ou bloquées. Configurer et tester Captive Portal sur Sophos Firewall explique la connexion des invités et la règle firewall.

Tester les limites horaires de manière fiable

Une politique enregistrée n’est pas encore une preuve de réussite. Le test de recette vérifie conjointement l’identité, la politique et l’accès Internet réel :

1. Documenter l’heure du firewall, le fuseau horaire, le Schedule et l’Action.
2. Authentifier à nouveau l’utilisateur pilote.
3. Sous Current activities > Live users, contrôler le nom d’utilisateur et l’adresse source ; sous Authentication > Users, contrôler le groupe principal.
4. À l’intérieur de la plage Allow, ouvrir une nouvelle connexion HTTP ou HTTPS vers une destination de test autorisée.
5. Dans Log Viewer, contrôler l’utilisateur, le groupe, la source, la destination, le Firewall Rule ID, l’action et l’horodatage.
6. En dehors de la plage, tester une nouvelle connexion vers la même destination et confirmer le blocage attendu.
7. Pour une politique Deny, effectuer le même test avec l’attente inverse.
8. N’attribuer d’autres utilisateurs ou le groupe de production qu’ensuite.

La règle firewall doit toujours correspondre à l’utilisateur, au réseau et à la destination. Tester correctement une règle Sophos Firewall explique comment évaluer ensemble la Rule ID, Log Viewer et Packet Capture.

Sophos documente que les modifications des politiques Access Time prennent effet immédiatement. Cela ne constitue toutefois pas une promesse générale que chaque session applicative existante soit interrompue exactement à la limite horaire. Pour les exigences critiques de sécurité, une nouvelle connexion et une session déjà en cours sont donc observées séparément.

Délimiter systématiquement les erreurs

L’utilisateur n’a aucun accès Internet malgré la politique

Vérifier d’abord si l’heure actuelle se situe à l’intérieur du Schedule pour Allow, ou à l’extérieur pour Deny. Contrôler ensuite l’identité de l’utilisateur et l’adresse source sous Current activities > Live users, puis le groupe principal sous Authentication > Users. Si l’utilisateur n’apparaît pas dans Live users, l’étape suivante concerne l’authentification et non un élargissement de la politique Access Time.

Contrôler ensuite la règle firewall, la correspondance utilisateur, la position de la règle et Log Viewer. Access Time ne peut pas réparer un chemin réseau manquant ni une politique Web, Application ou TLS qui bloque le trafic.

L’accès fonctionne en dehors de la plage Allow

Vérifier que le test porte réellement sur l’utilisateur attendu et qu’une autre Access Time n’est pas définie dans l’objet utilisateur. Pour AD, contrôler également le groupe principal et l’ordre des groupes. Un test non authentifié ou mal attribué ne prouve pas que la politique est défaillante.

Générer ensuite un nouveau flux de test. Une session existante peut présenter un comportement différent d’une nouvelle connexion. Si le trafic apparaît dans Log Viewer sans l’utilisateur attendu, il faut d’abord résoudre l’identification de l’utilisateur.

Une modification de groupe n’agit pas sur un utilisateur

Une politique utilisateur explicite a priorité sur la politique du groupe. Sous Authentication > Users, contrôler le champ Access time et, pour AD, le groupe principal. Access Time n’évalue pas les Other group memberships.

Après une modification des groupes AD, authentifier à nouveau l’utilisateur. Ce n’est qu’ensuite que l’ordre actuel des groupes et l’attribution de la politique peuvent être évalués.

Captive Portal apparaît de manière inattendue

Sophos cite une Access Time restrictive, des identifiants incorrects et des quotas épuisés parmi les causes possibles de problèmes NTLM ou Captive Portal. Contrôler séparément Access Time, Surfing quota, Network traffic quota et les identifiants. Il ne faut pas basculer précipitamment la politique sur Allow ni élargir le Schedule tant que la cause réelle reste incertaine.

Une modification touche plus d’utilisateurs que prévu

Une politique Access Time partagée agit immédiatement sur toutes ses attributions après une modification. Rétablir d’abord l’Action et le Schedule précédemment documentés. Recenser ensuite les groupes et les exceptions utilisateur concernés, puis tester la nouvelle exigence avec une politique pilote distincte.

Planifier les modifications et le rollback

Avant toute modification en production, documenter le nom de la politique, l’Action, le Schedule, les groupes concernés, les exceptions utilisateur, les groupes principaux, l’heure du firewall et le résultat du test. Le retour arrière reste ainsi sans ambiguïté.

Un rollback contrôlé suit les étapes suivantes :

1. Rétablir l’attribution Access Time précédente pour l’utilisateur ou le groupe pilote.
2. Pour AD, authentifier à nouveau l’utilisateur de test.
3. Sous Current activities > Live users, contrôler l’utilisateur et l’adresse source, puis sous Authentication > Users, contrôler le groupe principal.
4. Tester une nouvelle connexion à l’intérieur et à l’extérieur de la plage concernée.
5. Contrôler Log Viewer et le Firewall Rule ID utilisé.
6. Ne supprimer la nouvelle politique et le nouveau Schedule que lorsqu’il ne reste plus aucune dépendance.
7. Mettre à jour le ticket, le responsable et le résultat du test.

En exploitation, les politiques partagées doivent avoir un responsable et une Description explicite. Lorsque les horaires de travail, les modèles de jours fériés ou les structures de groupes changent, les plages horaires et les attributions sont à nouveau contrôlées au lieu d’élargir progressivement la politique sans documentation.

Liste de contrôle opérationnelle

• L’heure et le fuseau horaire du firewall sont corrects.
• Le Schedule est récurrent et documenté.
• Allow ou Deny correspond à l’état normal souhaité.
• La politique Access Time est attribuée au bon groupe ou au bon utilisateur.
• Les exceptions utilisateur ont été contrôlées.
• Pour AD, le groupe principal est correct ; les Other group memberships ne sont pas supposées prises en compte.
• L’utilisateur pilote apparaît comme Live User et son objet utilisateur affiche le groupe principal attendu.
• Les tests positif et négatif aux limites ont été effectués avec de nouvelles connexions.
• La règle firewall, l’utilisateur, la Rule ID et les logs concordent.
• L’état précédent et le rollback sont documentés.

Questions fréquentes