Sophos Protected Browser: configurare utenti e accesso

Ogni utente di Sophos Protected Browser deve disporre di tre elementi: un oggetto utente in Sophos Central, un metodo di accesso appropriato e l’accesso al Sophos Self Service Portal (SSP), ossia il portale self-service Sophos. La sequenza più sicura consiste quindi nello scegliere l’origine degli utenti, eseguirne il provisioning, configurare l’accesso federato se si usa un provider di identità cloud, scegliere il metodo di accesso Sophos e, solo a quel punto, abilitare l’accesso all’SSP.

Prerequisiti, licenza e ruoli

Prima di apportare modifiche, verificare quanto segue:

Accesso al prodotto: Protected Browser deve essere disponibile nel tenant previsto in My Products > Protected Browser. Questa guida non documenta SKU separati né procedure per ottenere una licenza di prova. Se la voce di menu non è presente, interrompere la procedura e far verificare l’abilitazione del tenant, senza formulare ipotesi sulla licenza.
SSP: tutti gli utenti di Protected Browser devono poter accedere al portale self-service Sophos.
Origine degli utenti: gli utenti gestiti manualmente possono integrare quelli provenienti da una directory, ad esempio per includere persone non presenti nel servizio directory. Gli utenti dello stesso dominio non devono però essere sincronizzati contemporaneamente sia da AD sia da Entra ID.
Ruolo: per verificare un dominio federato e configurare un provider di identità è necessario un Super Admin. Le origini directory vengono configurate da un amministratore della console Sophos Central. È necessario un Super Admin anche per assegnare un ruolo amministrativo durante la creazione manuale di un utente. Per chi usa soltanto Protected Browser è sufficiente il ruolo User, che consente esclusivamente l’accesso all’SSP. La guida Assegnare correttamente i ruoli amministrativi di Sophos Fusion descrive i limiti dei ruoli amministrativi.
Utente pilota: predisporre un singolo utente di prova con un indirizzo email raggiungibile. In Entra ID, Email e User principal name devono coincidere. Protected Browser non supporta Google Directory.

Se si usa Okta, sincronizzare prima gli utenti Okta con Active Directory e successivamente AD con Sophos Central. Le dipendenze generali relative alle identità e a ZTNA sono descritte in Configurare Sophos ZTNA: panoramica e sequenza; questo articolo tratta soltanto la catena di utenti e accesso necessaria per Protected Browser.

Scegliere un’origine e predisporre gli utenti

Opzione A: creare manualmente singoli utenti

Questa opzione è adatta a un progetto pilota di piccole dimensioni o a persone non presenti nel servizio directory.

Aprire My Environment > Users & Groups.
Fare clic su Add user.
In First and last name, inserire il nome senza il nome di dominio.
In Role, selezionare User per un normale utente di Protected Browser. Assegnare un ruolo amministrativo soltanto se la persona dovrà effettivamente amministrare Central.
Se necessario, specificare il Manager.
Aggiungere l’indirizzo email e salvare l’utente con Save.

Il nome dell’utente pilota può essere scelto liberamente e non costituisce una chiave tecnica. Ai fini dell’invito e dell’accesso è essenziale disporre di un indirizzo email corretto e raggiungibile.

Opzione B: sincronizzare Active Directory

La sincronizzazione completa di AD è un’attività condivisa di gestione delle identità e non viene riproposta come procedura separata in questo articolo. Per la scelta relativa a Protected Browser è tuttavia importante rispettare i limiti seguenti:

Nel computer usato per la sincronizzazione deve essere installato .NET Framework 4.6.2.
Sono necessarie credenziali API Sophos con il ruolo API Service Principal Active Directory Sync. Limitare l’accesso allo stretto necessario.
Ogni utente da sincronizzare deve disporre di un indirizzo email. Il firewall o il proxy devono consentire i domini richiesti da Sophos.
Gli utenti e gli indirizzi email devono essere univoci all’interno di ciascun account Sophos Central. Non sono supportati più client AD appartenenti allo stesso dominio o sottodominio.
Gli utenti e i gruppi di utenti vengono sincronizzati insieme; non è possibile sincronizzare soltanto uno dei due tipi di oggetto.

Nota operativa: Sophos consiglia di rimuovere da AD gli utenti e i dispositivi inattivi. Un filtro AD può impedire la sincronizzazione degli utenti inattivi, ma non elimina il rischio per la sicurezza rappresentato dall’account AD ancora esistente. Inoltre, le modifiche alle basi di ricerca o ai filtri possono escludere dall’ambito di ricerca utenti e gruppi Central creati in precedenza, provocandone la rimozione da Sophos Central. Verificare quindi l’ambito previsto prima di apportare modifiche.

Opzione C: aggiungere Microsoft Entra ID

Per Entra ID sono necessari un amministratore della console Sophos Central, una sottoscrizione Microsoft Azure con Entra ID, l’autorizzazione Directory.Read.All e un’applicazione Azure. Annotare Tenant domain, Application ID, il Value del segreto client e la relativa data di scadenza.

Prima di iniziare, tenere presenti i limiti seguenti:

Office 365 GCC High non è supportato per questa sincronizzazione.
Per ogni dominio è possibile configurare una sola origine Entra ID.
Gli utenti o gli indirizzi email non devono essere sincronizzati con più account Sophos Central.
La sincronizzazione degli utenti dello stesso dominio non deve essere eseguita in parallelo da AD ed Entra ID.
Gli utenti e i gruppi Central esistenti che non hanno un oggetto Entra ID corrispondente devono essere gestiti manualmente.

Per aggiungere l’origine:

Aprire Global Settings > Platform > Directory service.
Fare clic su Add Microsoft Entra ID.
Inserire Name e Description dell’origine, quindi il relativo Domain.
Fare clic su Next.

Le fasi successive della sincronizzazione della directory restano di competenza del team centrale che gestisce le identità, che dovrà usare i valori Azure verificati in precedenza. Se un’applicazione Azure esistente dispone soltanto della precedente autorizzazione Microsoft Entra ID Graph Directory.Read.All, prima di modificare la sincronizzazione occorre aggiungere l’autorizzazione Microsoft Graph Directory.Read.All.

Configurare l’accesso federato

Seguire questa sezione se gli utenti accedono tramite un provider di identità cloud. I passaggi devono essere eseguiti da un Super Admin. Prima di cambiare metodo, assicurarsi che tutti gli amministratori e gli utenti siano assegnati a un dominio e dispongano di un provider di identità. In caso contrario, l’accesso federato non deve ancora essere reso disponibile come opzione di accesso.

1. Verificare il dominio federato

Aprire Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
Fare clic su Verify domains.
In Federated domains, selezionare Add domain.
Inserire Domain name e Description, quindi fare clic su Save.
Nella finestra Verify domain ownership, usare Copy per copiare il TXT record visualizzato, quindi selezionare Cancel.
Pubblicare il record TXT nel DNS. La propagazione può richiedere fino a 24 ore.
Tornare a Sign-in and Identity > Sophos Sign-in > Verify domains. In corrispondenza del Verification Status pertinente, fare clic su Verify domain ownership, verificare i dettagli e selezionare Verify.

Il passaggio è riuscito quando il dominio compare in Federated domains con una data di verifica. La verifica è valida per un anno e può essere ripetuta durante tale periodo.

2. Aggiungere un provider di identità

Aprire Global Settings > Access Control > Sign-in and Identity > Federated identity providers e fare clic su Add identity provider. Assegnare un nome privo di caratteri speciali come ., @ o #, altrimenti non sarà possibile salvare la configurazione.

Selezionare quindi l’opzione appropriata:

Microsoft Entra ID: in Type e Vendor, selezionare in entrambi i casi Microsoft Entra ID, inserire il Tenant ID in Configure Entra ID settings e selezionare il dominio verificato in Configure domains.
OpenID Connect, ad esempio Okta: selezionare OpenID Connect e il provider. In Configure OpenID Connect settings, inserire Client ID, Issuer, Authz endpoint e JWKS URL. Selezionare quindi il dominio verificato.
Microsoft AD FS: selezionare Microsoft AD FS, il provider e AD FS metadata URL. Selezionare quindi il dominio, salvare con Save e riportare i valori Entity ID e Callback URL visualizzati nella configurazione di AD FS.

È possibile aggiungere più domini a un provider, ma ogni utente può essere assegnato a un solo dominio. Specificare inoltre quale sistema deve applicare l’MFA:

IdP enforced MFA: il provider di identità applica l’MFA.
No IdP enforced MFA: Sophos Central applica l’MFA dopo che l’autenticazione tramite IdP è riuscita.

Fare clic su Save, selezionare il provider nell’elenco e fare clic su Turn on. Central consente l’attivazione soltanto quando la configurazione è completa e le informazioni sono valide.

3. Scegliere il metodo di accesso Sophos

Aprire Global Settings > Access Control > Sign-in and Identity > Sophos sign-in settings.
Selezionare una sola opzione:
- Federated credentials only se si usa esclusivamente un provider di identità cloud e non sono stati creati manualmente utenti in Sophos Central.
- Sophos Fusion Admin or Federated credentials se, oltre al provider di identità cloud, sono presenti utenti creati manualmente.
Fare clic su Save.

La seconda opzione non è in assoluto una modalità «più sicura», ma è la scelta necessaria in presenza di utenti provenienti da origini diverse. Prima di estendere la modifica ad altri utenti, annotare la modalità precedente e verificare innanzitutto l’utente pilota.

Abilitare l’accesso all’SSP

Scegliere il metodo di abilitazione in base al piano di distribuzione. Per concedere l’accesso all’SSP a tutti gli utenti sincronizzati, abilitare l’accesso generale prima della sincronizzazione della directory. Se invece deve iniziare soltanto un gruppo selezionato, eseguire prima la sincronizzazione e inviare poi l’email di configurazione esclusivamente a quel gruppo.

Accesso per tutti gli utenti

Aprire Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
In User Access, abilitare Sophos Fusion Self Service Portal access.

In questo modo tutti gli utenti, compresi quelli sincronizzati da un servizio directory, ottengono l’accesso all’SSP e ricevono un’email di benvenuto con le informazioni necessarie per accedere.

Accesso soltanto per utenti selezionati

Aprire My Environment > Users & Groups > Users.
Selezionare gli utenti previsti per il progetto pilota e fare clic su Email Setup Link.
In Other Emails, selezionare Sophos Fusion Self Service Welcome/Setup Email.
Fare clic su Save.

Anche con questa opzione, gli utenti selezionati ricevono un’email di benvenuto con le informazioni necessarie per accedere.

Eseguire la verifica con un utente pilota

Verificare la catena nello stesso ordine in cui è stata configurata:

L’utente compare una sola volta in My Environment > Users & Groups > Users e dispone dell’indirizzo email previsto.
Se si usa l’accesso federato, il dominio compare in Federated domains con una data di verifica e il provider di identità è attivo.
In Sophos sign-in settings è salvata la modalità adatta all’insieme di utenti.
L’utente pilota riceve l’email di benvenuto dell’SSP e può seguire la procedura di accesso indicata nel messaggio.
Estendere lo stesso metodo ad altri utenti soltanto dopo l’esito positivo di questa verifica.

Se uno di questi risultati non si verifica, non estendere la distribuzione. Controllare prima il componente immediatamente precedente: ad esempio, la corretta verifica del dominio non dimostra che il provider di identità sia attivo o che sia stato concesso l’accesso all’SSP.

Risoluzione dei problemi in base al sintomo

Il dominio federato non può ancora essere verificato

Controllare che il record TXT copiato sia stato pubblicato esattamente nella zona DNS corretta. Attendere quindi il tempo di propagazione documentato, fino a 24 ore, e avviare nuovamente Verify domain ownership. Se non è ancora presente una data di verifica, non procedere con l’attivazione dell’IdP.

Il provider di identità non può essere salvato o attivato

Se non è possibile salvare, rimuovere dal nome i caratteri speciali come ., @ o #. Se Turn on non è disponibile, la configurazione è incompleta o contiene dati non validi. A seconda del tipo di provider, controllare Tenant ID, gli endpoint OIDC oppure AD FS metadata URL, oltre al dominio selezionato.

Il test della connessione Entra segnala un ID client non valido

Controllare che nel campo Client ID sia stato effettivamente inserito l’Application ID dell’applicazione Azure. Sophos indica inoltre come possibile causa il fatto che l’accesso degli utenti sia disabilitato nel centro di amministrazione di Microsoft Entra ID. Correggere innanzitutto questi due aspetti; non creare per precauzione una seconda origine per lo stesso dominio.

Alcuni utenti mancano o compaiono due volte

Per AD, controllare innanzitutto che l’account sia attivo, disponga di un indirizzo email e rientri nella base di ricerca o nel filtro selezionato. In Entra ID, agli oggetti Central esistenti deve corrispondere un oggetto Entra ID. Possono comparire utenti duplicati se l’UPN sincronizzato da Entra ID non corrisponde alle credenziali usate dall’utente per accedere all’endpoint. Correggere prima l’origine, l’UPN e l’associazione dell’indirizzo email, anziché abilitare l’accesso all’SSP per entrambi gli oggetti.

L’utente non riceve l’email di benvenuto dell’SSP

Controllare quale delle due opzioni di abilitazione è stata usata. Per l’accesso generale deve essere attiva l’opzione Sophos Fusion Self Service Portal access; per un progetto pilota mirato, l’opzione Sophos Fusion Self Service Welcome/Setup Email deve essere stata salvata per quello specifico utente. Controllare quindi l’indirizzo email memorizzato per l’utente. Se queste impostazioni sono corrette ma l’email non arriva, il percorso diagnostico verificato termina qui: inoltrare il problema relativo alla consegna al supporto, senza modificare per tentativi le impostazioni di accesso o i ruoli.

Ripristino sicuro e rimozione degli utenti

Questa guida non documenta una procedura generale per rimuovere l’accesso a Protected Browser né un ripristino completo dopo una modifica della federazione. Procedere quindi in modo circoscritto e reversibile:

Prima della modifica, annotare il valore attuale in Sophos sign-in settings e l’ambito del progetto pilota.
Se l’utente pilota non riesce a completare l’accesso, interrompere la distribuzione. Finché è disponibile una sessione amministrativa funzionante, ripristinare nella stessa finestra la modalità di accesso precedente annotata e salvare.
Verificare nuovamente la procedura di accesso precedente. Non rimuovere il dominio federato né il provider di identità finché le relative dipendenze non sono state esaminate al di fuori di questa guida.
Quando si rimuovono utenti da AD, eliminare dalla directory autorevole gli utenti e i dispositivi inattivi. Escluderli dalla sincronizzazione riduce la quantità di dati trasferiti, ma non elimina l’account AD inattivo né il relativo rischio per la sicurezza.
Questa procedura non fornisce alcun metodo verificato per revocare l’accesso all’SSP a singoli utenti o a tutti gli utenti. Interrompere qui le operazioni e verificare la procedura attuale nel tenant o con il supporto Sophos, senza tentare azioni di eliminazione o disattivazione non documentate.

Gestione ordinaria

Verificare regolarmente quanto segue:

Dominio federato: monitorare la data di verifica; la verifica è valida per un anno e può essere rinnovata prima della scadenza.
Entra ID: annotare la data di scadenza del segreto client. Prima di apportare modifiche, assicurarsi che sia presente l’autorizzazione Microsoft Graph Directory.Read.All.
AD: individuare e rimuovere regolarmente gli account e i dispositivi inattivi dalla directory autorevole. Prima di modificare i filtri, verificare che le modifiche non causino rimozioni involontarie da Sophos Central.
Copertura delle identità: assicurarsi che ogni amministratore e utente interessato rimanga assegnato a un solo dominio e a un provider di identità valido.
Accesso all’SSP: per ogni nuovo ingresso, cambio di ruolo o uscita, verificare che l’origine dell’utente, la modalità di accesso e l’abilitazione all’SSP siano ancora coerenti.
Progetto pilota prima di modifiche estese: testare le modifiche all’origine, al dominio, all’IdP o alla modalità di accesso prima con un singolo utente pilota e distribuirle solo dopo aver ottenuto il risultato previsto.