Access Time voor gebruikers instellen op Sophos Firewall

Met een Access Time-policy wordt de internettoegang van een gebruiker, groep of gastgebruiker beperkt tot vastgelegde tijden. De policy combineert een terugkerend Schedule met Allow of Deny. De policy werkt echter alleen voor een identiteit die de firewall daadwerkelijk heeft herkend en waaraan de policy rechtstreeks of via de hoofdgroep is toegewezen.

De korte route om internettoegang tijdens kantooruren toe te staan is:

1. Onder Administration > Time de firewalltijd en tijdzone controleren.
2. Onder Profiles > Schedule een terugkerend Schedule maken, bijvoorbeeld Internet_OfficeHours.
3. Onder Profiles > Access time > Add de policy Employees_OfficeHours_Allow met Action: Allow maken.
4. Onder Authentication > Groups de policy aan een kleine pilotgroep toewijzen.
5. Onder Current activities > Live users de gebruiker en het bronadres controleren en onder Authentication > Users de verwachte hoofdgroep controleren.
6. Zowel binnen als buiten het tijdvenster een nieuwe internetverbinding testen.
7. Pas na een geslaagde positieve en negatieve test meer gebruikers toevoegen.

⚠️ Volgens Sophos worden wijzigingen in een Access Time-policy onmiddellijk van kracht. Een gedeelde policy mag daarom niet impulsief worden aangepast. Breng eerst de betrokken gebruikers en groepen in kaart, documenteer een pilotaccount en de vorige toestand en test daarna de tijdgrenzen gecontroleerd.

Wat Access Time werkelijk regelt

Access Time bepaalt of een geauthenticeerde gebruiker op een bepaald tijdstip internettoegang krijgt. De policy maakt geen firewallregel of Web Policy en authenticeert geen gebruiker. Het netwerkpad, de gebruikersherkenning, de rule match en de beveiligingsfuncties moeten daarom al werken.

Voor de beoordeling zijn vier elementen nodig:

• een terugkerend Schedule met dagen en tijden;
• een Access Time-policy met Allow of Deny;
• een toewijzing aan een gebruiker, groep of gastgebruiker;
• een herkende identiteit, bijvoorbeeld via Captive Portal, STAS, SATC of een andere geschikte authenticatiemethode.

Allow of Deny bewust kiezen

• Allow: internettoegang is tijdens het geselecteerde Schedule toegestaan en buiten dat venster geblokkeerd. Dit model past bij medewerkers, leslokalen of accounts van dienstverleners met duidelijk vastgelegde gebruikstijden.
• Deny: internettoegang is tijdens het Schedule geblokkeerd en daarbuiten toegestaan. Dit model past bij een gerichte blokkeerperiode, bijvoorbeeld een terugkerende les- of rustperiode.

Voor nieuwe beperkte toegang is Allow meestal eenvoudiger te begrijpen: het toegestane venster is direct in het object zichtbaar en kan met een kleine pilotgroep positief en negatief worden getest. Deny is zinvol wanneer de normale toestand uitdrukkelijk open moet blijven en alleen een precies vastgelegd blokkeervenster nodig is.

Schedule, quota en aanmeldtijd zijn verschillende lagen

Functies met vergelijkbare namen lossen verschillende taken op:

• Een Schedule bevat alleen dagen en tijden. Het krijgt pas effect via een firewallregel, policy of Access Time-policy. Sophos Firewall Schedules voor regels en policies legt de volledige configuratie uit.
• Surfing quota beperkt de hoeveelheid internettijd die een gebruiker kan verbruiken. Het is een gebruiksbudget, geen vast tijdvenster.
• Network traffic quota beperkt de hoeveelheid overgedragen gegevens.
• De geldigheid van een gastaccount bepaalt hoelang de aanmeldgegevens bestaan. Dit vervangt geen terugkerende Access Time.
• Clientless Users ondersteunen geen Access Time-policy. Als een vast apparaat alleen op bepaalde tijden mag communiceren, wordt het Schedule in een nauw begrensde firewallregel gebruikt. Sophos Firewall Clientless Users instellen legt de IP-gebaseerde identiteit uit.
• Schedule for device access in de beheerdersinstellingen beperkt WebAdmin-aanmeldingen. De gewone Access time is daarvoor niet bedoeld.

Surfing Quota en Network Traffic Quota op Sophos Firewall legt uit hoe beide verbruikstegoeden worden gemaakt en toegewezen, onder View usage worden gecontroleerd en veilig worden gereset.

Meerdere tijdslagen mogen alleen met een gedocumenteerde reden worden gecombineerd. Het Schedule van een firewallregel kan het volledige netwerkpad sluiten, terwijl Access Time alleen de toegewezen gebruikers treft. Als beide lagen verschillende tijdvensters gebruiken, moet elke grens afzonderlijk worden getest.

Voorbeeld en vereisten plannen

In het volgende voorbeeld krijgt een medewerkersgroep van maandag tot en met vrijdag tussen 07:30 en 18:00 internettoegang:

• Schedule: Internet_OfficeHours
• Access Time-policy: Employees_OfficeHours_Allow
• Action: Allow
• Groep: Internet_OfficeHours
• Testgebruiker: access-time-pilot
• Tijdzone: Europe/Zurich
• Tijdvenster: maandag tot en met vrijdag, 07:30 tot 18:00

De namen en tijden zijn voorbeeldwaarden. In de eigen omgeving worden de groepsnaam, eigenaar, tijdzone en toegestane bedrijfstijden uit de werkelijke toegangsbehoefte overgenomen. Een groep mag alleen gebruikers met hetzelfde tijdmodel bevatten.

Controleer vóór de wijziging de volgende vereisten:

1. Onder Administration > Time zijn Current time en Time zone correct. Sophos Firewall systeemtijd en NTP configureren legt de NTP-configuratie uit.
2. De pilotgebruiker kan zich met de geplande methode authenticeren.
3. Onder Current activities > Live users worden de gebruikersnaam en het bronadres weergegeven; onder Authentication > Users is het veld Group correct.
4. Een passende gebruikers- of netwerkregel staat het geplande internetpad toe en registreert het testverkeer.
5. De vorige Access Time-toewijzing, de hoofdgroep en eventuele gebruikersuitzonderingen zijn gedocumenteerd.

Als de gebruiker niet als Live User herkenbaar is, moet eerst de authenticatie worden gecorrigeerd. Een Access Time-policy kan een onbekende identiteit niet betrouwbaar per gebruiker of groep regelen.

Schedule en Access Time-policy maken

Een terugkerend Schedule voorbereiden

Access Time-policies accepteren uitsluitend terugkerende Schedules. Een One-time-Schedule is hier niet beschikbaar.

Voor het voorbeeld:

1. Profiles > Schedule > Add openen.
2. Name instellen op Internet_OfficeHours.
3. Recurrence type instellen op Recurring.
4. Maandag tot en met vrijdag selecteren.
5. Start time instellen op 07:30 en Stop time op 18:00.
6. In Description het doel, de tijdzone en de eigenaar documenteren.
7. Opslaan met Save.

Het Schedule alleen wijzigt nog geen toegang. Het is een herbruikbaar tijdobject dat ook op andere plaatsen kan worden gebruikt. Controleer daarom vóór een latere wijziging altijd alle toepassingen.

De Access Time-policy maken

Vervolgens wordt het tijdobject aan de toegangsactie gekoppeld:

1. Profiles > Access time openen.
2. Add selecteren.
3. Name instellen op Employees_OfficeHours_Allow.
4. In Description bijvoorbeeld Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT invoeren.
5. Action instellen op Allow.
6. Onder Schedule Internet_OfficeHours selecteren.
7. Opslaan met Save.

Ook deze policy heeft geen effect zolang deze niet aan een gebruiker, groep of gastgebruiker is toegewezen.

De policy aan een groep of gebruiker toewijzen

Een groep als normaal bedrijfsmodel gebruiken

Voor gebruikers met hetzelfde tijdmodel is een groep overzichtelijker dan veel afzonderlijke toewijzingen:

1. Authentication > Groups openen.
2. De pilotgroep Internet_OfficeHours maken of een passend begrensde bestaande groep bewerken.
3. In het policygedeelte bij Access time Employees_OfficeHours_Allow selecteren.
4. Andere instellingen voor quota, Traffic Shaping en Remote Access niet terloops wijzigen.
5. De wijzigingen opslaan.
6. Eén testgebruiker in deze groep authenticeren en de werkelijke hoofdgroep controleren.

Sophos Firewall-gebruikersgroepen veilig beheren legt uit hoe lokale en geïmporteerde groepen, de hoofdgroep en gebruikersoverrides samenwerken. De eigenlijke AD-import blijft beschreven in Active Directory met Sophos Firewall verbinden.

Een gebruikersuitzondering alleen bewust gebruiken

Onder Authentication > Users kan voor één gebruiker een afzonderlijke Access time worden geselecteerd. Deze gebruikerswaarde heeft voorrang op de groepspolicy.

Een uitzondering is nuttig voor een gedocumenteerd geval, maar kan groepswijzigingen schijnbaar zonder effect laten. Als een groep correct is geconfigureerd maar één gebruiker zich anders gedraagt, moet daarom eerst het gebruikersobject worden gecontroleerd. Om terug te keren naar de groepspolicy, mag niet zomaar een nieuwe individuele policy worden gekozen; de eerdere overervingsstatus wordt gecontroleerd hersteld.

Bij Active Directory telt alleen de hoofdgroep

Voor AD-gebruikers beoordeelt Access Time geen Other group memberships. De hoofdgroep die in het gebruikersobject onder Group staat, is van toepassing, tenzij expliciet een policy voor de gebruiker is geselecteerd.

De volgorde onder Authentication > Groups > Reorder bepaalt welke geïmporteerde groep de hoofdgroep wordt. Een wijziging van deze volgorde kan daarom niet alleen Access Time, maar ook andere functies beïnvloeden. Gebruik dit niet als snelle oplossing voor één gebruiker. Een bewust geplande groepsvolgorde of een gedocumenteerde gebruikersuitzondering is veiliger.

Wijzigingen in AD-groepen, de groepsvolgorde en de bijbehorende policies worden bij de volgende aanmelding van de gebruiker toegepast. Maak voor een zuivere test daarom een nieuwe authenticatiesessie en controleer daarna de hoofdgroep opnieuw.

Gastgebruikers via hun groep regelen

Gastgebruikers op Sophos Firewall krijgen onder Authentication > Guest user settings een groep en nemen de policies daarvan over. Als gasten een terugkerend tijdvenster voor internettoegang moeten krijgen, wordt de Access Time-policy aan deze duidelijk begrensde gastgroep toegewezen.

De Validity period van een gastaccount blijft een extra grens: deze bepaalt hoelang het account geldig is. Access Time bepaalt binnen deze geldigheid de terugkerende toegestane of geblokkeerde tijden. Sophos Firewall Captive Portal instellen en testen legt de gastaanmelding en de firewallregel uit.

Tijdgrenzen betrouwbaar testen

Een opgeslagen policy is nog geen bewijs van succes. De acceptatietest controleert identiteit, policy en werkelijke internettoegang samen:

1. Firewalltijd, tijdzone, Schedule en Action documenteren.
2. De pilotgebruiker opnieuw authenticeren.
3. Onder Current activities > Live users de gebruikersnaam en het bronadres controleren; onder Authentication > Users de hoofdgroep controleren.
4. Binnen het Allow-venster een nieuwe HTTP- of HTTPS-verbinding naar een toegestane testbestemming openen.
5. In Log Viewer de gebruiker, groep, bron, bestemming, Firewall Rule ID, actie en tijdstempel controleren.
6. Buiten het venster een nieuwe verbinding naar dezelfde bestemming testen en de verwachte blokkering bevestigen.
7. Voor een Deny-policy dezelfde test met de omgekeerde verwachting uitvoeren.
8. Pas daarna meer gebruikers of de productiegroep toewijzen.

De firewallregel moet nog steeds bij de gebruiker, het netwerk en de bestemming passen. Een Sophos Firewall-regel correct testen legt uit hoe Rule ID, Log Viewer en Packet Capture samen worden beoordeeld.

Sophos documenteert dat wijzigingen in Access Time-policies onmiddellijk van kracht worden. Daaruit volgt echter geen algemene toezegging dat elke bestaande applicatiesessie precies op de tijdgrens onmiddellijk wordt verbroken. Voor beveiligingskritieke eisen worden daarom een nieuwe verbinding en een al lopende sessie afzonderlijk geobserveerd.

Fouten systematisch afbakenen

Gebruiker heeft ondanks de policy geen internettoegang

Controleer eerst of de huidige tijd bij Allow binnen of bij Deny buiten het Schedule valt. Controleer daarna de gebruikersidentiteit en het bronadres onder Current activities > Live users en de hoofdgroep onder Authentication > Users. Ontbreekt de gebruiker in Live users, dan ligt de volgende stap bij de authenticatie en niet bij een ruimere Access Time-policy.

Controleer vervolgens de firewallregel, de gebruikersmatch, de regelpositie en Log Viewer. Access Time kan een ontbrekend netwerkpad of een blokkerende Web-, Application- of TLS-policy niet herstellen.

Toegang werkt buiten het Allow-venster

Controleer of werkelijk de verwachte gebruiker wordt getest en of in het gebruikersobject een andere Access Time is ingesteld. Controleer bij AD ook de hoofdgroep en de groepsvolgorde. Een niet-geauthenticeerde of verkeerd toegewezen test bewijst niet dat de policy niet werkt.

Maak daarna een nieuwe testflow. Een bestaande sessie kan zich anders gedragen dan een nieuwe verbinding. Als het verkeer in Log Viewer zonder de verwachte gebruiker verschijnt, moet eerst de gebruikersherkenning worden opgelost.

Een groepswijziging werkt niet voor één gebruiker

Een expliciete gebruikerspolicy heeft voorrang op de groepspolicy. Controleer onder Authentication > Users het veld Access time en bij AD de hoofdgroep. Access Time beoordeelt geen Other group memberships.

Authenticeer de gebruiker opnieuw na een wijziging in AD-groepen. Pas daarna kunnen de actuele groepsvolgorde en policytoewijzing worden beoordeeld.

Captive Portal verschijnt onverwacht

Sophos noemt een beperkte Access Time, onjuiste aanmeldgegevens en verbruikte quota als mogelijke oorzaken van NTLM- of Captive Portal-problemen. Controleer Access Time, Surfing quota, Network traffic quota en de aanmeldgegevens afzonderlijk. Zet de policy niet overhaast op Allow en maak het Schedule niet ruimer zolang de werkelijke oorzaak onduidelijk is.

Een wijziging raakt meer gebruikers dan verwacht

Een gedeelde Access Time-policy werkt na een wijziging onmiddellijk voor alle toewijzingen. Herstel eerst de eerder gedocumenteerde Action en het Schedule. Breng daarna de betrokken groepen en gebruikersuitzonderingen in kaart en test de nieuwe eis met een afzonderlijke pilotpolicy.

Wijzigingen en rollback plannen

Documenteer vóór elke productiewijziging de policynaam, Action, het Schedule, de betrokken groepen, gebruikersuitzonderingen, hoofdgroepen, firewalltijd en het testresultaat. Zo blijft de weg terug eenduidig.

Een gecontroleerde rollback verloopt als volgt:

1. De vorige Access Time-toewijzing voor de pilotgebruiker of pilotgroep herstellen.
2. Bij AD de testgebruiker opnieuw authenticeren.
3. Onder Current activities > Live users de gebruiker en het bronadres controleren en onder Authentication > Users de hoofdgroep controleren.
4. Zowel binnen als buiten het relevante venster een nieuwe verbinding testen.
5. Log Viewer en de gebruikte Firewall Rule ID controleren.
6. De nieuwe policy en het nieuwe Schedule pas verwijderen wanneer er geen afhankelijkheden meer zijn.
7. Ticket, eigenaar en testresultaat bijwerken.

In de dagelijkse werking moeten gedeelde policies een eigenaar en een begrijpelijke Description hebben. Wanneer werktijden, feestdagmodellen of groepsstructuren wijzigen, moeten tijdvensters en toewijzingen opnieuw worden gecontroleerd in plaats van de policy ongemerkt steeds verder te verruimen.

Operationele checklist

• Firewalltijd en tijdzone zijn correct.
• Het Schedule is terugkerend en gedocumenteerd.
• Allow of Deny komt overeen met de gewenste normale toestand.
• De Access Time-policy is aan de juiste groep of gebruiker toegewezen.
• Gebruikersuitzonderingen zijn gecontroleerd.
• Bij AD is de hoofdgroep correct; Other group memberships worden niet verondersteld.
• De pilotgebruiker verschijnt als Live User en het gebruikersobject toont de verwachte hoofdgroep.
• Positieve en negatieve grenstests zijn met nieuwe verbindingen uitgevoerd.
• Firewallregel, gebruiker, Rule ID en logs komen overeen.
• De vorige toestand en rollback zijn gedocumenteerd.

Veelgestelde vragen