Konfigurera Access Time för användare på Sophos Firewall

En Access Time-policy begränsar internetåtkomsten för en användare, grupp eller gästanvändare till bestämda tider. Policyn kombinerar ett återkommande Schedule med Allow eller Deny. Den gäller dock bara för en identitet som brandväggen faktiskt har identifierat och som policyn har tilldelats direkt eller via identitetens huvudgrupp.

Snabbvägen för att tillåta internetåtkomst under kontorstid är:

1. Kontrollera brandväggens tid och tidszon under Administration > Time.
2. Skapa ett återkommande Schedule under Profiles > Schedule, till exempel Internet_OfficeHours.
3. Skapa policyn Employees_OfficeHours_Allow med Action: Allow under Profiles > Access time > Add.
4. Tilldela policyn till en liten pilotgrupp under Authentication > Groups.
5. Kontrollera användaren och källadressen under Current activities > Live users och den förväntade huvudgruppen under Authentication > Users.
6. Testa en ny internetanslutning både inom och utanför tidsfönstret.
7. Lägg inte till fler användare förrän både det positiva och negativa testet har lyckats.

⚠️ Enligt Sophos börjar ändringar i en Access Time-policy gälla omedelbart. En delad policy bör därför inte ändras spontant. Inventera först berörda användare och grupper, dokumentera ett pilotkonto och det tidigare läget och testa därefter tidsgränserna kontrollerat.

Vad Access Time faktiskt styr

Access Time avgör om en autentiserad användare får internetåtkomst vid en viss tidpunkt. Policyn skapar varken en firewallregel eller en Web Policy och autentiserar inte någon användare. Nätverkssökvägen, användaridentifieringen, regelmatchningen och skyddsfunktionerna måste därför redan fungera.

Fyra delar krävs för utvärderingen:

• ett återkommande Schedule med dagar och tider;
• en Access Time-policy med Allow eller Deny;
• en tilldelning till en användare, grupp eller gästanvändare;
• en identifierad identitet, till exempel via Captive Portal, STAS, SATC eller en annan lämplig autentiseringsmetod.

Välj Allow eller Deny medvetet

• Allow: internetåtkomst tillåts under det valda Schedule och blockeras utanför detta fönster. Modellen passar medarbetare, undervisningslokaler eller leverantörskonton med tydligt definierade användningstider.
• Deny: internetåtkomst blockeras under Schedule och tillåts utanför det. Modellen passar en specifik spärrperiod, till exempel en återkommande lektion eller viloperiod.

För en ny begränsad åtkomst är Allow vanligtvis enklare att förstå: det tillåtna fönstret syns direkt i objektet och kan testas positivt och negativt med en liten pilotgrupp. Deny är lämpligt när normalläget uttryckligen ska förbli öppet och endast ett exakt definierat spärrfönster behövs.

Schedule, kvot och inloggningstid är olika lager

Funktioner med liknande namn löser olika uppgifter:

• Ett Schedule innehåller bara dagar och tider. Det får effekt först genom en firewallregel, policy eller Access Time-policy. Sophos Firewall Schedules för regler och policyer beskriver hela konfigurationen.
• Surfing quota begränsar den mängd internettid som en användare kan förbruka. Det är en användningskvot, inte ett fast tidsfönster.
• Network traffic quota begränsar mängden överförd data.
• Ett gästkontos giltighet anger hur länge inloggningsuppgifterna finns. Den ersätter inte en återkommande Access Time.
• Clientless Users stöder inte en Access Time-policy. Om en fast enhet bara ska kommunicera under vissa tider används Schedule i en snävt avgränsad firewallregel. Konfigurera Sophos Firewall Clientless Users beskriver den IP-baserade identiteten.
• Schedule for device access i administratörsinställningarna begränsar WebAdmin-inloggningar. Vanlig Access time är inte avsedd för detta.

Surfing Quota och Network Traffic Quota på Sophos Firewall beskriver hur båda förbrukningskvoterna skapas och tilldelas, kontrolleras under View usage och återställs säkert.

Flera tidslager bör endast kombineras med ett dokumenterat syfte. En firewallregels Schedule kan stänga hela nätverkssökvägen, medan Access Time bara påverkar tilldelade användare. Om de två lagren använder olika tidsfönster måste varje gräns testas separat.

Planera exempel och förutsättningar

Följande exempel ger en medarbetargrupp internetåtkomst måndag till fredag mellan 07:30 och 18:00:

• Schedule: Internet_OfficeHours
• Access Time-policy: Employees_OfficeHours_Allow
• Action: Allow
• Grupp: Internet_OfficeHours
• Testanvändare: access-time-pilot
• Tidszon: Europe/Zurich
• Tidsfönster: måndag till fredag, 07:30 till 18:00

Namnen och tiderna är exempelvärden. I den egna miljön hämtas gruppnamn, ansvarig, tidszon och godkända drifttider från det verkliga åtkomstkravet. En grupp bör bara innehålla användare med samma tidsmodell.

Kontrollera följande förutsättningar före ändringen:

1. Current time och Time zone är korrekta under Administration > Time. Konfigurera systemtid och NTP på Sophos Firewall beskriver NTP-konfigurationen.
2. Pilotanvändaren kan autentisera sig med den avsedda metoden.
3. Användarnamn och källadress visas under Current activities > Live users och fältet Group är korrekt under Authentication > Users.
4. En lämplig användar- eller nätverksregel tillåter den avsedda internetvägen och loggar testtrafiken.
5. Tidigare Access Time-tilldelning, huvudgrupp och eventuella användarundantag är dokumenterade.

Om användaren inte kan identifieras som Live User måste autentiseringen korrigeras först. En Access Time-policy kan inte tillförlitligt styra en okänd identitet per användare eller grupp.

Skapa Schedule och Access Time-policy

Förbered ett återkommande Schedule

Access Time-policyer accepterar endast återkommande Schedules. Ett One-time-Schedule är inte tillgängligt här.

För exemplet:

1. Öppna Profiles > Schedule > Add.
2. Ange Internet_OfficeHours i Name.
3. Ställ in Recurrence type på Recurring.
4. Välj måndag till fredag.
5. Ange 07:30 som Start time och 18:00 som Stop time.
6. Dokumentera syfte, tidszon och ansvarig i Description.
7. Spara med Save.

Schedule i sig ändrar ännu ingen åtkomst. Det är ett återanvändbart tidsobjekt som även kan användas på andra platser. Kontrollera därför alltid alla användningar före en senare ändring.

Skapa Access Time-policyn

Därefter kopplas tidsobjektet till åtkomståtgärden:

1. Öppna Profiles > Access time.
2. Välj Add.
3. Ange Employees_OfficeHours_Allow i Name.
4. Ange till exempel Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT i Description.
5. Ställ in Action på Allow.
6. Välj Internet_OfficeHours under Schedule.
7. Spara med Save.

Inte heller denna policy får någon effekt förrän den har tilldelats en användare, grupp eller gästanvändare.

Tilldela policyn till en grupp eller användare

Använd en grupp som normal driftmodell

För användare med samma tidsmodell är en grupp tydligare än många enskilda tilldelningar:

1. Öppna Authentication > Groups.
2. Skapa pilotgruppen Internet_OfficeHours eller redigera en lämpligt avgränsad befintlig grupp.
3. Välj Employees_OfficeHours_Allow för Access time i policyavsnittet.
4. Ändra inte andra inställningar för kvoter, Traffic Shaping eller Remote Access av misstag.
5. Spara ändringarna.
6. Autentisera en testanvändare i gruppen och kontrollera den faktiska huvudgruppen.

Hantera användargrupper i Sophos Firewall säkert beskriver hur lokala och importerade grupper, huvudgruppen och användaråsidosättningar samverkar. Själva AD-importen finns kvar i Anslut Active Directory till Sophos Firewall.

Använd endast användarundantag medvetet

Under Authentication > Users kan en separat Access time väljas för en enskild användare. Detta användarvärde har företräde framför grupppolicyn.

Ett undantag är användbart för ett dokumenterat specialfall, men kan få gruppändringar att verka verkningslösa. Om en grupp är korrekt konfigurerad men en användare beter sig annorlunda kontrolleras därför användarobjektet först. För att återgå till grupppolicyn ska man inte välja en godtycklig ny individuell policy, utan kontrollerat återställa det tidigare ärvda läget.

I Active Directory räknas bara huvudgruppen

För AD-användare utvärderar Access Time inte Other group memberships. Den huvudgrupp som visas under Group i användarobjektet gäller, om inte en policy uttryckligen har valts för användaren.

Ordningen under Authentication > Groups > Reorder påverkar vilken importerad grupp som blir huvudgrupp. En ändring av denna ordning kan därför påverka både Access Time och andra funktioner. Den bör inte användas som en snabb lösning för en enskild användare. En medvetet planerad gruppordning eller ett dokumenterat användarundantag är säkrare.

Ändringar i AD-grupper, gruppordning och tillhörande policyer tillämpas vid användarens nästa inloggning. Skapa därför en ny autentiseringssession för ett rent test och kontrollera sedan huvudgruppen igen.

Styr gästanvändare via deras grupp

Gästanvändare i Sophos Firewall får en grupp under Authentication > Guest user settings och ärver dess policyer. Om gäster ska omfattas av ett återkommande tidsfönster för internetåtkomst tilldelas Access Time-policyn till denna tydligt avgränsade gästgrupp.

Gästkontots Validity period är fortfarande en ytterligare gräns: den avgör hur länge kontot är giltigt. Access Time avgör de återkommande tillåtna eller blockerade tiderna inom denna giltighet. Konfigurera och testa Sophos Firewall Captive Portal beskriver gästinloggningen och firewallregeln.

Testa tidsgränserna tillförlitligt

En sparad policy är ännu inget bevis på att lösningen fungerar. Acceptanstestet kontrollerar identitet, policy och verklig internetåtkomst tillsammans:

1. Dokumentera brandväggens tid, tidszon, Schedule och Action.
2. Autentisera pilotanvändaren på nytt.
3. Kontrollera användarnamn och källadress under Current activities > Live users och huvudgruppen under Authentication > Users.
4. Öppna en ny HTTP- eller HTTPS-anslutning till ett tillåtet testmål inom Allow-fönstret.
5. Kontrollera användare, grupp, källa, destination, Firewall Rule ID, åtgärd och tidsstämpel i Log Viewer.
6. Testa en ny anslutning till samma mål utanför fönstret och bekräfta den förväntade blockeringen.
7. Genomför samma test med omvänd förväntan för en Deny-policy.
8. Tilldela först därefter fler användare eller produktionsgruppen.

Firewallregeln måste fortfarande matcha användaren, nätverket och destinationen. Testa en Sophos Firewall-regel korrekt beskriver hur Rule ID, Log Viewer och Packet Capture bedöms tillsammans.

Sophos dokumenterar att ändringar i Access Time-policyer börjar gälla omedelbart. Det innebär dock ingen allmän garanti för att varje befintlig programsession kopplas ned exakt vid tidsgränsen. För säkerhetskritiska krav observeras därför en ny anslutning och en redan pågående session separat.

Avgränsa fel systematiskt

Användaren saknar internetåtkomst trots policyn

Kontrollera först om den aktuella tiden ligger inom Schedule för Allow eller utanför det för Deny. Kontrollera därefter användaridentiteten och källadressen under Current activities > Live users samt huvudgruppen under Authentication > Users. Om användaren saknas i Live users är nästa steg autentiseringen, inte en bredare Access Time-policy.

Kontrollera sedan firewallregeln, användarmatchningen, regelpositionen och Log Viewer. Access Time kan inte reparera en saknad nätverkssökväg eller en blockerande Web-, Application- eller TLS-policy.

Åtkomsten fungerar utanför Allow-fönstret

Kontrollera att det verkligen är den förväntade användaren som testas och om ett annat Access Time-värde har angetts i användarobjektet. Kontrollera även huvudgrupp och gruppordning för AD. Ett oautentiserat eller felaktigt tilldelat test motbevisar inte policyn.

Skapa därefter ett nytt testflöde. En befintlig session kan bete sig annorlunda än en ny anslutning. Om trafiken visas i Log Viewer utan den förväntade användaren måste användaridentifieringen lösas först.

En gruppändring påverkar inte en användare

En uttrycklig användarpolicy har företräde framför grupppolicyn. Kontrollera fältet Access time under Authentication > Users och, för AD, huvudgruppen. Access Time utvärderar inte Other group memberships.

Autentisera användaren på nytt efter ändringar i AD-grupper. Först därefter går det att bedöma aktuell gruppordning och policytilldelning.

Captive Portal visas oväntat

Sophos anger begränsad Access Time, felaktiga inloggningsuppgifter och förbrukade kvoter som möjliga orsaker till NTLM- eller Captive Portal-problem. Kontrollera Access Time, Surfing quota, Network traffic quota och inloggningsuppgifterna separat. Ändra inte förhastat policyn till Allow och bredda inte Schedule så länge den verkliga orsaken är oklar.

En ändring påverkar fler användare än väntat

En delad Access Time-policy påverkar omedelbart alla tilldelningar efter en ändring. Återställ först tidigare dokumenterade Action och Schedule. Inventera därefter berörda grupper och användarundantag och testa det nya kravet med en separat pilotpolicy.

Planera ändringar och rollback

Dokumentera före varje produktionsändring policynamn, Action, Schedule, berörda grupper, användarundantag, huvudgrupper, brandväggstid och testresultat. Då förblir återställningsvägen entydig.

En kontrollerad rollback genomförs så här:

1. Återställ den tidigare Access Time-tilldelningen för pilotanvändaren eller pilotgruppen.
2. Autentisera testanvändaren på nytt för AD.
3. Kontrollera användaren och källadressen under Current activities > Live users och huvudgruppen under Authentication > Users.
4. Testa en ny anslutning både inom och utanför det relevanta fönstret.
5. Kontrollera Log Viewer och den Firewall Rule ID som användes.
6. Ta inte bort den nya policyn och det nya Schedule förrän inga beroenden återstår.
7. Uppdatera ärendet, ansvarig och testresultatet.

I drift bör delade policyer ha en ansvarig och en begriplig Description. När arbetstider, helgdagsmodeller eller gruppstrukturer ändras ska tidsfönster och tilldelningar kontrolleras på nytt i stället för att policyn gradvis utökas utan dokumentation.

Checklista för drift

• Brandväggens tid och tidszon är korrekta.
• Schedule är återkommande och dokumenterat.
• Allow eller Deny motsvarar det avsedda normalläget.
• Access Time-policyn är tilldelad rätt grupp eller användare.
• Användarundantag har kontrollerats.
• Huvudgruppen är korrekt för AD; Other group memberships förutsätts inte.
• Pilotanvändaren visas som Live User och användarobjektet visar den förväntade huvudgruppen.
• Positiva och negativa gränstester har genomförts med nya anslutningar.
• Firewallregel, användare, Rule ID och loggar stämmer överens.
• Tidigare tillstånd och rollback är dokumenterade.

Vanliga frågor