Configurare in sicurezza amministratori e profili Sophos Firewall

Per l’amministrazione quotidiana, ogni persona dovrebbe avere un account personale. Prima si crea un profilo Device Access adatto, quindi in Authentication > Users si aggiunge un utente locale con User type: Administrator. Il profilo stabilisce cosa l’amministratore può visualizzare o modificare. MFA, sorgenti di login e Device Access proteggono inoltre l’autenticazione e la raggiungibilità di WebAdmin.

L’amministratore predefinito admin rimane un accesso di emergenza verificato e non viene usato come account quotidiano condiviso. In questo modo le modifiche restano attribuibili a una persona e un errore in un profilo limitato non blocca l’ultima via di ripristino.

Configurare un amministratore locale in otto passaggi

1. Verificare backup, amministratore predefinito e accesso di ripristino. Mantenere aperta una sessione amministrativa esistente finché il test non ha esito positivo.
2. Documentare attività e diritti necessari, per esempio solo diagnosi oppure anche modifiche agli oggetti di rete.
3. Creare un profilo dedicato in Profiles > Device access > Add e lasciare su None le aree non necessarie.
4. In Authentication > Users > Add, inserire un nome utente personale e impostare User type su Administrator.
5. Assegnare il nuovo profilo, una password personale robusta e l’indirizzo e-mail aziendale.
6. In Administrator advanced settings, limitare se necessario Schedule for device access e Login restriction for device access.
7. Verificare che Local rimanga disponibile in Authentication > Services > Administrator authentication methods. Configurare quindi MFA e l’accesso WebAdmin dalla rete di gestione.
8. Eseguire un test positivo e negativo dell’account in una finestra privata del browser. Solo a quel punto migrare altri account o disattivare i vecchi accessi.

⚠️ Un nuovo profilo non deve essere utilizzato in produzione finché non sono disponibili un secondo amministratore funzionante e una via di ripristino documentata. Il profilo integrato Administrator concede accesso completo e va assegnato solo al gruppo minimo indispensabile.

Distinguere i cinque livelli di protezione

Per gli accessi amministrativi interagiscono più impostazioni. Svolgono compiti diversi e non si sostituiscono a vicenda:

• Account utente: Identifica la persona. Gli account personali rendono tracciabili le modifiche; account di team come firewalladmin ne confondono l’attribuzione.
• Profilo Device Access: Definisce con None, Read-only e Read-write quali menu e funzioni sono visibili o modificabili. I diritti valgono anche per l’API.
• Schedule e Login Restriction: Limitano quando e da quali indirizzi IPv4 questo specifico account amministratore può utilizzare WebAdmin.
• Device Access e Local Service ACL: Definiscono da quali zone e sorgenti WebAdmin è raggiungibile. Configurare in sicurezza Device Access e Local Service ACL ne descrive l’implementazione.
• MFA e Audit Trail: MFA protegge l’account oltre alla password. Audit Trail aiuta ad attribuire le modifiche supportate a identità, sorgente e console. Per Data Anonymization in log e report vengono inoltre preparati almeno due authorizer personali con account separati.

Un profilo Read-only, per esempio, non protegge dal furto della password. A sua volta, MFA non impedisce attacchi contro una pagina di login inutilmente esposta a Internet. Solo l’insieme riduce sia i diritti sia la superficie di attacco.

Gli avvisi di accesso e i messaggi personalizzati aggiungono a questi livelli soltanto indicazioni visibili. L’accettazione non amplia né il profilo Device Access né l’autorizzazione di rete e non sostituisce nessuno dei cinque controlli.

Amministratore predefinito, account locali e identità centrali

L’utente predefinito admin possiede i diritti del profilo integrato Administrator. È adatto come accesso locale di emergenza, ma non come account quotidiano condiviso. Password, MFA, accesso alla console e procedura di ripristino devono essere documentati e testati indipendentemente dagli account personali.

Gli amministratori locali personali sono adatti a piccoli team, firewall isolati e come fallback consapevole. I team più grandi possono gestire i ruoli amministrativi tramite Microsoft Entra ID SSO per WebAdmin, TACACS+ con assegnazione locale del profilo o ruoli amministrativi di Sophos Central. Un utente contrassegnato come Managed by Central in Authentication > Users viene gestito in Central e non può essere modificato localmente.

Le automazioni non ricevono un account personale quotidiano. Per l’API XML si utilizza un account di servizio separato, con un responsabile proprio, diritti limitati e una sorgente autorizzata fissa. Proteggere l’accesso all’API XML di Sophos Firewall illustra l’intero percorso di protezione.

Pianificare il profilo Device Access

Sophos fornisce alcuni profili standard non modificabili in Profiles > Device access:

• Administrator: Accesso completo a WebAdmin e API. Sophos descrive questo profilo anche con accesso CLI completo; il login SSH diretto in SFOS accetta tuttavia solo il nome utente predefinito admin.
• Audit admin: Accesso in lettura e scrittura a log e report.
• Crypto admin: Accesso in lettura e scrittura ai certificati di sicurezza.
• HAProfile: Accesso Read-only all’Auxiliary Appliance di un cluster HA.
• Security admin: Accesso in scrittura alle funzioni, eccetto profili, log e report.

Questi profili sono punti di partenza pratici, ma non rappresentano automaticamente il ruolo corretto per ogni ambiente. Un profilo personalizzato è preferibile quando una persona necessita solo di un ambito di responsabilità chiaramente limitato.

Derivare i diritti dall’attività

Il nome del profilo non produce da solo alcun effetto tecnico. Un profilo chiamato ReadOnly può comunque contenere diritti di scrittura. Ciò che conta è l’intera matrice delle autorizzazioni, compresi i sottomenu espansi.

Un account Help Desk può, per esempio, essere pianificato così:

• Impostare su Read-only diagnosi, log e aree di configurazione necessarie al supporto.
• Concedere Read-write solo se il team deve eseguire direttamente una modifica definita con precisione.
• Lasciare su None i profili amministratore, i certificati e tutte le aree di prodotto non necessarie.
• Per ogni autorizzazione di scrittura, definire un esempio di ciò che deve essere consentito e uno di ciò che deve rimanere espressamente vietato.

Un profilo Network Operations può leggere più aree e modificare, per esempio, determinati ambiti di rete. Non gli serve comunque l’accesso completo ad amministratori, certificati o altre funzioni di sicurezza indipendenti. Privilegio minimo non significa mostrare il minor numero possibile di menu, ma concedere esattamente i diritti necessari all’attività assegnata.

Creare un profilo personalizzato

1. Aprire Profiles > Device access.
2. Selezionare Add.
3. Inserire un nome univoco, per esempio SFOS-NOC-Limited.
4. Selezionare None, Read-only o Read-write per ogni menu visibile.
5. Usare Expand per aprire i sottomenu e limitare con maggiore precisione i diritti differenti.
6. Salvare con Save.
7. Verificare nuovamente il profilo rispetto alle attività e ai test negativi documentati.

SFOS-NOC-Limited è solo un nome di esempio. Va adattato al team e all’attività. I diritti effettivamente assegnati devono inoltre essere documentati, perché il nome non spiega la matrice delle autorizzazioni.

Creare un amministratore locale personale

Inserire i dati dell’utente

1. Aprire Authentication > Users.
2. Selezionare Add.
3. In Username, inserire un nome personale permanente, per esempio m.mueller. Il nome utente non può essere modificato in seguito.
4. Inserire un nome visualizzato chiaro e l’indirizzo e-mail aziendale.
5. Impostare User type su Administrator.
6. In Profile, selezionare il profilo SFOS-NOC-Limited verificato in precedenza.
7. Impostare una password lunga e univoca, quindi trasmetterla in modo sicuro. Se il firewall rileva una password di uso comune o una parola del dizionario, richiede una password più robusta.

m.mueller è un esempio e deve essere sostituito con l’identità univoca della persona responsabile. Nomi funzionali come noc-admin dovrebbero essere usati solo se rappresentano davvero una singola identità tecnica con un proprio responsabile. Più persone non devono condividere la stessa password.

Limitare orario e sorgente di login

In Administrator advanced settings sono disponibili due controlli aggiuntivi:

• Schedule for device access: Consente il login a WebAdmin solo durante l’orario selezionato. È adatto al supporto temporaneo o a orari operativi definiti. Per un servizio di reperibilità, l’orario non deve bloccare involontariamente gli interventi di emergenza necessari.
• Login restriction for device access: Consente il login a WebAdmin solo da indirizzi IPv4 selezionati o da un intervallo IPv4. Per un jump host amministrativo, per esempio, si può usare 10.20.30.25 come Selected node.

L’indirizzo 10.20.30.25 è un esempio di rete privata. Va sostituito con l’indirizzo fisso del jump host o della postazione di gestione. In presenza di indirizzi client variabili, una VPN amministrativa o una rete di gestione dedicata è generalmente più ordinata di un ampio intervallo IP.

Access Time per utenti e gruppi normali controlla l’accesso a internet; per WebAdmin è rilevante Schedule for device access in Administrator advanced settings. Non sono la stessa impostazione.

Mantenere disponibile l’autenticazione locale

In Authentication > Services > Administrator authentication methods, il database locale deve essere selezionato per gli amministratori locali personali. Il super amministratore predefinito admin è escluso da questo elenco di metodi, ma i nuovi amministratori locali non lo sono.

Il metodo locale non va rimosso prima che il nuovo account sia stato testato correttamente in un browser separato. Con server di autenticazione esterni, l’ordine stabilisce dove viene inviato per primo un tentativo di login. Le modifiche a tale ordine devono quindi rientrare nello stesso piano di accettazione e rollback dell’account.

Proteggere MFA e raggiungibilità

MFA dovrebbe essere attivata per gli amministratori interattivi. Gli amministratori personali vengono aggiunti in Authentication > Multi-factor authentication per Web admin console. Per l’utente predefinito admin esiste un’impostazione separata in Administration > Device access > MFA for default admin. Attivare MFA per WebAdmin di Sophos Firewall spiega gruppo pilota, registrazione dei token, Login Security e ripristino. MFA va prima testata con un singolo nuovo amministratore, non contemporaneamente con tutti gli account.

WebAdmin rimane inoltre limitato a reti di gestione, VPN o sorgenti strettamente definite. Una Login restriction for device access attiva non rende sicura un’ampia autorizzazione WAN. Al contrario, una Local Service ACL non sostituisce l’account personale e il relativo profilo di autorizzazioni.

Un test WebAdmin riuscito non abilita SSH. SFOS accetta solo il nome utente admin per il login SSH diretto; un amministratore WebAdmin locale personale non viene quindi testato come account SSH. Anche SSH richiede una decisione Device Access separata. La gestione delle chiavi pubbliche dell’amministratore predefinito e l’accesso SSH sicuro sono trattati separatamente in Connettersi a Sophos Firewall tramite SSH.

In Administration > Admin and user settings, Administrator password complexity, il timeout di sessione e Block login completano le impostazioni dell’account. Questi valori si applicano a tutto il sistema e non devono quindi essere irrigiditi eccessivamente per un singolo account. In particolare, Block login può bloccare l’IP sorgente per tutti i servizi di login dopo tentativi falliti; prima del test devono essere disponibili una seconda sorgente di gestione o l’accesso alla console.

Testare in sicurezza diritti e login

Durante il test restano disponibili la finestra amministrativa esistente e una via di ripristino indipendente. Non è opportuno provocare più login falliti, perché Block login può bloccare temporaneamente l’IP sorgente condiviso per altri servizi di autenticazione.

1. Aprire una finestra privata del browser e accedere a WebAdmin tramite il FQDN previsto dalla rete di gestione consentita.
2. Effettuare il login con il nuovo account e MFA.
3. Verificare che tutti i menu necessari siano visibili e che le informazioni previste siano consultabili.
4. Se il profilo contiene diritti di scrittura, eseguire una modifica di test innocua e preventivamente approvata, con rollback immediato.
5. Aprire un’area impostata su None o Read-only. L’account non deve potervi salvare una modifica vietata.
6. Provare al massimo una volta un login controllato da una sorgente non consentita. Se il risultato non è chiaro, analizzare prima impostazioni e log anziché generare ulteriori tentativi falliti.
7. Verificare la modifica di test e l’amministratore utilizzato in Configuration Audit Trail. Non tutti gli oggetti producono lo stesso livello di dettaglio; controllare inoltre l’effetto tecnico nella funzione interessata.
8. Disconnettersi, effettuare nuovamente il login e solo dopo migrare l’account successivo.

In un cluster HA, dopo un failover pianificato si testa inoltre un nuovo login sul nodo ora attivo. Una sessione WebAdmin esistente o la sua prosecuzione senza interruzioni non costituisce un criterio di successo affidabile.

Un menu visibile non dimostra che il diritto di scrittura funzioni. Un menu nascosto non dimostra che le altre funzioni assegnate siano corrette. Test positivo, test negativo e attribuzione nell’audit devono quindi essere eseguiti insieme.

Verificare e rimuovere gli account in sicurezza

Gli accessi amministrativi vengono controllati regolarmente rispetto a responsabile, attività, profilo, MFA, sorgente di login e ultimo utilizzo. Gli account di supporto temporanei devono inoltre avere una data di fine documentata. Per un intervento Avanet a tempo limitato rimane valida la procedura dedicata Configurare l’accesso al supporto Avanet su Sophos Firewall.

Nell’offboarding, una procedura controllata è più sicura dell’eliminazione immediata:

1. Verificare se l’account è usato in script API, password vault, documentazione o processi di supporto.
2. In Authentication > Users, impostare lo stato su inattivo.
3. Verificare in una finestra privata del browser che non sia più possibile un nuovo login.
4. Controllare separatamente le sessioni WebAdmin attive e le modifiche recenti. La disattivazione non deve essere considerata una prova che ogni sessione esistente sia terminata immediatamente.
5. Rimuovere o ruotare token MFA, segreti e assegnazioni esterne associati all’account.
6. Dopo il periodo di osservazione concordato, eliminare l’utente se non rimangono dipendenze.
7. Eliminare un profilo personalizzato non più necessario solo quando non è più assegnato ad alcun amministratore.

L’amministratore predefinito rimane escluso da questo normale processo di offboarding. Se si perde la password o l’accesso MFA, Ripristinare la password admin di Sophos Firewall aiuta a preparare la procedura di ripristino.

Individuare i problemi comuni

L’account esiste, ma il login WebAdmin non riesce

Verificare questi punti nell’ordine:

• User type è effettivamente impostato su Administrator.
• Lo stato dell’utente è attivo e la password è corretta.
• Local è selezionato in Administrator authentication methods.
• Schedule for device access consente l’orario attuale.
• Login restriction for device access contiene l’indirizzo IPv4 sorgente effettivo.
• Token MFA, ora di sistema e registrazione sono corretti.
• Block login non ha bloccato l’IP sorgente dopo tentativi falliti.
• Device Access o una Local Service ACL consente HTTPS da questa sorgente.

Se la pagina di login non è raggiungibile, l’analisi parte da Device Access, routing e indirizzo sorgente. Se è raggiungibile ma rifiuta soltanto questo account, le verifiche più immediate riguardano utente, profilo, metodo di autenticazione, Schedule, Login Restriction e MFA.

Per la correlazione temporale sono utili l’area Authentication di Log Viewer e access_server.log per autenticazione e autorizzazione. syslog.log aggiunge eventi di sistema e attivati dagli amministratori. Le modifiche agli oggetti supportati vengono controllate separatamente in configuration-audit.log.

L’account vede troppo o troppo poco

Verificare il profilo assegnato e i relativi sottomenu espansi. Read-only e Read-write possono essere impostati diversamente all’interno di un menu principale. Eseguire quindi un nuovo test con un nuovo login, senza affidarsi soltanto al nome del profilo.

Con Managed by Central, il ruolo proviene da Sophos Central e non viene modificato sull’utente locale. Con Entra SSO, il mapping di ruolo o gruppo del server Entra determina il profilo Device Access locale.

WebAdmin funziona, ma API o SSH no

Il profilo Device Access si applica anche ai diritti API, ma l’API richiede inoltre l’accesso API attivato e una sorgente consentita. SSH è un servizio locale separato e non costituisce un test di successo adatto per un profilo WebAdmin limitato. Un account non ottiene l’accesso SSH solo perché il login WebAdmin funziona.

Checklist operativa

• L’amministratore predefinito e la via di ripristino sono testati e non vengono condivisi.
• Ogni persona utilizza un account personale.
• I profili derivano dalle attività e i sottomenu espansi sono stati verificati.
• L’accesso completo è limitato al gruppo minimo necessario.
• MFA, Schedule e sorgente di login sono adatti allo scopo.
• WebAdmin è raggiungibile solo dalle sorgenti di gestione previste.
• Sono stati eseguiti test positivi e negativi dei diritti.
• Dove supportato, le modifiche sono attribuibili a un account amministratore personale in Audit Trail.
• Gli account API e di supporto hanno responsabili e cicli di vita propri.
• L’offboarding comprende stato, sessioni, MFA, segreti e dipendenze.

FAQ