Sophos Firewall Access Time für Benutzer einrichten

Mit einer Access-Time-Policy begrenzt man den Internetzugriff eines Benutzers, einer Gruppe oder von Gastbenutzern auf definierte Zeiten. Die Policy verbindet einen wiederkehrenden Schedule mit Allow oder Deny. Sie wirkt jedoch nur für eine Identität, welche die Firewall tatsächlich erkannt hat und der die Policy direkt oder über ihre Main Group zugewiesen ist.

Der Kurzweg für einen erlaubten Internetzugriff während der Bürozeiten lautet:

1. Unter Administration > Time Firewall-Zeit und Zeitzone kontrollieren.
2. Unter Profiles > Schedule einen wiederkehrenden Schedule erstellen, beispielsweise Internet_OfficeHours.
3. Unter Profiles > Access time > Add die Policy Employees_OfficeHours_Allow mit Action: Allow erstellen.
4. Die Policy unter Authentication > Groups einer kleinen Pilotgruppe zuweisen.
5. Unter Current activities > Live users Benutzer und Quelladresse sowie unter Authentication > Users die erwartete Main Group prüfen.
6. Innerhalb und ausserhalb des Zeitfensters jeweils eine neue Internetverbindung testen.
7. Erst nach dem positiven und negativen Test weitere Benutzer aufnehmen.

⚠️ Änderungen an einer Access-Time-Policy werden laut Sophos sofort wirksam. Eine gemeinsam verwendete Policy wird deshalb nicht spontan bearbeitet. Zuerst betroffene Benutzer und Gruppen erfassen, einen Pilotzugang und den vorherigen Zustand dokumentieren und danach die Zeitgrenzen kontrolliert testen.

Was Access Time wirklich steuert

Access Time entscheidet, ob ein authentifizierter Benutzer zu einer bestimmten Uhrzeit Internetzugriff erhält. Die Policy erstellt weder eine Firewall-Regel noch eine Web Policy und authentifiziert keinen Benutzer. Netzwerkpfad, Benutzererkennung, Regel-Match und Schutzfunktionen müssen deshalb bereits funktionieren.

Für die Auswertung sind vier Elemente nötig:

• ein wiederkehrender Schedule mit Tagen und Uhrzeiten;
• eine Access-Time-Policy mit Allow oder Deny;
• eine Zuweisung an Benutzer, Gruppe oder Gastbenutzer;
• eine erkannte Identität, beispielsweise über Captive Portal, STAS, SATC oder eine andere passende Authentifizierungsmethode.

Allow oder Deny bewusst wählen

• Allow: Internetzugriff ist während des ausgewählten Schedules erlaubt und ausserhalb dieses Fensters gesperrt. Dieses Modell passt zu Mitarbeitenden, Lernräumen oder Dienstleisterkonten mit klaren Nutzungszeiten.
• Deny: Internetzugriff ist während des Schedules gesperrt und ausserhalb erlaubt. Dieses Modell passt zu einer gezielten Sperrzeit, beispielsweise einer wiederkehrenden Unterrichts- oder Ruhephase.

Für einen neuen eingeschränkten Zugriff ist Allow meist leichter zu verstehen: Das erlaubte Fenster ist direkt im Objekt sichtbar und kann mit einem kleinen Pilotkreis positiv und negativ getestet werden. Deny ist sinnvoll, wenn der Normalzustand ausdrücklich offen bleiben soll und nur ein genau definiertes Sperrfenster benötigt wird.

Schedule, Quota und Loginzeit sind andere Ebenen

Ähnlich klingende Funktionen lösen andere Aufgaben:

• Ein Schedule beschreibt nur Tage und Uhrzeiten. Er erhält seine Wirkung erst durch eine Firewall-Regel, Policy oder Access-Time-Policy. Die vollständige Erstellung erklärt Sophos Firewall Zeitpläne für Regeln und Policies.
• Surfing quota begrenzt die nutzbare Internetzeit eines Benutzers. Das ist ein Verbrauchskontingent und kein festes Uhrzeitfenster.
• Network traffic quota begrenzt die übertragene Datenmenge.
• Die Gültigkeit eines Gastkontos legt fest, wie lange die Anmeldedaten bestehen. Sie ersetzt keine wiederkehrende Access Time.
• Clientless Users unterstützen keine Access-Time-Policy. Soll ein festes Gerät nur zu bestimmten Zeiten kommunizieren, wird der Zeitplan in einer engen Firewall-Regel verwendet. Die IP-basierte Identität erklärt Sophos Firewall Clientless Users einrichten.
• Schedule for device access unter den Administrator-Einstellungen begrenzt WebAdmin-Anmeldungen. Die normale Access time ist dafür nicht vorgesehen.

Wie man beide Verbrauchskontingente erstellt, zuweist, unter View usage kontrolliert und sicher zurücksetzt, erklärt Surfing Quota und Network Traffic Quota auf Sophos Firewall.

Mehrere Zeitebenen sollten nur mit dokumentierter Absicht kombiniert werden. Ein Firewall-Regel-Schedule kann den ganzen Netzwerkpfad schliessen, während Access Time nur die zugewiesenen Benutzer betrifft. Wenn beide Ebenen unterschiedliche Zeitfenster verwenden, muss jede Grenze separat getestet werden.

Beispiel und Voraussetzungen planen

Das folgende Beispiel erlaubt einer Mitarbeitergruppe den Internetzugriff von Montag bis Freitag zwischen 07:30 und 18:00:

• Schedule: Internet_OfficeHours
• Access-Time-Policy: Employees_OfficeHours_Allow
• Action: Allow
• Gruppe: Internet_OfficeHours
• Testbenutzer: access-time-pilot
• Zeitzone: Europe/Zurich
• Zeitfenster: Montag bis Freitag, 07:30 bis 18:00

Namen und Uhrzeiten sind Musterwerte. In der eigenen Umgebung werden Gruppenname, Owner, Zeitzone und freigegebene Betriebszeiten aus der tatsächlichen Zugriffsanforderung übernommen. Eine Gruppe sollte nur Benutzer mit demselben Zeitmodell enthalten.

Vor der Änderung werden diese Voraussetzungen geprüft:

1. Unter Administration > Time stimmen Current time und Time zone. Die NTP-Konfiguration erklärt Sophos Firewall Systemzeit und NTP konfigurieren.
2. Der Pilotbenutzer kann sich mit der vorgesehenen Methode authentifizieren.
3. Unter Current activities > Live users erscheinen Benutzername und Quelladresse; unter Authentication > Users stimmt das Feld Group.
4. Eine passende Benutzer- oder Netzwerkregel erlaubt den vorgesehenen Internetpfad und protokolliert den Testtraffic.
5. Vorherige Access-Time-Zuweisung, Main Group und mögliche Benutzer-Overrides sind dokumentiert.

Ist der Benutzer nicht als Live User erkennbar, wird zuerst die Authentifizierung korrigiert. Eine Access-Time-Policy kann eine unbekannte Identität nicht zuverlässig nach Benutzer oder Gruppe steuern.

Schedule und Access-Time-Policy erstellen

Wiederkehrenden Schedule vorbereiten

Access-Time-Policies akzeptieren ausschliesslich wiederkehrende Schedules. Ein One-time-Schedule ist hier nicht verfügbar.

Für das Beispiel:

1. Profiles > Schedule > Add öffnen.
2. Name auf Internet_OfficeHours setzen.
3. Recurrence type auf Recurring setzen.
4. Montag bis Freitag auswählen.
5. Start time auf 07:30 und Stop time auf 18:00 setzen.
6. In Description Zweck, Zeitzone und Owner dokumentieren.
7. Mit Save speichern.

Der Schedule allein ändert noch keinen Zugriff. Er ist ein wiederverwendbares Zeitobjekt und kann auch an anderen Stellen eingesetzt werden. Vor einer späteren Änderung werden deshalb immer alle Verwendungen geprüft.

Access-Time-Policy erstellen

Danach wird Zeitobjekt und Zugriffsaktion verbunden:

1. Profiles > Access time öffnen.
2. Add auswählen.
3. Name auf Employees_OfficeHours_Allow setzen.
4. Als Description beispielsweise Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT eintragen.
5. Action auf Allow setzen.
6. Unter Schedule Internet_OfficeHours auswählen.
7. Mit Save speichern.

Auch diese Policy hat noch keine Wirkung, solange sie keinem Benutzer, keiner Gruppe und keinem Gastbenutzer zugewiesen ist.

Policy einer Gruppe oder einem Benutzer zuweisen

Gruppe als normalen Betriebsweg verwenden

Für Benutzer mit demselben Zeitmodell ist eine Gruppe übersichtlicher als viele Einzelzuweisungen:

1. Authentication > Groups öffnen.
2. Die Pilotgruppe Internet_OfficeHours erstellen oder eine passend abgegrenzte bestehende Gruppe bearbeiten.
3. Im Policy-Bereich bei Access time Employees_OfficeHours_Allow auswählen.
4. Andere Quota-, Traffic-Shaping- und Remote-Access-Einstellungen nicht beiläufig verändern.
5. Speichern.
6. Einen einzelnen Testbenutzer in dieser Gruppe authentifizieren und die tatsächliche Main Group kontrollieren.

Wie lokale und importierte Gruppen, Main Group und Benutzer-Overrides zusammenspielen, erklärt Sophos Firewall Benutzergruppen sicher verwalten. Der eigentliche AD-Import bleibt im Ablauf Active Directory mit Sophos Firewall verbinden.

Benutzer-Override nur bewusst einsetzen

Unter Authentication > Users kann man für einen einzelnen Benutzer eine eigene Access time auswählen. Dieser Benutzerwert hat Vorrang vor der Gruppen-Policy.

Ein Override ist sinnvoll für eine dokumentierte Ausnahme, kann aber Gruppenänderungen scheinbar wirkungslos machen. Wenn eine Gruppe korrekt konfiguriert ist, ein einzelner Benutzer aber abweicht, wird deshalb zuerst dessen Benutzerobjekt geprüft. Soll wieder die Gruppen-Policy gelten, darf nicht irgendeine neue Einzel-Policy gewählt werden; die benutzerspezifische Abweichung wird kontrolliert auf den vorherigen Vererbungszustand zurückgesetzt.

Bei Active Directory zählt nur die Main Group

Access Time unterstützt bei AD-Benutzern keine Auswertung von Other group memberships. Es gilt die Main Group, die im Benutzerobjekt unter Group erscheint, oder eine explizit am Benutzer gewählte Policy.

Die Reihenfolge unter Authentication > Groups > Reorder beeinflusst, welche importierte Gruppe zur Main Group wird. Eine Änderung dieser Reihenfolge kann deshalb nicht nur Access Time, sondern auch andere Funktionen betreffen. Sie wird nicht als schneller Fix nur für einen Benutzer verwendet. Besser ist eine bewusst geplante Gruppenreihenfolge oder eine dokumentierte Benutzer-Ausnahme.

Änderungen an AD-Gruppen, Gruppenreihenfolge und zugehörigen Policies werden beim nächsten Sign-in des Benutzers übernommen. Für einen sauberen Test wird deshalb eine neue Authentifizierung erzeugt und danach die Main Group erneut kontrolliert.

Gastbenutzer über ihre Gruppe steuern

Gastbenutzer auf Sophos Firewall erhalten unter Authentication > Guest user settings eine Gruppe und erben deren Policies. Soll für Gäste ein wiederkehrendes Internetzeitfenster gelten, wird die Access-Time-Policy dieser klar abgegrenzten Gastgruppe zugewiesen.

Die Validity period eines Gastkontos bleibt eine zusätzliche Grenze: Sie bestimmt, wie lange das Konto gültig ist. Access Time bestimmt innerhalb dieser Gültigkeit die wiederkehrenden erlaubten oder gesperrten Uhrzeiten. Die Anmeldung und Firewall-Regel für Gäste erklärt Sophos Firewall Captive Portal einrichten und testen.

Zeitgrenzen zuverlässig testen

Eine gespeicherte Policy ist noch kein Erfolgsnachweis. Die Abnahme prüft Identität, Policy und echten Internetzugriff gemeinsam:

1. Firewall-Zeit, Zeitzone, Schedule und Action dokumentieren.
2. Pilotbenutzer neu authentifizieren.
3. Unter Current activities > Live users Benutzername und Quelladresse prüfen; unter Authentication > Users die Main Group kontrollieren.
4. Innerhalb des Allow-Fensters eine neue HTTP- oder HTTPS-Verbindung zu einem erlaubten Testziel öffnen.
5. Im Log Viewer Benutzer, Gruppe, Source, Destination, Firewall Rule ID, Action und Zeitstempel kontrollieren.
6. Ausserhalb des Fensters eine neue Verbindung zum gleichen Ziel testen und die erwartete Sperre bestätigen.
7. Bei einer Deny-Policy dieselbe Abnahme mit umgekehrter Erwartung durchführen.
8. Erst danach weitere Benutzer oder die produktive Gruppe zuweisen.

Die Firewall-Regel muss weiterhin zum Benutzer, Netz und Ziel passen. Wie man Rule ID, Log Viewer und Packet Capture gemeinsam auswertet, erklärt Sophos Firewall-Regel sauber testen.

Sophos dokumentiert, dass Änderungen an Access-Time-Policies sofort wirksam werden. Daraus folgt jedoch keine allgemeine Zusage, dass jede bereits bestehende Anwendungssitzung exakt am Zeitrand sofort getrennt wird. Für sicherheitskritische Vorgaben werden daher eine neue Verbindung und eine bereits laufende Sitzung getrennt beobachtet.

Fehler systematisch eingrenzen

Benutzer hat trotz Policy keinen Internetzugriff

Zuerst prüfen, ob der aktuelle Zeitpunkt bei Allow innerhalb oder bei Deny ausserhalb des Schedules liegt. Danach unter Current activities > Live users Benutzeridentität und Quelladresse sowie unter Authentication > Users die Main Group kontrollieren. Fehlt der Benutzer unter Live users, liegt der nächste Schritt bei Authentifizierung, nicht bei einer breiteren Access-Time-Policy.

Anschliessend Firewall-Regel, Benutzer-Match, Regelposition und Log Viewer prüfen. Access Time kann keinen fehlenden Netzwerkpfad oder eine blockierende Web-, Application- oder TLS-Policy reparieren.

Zugriff funktioniert ausserhalb des Allow-Fensters

Kontrollieren, ob wirklich der erwartete Benutzer getestet wird und ob am Benutzerobjekt eine andere Access Time hinterlegt ist. Bei AD zusätzlich Main Group und Gruppenreihenfolge prüfen. Ein nicht authentifizierter oder falsch zugeordneter Test ist kein Beweis gegen die Policy.

Danach einen neuen Testfluss erzeugen. Eine bereits laufende Sitzung kann ein anderes Bild liefern als eine neue Verbindung. Falls der Traffic im Log Viewer ohne erwarteten Benutzer erscheint, muss zuerst die Benutzererkennung geklärt werden.

Gruppenänderung wirkt bei einem Benutzer nicht

Eine explizite Benutzer-Policy hat Vorrang vor der Gruppen-Policy. Unter Authentication > Users das Feld Access time und bei AD die Main Group prüfen. Other group memberships werden für Access Time nicht ausgewertet.

Bei AD-Gruppenänderungen den Benutzer neu authentifizieren. Erst danach lässt sich beurteilen, ob die aktuelle Gruppenreihenfolge und Policy übernommen wurden.

Captive Portal erscheint unerwartet

Sophos nennt eine eingeschränkte Access Time neben falschen Anmeldedaten und überschrittenen Quotas als mögliche Ursache für NTLM- oder Captive-Portal-Probleme. Deshalb Access Time, Surfing quota, Network traffic quota und Credentials getrennt prüfen. Die Policy wird nicht vorschnell auf Allow oder einen breiteren Schedule gesetzt, solange die tatsächliche Ursache unklar ist.

Änderung trifft mehr Benutzer als erwartet

Eine gemeinsam zugewiesene Access-Time-Policy wirkt nach einer Änderung sofort für alle Verwendungen. Zuerst den vorher dokumentierten Action-/Schedule-Stand wiederherstellen. Danach betroffene Gruppen und Benutzer-Overrides inventarisieren und die neue Anforderung mit einer separaten Pilot-Policy testen.

Änderungen und Rollback planen

Vor jeder produktiven Änderung werden Policy-Name, Action, Schedule, betroffene Gruppen, Benutzer-Overrides, Main Groups, Firewall-Zeit und Testergebnis dokumentiert. So bleibt der Rückweg eindeutig.

Ein kontrollierter Rollback lautet:

1. Vorherige Access-Time-Zuweisung für Pilotbenutzer oder Pilotgruppe wiederherstellen.
2. Bei AD den Testbenutzer neu authentifizieren.
3. Unter Current activities > Live users Benutzer und Quelladresse sowie unter Authentication > Users die Main Group prüfen.
4. Innerhalb und ausserhalb des relevanten Fensters je eine neue Verbindung testen.
5. Log Viewer und verwendete Firewall Rule ID kontrollieren.
6. Die neue Policy und den neuen Schedule erst entfernen, wenn keine Abhängigkeit mehr besteht.
7. Ticket, Owner und Testergebnis aktualisieren.

Im Betrieb sollten gemeinsam verwendete Policies einen Owner und eine verständliche Description haben. Bei geänderten Arbeitszeiten, Feiertagsmodellen oder Gruppenstrukturen werden Zeitfenster und Zuweisungen erneut geprüft, statt die Policy stillschweigend immer weiter zu verbreitern.

Betriebscheckliste

• Firewall-Zeit und Zeitzone stimmen.
• Der Schedule ist wiederkehrend und dokumentiert.
• Allow oder Deny entspricht dem gewünschten Normalzustand.
• Die Access-Time-Policy ist der richtigen Gruppe oder dem richtigen Benutzer zugewiesen.
• Benutzer-Overrides wurden geprüft.
• Bei AD stimmt die Main Group; Other group memberships werden nicht vorausgesetzt.
• Der Pilotbenutzer erscheint als Live User und sein Benutzerobjekt zeigt die erwartete Main Group.
• Positive und negative Grenztests wurden mit neuen Verbindungen durchgeführt.
• Firewall-Regel, Benutzer, Rule ID und Logs passen zusammen.
• Vorheriger Zustand und Rollback sind dokumentiert.

Häufige Fragen