Configurare Access Time per gli utenti su Sophos Firewall

Una policy Access Time limita l’accesso a internet di un utente, di un gruppo o degli utenti guest a orari definiti. La policy combina uno Schedule ricorrente con Allow o Deny. Si applica tuttavia solo a un’identità che il firewall ha effettivamente riconosciuto e alla quale la policy è assegnata direttamente o tramite il relativo gruppo principale.

La procedura rapida per consentire l’accesso a internet durante l’orario d’ufficio è la seguente:

1. In Administration > Time, controllare l’ora e il fuso orario del firewall.
2. In Profiles > Schedule, creare uno Schedule ricorrente, ad esempio Internet_OfficeHours.
3. In Profiles > Access time > Add, creare la policy Employees_OfficeHours_Allow con Action: Allow.
4. In Authentication > Groups, assegnare la policy a un piccolo gruppo pilota.
5. In Current activities > Live users, controllare l’utente e l’indirizzo di origine e, in Authentication > Users, il gruppo principale previsto.
6. Testare una nuova connessione internet sia all’interno sia all’esterno della finestra temporale.
7. Aggiungere altri utenti solo dopo il superamento del test positivo e di quello negativo.

⚠️ Secondo Sophos, le modifiche a una policy Access Time hanno effetto immediato. Una policy condivisa non va quindi modificata in modo estemporaneo. Occorre prima censire gli utenti e i gruppi interessati, documentare un account pilota e lo stato precedente, quindi testare i limiti temporali in modo controllato.

Cosa controlla realmente Access Time

Access Time decide se un utente autenticato ottiene l’accesso a internet in un determinato momento. La policy non crea una regola firewall o una Web Policy e non autentica alcun utente. Il percorso di rete, l’identificazione dell’utente, la corrispondenza della regola e le funzioni di protezione devono quindi essere già funzionanti.

Per la valutazione sono necessari quattro elementi:

• uno Schedule ricorrente con giorni e orari;
• una policy Access Time con Allow o Deny;
• un’assegnazione a un utente, un gruppo o un utente guest;
• un’identità riconosciuta, ad esempio tramite Captive Portal, STAS, SATC o un altro metodo di autenticazione appropriato.

Scegliere consapevolmente Allow o Deny

• Allow: l’accesso a internet è consentito durante lo Schedule selezionato e bloccato al di fuori di quella finestra. Questo modello è adatto a dipendenti, aule didattiche o account di fornitori con orari di utilizzo chiaramente definiti.
• Deny: l’accesso a internet è bloccato durante lo Schedule e consentito al di fuori. Questo modello è adatto a un periodo di blocco specifico, ad esempio una lezione ricorrente o una fascia di riposo.

Per un nuovo accesso limitato, Allow è in genere più facile da comprendere: la finestra consentita è visibile direttamente nell’oggetto e può essere sottoposta a test positivo e negativo con un piccolo gruppo pilota. Deny è indicato quando lo stato normale deve rimanere esplicitamente aperto e serve soltanto una finestra di blocco definita con precisione.

Schedule, quota e orario di accesso sono livelli diversi

Funzioni dai nomi simili risolvono compiti differenti:

• Uno Schedule contiene soltanto giorni e orari. Produce un effetto solo attraverso una regola firewall, una policy o una policy Access Time. Gli Schedule di Sophos Firewall per regole e policy ne spiegano la configurazione completa.
• Surfing quota limita il tempo di utilizzo di internet a disposizione di un utente. È un monte ore di consumo, non una finestra oraria fissa.
• Network traffic quota limita la quantità di dati trasferiti.
• La validità di un account guest determina per quanto tempo esistono le credenziali. Non sostituisce un’Access Time ricorrente.
• I Clientless Users non supportano una policy Access Time. Se un dispositivo fisso deve comunicare solo in determinati orari, lo Schedule viene applicato a una regola firewall con ambito ristretto. Configurare i Clientless Users su Sophos Firewall spiega l’identità basata su IP.
• Schedule for device access nelle impostazioni amministratore limita gli accessi a WebAdmin. La normale opzione Access time non è destinata a questo scopo.

Surfing Quota e Network Traffic Quota su Sophos Firewall spiega come creare e assegnare entrambi i crediti di consumo, controllarli in View usage e azzerarli in sicurezza.

Più livelli temporali vanno combinati solo con un’intenzione documentata. Lo Schedule di una regola firewall può chiudere l’intero percorso di rete, mentre Access Time riguarda soltanto gli utenti assegnati. Se i due livelli usano finestre temporali diverse, ogni limite deve essere testato separatamente.

Pianificare l’esempio e i prerequisiti

L’esempio seguente consente a un gruppo di dipendenti di accedere a internet dal lunedì al venerdì tra le 07:30 e le 18:00:

• Schedule: Internet_OfficeHours
• Policy Access Time: Employees_OfficeHours_Allow
• Action: Allow
• Gruppo: Internet_OfficeHours
• Utente di test: access-time-pilot
• Fuso orario: Europe/Zurich
• Finestra temporale: dal lunedì al venerdì, dalle 07:30 alle 18:00

I nomi e gli orari sono valori di esempio. Nell’ambiente reale, il nome del gruppo, il responsabile, il fuso orario e gli orari operativi autorizzati derivano dall’effettiva richiesta di accesso. Un gruppo dovrebbe contenere soltanto utenti con lo stesso modello temporale.

Prima della modifica vanno verificati questi prerequisiti:

1. In Administration > Time, Current time e Time zone sono corretti. Configurare l’ora di sistema e NTP su Sophos Firewall spiega la configurazione NTP.
2. L’utente pilota riesce ad autenticarsi con il metodo previsto.
3. In Current activities > Live users vengono visualizzati il nome utente e l’indirizzo di origine; in Authentication > Users, il campo Group è corretto.
4. Una regola utente o di rete adatta consente il percorso internet previsto e registra il traffico di test.
5. L’assegnazione Access Time precedente, il gruppo principale e le eventuali eccezioni utente sono documentati.

Se l’utente non è identificabile come Live User, occorre correggere prima l’autenticazione. Una policy Access Time non può controllare in modo affidabile per utente o gruppo un’identità sconosciuta.

Creare lo Schedule e la policy Access Time

Preparare uno Schedule ricorrente

Le policy Access Time accettano esclusivamente Schedule ricorrenti. Uno Schedule One-time non è disponibile in questo caso.

Per l’esempio:

1. Aprire Profiles > Schedule > Add.
2. Impostare Name su Internet_OfficeHours.
3. Impostare Recurrence type su Recurring.
4. Selezionare i giorni da lunedì a venerdì.
5. Impostare Start time su 07:30 e Stop time su 18:00.
6. Documentare in Description lo scopo, il fuso orario e il responsabile.
7. Salvare con Save.

Lo Schedule da solo non modifica ancora alcun accesso. È un oggetto temporale riutilizzabile che può essere impiegato anche altrove. Prima di una modifica successiva occorre quindi controllarne sempre tutti gli utilizzi.

Creare la policy Access Time

Successivamente si collega l’oggetto temporale all’azione di accesso:

1. Aprire Profiles > Access time.
2. Selezionare Add.
3. Impostare Name su Employees_OfficeHours_Allow.
4. In Description, inserire ad esempio Internet Mon-Fri 07:30-18:00 Europe/Zurich, Owner IT.
5. Impostare Action su Allow.
6. In Schedule, selezionare Internet_OfficeHours.
7. Salvare con Save.

Anche questa policy non ha effetto finché non viene assegnata a un utente, a un gruppo o a un utente guest.

Assegnare la policy a un gruppo o a un utente

Utilizzare un gruppo come modello operativo normale

Per gli utenti con lo stesso modello temporale, un gruppo è più chiaro di molte assegnazioni individuali:

1. Aprire Authentication > Groups.
2. Creare il gruppo pilota Internet_OfficeHours oppure modificare un gruppo esistente con un ambito adeguato.
3. Nella sezione delle policy, selezionare Employees_OfficeHours_Allow per Access time.
4. Non modificare incidentalmente altre impostazioni relative a quote, Traffic Shaping o Remote Access.
5. Salvare le modifiche.
6. Autenticare un singolo utente di test appartenente a questo gruppo e controllare il gruppo principale effettivo.

Gestire in sicurezza i gruppi utenti di Sophos Firewall spiega come interagiscono gruppi locali e importati, gruppo principale e override degli utenti. L’importazione AD vera e propria resta descritta in Collegare Active Directory a Sophos Firewall.

Utilizzare un’eccezione utente solo consapevolmente

In Authentication > Users è possibile selezionare un’Access time specifica per un singolo utente. Questo valore utente ha la precedenza sulla policy del gruppo.

Un’eccezione è utile per un caso documentato, ma può far sembrare inefficaci le modifiche al gruppo. Se un gruppo è configurato correttamente ma un singolo utente si comporta diversamente, occorre quindi controllare prima l’oggetto di quell’utente. Per tornare alla policy del gruppo non va selezionata una nuova policy individuale qualsiasi; lo stato di ereditarietà precedente va ripristinato in modo controllato.

Con Active Directory conta solo il gruppo principale

Per gli utenti AD, Access Time non valuta le Other group memberships. Si applica il gruppo principale visualizzato in Group nell’oggetto utente, a meno che non sia stata selezionata esplicitamente una policy per l’utente.

L’ordine in Authentication > Groups > Reorder influisce su quale gruppo importato diventa il gruppo principale. La modifica di questo ordine può quindi influire non solo su Access Time, ma anche su altre funzioni. Non va usata come soluzione rapida per un singolo utente. È preferibile un ordine dei gruppi pianificato consapevolmente o un’eccezione utente documentata.

Le modifiche ai gruppi AD, al loro ordine e alle policy associate vengono applicate al successivo accesso dell’utente. Per un test pulito, occorre quindi generare una nuova sessione di autenticazione e poi ricontrollare il gruppo principale.

Controllare gli utenti guest tramite il relativo gruppo

Gli utenti guest su Sophos Firewall ricevono un gruppo in Authentication > Guest user settings e ne ereditano le policy. Per applicare agli ospiti una finestra ricorrente di accesso a internet, la policy Access Time viene assegnata a questo gruppo guest chiaramente delimitato.

Il Validity period dell’account guest rimane un limite aggiuntivo: determina per quanto tempo l’account è valido. Access Time determina, all’interno di tale validità, gli orari ricorrenti consentiti o bloccati. Configurare e testare Captive Portal su Sophos Firewall spiega l’accesso guest e la regola firewall.

Testare in modo affidabile i limiti temporali

Una policy salvata non è ancora una prova di successo. Il collaudo verifica insieme identità, policy e accesso internet reale:

1. Documentare l’ora del firewall, il fuso orario, lo Schedule e l’Action.
2. Autenticare nuovamente l’utente pilota.
3. In Current activities > Live users, controllare il nome utente e l’indirizzo di origine; in Authentication > Users, controllare il gruppo principale.
4. All’interno della finestra Allow, aprire una nuova connessione HTTP o HTTPS verso una destinazione di test consentita.
5. In Log Viewer, controllare utente, gruppo, origine, destinazione, Firewall Rule ID, azione e timestamp.
6. Al di fuori della finestra, testare una nuova connessione alla stessa destinazione e confermare il blocco previsto.
7. Per una policy Deny, eseguire lo stesso test con l’aspettativa opposta.
8. Solo a quel punto assegnare altri utenti o il gruppo di produzione.

La regola firewall deve continuare a corrispondere all’utente, alla rete e alla destinazione. Testare correttamente una regola Sophos Firewall spiega come valutare insieme Rule ID, Log Viewer e Packet Capture.

Sophos documenta che le modifiche alle policy Access Time hanno effetto immediato. Ciò non equivale tuttavia a una garanzia generale che ogni sessione applicativa esistente venga interrotta esattamente al limite temporale. Per requisiti critici di sicurezza, una nuova connessione e una sessione già in corso vanno quindi osservate separatamente.

Circoscrivere sistematicamente gli errori

L’utente non ha accesso a internet nonostante la policy

Controllare innanzitutto se l’ora corrente si trova all’interno dello Schedule per Allow o all’esterno per Deny. Controllare quindi l’identità dell’utente e l’indirizzo di origine in Current activities > Live users, nonché il gruppo principale in Authentication > Users. Se l’utente non compare in Live users, il passo successivo riguarda l’autenticazione, non l’ampliamento della policy Access Time.

Successivamente controllare la regola firewall, la corrispondenza dell’utente, la posizione della regola e Log Viewer. Access Time non può correggere un percorso di rete mancante o una policy Web, Application o TLS che blocca il traffico.

L’accesso funziona al di fuori della finestra Allow

Controllare che venga effettivamente testato l’utente previsto e che nell’oggetto utente non sia configurata un’Access Time diversa. Per AD, controllare anche il gruppo principale e l’ordine dei gruppi. Un test non autenticato o assegnato in modo errato non dimostra un malfunzionamento della policy.

Generare quindi un nuovo flusso di test. Una sessione esistente può comportarsi diversamente da una nuova connessione. Se il traffico compare in Log Viewer senza l’utente previsto, va chiarita prima l’identificazione dell’utente.

Una modifica al gruppo non ha effetto su un utente

Una policy utente esplicita ha la precedenza sulla policy del gruppo. In Authentication > Users, controllare il campo Access time e, per AD, il gruppo principale. Access Time non valuta le Other group memberships.

Dopo aver modificato i gruppi AD, autenticare nuovamente l’utente. Solo allora è possibile valutare l’ordine attuale dei gruppi e l’assegnazione della policy.

Captive Portal compare inaspettatamente

Sophos indica un’Access Time limitata, credenziali errate e quote esaurite come possibili cause di problemi NTLM o Captive Portal. Controllare separatamente Access Time, Surfing quota, Network traffic quota e le credenziali. Non impostare frettolosamente la policy su Allow né ampliare lo Schedule finché la causa effettiva non è chiara.

Una modifica interessa più utenti del previsto

Una policy Access Time condivisa ha effetto immediato su tutte le sue assegnazioni dopo una modifica. Ripristinare innanzitutto l’Action e lo Schedule documentati in precedenza. Successivamente censire i gruppi e le eccezioni utente interessati e testare il nuovo requisito con una policy pilota separata.

Pianificare le modifiche e il rollback

Prima di ogni modifica in produzione, documentare nome della policy, Action, Schedule, gruppi interessati, eccezioni utente, gruppi principali, ora del firewall e risultato del test. In questo modo il percorso di rollback rimane inequivocabile.

Un rollback controllato prevede:

1. Ripristinare l’assegnazione Access Time precedente per l’utente o il gruppo pilota.
2. Per AD, autenticare nuovamente l’utente di test.
3. In Current activities > Live users, controllare l’utente e l’indirizzo di origine e, in Authentication > Users, il gruppo principale.
4. Testare una nuova connessione sia all’interno sia all’esterno della finestra pertinente.
5. Controllare Log Viewer e il Firewall Rule ID utilizzato.
6. Rimuovere la nuova policy e il nuovo Schedule solo quando non esiste più alcuna dipendenza.
7. Aggiornare il ticket, il responsabile e il risultato del test.

Durante l’esercizio, le policy condivise dovrebbero avere un responsabile e una Description comprensibile. Quando cambiano gli orari di lavoro, i modelli di festività o le strutture dei gruppi, le finestre temporali e le assegnazioni vanno nuovamente controllate anziché ampliare silenziosamente la policy sempre di più.

Checklist operativa

• L’ora e il fuso orario del firewall sono corretti.
• Lo Schedule è ricorrente e documentato.
• Allow o Deny corrisponde allo stato normale desiderato.
• La policy Access Time è assegnata al gruppo o all’utente corretto.
• Le eccezioni utente sono state controllate.
• Per AD, il gruppo principale è corretto; le Other group memberships non vengono date per scontate.
• L’utente pilota compare come Live User e il relativo oggetto utente mostra il gruppo principale previsto.
• I test positivo e negativo ai limiti sono stati eseguiti con nuove connessioni.
• La regola firewall, l’utente, la Rule ID e i log sono coerenti.
• Lo stato precedente e il rollback sono documentati.

Domande frequenti