Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access

L’accesso amministrativo e i portali di accesso remoto non dovrebbero essere protetti solo con nome utente e password. Con l’autenticazione a più fattori, MFA in breve, lo Sophos Firewall richiede anche un secondo fattore, ad esempio un codice OTP basato sul tempo da un’app Authenticator.

Per il contesto generale di hardening, consultare l’hub Sophos Firewall Hardening: best practice per una configurazione sicura.

L’articolo spiega come progettare, attivare e testare in modo sensato MFA. L’attenzione è rivolta a WebAdmin, VPN Portal e all’accesso remoto.

Classificazione e protezione degli accessi

MFA è una protezione importante per gli accessi, ma è solo un elemento fondamentale. Innanzitutto dovrebbe essere chiaro quale accesso è protetto, quale fonte di identità si nasconde dietro e se il servizio deve essere accessibile anche dalla rispettiva rete.

Quale articolo di autenticazione è adatto?

MFA è solo una parte della sicurezza di accesso. A seconda dell’obiettivo, la prima cosa da considerare è l’accessibilità, la fonte dell’identità, il portale, il client VPN o l’applicazione web pubblicata:

• MFA per WebAdmin, VPN Portal o Programma accesso remoto: Questo articolo.
• WebAdmin, SSH, User Portal, VPN Portal, Limita DNS o Ping raggiungibile: Sophos Firewall Protezione dell’accesso: configurare correttamente Device Access
• Utilizza l’SSO Microsoft Entra ID per Sophos Connect o VPN Portal: Configura l’SSO Microsoft Entra ID per Sophos Connect e VPN Portal
• Confronta Sophos Connect, SSL VPN, IPsec o ZTNA come modello di accesso remoto: Sophos Connect o SSL VPN: quale soluzione di accesso remoto è giusta?
• Controllare la versione del client Sophos Connect, le riconnessioni OTP o il provisioning SSO: Verifica la versione del client Sophos Connect e aggiornalo in sicurezza
• Protezione dell’applicazione Web pubblicata WAF con MFA: Proteggi il WAF Sophos Firewall con MFA
• Connetti Active Directory classico come origine utente: Aggiungi Active Directory su Sophos Firewall
• Preparare l’accesso controllato al supporto per Avanet o Sophos: Configurazione dell’accesso al supporto Avanet a Sophos Firewall
• Dai la priorità ai risultati del controllo dello stato per MFA o all’accesso al portale: Utilizzare Sophos Firewall Health Check correttamente

Questa separazione è importante: MFA protegge gli accessi, ma non limita automaticamente da quali reti WebAdmin, SSH o portali è possibile raggiungere. Al contrario, una regola di accesso al dispositivo ristretta non sostituisce un secondo fattore. Una buona sicurezza di accesso combina raggiungibilità, origine identità, MFA, registrazione e accesso fallback testato.

Quando MFA ha senso

MFA deve essere abilitato almeno per tutti gli account a cui è consentito accedere alle interfacce amministrative o alle funzioni di accesso remoto.

Aree di applicazione tipiche:

• Registrazione su WebAdmin.
• Registrazione su VPN Portal.
• SSL VPN o Sophos Connect Accesso remoto.
• Accesso per fornitori di servizi esterni.
• Accesso per amministratori privilegiati.

MFA riduce il rischio di password rubate, ma non sostituisce le adeguate restrizioni di accesso. SSH, WebAdmin e i portali dovrebbero comunque essere accessibili solo da reti affidabili o tramite un accesso di gestione chiaramente definito.

MFA non sostituisce Device Access

MFA protegge il processo di accesso. Tuttavia, non riduce la superficie di attacco di un servizio. Se WebAdmin, User Portal, VPN Portal o SSL VPN sono raggiungibili da Internet, questi servizi continueranno a essere colpiti da bot, scanner e tentativi di forza bruta. Ciò crea voci di registro non necessarie, sforzi di supporto e rischi.

Ecco perché dovresti sempre combinare MFA con i controlli di disponibilità:

• Device access: Fondamentalmente determinare quali servizi sono accessibili in quale zona.
• Regola di eccezione ACL del servizio locale: WebAdmin, SSH o portali consentono specificatamente solo reti di gestione, reti VPN o indirizzi di origine noti.
• MFA: Inoltre, proteggi le registrazioni se i dati di accesso validi sono stati compromessi.
• Registrazione e Syslog: Rendi comprensibili i tentativi falliti, i problemi di implementazione e gli attacchi.

Se un portale deve essere accessibile in tutto il mondo, dovresti almeno combinare MFA, certificati validi, registrazione, gruppi di utenti restrittivi e processi di revisione regolari. Per i servizi firewall accessibili al pubblico, la questione non è solo se un utente malintenzionato può accedere, ma se il servizio deve essere ampiamente accessibile.

Limita inoltre l’accesso con le regole ACL

Prima di attivare MFA è opportuno verificare da dove sono effettivamente raggiungibili WebAdmin, SSH, User Portal e VPN Portal.

Il percorso del menu è Sistema > Administration > Device access.

Ci sono due aree rilevanti:

• Servizio locale ACL: accesso di base per zona, ad esempio LAN, VPN o WAN.
• Regola di eccezione ACL del servizio locale: eccezioni mirate per singole reti di origine, host o accesso al supporto.

Per gli ambienti di produzione, in genere non è necessario abilitare WebAdmin e SSH per la zona WAN. È meglio limitarlo a:

• un IP di gestione,
• una rete amministrativa,
• una rete VPN,
• un host di supporto dedicato,
• o un’eccezione FQDN/host chiaramente definita.

Se è necessario SSH, l’accesso dovrebbe essere ulteriormente limitato e idealmente utilizzato con una chiave pubblica. Questo si adatta a Collega Sophos Firewall tramite SSH.

⚠️ MFA protegge dalle credenziali rubate, ma non dai servizi esposti inutilmente. WebAdmin, SSH e i portali non dovrebbero mai essere più ampiamente accessibili del necessario.

Seleziona la variante MFA e pianifica l’implementazione

Prima dell’attivazione è necessario decidere se la funzione Sophos OTP locale è sufficiente o se è necessario integrare una piattaforma MFA esistente tramite RADIUS, NPS o SSO. L’implementazione viene quindi pianificata in modo tale che amministratori e utenti non si chiudano fuori.

Requisiti

Prima dell’attivazione dovresti controllare:

• L’ora del sistema firewall è corretta.
• È configurato un server NTP funzionante.
• Gli utenti esistono localmente, tramite AD, LDAP, RADIUS o altro servizio di autenticazione supportato.
• Gli utenti interessati possono accedere allo User Portal o al rispettivo servizio.
• È disponibile almeno un accesso fallback amministrativo.> ⚠️ Devi prestare particolare attenzione con Admin-MFA. MFA non deve essere abilitato direttamente per tutti gli amministratori senza prima verificare un utente di prova, un secondo amministratore e l’accesso fallback. Una configurazione MFA errata può comportare il blocco dell’accesso a WebAdmin o VPN Portal.

Sophos MFA o MFA esterno?

Esistono fondamentalmente due modi per MFA sullo Sophos Firewall: utilizzare la funzione OTP locale del firewall o connettere una soluzione MFA esterna tramite RADIUS o SSO. Entrambe le varianti sono legittime, ma risolvono problemi diversi.

Lo MFA locale dello Sophos Firewall gestisce i token OTP direttamente sul firewall. Questo è solitamente il modo più rapido per proteggere WebAdmin, portali e accesso remoto con un secondo fattore. Non è richiesta alcuna infrastruttura RADIUS aggiuntiva o provider di identità.

Vantaggi del MFA di Sophos:

• Non è richiesta alcuna integrazione aggiuntiva con RADIUS o provider di identità.
• Implementazione rapida per utenti locali e ambienti di piccole dimensioni.
• I token possono essere generati e gestiti direttamente sul firewall.
• Adatto per accesso remoto WebAdmin, User Portal, VPN Portal, SSL VPN e accesso remoto IPsec.

Svantaggi:

• Gli utenti potrebbero dover mantenere un’app o un token Authenticator aggiuntivo.
• Il token è separato da Microsoft 365, Entra ID o altri processi MFA esistenti.
• A seconda della maschera di accesso non esiste un campo OTP separato.
• Su alcuni portali gli utenti devono inserire password e token direttamente uno dopo l’altro.

In ambienti più grandi, una soluzione MFA esterna potrebbe avere più senso. Le varianti tipiche sono RADIUS con un backend compatibile con MFA, Microsoft NPS con estensione Entra-MFA o un altro sistema MFA compatibile con RADIUS. A seconda della versione SFOS e del modello di accesso remoto, possono essere adatti anche Microsoft Entra ID SSO per WebAdmin, VPN Portal e Sophos Connect con SSL VPN o IPsec VPN.

La distinzione importante è che Entra ID non è semplicemente lo stesso meccanismo della funzionalità OTP locale di Sophos. Entra MFA è integrato indirettamente nel flusso di autenticazione tramite RADIUS/NPS oppure viene utilizzato un modello SSO se il servizio e il client utilizzati lo supportano.

Gli utenti spesso trovano più conveniente uno MFA esterno perché utilizzano lo stesso MFA di Microsoft 365 o altri servizi aziendali. Ciò non crea un secondo mondo MFA con un’app aggiuntiva, un token aggiuntivo e un comportamento di accesso diverso.

Lo svantaggio di una soluzione esterna è la maggiore complessità. RADIUS, gruppi, timeout, comportamento di sfida e fallback devono essere attentamente pianificati e testati.| Variante | Vantaggio | Svantaggio | Uso tipico |

• MFA esterno tramite RADIUS: È possibile utilizzare la piattaforma MFA esistente, i processi utente centrali vengono mantenuti RADIUS, NPS, timeout, gruppi e comportamento del client devono essere testati in modo pulito Ambienti AD/Microsoft 365 con molti utenti VPN.
• Entra ID SSO: Accesso Microsoft familiare, migliore esperienza utente, processi di identità centralizzati Non utilizzabile in modo identico per ogni scenario, a seconda della versione, del servizio e del client SFOS WebAdmin, VPN Portal e Sophos Connect se SSO è adatto al modello operativo.

Supporto decisionale

La variante MFA giusta dipende meno dal firewall che dall’operazione di identità esistente.

• Piccolo ambiente con utenti firewall locali: La funzione OTP propria di Sophos è spesso sufficiente.
• Ambiente Microsoft 365 con Entra-MFA esistente: Convalida MFA esterno tramite RADIUS/NPS o Entra-ID SSO in modo che gli utenti non debbano mantenere due mondi MFA.
• Molti fornitori di servizi esterni: Proprio gruppo di utenti, obbligo MFA, termini chiari e revisione regolare.
• Accesso amministrativo critico: MFA più Device Access, combinano rete di gestione, amministrazione fallback e registrazione.
• Molti utenti di accesso remoto: Pianifica il gruppo pilota, il processo di helpdesk, la reimpostazione dei token e i test dei client prima dell’implementazione su vasta scala.

Se Microsoft Entra ID è pianificato direttamente come origine SSO per VPN Portal o Sophos Connect, anche Configura Microsoft Entra ID SSO per Sophos Connect e VPN Portal è adatto. Si tratta di un modello operativo diverso rispetto alla classica funzione OTP di Sophos e non deve essere equiparato a RADIUS-MFA non testato.

Piano MFA

Per gli ambienti di produzione, in genere è meglio attivare prima MFA per un piccolo gruppo pilota.

Questo ordine ha avuto successo:

1. Preparare gli utenti di prova o il gruppo pilota.
2. Controllare NTP e l’ora del firewall.
3. Abilita MFA per l’area di prova.
4. Prova la registrazione con l’app Authenticator.
5. Solo successivamente integrare ulteriori gruppi di utenti.

Per i fornitori di servizi si consiglia un gruppo utenti separato. Ciò consente di forzare in modo specifico MFA e rimuovere l’accesso in seguito più facilmente.

Per gli amministratori dovresti pianificare anche:

• Chi è il primo amministratore del test?
• Esiste un secondo amministratore con accesso funzionante?
• L’accesso è possibile tramite una rete di gestione o VPN?
• Il admin predefinito è protetto separatamente?
• È documentato come viene sostituito un token smarrito?

Attiva MFA e imposta i token

Una volta chiariti i prerequisiti, i gruppi e il fallback, MFA può essere prima attivato per un gruppo pilota. Solo dopo aver superato con successo i test dovresti includere ulteriori utenti o amministratori.

Attiva MFA sullo Sophos Firewall

Le impostazioni MFA si trovano in Configure > Authentication > Multi-factor authentication.

1. Accedere allo WebAdmin dello Sophos Firewall.
2. Apri Configura > Autenticazione.
3. Passa alla scheda Autenticazione a più fattori.
4. Per One-time password (OTP), selezionare a chi deve essere applicata MFA:
   • Nessuna OTP: MFA è disabilitato.
   • Tutti gli utenti: MFA si applica a tutti gli utenti.
   • Utenti e gruppi specifici: MFA si applica solo a utenti o gruppi selezionati.
5. Attiva Genera token OTP al prossimo accesso se desideri che gli utenti configurino autonomamente il proprio token al successivo accesso.
6. In Richiedi MFA per, selezionare per quali servizi è richiesto MFA.
7. Salvare la configurazione con Applica.

Le opzioni tipiche in Richiedi MFA per sono:

• Portale utenti
• Console di amministrazione Web
• Portale VPN
• Accesso remoto SSL VPN
• Accesso remoto IPsec
• Firewall applicazione Web

A seconda dell’ambiente, MFA può essere applicato in modo diverso per singoli servizi o gruppi di utenti. Per gli amministratori, MFA deve essere applicato in modo coerente, ma prima testato in modo controllato.

Se le applicazioni Web vengono pubblicate tramite Web Server Protection, è richiesta anche una policy di autenticazione WAF appropriata. Il processo è in Sophos Firewall WAF sicuro con MFA.

Prepararsi per il lancio e le operazioni

MFA non è solo un interruttore nel firewall. Dopo l’attivazione, il comportamento di accesso, le domande di supporto e l’accesso di emergenza cambiano. Pertanto, prima del lancio su vasta scala, dovrebbe essere chiaro chi emette i token, chi ripristina i token persi e come sarà la reazione al di fuori degli orari di ufficio.

Questi punti si sono rivelati utili per il funzionamento:

• Testare il gruppo pilota con utenti reali, non solo amministratori.
• Documentare un secondo accesso amministratore e rompere il vetro.
• Informare l’helpdesk sul comportamento password+OTP.
• Imposta il processo di ripristino del token per nuovi smartphone o dispositivi smarriti.
• Controlla Log Viewer e i log di autenticazione dopo l’implementazione.
• Testare MFA esterno tramite RADIUS con timeout realistici.
• Controllare regolarmente le eccezioni Device Access e ACL.

Soprattutto con l’accesso remoto, dovresti testare MFA insieme alle regole VPN, ai gruppi utente e ai profili client interessati. Un accesso WebAdmin funzionante non dimostra automaticamente che SSL VPN, IPsec Remote Access o Sophos Connect funzionino allo stesso modo.

Pianifica il fallback e la rottura del vetro

MFA aumenta la sicurezza, ma può anche bloccare gli amministratori legittimi se il token, l’ora, il server di autenticazione o i gruppi non corrispondono. Ecco perché è necessario un piano di riserva prima dell’attivazione.

Almeno questi punti dovrebbero essere documentati:

• Chi ha un secondo accesso amministrativo testato?
• È possibile l’accesso da una rete di gestione o amministrazione VPN?
• L’account locale predefinito admin è protetto come account di emergenza ma non viene utilizzato per l’uso quotidiano?
• Come reimpostare un token OTP smarrito o rotto?
• Chi può reimpostare i token per gli amministratori?
• Come reagisci al di fuori dell’orario di ufficio?
• Esiste un backup attuale prima della modifica?Il fallback non deve significare che l’accesso amministrativo non protetto rimanga permanentemente accessibile da Internet. È meglio avere un conto di emergenza con documentazione chiara, un percorso di accesso ristretto e revisioni periodiche.

MFA per l’amministratore predefinito

L’utente predefinito locale admin è un caso speciale. MFA per questo utente non è attivato direttamente nella scheda Autenticazione a più fattori.

Il percorso del menu è Sistema > Administration > Device access.

Lì puoi attivare MFA per l’amministratore predefinito. Dovresti farlo solo se:

• l’ora del sistema è corretta,
• è stato testato un secondo amministratore,
• l’accesso avviene tramite una rete di gestione affidabile,
• ed è chiaro come recuperare l’accesso amministrativo in caso di emergenza.

Per lo admin predefinito vale quanto segue: non disattivarlo, non renderlo accessibile senza protezione su Internet e non utilizzarlo come normale utente quotidiano. Si tratta di un conto rottura vetro o di emergenza.

Gli altri amministratori non devono presumere di poter modificare o eliminare il token MFA dello admin predefinito come un normale token utente. Questo accesso deve essere pianificato e testato consapevolmente tramite il proprio percorso di accesso al dispositivo.

Configura i token per gli utenti

Una volta attivato, l’utente deve impostare il secondo fattore. Se Genera token OTP al prossimo accesso è attivo, l’utente accede a User Portal o VPN Portal ed esegue la scansione del codice QR con un’app Authenticator.

Le app adatte includono:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Altre app Authenticator compatibili con TOTP.

Il codice generato è basato sul tempo. Se l’ora sul firewall o sullo smartphone differisce in modo significativo, l’accesso non riuscirà.

Se User Portal è disabilitato, gli utenti potrebbero non essere in grado di configurare autonomamente i propri token. In questo caso è necessario fornire il portale in modo controllato oppure preparare i token a livello amministrativo.

Algoritmo dei token e cambio di app

Sophos Firewall supporta gli algoritmi hash SHA1, SHA256 e SHA512 per i token OTP. Le versioni SFOS precedenti alla 22.0 usano SHA1 per MFA; da SFOS 22.0 in poi, per token nuovi o migrati conviene testare SHA256 o SHA512. Questa scelta non va applicata alla cieca: l’algoritmo selezionato deve essere compatibile con l’app di autenticazione utilizzata.

Sophos indica esplicitamente che l’app deve supportare l’algoritmo selezionato. Se un’app non supporta correttamente SHA256 o SHA512, il codice QR può essere comunque scansionato, ma l’accesso fallisce. Per questo l’algoritmo deve sempre far parte del test pilota, soprattutto quando si usano insieme Microsoft Authenticator, TOTP in password manager, Google Authenticator o Sophos Intercept X for Mobile.

Questi punti sono importanti per il funzionamento:

• Non pianificare più nuovi token con i presupposti delle vecchie app.
• Utilizza un’app Authenticator che supporti l’algoritmo di hashing selezionato.
• Se cambi app o perdi lo smartphone, elimina il vecchio token e fai rigenerare il codice QR.
• Utilizzare i token hardware solo se l’algoritmo, la fase temporale e il segreto possono essere gestiti correttamente.
• Testare un gruppo pilota prima di una migrazione SHA256/SHA512 invece di cambiare tutti i token contemporaneamente.
• Eliminare e rigenerare in modo controllato i token SHA1 esistenti durante una migrazione.

La vecchia app Sophos Authenticator non dovrebbe più essere pianificata come nuova app predefinita; secondo Sophos è End of Life dal 31 luglio 2022. In molti ambienti, Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password o Bitwarden sono opzioni più realistiche. Il marchio dell’app conta meno della compatibilità tra TOTP, algoritmo hash, comportamento di backup/ripristino e processo di helpdesk.

Nota importante su password e token

A seconda del servizio Sophos, non esiste un campo modulo separato per il codice OTP. Ciò crea sempre confusione, soprattutto con VPN Portal o con gli accessi ad accesso remoto. In questi casi spesso l’utente deve inserire in successione la password e il codice OTP.

Esempio:

Password: MiaPasswordSicura
Codice OTP: 123456
Input:       MiaPasswordSicura123456

Questo dovrebbe essere chiaramente comunicato agli utenti prima del lancio. In caso contrario all’utente sembrerà che la password sia errata, anche se manca solo il codice OTP.

Questo comportamento dovrebbe essere testato e documentato prima del rollout perché viene percepito in modo diverso a seconda del servizio e della maschera di accesso.

Operazione di test e controllo

Un test WebAdmin riuscito non è sufficiente. Ciascuna superficie di accesso interessata deve essere testata separatamente poiché il portale, il client VPN, il gruppo utenti e il server di autenticazione potrebbero reagire in modo diverso.

Prova l’accesso

MFA deve essere prima testato con un utente che non sia l’unico amministratore.

Questi punti dovrebbero essere controllati:

• Registrazione su WebAdmin.
• Registrazione su VPN Portal.
• Accedere al servizio di accesso remoto.
• Comportamento in caso di codice OTP errato.
• Comportamento dopo la scadenza di un codice OTP.
• Accesso con un utente che non sia nel gruppo MFA.
• Login con password e codice OTP allegato.
• Accesso tramite regole ACL pianificate.

Solo quando questi test avranno esito positivo, MFA potrà essere distribuito ad altri gruppi.

Matrice di test per servizio

Un test MFA non dovrebbe consistere solo in un accesso WebAdmin riuscito. A seconda del servizio si applicano altri portali, gruppi, profili e file di registro. Questa matrice aiuta ad esaminare separatamente i casi più importanti:

• WebAdmin: Accesso utente amministratore con OTP corretta e errata L’OTP corretta consente l’accesso, l’OTP errata viene rifiutata e registrata in modo pulito.
• Predefinito admin: Testare il percorso MFA separato in Sistema > Administration > Device access Il conto di emergenza è protetto, ma rimane disponibile un percorso documentato di rottura del vetro.
• User Portal: L’utente configura personalmente i token Il codice QR viene visualizzato solo per gli utenti autorizzati, il token funziona quindi quando si accede.
• VPN Portal: L’utente accede con password e OTP Il login funziona con un formato di input documentato ed è visibile in Log Viewer.
• SSL VPN / Sophos Connect: Importa profilo o riconnetti MFA viene interrogato nel client reale, non solo nel browser.
• IPsec Accesso remoto: Controlla il gruppo e il metodo di autenticazione MFA si applica allo stesso gruppo consentito anche nella configurazione di accesso remoto.
• MFA esterno tramite RADIUS: Prova push, sfida o token con un cliente reale Il timeout è sufficiente, il comportamento della verifica corrisponde al client, gli errori sono visibili sul server RADIUS.

Ogni test dovrebbe inoltre verificare se Device Access o una regola ACL del servizio locale consente intenzionalmente il servizio. Se il token funziona ma il portale è accessibile dalla rete sbagliata, la configurazione MFA è solo una parte del problema risolto.

Registri e controllo operativo

Dopo l’implementazione è necessario verificare se gli eventi MFA possono essere tracciati durante il funzionamento. Questo è importante per i casi di supporto, le revisioni della sicurezza e la risposta agli incidenti.

Punti di controllo utili:

• Controlla gli eventi di autenticazione nel Visualizzatore registro.
• Distinguere gli accessi non riusciti da password errata, OTP errata e OTP scaduta.
• Documento Portale VPN e test di accesso remoto con ora e utente.
• Per RADIUS esterno, controllare anche il server RADIUS, i log NPS o i log del provider di identità.
• Per una conservazione più lunga, pianificare Central Reporting o Syslog/SIEM.

Per i file di registro locali e la mappatura dei servizi, è adatto Sophos Firewall Risoluzione dei problemi: Services e registri. Se l’autenticazione e gli eventi del portale devono essere valutati a lungo termine, Sophos Firewall invia Syslog a SIEM è adatto.

Risoluzione dei problemi

Il codice OTP non è accettato

Controllare innanzitutto l’ora di sistema del firewall e l’ora dello smartphone. TOTP dipende dal tempo. Anche una deviazione significativa può portare al rifiuto di codici validi.

Puoi controllare i token emessi in Autenticazione > Autenticazione a più fattori. Se un singolo token continua a mancare il segno, non dovresti modificare immediatamente l’intera configurazione MFA. Per prima cosa controlla la deriva temporale del token, l’app utilizzata, l’algoritmo hash e il passaggio temporale.

L’utente non vede il codice QR

L’utente deve essere idoneo per MFA e accedere al portale corretto. Inoltre, è necessario verificare se l’utente viene trovato tramite la fonte di autenticazione prevista.

Se User Portal è disabilitato, l’utente potrebbe non essere in grado di configurare il token da solo. Il portale deve quindi essere reso temporaneamente accessibile oppure il token deve essere creato a livello amministrativo.

Il portale non può essere raggiunto tramite Device Access

Se gli utenti non riescono a configurare il proprio token anche se MFA è stato attivato correttamente, non è necessario eliminare prima il token. Spesso il portale richiesto non può essere raggiunto dalla rete corrente tramite Sistema > Administration > Device access o una regola ACL del servizio locale.

Controlla prima:

• Quale portale viene utilizzato per la configurazione dei token?
• Da quale zona o fonte proviene l’utente?
• L’accesso è consentito intenzionalmente o bloccato accidentalmente?
• Esiste un’eccezione ACL più ristretta invece di una versione più ampia?

L’amministratore è bloccato

In questo caso, utilizzare l’accesso fallback preparato. Se non esiste un fallback, l’accesso deve essere valutato tramite console, supporto o percorsi di ripristino a seconda della situazione.

MFA non funziona per l’accesso remoto

Verificare se la configurazione dell’accesso remoto utilizza lo stesso gruppo utenti per il quale è stato attivato MFA. Spesso l’errore non riguarda MFA stesso, ma diversi gruppi in VPN e regole di autenticazione.

Anche i profili cliente devono corrispondere alla configurazione corrente. Dopo aver apportato modifiche a VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO o RADIUS, i profili Sophos Connect interessati devono essere reimportati o ridistribuiti.

L’utente inserisce solo la password

Se non viene visualizzato un campo OTP separato, l’utente deve inserire in sequenza la password e il codice OTP. Questo è uno dei casi di supporto più comuni dopo l’attivazione di Sophos OTP.

Lo MFA esterno non funziona in modo affidabile

Per le soluzioni MFA basate su RADIUS, i timeout, il comportamento delle sfide e i gruppi devono adattarsi perfettamente. Se vengono utilizzati Push-MFA, Call-MFA o risposte di sfida, è necessario testare l’intero processo di accesso con il client interessato.

MFA è stato attivato per il gruppo sbagliato

Se MFA funziona per alcuni utenti e non per altri, dovresti prima confrontare i gruppi tecnicamente. Non sono rilevanti solo i nomi visualizzati visibili, ma anche i gruppi effettivamente importati o abbinati da AD, LDAP, RADIUS o Entra ID. Un utente può autenticarsi con successo e tuttavia non finire nel gruppo per il quale è richiesto MFA.

Lista di controllo operativa e raccomandazioni

Dopo l’attivazione tecnica, MFA necessita di un processo operativo semplice: chi reimposta i token, chi controlla i log e come viene verificato che i portali non siano inutilmente accessibili?

Lista di controllo delle operazioni

• Ora di sistema e NTP controllati.
• Gruppo pilota definito e testato.
• MFA non attivato direttamente per tutti gli amministratori contemporaneamente.
• Accesso al secondo amministratore e alla rottura del vetro documentati.
• Device Access e Local Service ACL testati per WebAdmin, User Portal, VPN Portal e SSL VPN.
• Accesso da reti di fonti consentite e vietate testate.
• Utente informato sul comportamento password+OTP.
• Processo di ripristino del token documentato per gli smartphone smarriti.
• App Authenticator, algoritmo di hashing e migrazione dei token documentati.
• Accesso remoto testato con clienti reali e profili attuali.
• Timeout RADIUS/Entra testati se viene utilizzato MFA esterno.
• Registri e archiviazione centrale controllati.

Raccomandazione operativa

MFA dovrebbe essere standard per l’accesso amministrativo. MFA è particolarmente importante per WebAdmin, VPN Portal e tutti gli utenti con autorizzazione di accesso remoto.

Per gli ambienti di piccole dimensioni, la funzione OTP di Sophos è spesso sufficiente. Negli ambienti Microsoft 365 o Entra ID, un MFA esterno su RADIUS potrebbe essere più conveniente perché gli utenti non devono apprendere un secondo mondo MFA.

Indipendentemente dalla variante MFA vale quanto segue: limitare prima l’accesso con le regole ACL, testare attentamente Admin-MFA, informare gli utenti su password + token e solo dopo diffonderlo ampiamente.

Domande frequenti