Gestire correttamente i gruppi utenti e il gruppo principale su Sophos Firewall

I gruppi utenti su Sophos Firewall riuniscono policy comuni per gli utenti autenticati. Consentono di uniformare Access Time, quote, Traffic Shaping, Remote Access e Sign-in Restrictions. Un gruppo, tuttavia, non concede automaticamente l’accesso: contano anche l’identità rilevata, il gruppo principale effettivo, la specifica policy firewall o VPN e il relativo ordine.

La procedura rapida e sicura è la seguente:

1. Stabilire da quale origine provengono gli utenti e quale compito deve svolgere il gruppo.
2. Utilizzare un gruppo di tipo Normal per gli utenti normali; pianificare separatamente come Clientless le identità dei dispositivi basate sull’IP.
3. Creare o importare un piccolo gruppo pilota con una funzione chiara e il minor numero possibile di policy condivise.
4. In Authentication > Services, controllare il Default Group previsto oppure il gruppo di fallback sul server Entra.
5. Per Active Directory, documentare l’ordine in Authentication > Groups > Reorder e definire il gruppo principale previsto.
6. Evitare gli override per singolo utente oppure documentarli esplicitamente, perché prevalgono sulle policy di gruppo.
7. Generare un nuovo accesso e controllare Group e Other group memberships in Authentication > Users.
8. Provare la funzione interessata con un utente positivo e uno negativo; per il traffico, verificare anche la Firewall Rule ID prevista.
9. Aggiungere altri utenti solo dopo il buon esito del pilota, quindi riesaminare regolarmente l’ordine dei gruppi, il Default Group e le eccezioni.

⚠️ Reorder non è una funzione di ordinamento innocua. Per gli utenti AD, lo spostamento di un gruppo può cambiare il gruppo principale e quindi MFA, quote, Access Time, Remote Access e altre policy per molti utenti. Prima documentare l’ordine esistente, le policy di gruppo, gli utenti pilota e il percorso di ripristino.

Comprendere il modello dei gruppi in pochi minuti

Sul firewall, un gruppo è un contenitore comune di policy. Può assegnare le stesse impostazioni a più utenti, evitando di gestire ogni account singolarmente. Non sostituisce né l’autenticazione né una regola firewall. Un utente può comparire nel gruppo corretto e non ottenere comunque l’accesso se mancano la regola, la policy VPN, la zona, la route o il percorso di ritorno previsti.

Per la gestione sono utili quattro domande separate:

1. Da dove proviene l’identità? Localmente, da Active Directory, LDAP, RADIUS, Microsoft Entra ID o da un’associazione Clientless basata su IP.
2. Quale gruppo è effettivo? Con AD può trattarsi del gruppo principale oppure, per le funzioni supportate, di un’altra appartenenza a un gruppo.
3. Quale policy di gruppo si applica? Access Time, Quota, Remote Access e altri campi seguono regole di valutazione diverse.
4. Quale regola consente il traffico? Le sole policy di gruppo non aprono un percorso di rete.

Non confondere i gruppi Normal, importati e Clientless

Un gruppo locale di tipo Normal è adatto agli utenti che si autenticano tramite un servizio supportato. Un utente locale riceve il proprio gruppo nell’oggetto utente. Con un’origine utenti esterna, i record utente locali vengono generalmente creati solo dopo il primo accesso riuscito.

Gli account guest temporanei vengono generati tramite Guest user settings ed ereditano un gruppo restrittivo scelto consapevolmente. Creare e gestire in sicurezza gli utenti guest su Sophos Firewall illustra creazione, validità, verifica del Captive Portal e offboarding.

I gruppi AD vengono acquisiti tramite la procedura guidata di importazione. Le appartenenze vengono gestite nella directory e valutate all’accesso. La procedura completa per server, LDAPS e importazione è descritta in Collegare Active Directory a Sophos Firewall. Per LDAP generico occorre pianificare separatamente la base di ricerca, memberOf o un altro attributo di gruppo e il Default Group locale; Collegare un server LDAP a Sophos Firewall spiega questi campi.

Un gruppo di tipo Clientless risolve un compito diverso. Associa un’identità a un indirizzo IP fisso senza che una persona effettui l’accesso. È pensato per stampanti o altri sistemi chiaramente attribuibili e non sostituisce l’autenticazione degli utenti. Configurare i Clientless Users su Sophos Firewall descrive il test sicuro di IP, regola ed esito negativo.

Scegliere consapevolmente il Default Group e il gruppo di fallback

In Authentication > Services > Firewall authentication methods, Default group stabilisce quale gruppo riceve un utente esterno quando non esiste un gruppo locale corrispondente. Un Default Group troppo ampio o cresciuto nel tempo può quindi assegnare policy inattese. È più sicuro usare un gruppo di fallback volutamente restrittivo, il cui effetto sia stato verificato con test positivi e negativi.

Microsoft Entra ID SSO utilizza un proprio Fallback user group nella configurazione del server Entra. Questa impostazione si applica anche quando il server viene usato in Firewall authentication methods. Il Default Group generale e il gruppo di fallback Entra non devono quindi essere considerati la stessa impostazione.

Pianificare l’esempio e i prerequisiti

L’esempio seguente separa tre finalità:

• Local_Contractors: gruppo pilota locale per pochi collaboratori esterni;
• SFOS_Internet_Standard: gruppo AD importato per il normale accesso a Internet;
• SFOS_SSLVPN: gruppo AD importato per una policy SSL VPN;
• auth-pilot@example.com: account di prova creato intenzionalmente;
• LAN-Users-to-WAN: regola firewall con logging per il test Internet.

example.com è un dominio riservato alla documentazione. I nomi dei gruppi, l’utente e il nome della regola vanno sostituiti con la convenzione di denominazione dell’ambiente. Un buon nome di gruppo descrive la funzione e non soltanto un reparto. Ad esempio, SFOS_SSLVPN resta comprensibile anche se la struttura organizzativa cambia in seguito.

Prima della prima modifica, annotare:

• l’ordine corrente in Authentication > Groups;
• il Default Group e, per Entra ID, il gruppo di fallback;
• le policy di gruppo e gli override specifici degli utenti;
• i servizi di autenticazione e le policy Remote Access interessati;
• un accesso amministrativo verificato e un percorso di gestione indipendente;
• un utente pilota con il comportamento positivo e negativo previsto.

Creare un gruppo utenti locale

Creare la base comune in Authentication > Groups > Add:

1. Inserire Local_Contractors in Name.
2. Selezionare Normal in Group type.
3. Impostare Surfing quota, Access time, Network traffic e Traffic shaping solo se il gruppo necessita realmente di queste funzioni in comune.
4. Attivare campi Remote Access come SSL VPN policy o IPsec remote access soltanto per l’accesso pianificato.
5. Limitare Sign-in restriction agli indirizzi di origine realmente necessari o all’intervallo previsto, se il modello di autenticazione lo consente.
6. Attivare Quarantine digest e MAC binding solo consapevolmente.
7. Salvare con Save.

I nomi dei campi sono definiti dal prodotto. Le policy selezionate dipendono invece dall’ambiente. Un normale gruppo Internet non richiede automaticamente VPN, Quota o MAC Binding. Meno funzioni vengono combinate in un gruppo, più è semplice comprenderne l’effetto e il ripristino.

Assegnare gli utenti senza creare override nascosti

Creare e gestire utenti locali normali descrive in modo completo username, password, ereditarietà del gruppo, metodo di autenticazione e verifica. Possono essere assegnati a un gruppo in Authentication > Users. Durante la modifica del gruppo, Show group members mostra i membri e Add member(s) permette di aggiungere utenti locali idonei. Per le identità gestite esternamente, la directory rimane la fonte dell’appartenenza. Un’assegnazione locale manuale non sostituisce una corretta configurazione AD, LDAP o Entra.

Le policy specifiche dell’utente hanno priorità sulle policy di gruppo. Un override può essere utile per un’eccezione documentata o un pilota, ma può far sembrare inefficace una successiva modifica del gruppo. Per ogni utente differente, documentare quale campo è stato sostituito, perché esiste l’eccezione e come tornare al valore del gruppo.

La creazione e la verifica complete delle policy Access Time, delle quote Surfing e Network Traffic e dell’MFA per Sophos Firewall restano nei rispettivi articoli specialistici. Nell’oggetto gruppo viene assegnata soltanto la policy già pianificata.

Gestire in modo controllato i gruppi AD importati

I gruppi AD vengono importati nel firewall in Authentication > Servers > Import. In un cluster HA, l’importazione avviene sul dispositivo Primary. La procedura guidata importa solo i gruppi selezionati. Un gruppo creato successivamente in AD non compare quindi automaticamente sul firewall e deve essere nuovamente importato o creato intenzionalmente in modo corrispondente.

I gruppi AD annidati non vengono valutati. Se un sottogruppo deve essere utilizzato per una regola firewall, una policy VPN o un’altra funzione, occorre importare esattamente quel sottogruppo. Anche il gruppo AD primario di un utente non viene importato come appartenenza normale. Per le policy sono quindi più adatti gruppi di sicurezza espliciti rispetto al gruppo AD predefinito Domain Users.

Dopo una modifica alle appartenenze AD, ai gruppi importati o all’ordine dei gruppi, generare un nuovo accesso. Solo allora il firewall rivaluta i gruppi e aggiorna l’oggetto utente.

Comprendere il gruppo principale e l’ordine dei gruppi

Per un utente AD, Authentication > Users mostra due livelli distinti:

• Group: il primo gruppo corrispondente nell’elenco del firewall e quindi il gruppo principale;
• Other group memberships: gli altri gruppi importati dell’utente.

Modificare l’ordine in Authentication > Groups > Reorder. Se auth-pilot@example.com appartiene a SFOS_Internet_Standard e SFOS_SSLVPN, al successivo accesso diventa gruppo principale quello corrispondente posizionato più in alto nell’elenco.

L’ordine non viene modificato spontaneamente per un singolo problema. Prima si verifica quale funzione concreta è interessata e se supporta realmente altri gruppi. In caso contrario, uno spostamento potrebbe risolvere un caso VPN e contemporaneamente cambiare MFA, Quota o Access Time per altri utenti.

I gruppi multipli vengono valutati diversamente in base alla funzione

Il limite seguente si applica espressamente alle appartenenze ai gruppi Active Directory. Non va trasferito senza verifica a LDAP, RADIUS o Microsoft Entra ID.

È possibile considerare più gruppi AD per:

• Firewall rules e SSL/TLS inspection rules;
• SD-WAN routes;
• Web policies;
• IPS e Application control policies;
• Policy test;
• Remote access SSL VPN;
• Clientless SSL VPN.

Per Remote access SSL VPN, le autorizzazioni delle policy utente e gruppo corrispondenti vengono combinate. Se è coinvolta una policy Full Tunnel corrispondente, il risultato è un Full Tunnel. Questa combinazione va quindi verificata con un vero test del client e non soltanto confrontando i nomi dei gruppi.

Viene considerato solo il gruppo principale o un’assegnazione esplicita dell’utente per:

• WAF rules, My policy overrides e Hotspots;
• Remote access IPsec VPN, L2TP e PPTP;
• Surfing quota, Access time, Network traffic e Traffic shaping;
• Quarantine digest, MAC binding e Sign-in restriction;
• MFA.

Per le funzioni che supportano più gruppi, continua a contare l’ordine della regola o policy interessata. Ad esempio, una regola firewall può corrispondere tramite SFOS_SSLVPN anche se SFOS_Internet_Standard è il gruppo principale. Questo non significa che MFA o Quota utilizzi anch’esso SFOS_SSLVPN.

Verificare l’effetto del gruppo con un utente reale

Un gruppo salvato e un utente visibile non costituiscono ancora una prova di successo. Per il pilota si utilizza la stessa procedura che verrà poi applicata in produzione:

1. Terminare la sessione esistente dell’utente pilota e generare un nuovo accesso.
2. In Authentication > Users, documentare stato, Group, Other group memberships e possibili override dell’utente.
3. In Current activities > Live users, controllare nome utente, IP di origine e Client Type.
4. Per una regola firewall basata sull’utente, generare il flusso previsto e controllare la Firewall Rule ID in Log Viewer.
5. Per Access Time, Quota, MFA o Remote Access, provare separatamente il servizio interessato.
6. Eseguire lo stesso flusso come test negativo con un utente non appartenente al gruppo pilota.
7. Registrare risultato, ora, ordine dei gruppi e policy effettiva.

Verificare le regole firewall con Log Viewer, Policy Test e Packet Capture mostra il test completo del traffico. Se non è già chiaro se falliscono la scelta del servizio, l’identità, il gruppo principale o la regola successiva, Risolvere sistematicamente gli errori di autenticazione di Sophos Firewall guida attraverso l’intera catena di controllo.

Modifiche, ripristino e gestione

Le modifiche ai gruppi vengono trattate come modifiche alle policy:

1. Documentare lo stato iniziale e gli utenti interessati.
2. Modificare un solo gruppo, una sola policy o una sola posizione alla volta.
3. Autenticare nuovamente l’utente pilota.
4. Ricontrollare il gruppo principale, le altre appartenenze e la funzione specifica.
5. In caso di effetto inatteso, ripristinare l’ordine dei gruppi e l’assegnazione della policy precedenti.
6. Generare un altro nuovo accesso e ripetere il test positivo e quello negativo.

Un gruppo AD viene prima rimosso dalla directory e poi dal firewall. Un utente ancora presente in AD può essere ricreato localmente a un accesso successivo. Purge AD users non è quindi un pulsante di sincronizzazione né una procedura normale dopo una modifica a un gruppo.

Utenti e gruppi condividono l’intervallo di ID interno fino a 65535. Un numero elevato di oggetti visibili non dimostra da solo un problema di limite. Se un utente mostra una User ID superiore a 65535 e non diventa Live User, seguire la procedura separata per il limite degli ID utente di Sophos Firewall.

Circoscrivere gli errori in base al sintomo

Il nuovo gruppo AD non compare sul firewall

I nuovi gruppi non vengono sincronizzati automaticamente. Eseguire nuovamente la procedura guidata di importazione e, in HA, farlo sul Primary. In seguito, controllare in Authentication > Groups che sia presente esattamente il gruppo necessario. Non creare un ampio gruppo sostitutivo soltanto per far funzionare un accesso.

L’utente ha il gruppo principale errato

Documentare innanzitutto le appartenenze AD, i gruppi importati e l’ordine corrente. Quindi controllare se il gruppo previsto è effettivamente presente sul firewall. Una modifica pianificata in Reorder viene valutata soltanto dopo un nuovo accesso e deve essere provata con più utenti rappresentativi.

La regola firewall corrisponde, ma MFA o Quota non si applica

Le regole firewall supportano altri gruppi AD, mentre MFA e quote no. Nell’oggetto utente, controllare quale gruppo compare in Group come gruppo principale. Verificare quindi gli override specifici dell’utente e l’effettiva assegnazione della policy. La corrispondenza della regola non dimostra che MFA o Quota valuti i gruppi allo stesso modo.

La modifica al gruppo ha effetto errato soltanto per un utente

Confrontare i campi delle policy specifici dell’utente in Authentication > Users. Un singolo override ha priorità sulla policy di gruppo. Il valore non va modificato alla cieca, ma prima confrontato con l’eccezione documentata e lo stato di ereditarietà desiderato.

L’utente finisce nel Default Group

Con AD o un altro server di autenticazione classico, probabilmente manca un gruppo locale o un’associazione di gruppo corrispondente. Controllare importazione, nome del gruppo, base di ricerca e attributi restituiti. Con Microsoft Entra ID SSO, controllare invece il Fallback user group del server Entra. Non ampliare indiscriminatamente il Default Group per nascondere il reale errore di associazione.

Il gruppo AD annidato non si applica

Importare direttamente il sottogruppo necessario e inserirvi l’utente. Generare quindi un nuovo accesso e controllare Group e Other group memberships. Importare soltanto il gruppo superiore non è sufficiente.

Checklist operativa

• La finalità del gruppo e l’origine utenti responsabile sono documentate.
• I gruppi locali, importati e Clientless non vengono confusi.
• Il Default Group o il gruppo di fallback Entra è scelto consapevolmente e in modo restrittivo.
• L’ordine dei gruppi e i gruppi principali previsti sono documentati.
• Gli override degli utenti sono giustificati o rimossi.
• La funzione concreta supporta l’appartenenza al gruppo utilizzata.
• L’utente pilota è stato nuovamente autenticato e controllato in Authentication > Users.
• I test positivo e negativo confermano la policy o la Firewall Rule ID prevista.
• Remote Access, MFA, Access Time e quote sono stati verificati separatamente, se utilizzati.
• È documentato il percorso di ripristino per l’ordine dei gruppi e l’assegnazione delle policy.

Domande frequenti