Sophos Protected Browser: risoluzione dei problemi di accesso e login

Questo runbook aiuta a circoscrivere i problemi di accesso con Protected Browser e le risorse RDP/SSH ZTNA agentless. In Sophos Central, aprire Meine Produkte > Protected Browser e partire dal sintomo visibile. Correggere solo la causa confermata dalle verifiche. Modifiche estese al DNS, alla directory utenti o a ZTNA rendono più difficile la diagnosi.

Percorso rapido: Se l’aggiunta o la modifica di una risorsa non riesce, verificare gli indirizzi email di tutti i membri del gruppo di utenti utilizzato. Se una risorsa esistente non è raggiungibile senza un messaggio di errore specifico, testare prima il portale utente ZTNA e poi la risoluzione DNS dell’FQDN del gateway ZTNA. In caso di “Netzwerk nicht erreichbar” o “Verbindung konnte nicht hergestellt werden”, confrontare direttamente il provider di identità configurato in ZTNA con il metodo di login della sessione Protected Browser. Se il login a Protected Browser non riesce, verificare l’accesso a Self Service Portal e che l’indirizzo email sia univoco tra i tenant. Il messaggio “Hostschlüsselüberprüfung fehlgeschlagen” va gestito separatamente.

Prerequisiti e limiti operativi di sicurezza

Le verifiche descritte richiedono un ambiente Protected Browser e ZTNA già configurato e un utente interessato chiaramente identificato. L’assenza di menu o autorizzazioni non dimostra una specifica causa legata alla licenza o al ruolo. In questo caso, affidare la verifica all’amministratore Sophos Central responsabile.

Per verificare l’utente in Sophos Central è necessario accedere a Meine Umgebung > Benutzer und Gruppen > Benutzer. Per il test di raggiungibilità devono essere noti l’FQDN del gateway ZTNA effettivamente configurato e il tipo di gateway: Sophos Cloud Gateway o gateway locale. Nel comando, sostituire il segnaposto con l’FQDN del gateway ZTNA, non con il nome di una risorsa RDP/SSH di destinazione.

Durante la diagnosi, modificare un solo valore alla volta e ripetere poi il test con lo stesso utente e lo stesso dispositivo. Se un prerequisito non è chiaro o non è possibile accedere alla gestione utenti, interrompere la diagnosi e affidare il caso all’amministratore Sophos Central, del servizio directory o ZTNA responsabile.

Risoluzione dei problemi per sintomo

L’aggiunta o la modifica di una risorsa RDP/SSH agentless non riesce

Causa probabile: Almeno un membro del gruppo di utenti utilizzato non dispone di un indirizzo email valido. Ciò può interessare sia una risorsa ZTNA sia una risorsa RDP/SSH in un gruppo di applicazioni Protected Browser.

Verifica:

Aprire Meine Umgebung > Benutzer und Gruppen > Benutzer.
Nella colonna E-Mail, verificare tutti gli utenti del gruppo da assegnare alla risorsa o al gruppo di applicazioni.

Risultato atteso: Ogni utente del gruppo interessato dispone di un indirizzo email valido. Una voce vuota conferma la condizione di errore.

Intervento sicuro: Aggiungere l’indirizzo mancante nel servizio directory autorevole. Aggiungerlo direttamente in Sophos Central solo per gli utenti creati manualmente in Sophos Central. Non modificare gli indirizzi esistenti sulla base di supposizioni.

Nuova convalida: Ripetere l’aggiunta o la modifica della stessa risorsa senza cambiare il gruppo. Se l’operazione continua a non riuscire nonostante la colonna E-Mail sia completa, questa causa non è confermata. Invece di modificare altri dati di identità, registrare il tipo di risorsa, il gruppo, l’ora e il messaggio visibile, quindi eseguire l’escalation del caso.

La risorsa RDP/SSH agentless non è raggiungibile tramite Protected Browser

Causa probabile: Il dispositivo non riesce a risolvere correttamente l’FQDN del gateway ZTNA. Il primo punto di separazione è tuttavia il portale utente ZTNA: se anche questo non è raggiungibile tramite Protected Browser, il problema si verifica prima della singola risorsa RDP/SSH.

Verifica:

Sullo stesso dispositivo e con lo stesso utente, provare ad aprire il portale utente ZTNA tramite Protected Browser.
Se il portale non è raggiungibile, eseguire una query DNS sul dispositivo interessato:

nslookup <ZTNA-Gateway-FQDN>

Sostituire <ZTNA-Gateway-FQDN> con il nome del gateway effettivamente configurato. nslookup è un test di sola lettura e non modifica alcuna configurazione.

Risultato atteso: Con un Sophos Cloud Gateway, il nome del gateway viene risolto nell’indirizzo del proxy del gateway. Con un gateway locale, viene risolto nell’indirizzo del gateway ZTNA configurato sul proprio server DNS. Confrontare la risposta con la destinazione effettivamente configurata per il relativo modello di gateway. Se la risoluzione non riesce, occorre verificare la configurazione DNS. Una risposta diversa conferma un errore solo se non corrisponde alla destinazione configurata. Se la destinazione prevista non è nota, non modificare il DNS e affidare la verifica al responsabile DNS/ZTNA.

Intervento sicuro: Correggere la configurazione DNS mediante la procedura DNS/ZTNA prevista. La zona e la destinazione corrette dipendono dal modello di gateway; pertanto, non eseguire qui modifiche DNS generiche.

Nuova convalida: Dopo che il responsabile DNS/ZTNA ha confermato una correzione secondo la procedura prevista, eseguire nuovamente la stessa query nslookup. Aprire quindi il portale utente ZTNA e solo dopo testare la risorsa RDP/SSH originale. Se la risposta DNS è quella attesa e il portale è raggiungibile, ma la risorsa non lo è ancora, documentare questi due controlli positivi ed eseguire l’escalation della verifica ZTNA specifica per la risorsa.

“Netzwerk nicht erreichbar” o “Verbindung konnte nicht hergestellt werden”

Causa probabile: ZTNA utilizza un provider di identità come Okta o Entra ID, ma l’utente ha effettuato il login a Protected Browser con il proprio Sophos ID o come utente locale. Durante l’accesso a un’applicazione SSH o RDP dietro il gateway ZTNA possono quindi comparire i messaggi indicati.

Verifica: Individuare il provider di identità configurato in ZTNA e confrontarlo con il metodo di login della sessione Protected Browser corrente.

Risultato atteso: La causa è confermata se ZTNA utilizza un provider di identità, ma la sessione Protected Browser non è stata autenticata tramite tale provider.

Intervento sicuro: Terminare la sessione interessata ed effettuare il login dell’utente a Protected Browser tramite il provider di identità configurato in ZTNA. Non modificare il provider di identità ZTNA per aggirare un singolo errore di login.

Nuova convalida: Nella sessione appena autenticata, aprire la stessa applicazione SSH o RDP. Se il messaggio persiste nonostante i metodi di login corrispondano, registrare provider di identità, utente, risorsa e ora, quindi affidare il caso al responsabile ZTNA.

Qui occorre verificare due cause indipendenti. Non correggerle contemporaneamente, in modo che sia possibile identificare la causa effettiva.

Manca l’accesso a Self Service Portal

Verifica: Aprire Meine Umgebung > Benutzer und Gruppen > Benutzer e controllare la colonna Rolle per l’utente interessato. In alternativa, selezionare il nome utente e verificare il testo sotto l’immagine del profilo.

Risultato atteso: Se è disponibile l’accesso a Sophos Central Self Service Portal, nella colonna Rolle o sotto l’immagine del profilo compare SelfService.

Intervento sicuro: Se SelfService non è presente, affidare l’assegnazione dell’accesso a Self Service Portal all’amministratore Sophos Central responsabile.

Nuova convalida: Confermare prima la visualizzazione di SelfService, quindi ripetere il login con lo stesso utente.

L’indirizzo email è collegato a più account Sophos Central

Verifica: Stabilire se l’indirizzo email dell’utente interessato è assegnato a più account Sophos Central.

Risultato atteso: L’indirizzo non deve essere collegato a più account Sophos Central.

Intervento sicuro: Fare correggere l’assegnazione dall’amministratore tenant o delle identità responsabile. Senza un tenant di destinazione confermato, non eliminare alcun utente e non modificare alcun indirizzo di produzione.

Nuova convalida: Dopo la conferma dell’assegnazione univoca, ripetere il login a Protected Browser. Se non riesce ancora, documentare SelfService, l’assegnazione dell’email, l’ora e il messaggio visibile ai fini dell’escalation.

SSH segnala “Hostschlüsselüberprüfung fehlgeschlagen”

Causa probabile: La chiave memorizzata nel client SSH non corrisponde più alla chiave dell’host. Ciò può avvenire dopo una modifica legittima, come una reinstallazione, ma lo stesso messaggio può anche indicare una modifica imprevista.

Verifica: Ottenere l’impronta digitale prevista della chiave host dal responsabile del sistema tramite un canale indipendente e attendibile, quindi confrontarla con l’impronta digitale dell’host di destinazione corretto. Non fare affidamento né sulla connessione SSH non riuscita né sulla nuova chiave proposta in tale connessione. Se l’impronta prevista non è stata confermata in modo indipendente, non corrisponde o la modifica non è spiegabile, fermarsi a questo punto ed eseguire l’escalation come evento di sicurezza.

Risultato atteso: L’host di destinazione, la modifica legittima della chiave e l’impronta digitale prevista sono confermati in modo indipendente e inequivocabile.

Intervento sicuro: Prima di eliminare qualsiasi elemento, stabilire quali voci rimuove la funzione proposta dal client SSH. Sophos indica Bekannte Hosts löschen come esempio, ma non conferma che questa funzione rimuova solo l’host interessato. Se l’ambito dell’eliminazione è sconosciuto o non è possibile confermare in modo indipendente l’impronta prevista, non eseguire alcun reset ed effettuare l’escalation. Rimuovere la chiave memorizzata solo dopo aver chiarito l’ambito e confermato l’impronta. Alla connessione successiva, accettare solo la chiave la cui impronta corrisponde alla conferma indipendente.

Nuova convalida: Stabilire nuovamente la connessione. La verifica della chiave host deve riuscire con la chiave appena accettata. Se il messaggio ricompare o la chiave cambia di nuovo in modo imprevisto, non rimuovere ripetutamente le voci; eseguire l’escalation indicando nome host, ora e client SSH.

Ripristino, escalation e limiti operativi

Non esiste un rollback universale per questi problemi. Per tornare indietro in sicurezza, evitare modifiche estese e documentare il valore iniziale di ogni assegnazione utente modificata in modo mirato. Se l’intervento non risolve il problema, fermarsi al relativo punto di escalation. L’eliminazione delle chiavi host SSH note non è un reset generale ed è accettabile solo con un’impronta digitale confermata in modo indipendente e un ambito di eliminazione noto.

Per un’escalation interna o al supporto, registrare almeno il sintomo, l’utente, il dispositivo, il tipo di risorsa, il modello di gateway, l’FQDN del gateway ZTNA, l’ora e il risultato della verifica direttamente correlata. Credenziali, chiavi private e token non devono essere inseriti nel ticket.

Ripetere solo la verifica associata all’intervento effettivamente eseguito o al passaggio di responsabilità confermato: aggiungere o modificare nuovamente la risorsa dopo la correzione dell’email; effettuare il login dopo la conferma dell’accesso a Self Service Portal o dell’assegnazione univoca dell’account; aprire la risorsa dopo il login tramite il provider di identità configurato; oppure stabilire la connessione SSH dopo il reset controllato della chiave host. Dopo il passaggio al responsabile DNS/ZTNA, ripetere nslookup, il test del portale utente e quello della risorsa originale solo quando il responsabile ha confermato una correzione secondo la propria procedura.

Delimitazione rispetto alle guide correlate

Questo runbook tratta esclusivamente i sintomi di Protected Browser descritti qui. La configurazione di Protected Browser o dell’estensione e la configurazione generale di DNS e ZTNA rientrano nelle rispettive guide di configurazione. Se è necessaria una configurazione di questo tipo, affidare il caso all’amministratore responsabile.