Vai al contenuto
Avanet

Imporre l'uso di Sophos Protected Browser per le applicazioni SaaS

È possibile limitare l’accesso alle applicazioni SaaS critiche in modo che avvenga esclusivamente tramite Sophos Protected Browser. Entra ID o Okta autentica le richieste e, per le applicazioni selezionate, consente solo il traffico proveniente dagli indirizzi IP copiati da un’area del piano dati ZTNA. Di conseguenza, l’accesso da un altro browser viene bloccato.

La procedura sicura si articola in quattro fasi: preparare il provider di identità e le applicazioni, attivare in Sophos Central l’obbligo di utilizzare Protected Browser, registrare presso il provider di identità gli indirizzi IP ZTNA copiati come posizione attendibile e attivare inizialmente la policy di accesso con un ambito limitato. Con Entra ID, limitare gli utenti a un piccolo gruppo pilota. La procedura documentata per Okta, invece, non prevede una selezione di gruppo equivalente: utilizzare un’applicazione pilota dedicata oppure verificare e documentare in anticipo gli utenti assegnati all’applicazione scelta. Scegliere Entra ID o Okta e non applicare entrambe le procedure alla stessa applicazione pilota.

Nella navigazione, Sophos indica questa attività come Globale Einstellungen > Protected Browser erzwingen. Nell’interfaccia descritta, il percorso esatto è Globale Einstellungen > Produkte und Services > Protected Browser > Browserdurchsetzung. La guida ufficiale di Entra ID include anche un video dedicato alla procedura, ma è possibile completare tutti i passaggi seguenti senza guardarlo.

Requisiti, licenze e responsabilità

Prima di apportare la modifica, stabilire chi amministra Sophos Central e chi gestisce il provider di identità. Le fonti approvate non specificano una licenza Sophos separata né un ruolo specifico di Sophos Central per questa procedura. Non desumere quindi autorizzazioni non documentate: l’account responsabile deve poter aprire Globale Einstellungen > Produkte und Services > Protected Browser > Browserdurchsetzung e modificare le impostazioni. Se la voce di menu non è presente o non è modificabile, risolvere il problema di autorizzazione o di accesso al prodotto prima della distribuzione.

Per Entra ID si applicano i seguenti requisiti documentati:

  • Licenza Microsoft Entra ID P1.
  • Entra ID aggiunto come provider di identità federato in Sophos Central.
  • Applicazioni da proteggere aggiunte in Entra ID.
  • SAML configurato in Entra ID per l’autenticazione degli utenti.
  • Privilegi di amministratore per l’account che configura l’imposizione di Protected Browser in Entra ID.

Per Okta si applicano i seguenti requisiti:

  • Okta aggiunto come provider di identità federato in Sophos Central.
  • Applicazioni da proteggere aggiunte in Okta.
  • SAML configurato in Okta per l’autenticazione degli utenti.
  • Privilegi di amministratore per l’account che configura l’imposizione di Protected Browser in Okta.

Per entrambe le varianti è inoltre necessaria un’area selezionabile in Bereich der Datenebene. Questa guida presuppone che l’area ZTNA sia già disponibile, ma non ne descrive la creazione né tratta la gestione generale di ZTNA, delle directory o dei ruoli.

Prima del progetto pilota, annotare: provider di identità selezionato, area ZTNA, elenco IP copiato e applicazione pilota. Per Entra ID, annotare anche gli utenti o il gruppo di test. Per Okta, documentare invece gli utenti assegnati all’applicazione pilota. I menu dei prodotti di terze parti possono cambiare indipendentemente da Sophos. Prima dell’attivazione in produzione, confrontare quindi i percorsi di Entra ID o Okta indicati in questa guida con la documentazione aggiornata del rispettivo produttore.

Configurare Entra ID per imporre l’uso di Protected Browser

Entra ID autentica le richieste indirizzate a login.microsoftonline.com e instrada il traffico consentito attraverso l’area ZTNA selezionata. Limitare il primo test a un’applicazione pilota e a un piccolo gruppo di utenti, in modo da contenere gli effetti di un’eventuale condizione errata.

Attivare Entra ID in Protected Browser

  1. Aprire Globale Einstellungen > Produkte und Services > Protected Browser.
  2. Fare clic su Browserdurchsetzung.
  3. Attivare Entra ID.
  4. In Bereich der Datenebene, selezionare l’area ZTNA da utilizzare per l’autenticazione.
  5. Fare clic su IP-Liste kopieren. Nel passaggio successivo, registrare questi indirizzi IP come posizione denominata.

Importante se l’estensione viene installata in un secondo momento: se l’estensione Protected Browser viene installata dopo aver imposto l’uso di Protected Browser con Entra ID, disattivare Entra ID in questa impostazione e quindi riattivarlo.

Creare una posizione denominata in Entra ID

  1. In Entra ID, aprire Enterprise-Anwendungen > Bedingter Zugriff.
  2. Selezionare Benannte Standorte e fare clic su IP-Bereichsstandort.
  3. Assegnare un nome univoco, ad esempio Sophos-PB-ZTNA-Pilot. Il nome è libero, ma dovrebbe identificare l’area ZTNA associata e il relativo scopo.
  4. Fare clic sul simbolo più e incollare gli indirizzi IP copiati in precedenza con IP-Liste kopieren.
  5. Fare clic su Erstellen.

Confrontare i valori incollati con l’elenco IP annotato. Un elenco obsoleto o incompleto potrebbe bloccare il traffico legittimo di Protected Browser oppure escludere dal blocco una posizione errata.

Creare una policy di accesso condizionale

  1. Rimanere in Enterprise-Anwendungen > Bedingter Zugriff, selezionare Richtlinien e fare clic su Neue Richtlinie.
  2. Assegnare un nome, ad esempio SaaS nur via Protected Browser - Pilot.
  3. Aprire Benutzer > Einbeziehen > Benutzer und Gruppen auswählen, fare clic su Benutzer und Gruppen e selezionare solo gli utenti pilota o il gruppo pilota.
  4. Aprire Zielressourcen > Einbeziehen, fare clic su Ressourcen auswählen e selezionare inizialmente solo l’applicazione pilota.
  5. Aprire Netzwerk e impostare Konfigurieren su Ja.
  6. In Einbeziehen, selezionare Jedes Netzwerk oder jeder Standort.
  7. In Ausschliessen, selezionare Ausgewählte Netzwerke und Standorte, quindi selezionare la posizione denominata creata in precedenza.
  8. Aprire Gewähren, selezionare Zugriff blockieren e fare clic su Auswählen. In questo modo vengono bloccati tutti gli accessi inclusi nella policy che provengono dall’esterno della posizione ZTNA denominata.
  9. Impostare Richtlinie aktivieren su Ein e fare clic su Erstellen.

Prima dell’ultimo passaggio, verificare nuovamente la combinazione di utenti di test, applicazione pilota e posizione ZTNA esclusa dal blocco. Una selezione troppo ampia può bloccare immediatamente l’accesso diretto alle applicazioni SaaS per molti utenti.

Configurare Okta per imporre l’uso di Protected Browser

Per Okta, specificare in Sophos Central il dominio che riceve le richieste di accesso all’applicazione. Okta autentica queste richieste e instrada il traffico consentito attraverso l’area ZTNA selezionata. A differenza della procedura descritta per Entra ID, la policy Okta non viene limitata a un gruppo pilota. Preparare quindi un’applicazione pilota dedicata. Se è invece necessario selezionare un’applicazione già in uso in produzione, verificarne e documentarne esplicitamente le assegnazioni prima di apportare la modifica.

Attivare Okta in Protected Browser

  1. Aprire Globale Einstellungen > Produkte und Services > Protected Browser.
  2. Fare clic su Browserdurchsetzung.
  3. Attivare Okta e inserire il dominio che riceve le richieste di accesso all’applicazione.
  4. In Bereich der Datenebene, selezionare l’area ZTNA prevista.
  5. Fare clic su IP-Liste kopieren. Utilizzare questi indirizzi per creare una zona IP in Okta.

Importante se l’estensione viene installata in un secondo momento: se l’estensione Protected Browser viene installata dopo aver imposto l’uso di Protected Browser con Okta, disattivare Okta e quindi riattivarlo.

Aggiungere una zona IP in Okta

  1. In Okta, aprire Sicherheit > Netzwerke.
  2. Fare clic su Zone hinzufügen e selezionare IP-Zone.
  3. Assegnare un nome, ad esempio Sophos-PB-ZTNA-Pilot.
  4. In Gateway-IPs, incollare gli indirizzi IP dell’area ZTNA copiati da Sophos Central.
  5. Fare clic su Speichern.

Creare una policy di accesso condizionale in Okta

Verificare l’impatto prima della modifica: la regola Catch-all si applica a tutti gli utenti assegnati all’applicazione selezionata. Impostandola su Verweigert per un’applicazione di produzione, si rischia di bloccare l’accesso dall’esterno della zona IP ZTNA consentita per tutti gli utenti assegnati. Procedere solo con un’applicazione pilota dedicata oppure con assegnazioni dell’applicazione verificate e documentate in anticipo.

  1. Aprire Sicherheit > Authentifizierungsrichtlinien e fare clic su App-Anmeldung.
  2. Fare clic su Richtlinie erstellen, assegnare un nome, ad esempio SaaS nur via Protected Browser - Pilot, quindi fare nuovamente clic su Richtlinie erstellen.
  3. In Regeln, accanto a Catch-all-Regel, fare clic su Bearbeiten in Aktionen.
  4. Impostare Dann ist der Zugriff auf su Verweigert e fare clic su Speichern.
  5. Fare clic su Regel hinzufügen e assegnare un nome univoco.
  6. Impostare Die IP des Benutzers ist su In einer der folgenden Zonen e selezionare la zona IP creata in precedenza.
  7. Impostare Dann ist der Zugriff auf su Erlaubt nach erfolgreicher Authentifizierung e fare clic su Speichern.
  8. In Anwendungen, selezionare solo l’applicazione pilota dedicata oppure l’applicazione le cui assegnazioni sono state verificate in precedenza, quindi fare clic su Speichern.

L’ordine delle regole è essenziale per la sicurezza: la regola Catch-all nega l’accesso agli utenti assegnati all’applicazione, mentre la regola aggiuntiva lo consente solo dalla zona contenente gli indirizzi IP ZTNA copiati e dopo la corretta autenticazione.

Verificare il funzionamento con un progetto pilota limitato

Le fonti approvate non indicano un report specifico come prova dell’esito positivo. Verificare quindi l’effettivo comportamento dell’accesso utilizzando esattamente l’utente e l’applicazione inclusi nel progetto pilota:

  1. Disconnettere completamente l’utente di test dall’applicazione pilota, affinché una sessione precedente non alteri il risultato. Con Entra ID, l’utente deve appartenere al gruppo pilota; con Okta, deve essere assegnato all’applicazione pilota dedicata o verificata in precedenza.
  2. Aprire l’applicazione pilota in Protected Browser e autenticare l’utente di test. Dopo la corretta autenticazione, l’accesso deve essere consentito.
  3. Aprire la stessa applicazione in un altro browser con lo stesso utente di test. Questo tentativo di accesso deve essere bloccato.
  4. Verificare che l’ambito rimanga limitato in base al provider: con Entra ID, il comportamento di un utente esterno al gruppo pilota non deve cambiare involontariamente; con Okta, non deve cambiare il comportamento di un’altra applicazione non associata alla policy di autenticazione. Verificare inoltre che le assegnazioni dell’applicazione documentate corrispondano ancora al gruppo di utenti previsto per il progetto pilota.
  5. Documentare l’area ZTNA selezionata e confrontare nuovamente l’elenco IP registrato presso il provider di identità con quello ottenuto tramite IP-Liste kopieren.

Il token di autenticazione viene gestito dal provider di identità. Gli eventuali controlli di sessione per l’accesso condizionale configurati presso il provider hanno la precedenza. Ad esempio, se la frequenza di accesso è impostata su due giorni, la sessione termina dopo due giorni. Se il provider di identità non prevede alcun controllo di sessione, Sophos indica che Protected Browser applica una scadenza predefinita di sette giorni. Un token già esistente può quindi far apparire il risultato di un test diverso da quello ottenuto con un nuovo accesso.

Risoluzione dei problemi in base al sintomo

Un altro browser riesce ancora ad accedere

Verificare innanzitutto che l’utente di test e l’applicazione SaaS corretta siano effettivamente inclusi nella policy. Confrontare quindi la zona IP o la posizione denominata configurata presso il provider di identità con l’elenco IP corrente copiato da Sophos Central. In Entra ID, includere Jedes Netzwerk oder jeder Standort, escludere la posizione ZTNA denominata e selezionare Zugriff blockieren per tutti gli altri accessi. In Okta, la regola Catch-all deve negare l’accesso e la regola di autorizzazione deve essere limitata alla zona IP creata.

Terminare le sessioni esistenti dell’applicazione ed eseguire il test con un nuovo accesso. Se l’accesso rimane possibile, non estendere il progetto pilota e verificare presso il provider di identità come viene valutata la policy. Le fonti non documentano ulteriori opzioni Sophos da utilizzare per aggirare una regola errata di terze parti.

Anche Protected Browser viene bloccato

Confrontare, carattere per carattere, gli indirizzi IP ottenuti tramite IP-Liste kopieren con quelli della posizione denominata o di Gateway-IPs. Verificare inoltre che in Sophos Central sia selezionata la stessa voce di Bereich der Datenebene i cui indirizzi sono stati registrati presso il provider di identità. Controllare quindi SAML, l’applicazione selezionata e l’utente di test in base ai requisiti.

Se l’estensione Protected Browser è stata installata in un secondo momento, disattivare in Sophos Central il provider configurato e quindi riattivarlo. Questa operazione è espressamente richiesta sia per Entra ID sia per Okta. Non modificare contemporaneamente l’area ZTNA, l’elenco IP e la policy di accesso, altrimenti non sarà possibile isolare chiaramente la causa.

Le sessioni terminano prima o dopo il previsto

Verificare i controlli di sessione e la frequenza di accesso nel provider di identità. Questi valori hanno la precedenza sul comportamento delle sessioni di Protected Browser. La scadenza predefinita documentata di sette giorni si applica solo se non è configurato alcun controllo di sessione.

I menu o i nomi dei campi di terze parti sono diversi

Entra ID e Okta sono prodotti di terze parti. Se un menu o un controllo non è identificabile con certezza, non salvare una regola soltanto perché sembra equivalente. Confrontare la procedura con la documentazione aggiornata del rispettivo provider oppure rivolgersi all’amministrazione o al supporto del provider. La misura temporanea più sicura consiste nel non estendere la distribuzione in produzione oltre l’ambito pilota già testato con successo: il gruppo pilota per Entra ID oppure le assegnazioni dell’applicazione dedicata o verificata in precedenza per Okta.

Rollback e disattivazione sicuri

Le fonti pubblicate non documentano una procedura completa di eliminazione, disattivazione o rollback. Non eliminare quindi per primi la posizione, la zona IP o la connessione SAML: la regola di blocco potrebbe rimanere attiva senza l’eccezione necessaria.

Per ogni rollback, attenersi al seguente quadro di sicurezza:

  1. Interrompere qualsiasi estensione della distribuzione e registrare l’utente pilota, l’applicazione pilota, il provider di identità, l’area ZTNA e l’elenco IP. Per Entra ID, registrare anche il gruppo pilota; per Okta, le assegnazioni correnti dell’applicazione.
  2. Consultare la documentazione aggiornata di Entra ID o Okta per individuare il metodo supportato con cui disattivare in modo controllato la policy di accesso specifica.
  3. Disattivare esclusivamente la policy pilota, utilizzando il metodo confermato. Disconnettere completamente l’utente pilota dall’applicazione e autenticarlo di nuovo. L’applicazione pilota dovrebbe tornare accessibile sia in Protected Browser sia in un altro browser, a meno che un’altra policy di accesso non lo impedisca. Con Entra ID, l’accesso di un utente esterno al gruppo pilota deve rimanere invariato; con Okta, deve rimanere invariato l’accesso a un’altra applicazione non associata alla policy pilota.
  4. Confrontare i risultati effettivi con quelli attesi. Se anche un solo risultato è diverso, interrompere il rollback e non eliminare altre policy, posizioni, zone IP o assegnazioni delle applicazioni. Verificare invece la valutazione corrente delle policy e rivolgersi all’amministrazione responsabile o al supporto del provider.
  5. Rimuovere la posizione denominata o la zona IP solo dopo aver ottenuto il risultato previsto e aver verificato che nessuna policy attiva vi faccia ancora riferimento.
  6. Disattivare l’imposizione del browser in Sophos Central o rimuovere i componenti relativi all’identità federata, a SAML o a ZTNA solo attenendosi alle rispettive procedure operative approvate.

Se non è possibile confermare con certezza il metodo di disattivazione supportato dal provider di identità, interrompere la procedura e richiedere assistenza. Per una policy che blocca l’accesso alle applicazioni SaaS, procedere per tentativi non costituisce un rollback sicuro.

Gestione operativa e ciclo di vita

Considerare l’imposizione di Protected Browser come una modifica coordinata di Sophos Central, del piano dati ZTNA e del provider di identità. Dopo una modifica dell’area ZTNA o dei relativi indirizzi IP, confrontare nuovamente l’elenco registrato presso il provider di identità ed eseguire un test con un utente dell’ambito limitato. Ripetere la verifica anche dopo modifiche a SAML, alle applicazioni protette, alle assegnazioni di utenti o gruppi e ai controlli di sessione.

Includere questa verifica anche nella revisione periodica delle policy di Entra ID o Okta. Accertarsi che il responsabile, le applicazioni selezionate, gli utenti interessati, la posizione di riferimento e l’elenco IP documentato siano ancora coerenti tra loro. Se viene installata l’estensione Protected Browser, trattare la riattivazione del relativo provider di identità come una modifica separata, seguita da un test positivo e da uno negativo.

Le fonti non specificano una durata generale, una data di migrazione o un comportamento di fine vita per questa configurazione. Basare quindi tali decisioni sulla documentazione aggiornata del prodotto e del produttore, non su presupposti storici.

Guide correlate

Gli oggetti delle policy, la configurazione generale di ZTNA, la gestione dei ruoli, la sincronizzazione delle directory e l’installazione o la rimozione dell’estensione Protected Browser sono attività operative distinte. Questa guida non ne ripete intenzionalmente le procedure. Utilizzare il relativo articolo di riferimento non appena sarà disponibile nella versione corrente della knowledge base.