Configurare Sophos ZTNA: runbook di configurazione completo

Sophos Zero Trust Network Access, o ZTNA, controlla l’accesso ad applicazioni e siti interni tramite identità, gruppi e policy. Una configurazione completa richiede un servizio directory, un identity provider, un gateway, un progetto per certificati e DNS, policy e risorse. Le applicazioni locali richiedono un agente ZTNA; le applicazioni web possono essere pubblicate senza agente.

Questo runbook descrive l’architettura complessiva e l’ordine corretto. Non sostituisce la pianificazione dettagliata del gateway né i runbook specifici per domain controller, RDP o SSH. Inizia con una sola applicazione, un gruppo pilota e un percorso di ripristino documentato. Estendi l’ambito solo dopo il superamento dei test positivo e negativo.

Risposta diretta: l’ordine corretto

Configura Sophos ZTNA in questo ordine:

Verifica licenza, accesso amministrativo, piattaforme e applicazione target.
Definisci tipo di accesso e modalità gateway.
Sincronizza utenti e gruppi di sicurezza da Microsoft Entra ID o Active Directory.
Configura l’identity provider e verificane la connessione.
Predisponi certificato wildcard, dominio e gateway.
Configura la risoluzione DNS pubblica e privata.
Crea una policy ZTNA limitata.
Distribuisci l’agente ZTNA solo dove richiesto dal tipo di accesso.
Crea la risorsa con una sola policy e i gruppi previsti.
Verifica accessi autorizzati e non autorizzati e i log.
Solo dopo migra altri utenti, applicazioni e sedi.

Sophos Fusion è il piano di gestione. Gateway, agente, directory, identity provider, certificato, DNS, policy e risorsa rimangono dipendenze tecniche distinte. Un login riuscito non dimostra quindi che l’applicazione sia raggiungibile o correttamente limitata.

Prerequisiti, licenza e ruoli

Licenza e prova

Sophos ZTNA fa parte di Sophos Workspace Protection. La licenza è disponibile come abbonamento autonomo, tramite MSP Flex o nel pacchetto Sophos Endpoint Plus Workspace Protection. Per Workspace Protection, la quantità richiesta dipende dal consumo più alto tra i prodotti inclusi; per ZTNA si contano gli utenti univoci autenticati entro 30 giorni. Lo stesso tipo di licenza copre accesso con e senza agente e gateway locali e Sophos Cloud Gateway.

La licenza Workspace Protection autonoma non include una licenza Sophos Endpoint. L’accesso con agente richiede quindi anche un entitlement Endpoint applicabile e la possibilità di installare Sophos Endpoint Agent. Questo è distinto dal fatto che la licenza ZTNA copra entrambe le modalità.

Sophos Cloud Gateway prevede inoltre un limite medio di trasferimento di 15 GB per utente al mese. Una licenza di prova dura normalmente 30 giorni. Un tenant di prova consente al massimo 1.000 elementi per tipo di oggetto, come utenti, gruppi o dispositivi. Alla scadenza, i prodotti Workspace Protection non sono disponibili in Sophos Fusion; la configurazione resta conservata e riappare dopo il rinnovo.

Attiva e controlla la licenza tramite l’icona del profilo > Licensing. Per una prova strutturata, usa Avviare e valutare in sicurezza una prova di Sophos Fusion.

Responsabilità

Prima delle modifiche chiarisci almeno questi ruoli:

Amministratore Sophos Fusion: configura origini directory, identity provider, gateway, policy e risorse. Per un’origine AD serve un amministratore della console Sophos Central.
Amministratore delle identità: crea app registration, Client Secret, gruppi, Redirect URI ed eventuali account guest presso l’identity provider.
Responsabile DNS e certificati: crea record DNS pubblici e interni, conferma il dominio e rinnova i certificati.
Amministratore di rete o firewall: predispone routing, connessioni in uscita, NAT e regole firewall per la modalità scelta.
Application Owner: conosce FQDN interno o IP target, porte, autenticazione, redirect e criterio di accettazione.
Responsabile endpoint: distribuisce Sophos Endpoint Agent con il componente ZTNA e verifica i sistemi supportati.

Non salvare Client Secret, password di bind o chiavi private nel ticket o nel runbook. Documenta invece responsabile, posizione, scadenza e processo di rotazione.

Verifica tecnica preliminare

Prima di iniziare verifica:

Host gateway: VMware ESXi 6.5 o successivo oppure Hyper-V su Windows Server 2016 o successivo. Minimo 2 core CPU, 4 GB RAM e 80 GB di storage; SSD consigliato. Data e ora devono essere corrette e il fuso UTC.
Sophos Firewall come gateway: SFOS 19.5 MR3 o successivo, gestito da Sophos Fusion. Sono supportati firewall hardware, cloud, virtuali e software; alcune funzioni nuove possono richiedere SFOS più recente.
Certificato: wildcard di Let’s Encrypt o CA attendibile. Supportati RSA da 2048 bit ed ECDSA, non P-384 o P-521.
Directory: Microsoft Entra ID o Active Directory locale con gruppi aggiornati. I gruppi Entra per ZTNA devono essere security-enabled.
Identity provider: Microsoft Entra ID, Okta o Active Directory locale.
Piattaforma agente: Windows 10 1803 o successivo oppure macOS 11 Big Sur o successivo.
Applicazione: porte statiche note. Non sono supportate applicazioni con assegnazione dinamica o intervalli molto ampi, come vecchi prodotti VoIP.
Rete: raggiungibilità interna e risoluzione privata dal gateway all’applicazione. Per gateway locali devono essere raggiungibili in uscita anche le destinazioni Sophos richieste; l’ispezione SSL/TLS non deve interrompere tali connessioni.

Per architettura, dimensionamento e regole di rete segui Pianificare e creare un gateway Sophos ZTNA.

Valori di esempio

Sostituisci tutti i valori. Non mescolare domini di test e produzione.

Scopo	Valore di esempio
Gruppo pilota	`ZTNA-Pilot-Finance`
FQDN gateway	`ztna.example.net`
FQDN esterno risorsa	`wiki.example.net`
Target interno	`wiki.intern.example.net`
Porta web	`443/TCP`
Policy	`ZTNA-Pilot-Healthy`
Risorsa	`Wiki-Pilot`
PoP primario	`Europe (Frankfurt) Region`
Utente consentito	`ztna-allow@example.net`
Utente bloccato	`ztna-deny@example.net`

1. Scegliere percorso di accesso e modalità gateway

Senza agente o con agente

La scelta è vincolante:

Requisito	Senza agente	Con agente
Applicazione o sito web	Sì	Sì
Applicazione locale, ad esempio TCP nativa	No	Sì
Verifica stato dispositivo	No	Sì
Sophos Endpoint Agent richiesto	No	Sì
FQDN esterno risolvibile pubblicamente	Sì	No
Avviso se la risorsa non è raggiungibile	Solo in questa modalità	No

L’accesso senza agente controlla solo applicazioni e siti web e non valuta lo stato del dispositivo. Una policy con agente può verificare lo stato di sicurezza e limitare tutti i tipi di risorsa supportati. Policy e risorse con agente funzionano solo dopo l’installazione del componente ZTNA.

Protected Browser completo e la sua estensione non sono equivalenti: l’estensione in un altro browser non valuta l’integrità dell’endpoint. Le condizioni endpoint valgono quindi solo per il traffico del browser completo. Le sessioni RDP e SSH senza agente tramite Protected Browser sono casi distinti; crea una policy ZTNA agentless, una risorsa strettamente limitata e gli oggetti Protected Browser associati. Non copiare una policy web invariata su target amministrativi RDP o SSH.

Gateway locale o Sophos Cloud Gateway

Gateway locale: appliance virtuale nel proprio data center, raggiungibile da Internet. Gestisci l’istanza e predisponi porte firewall e regole NAT.
Sophos Cloud Gateway: Sophos gestisce il piano dati cloud. Un’istanza nel data center lo collega alle risorse interne; non servono esposizione Internet diretta, porte in ingresso o NAT per il percorso.

Le modalità sono intercambiabili, ma tratta la migrazione come modifica controllata: DNS, certificato, PoP, nomi esterni e test devono corrispondere al nuovo percorso.

In modalità cloud scegli il Point of Presence (PoP) vicino al data center, non automaticamente agli utenti. Le regioni sono Irlanda, Francoforte, Ohio, Oregon, Mumbai e Sydney. Da ZTNA 2.1 viene configurato per impostazione predefinita un PoP secondario vicino per il failover automatico. Modificalo in My Products > ZTNA > Gateways: apri il gateway, seleziona Edit, cambia la regione in Points of Presence e salva.

2. Preparare directory e gruppi

ZTNA autorizza in base ai gruppi sincronizzati. Crea prima un piccolo gruppo pilota security-enabled con il solo utente consentito. Per il test negativo serve un secondo utente esterno al gruppo.

Sincronizzare Microsoft Entra ID

La guida Sincronizzare Microsoft Entra ID con Sophos Fusion resta il riferimento dettagliato. Per ZTNA:

Registra l’applicazione ZTNA in Entra ID.
Per gateway ESXi e Hyper-V aggiungi https://<gateway-fqdn>/oauth2/callback; per Sophos Firewall https://<gateway-fqdn>/ztna-oauth2/callback come Redirect URI. Sono possibili più FQDN.
Registra Client ID, Tenant ID e valore del Client secret alla creazione; non sarà più visibile.
Concedi solo i permessi Microsoft Graph e il consenso amministrativo necessari.
Crea o seleziona gruppi security-enabled, verificando quelli importati da Microsoft 365 o AD.
In Sophos Fusion apri Global Settings > Directory service oppure Access control > Sign-in & identity e aggiungi Microsoft Entra ID.
Configura dominio, Client ID, Client secret, validità e pianificazione Hourly, Daily, Weekly, Monthly o None.
Limita utenti e gruppi al necessario. Salva e verifica in My Environment > Users & groups.

Non puoi sincronizzare più origini Entra ID dello stesso dominio. Office 365 GCC High non è supportato. Se UPN e login endpoint non coincidono possono nascere utenti duplicati o scollegati. Se rinomini un gruppo Entra assegnato, il nome non viene aggiornato automaticamente: riassegnalo.

Sincronizzare Active Directory locale

Scarica Active Directory Synchronization Setup da Global Settings > Directory service. Servono .NET Framework 4.6.2 sul computer, credenziali API Sophos con ruolo Service Principal Active Directory Sync, utenti ed e-mail univoci e le regole firewall o proxy necessarie.

Convalida Client ID e Client Secret nel setup.
Per LDAP usa un account con lettura della foresta e privilegi minimi.
Mantieni Use LDAP over SSL connection se possibile: porta 636 per LDAPS, 389 per connessione non sicura.
Seleziona insieme utenti e gruppi; lo stesso per dispositivi e relativi gruppi.
Limita l’ambito con Base Distinguished Names e filtri LDAP, ad esempio OU=Finance,DC=example,DC=net.
Dopo l’impostazione o una modifica ai filtri esegui prima anteprima e sincronizzazione manuali, che possono richiedere 15 minuti.

Non sincronizzare lo stesso dominio contemporaneamente da AD ed Entra ID. I gruppi primari AD non vengono sincronizzati per ZTNA; gli utenti devono appartenere anche a un altro gruppo. Modifiche a Base DN o filtri possono escludere e cancellare da Sophos Fusion oggetti importati. Rimuovi gli account inattivi dalla directory origine invece di nasconderli dalla sincronizzazione.

Accesso guest

Per utenti esterni usa Microsoft Entra B2B. Verifica se il tenant consente collaborazione esterna, quali domini invitare e chi approva. Aggiungi gli ospiti singolarmente o con batch controllato. Crea un gruppo guest separato, sincronizzalo e assegna solo le risorse necessarie. L’Application Owner deve conoscere data di uscita e sponsor di ogni account.

Aggiungere manualmente un utente

Se l’utente non viene sincronizzato, apri My Environment > Users & groups, scegli Add user e inserisci First and last name, Email address e, se necessario, Role, Manager, Exchange login e Add to groups (optional). Assegna un ruolo amministrativo solo se serve; User consente solo il portale self-service. Seleziona Email setup link solo se l’utente deve proteggere il proprio dispositivo e dispone di diritti amministrativi locali e Internet. Salva e verifica che compaia nell’elenco e nel gruppo ZTNA previsto. Altrimenti controlla e-mail, filtro gruppi e se la directory debba essere l’origine autorevole.

3. Configurare l’identity provider

Apri Sophos Central > My Products > ZTNA > Identity providers > Add identity provider oppure My Products > ZTNA > Identity providers. È possibile una sola voce per provider. Evita ., @ o # nel nome: potrebbero impedire il salvataggio.

Microsoft Entra ID

Seleziona Microsoft Entra ID (Azure AD).
Inserisci nome, descrizione, Client ID, Tenant ID e Client secret.
Prova la connessione.
Salva solo dopo il successo.

Active Directory locale

Seleziona Microsoft AD (on-prem).
Inserisci host e porta del server AD primario ed eventualmente un secondario dello stesso dominio.
Abilita TLS o StartTLS. Con Verify SSL certificate, carica un file .pem, .crt o .cer fino a 10 KB.
Inserisci Bind DN, password di bind e Base DN per utenti e gruppi.
Facoltativamente abilita Captcha e password monouso via e-mail con SMTP.
Assegna il provider a un gateway. Riaprilo, seleziona il gateway in Test Connection ed eventualmente uno username; il test mostrerà anche i gruppi.

Per AD come identity provider, un gateway ESXi o Hyper-V richiede almeno ZTNA 2.1; Sophos Firewall almeno SFOS 19.5 MR3. L’e-mail dell’utente di test deve essere valida. È supportato un solo dominio, non più child domain in una foresta. Con AD locale, gli utenti si autenticano al primo accesso dietro ogni gateway e possono essere autenticati su un solo dispositivo alla volta.

Okta

Servono gruppi sincronizzati e un authorization server OIDC; il gateway richiede almeno la versione 1.1. Crea in Okta un’app web OIDC, abilita Client Credentials e Refresh Token, usa il callback corretto e assegna i gruppi. Inserisci poi Client ID, Client Secret e Issuer URI in ZTNA. Un server Okta personalizzato richiede la licenza API Access Management.

Accesso federato a Sophos Fusion

L’accesso federato all’amministrazione Sophos Fusion è separato dall’identity provider ZTNA. Servono diritti Super Admin e la verifica preliminare del dominio in Access control > Sign-in & identity > Sophos sign-in con il TXT record generato. Apri poi Access control > Sign-in & identity > Federated identity providers e Add identity provider:

Inserisci nome e descrizione senza ., @ o #.
Scegli Microsoft Entra ID, OpenID Connect o Microsoft AD FS. Entra richiede Tenant ID; OIDC Client ID, Issuer, Authorization endpoint, JWKS URL; AD FS l’URL dei metadati.
Assegna il dominio verificato. Puoi aggiungerne più di uno, ma ogni utente appartiene a uno solo.
Scegli esplicitamente IdP-enforced MFA o No IdP-enforced MFA; nel secondo caso Sophos Fusion applica MFA dopo l’IdP.
Salva e abilita. Dati incompleti o non validi impediscono l’attivazione.

Abilita la federazione solo quando tutti gli amministratori e utenti interessati hanno dominio e provider. Prova un account amministrativo limitato in una finestra privata mantenendo aperta una sessione Super Admin funzionante. Se fallisce, disabilita il provider da quella sessione e controlla dominio, endpoint, trust del certificato e MFA.

Selezionare un identity provider in Sophos ZTNA

4. Predisporre gateway, domini e certificato

Segui Pianificare e creare un gateway Sophos ZTNA. Per più risorse nello stesso dominio usa un certificato wildcard; per Let’s Encrypt consulta Creare un certificato wildcard Let’s Encrypt.

Per il percorso Let’s Encrypt gestito da Sophos Fusion, apri My Products > ZTNA > Settings > Domains and certificates e scegli Add domain. Fusion genera un CNAME per _acme-challenge.<domain>. Pubblica esattamente nome e destinazione nel DNS pubblico, mantienilo per i rinnovi e scegli Verify. Lo stato deve risultare verificato. Copia la destinazione completa; alcuni provider richiedono il punto finale. Converti al CNAME corrente i domini in precedenza validati con TXT. Dopo ogni nuovo dominio rigenera l’unico certificato gestito dell’account per includerlo.

La challenge DNS manuale di Certbot per un wildcard proprio è separata: solo lì pubblichi il TXT richiesto da Certbot. Carica certificato, catena completa e chiave privata e controlla dominio e Subject Alternative Names. È operativo solo quando un client esterno considera attendibile la catena. L’emissione completa resta nel runbook collegato.

5. Configurare il DNS

Gateway locale

Per accesso senza agente pubblica:

record A del gateway, ad esempio ztna.example.net,
un CNAME per risorsa verso il gateway, ad esempio wiki.example.net,
gateway e risorse agentless nello stesso dominio.

Con agente basta il record A pubblico del gateway; nessun CNAME pubblico per le risorse. Il gateway deve risolvere internamente il FQDN target; in alternativa indica l’IP interno nella risorsa.

Sophos Cloud Gateway

Conferma il dominio con il CNAME generato da Sophos, poi pubblica il CNAME dell’alias gateway. Per ogni risorsa agentless aggiungi un CNAME all’alias mostrato. Le risorse con agente non richiedono CNAME pubblico.

Verifica ogni nome:

pubblicamente da una rete esterna,
internamente dalla rete del gateway,
dal dispositivo pilota nella modalità prevista.

L’agente intercetta per FQDN, non per IP. Se l’applicazione reindirizza a un altro FQDN, crealo come risorsa.

6. Creare una policy

Apri Sophos Central > My Products > ZTNA > Policies > Add policy oppure My Products > ZTNA > Policies.

Seleziona Add policy.
Scegli Agent o Agentless.
Assegna un nome univoco, ad esempio ZTNA-Pilot-Healthy.
Per una policy Agent lascia Use access control conditions attivo in Access rules.
In Allow access seleziona lo stato richiesto.
Salva.

La policy definisce metodo e condizioni; i gruppi si assegnano alla risorsa, non alla policy. Ogni risorsa ha una sola policy e una nuova assegnazione sostituisce la precedente. Le policy agentless non hanno regole sullo stato. Se appare Request agent, puoi creare la policy ma devi attendere provisioning e installazione prima dei test.

7. Agente e casi particolari

Installa il componente ZTNA tramite Sophos Endpoint Agent solo sul gruppo pilota. Verifica poi che l’agente sia configurato e abbia ricevuto la policy.

In My Products > ZTNA > Settings imposta l’inattività del tunnel a 5, 15 o 30 minuti oppure 1 ora; il default è 5 minuti. Il tunnel si ricrea con nuovo traffico. Il tempo minimo prima che un cambio di stato attivi una regola evita blocchi per problemi brevi.

Su Windows, Do not monitor local traffic può evitare hairpinning in ufficio. Richiede Sophos Core Agent 2025.2.1.709 o successivo. Inserisci FQDN e IP in Sophos Fusion e la stessa associazione nel DNS interno. Se coincidono, il traffico locale passa direttamente sulla LAN. Abilita solo se le risorse devono essere raggiungibili senza ZTNA; secondo la documentazione assegnata non è ancora disponibile su macOS.

Pianifica separatamente:

Farm RDS: Completa prima farm e appartenenza al dominio secondo la documentazione Microsoft corrente. In My Products > ZTNA > Resources & access > Add resource, seleziona gateway, Access method: Agent, Resource type: Remote Desktop Protocol (RDP), FQDN esterno RD Gateway, porte richieste (l’esempio usa 3389, 443, 80), FQDN interno o IP e gruppo pilota. Dal dispositivo pilota apri https://<rd-gateway-fqdn>/rdweb, scarica il file RDP e connettiti. Deve aprirsi una sessione su un Session Host. Una cattura deve mostrare traffico ZTNA su TAP/TUN e nessun traffico diretto verso RD Gateway/Session Host sull’interfaccia primaria. Altrimenti verifica agente, tipo, porte, DNS e broker/gateway RDS prima di ampliare.
Controllo SaaS: Usalo solo se il SaaS supporta allow list IP. Aggiungilo come risorsa, assegna solo il gruppo necessario e lascia vuoto Internal FQDN/IP address per usare il FQDN esterno. Nel SaaS consenti solo IP o intervallo pubblico dell’interfaccia NAT davanti al gateway. Il pilota deve accedere via ZTNA; un utente non autorizzato o un percorso diretto fuori dal NAT deve fallire. In caso contrario confronta il NAT in uscita reale con l’allow list e verifica gruppo, FQDN e percorso.
Windows Hello: Il percorso passwordless a chiavi richiede Microsoft Entra ID, licenza Azure Premium, Windows 10/11, ZTNA già configurato e server applicativo nello stesso dominio del dispositivo. In Azure abilita il join in Devices > Device settings. In Intune abilita Hello in Devices > Windows enrollment > Windows Hello for Business per tutti oppure crea in Devices > Configuration profiles > Create profile un profilo Windows 10 and later > Templates > Identity protection per il gruppo pilota. Esegui il join da Settings > Accounts > Access work or school > Connect > Join this device to Azure Active Directory, riavvia, accedi con Entra e configura MFA e PIN o biometria. Installa poi l’agente. L’accesso diretto a un’app agent-based, inclusi CIFS/RDP, non deve richiedere di nuovo l’IdP; Sophos Endpoint deve mostrare ZTNA configurato e utente autenticato. Altrimenti verifica join, profilo, login Hello, dominio comune e agente. Confronta i menu con la documentazione Microsoft corrente.
In ufficio: scegli tra lo stesso percorso ZTNA esterno e LAN diretta, evitando hairpinning involontario.
Domain controller: creali come risorse con agente per Windows. Da Endpoint 2026.1, più controller sono supportati; priorità e peso dei record SRV automatici consentono failover e bilanciamento. Per tre DC usa Configurare più domain controller con Sophos ZTNA, senza ricreare il failover in una risorsa web.

8. Creare una risorsa e assegnare l’accesso

Apri Sophos Central > My Products > ZTNA > Resources & access > Add resource oppure My Products > ZTNA > Resources & access.

Documenta: nome e Application Owner, gateway, tipo di applicazione, FQDN/IP interno, FQDN esterno, protocollo e porta, accesso con/senza agente, policy, gruppi consentiti, FQDN di redirect, test positivo e negativo.

Usa un FQDN per web app e siti; collega app locali tramite IP. Senza agente il FQDN esterno deve essere pubblico. Con agente non deve essere pubblico, altrimenti la risorsa non è raggiungibile.

Seleziona Add resource.
Scegli gateway e tipo di accesso.
Inserisci nomi interno ed esterno, protocollo e porta.
Scegli la policy creata.
Assegna solo il gruppo pilota.
Salva e controlla il riepilogo.

Le modifiche ai gruppi possono richiedere fino a un’ora sul gateway. Attendi prima di cambiare di nuovo la configurazione.

Convalida e risultato atteso

Verificare la configurazione

Nessun alert High o Medium inatteso in My Products > ZTNA > Dashboard.
Test dell’identity provider riuscito e, per AD, gruppo atteso visibile.
Dominio e certificato validi; nessun errore nei browser esterni.
DNS pubblico diretto al gateway o alias Sophos atteso.
Gateway capace di risolvere il target interno e raggiungerne la porta.
Tipo di policy, risorsa e stato agente coerenti.
Risorsa con la sola policy e il gruppo pilota previsti.

Verificare l’accesso

Apri l’applicazione come utente autorizzato tramite FQDN esterno, non IP.
Conferma il login presso l’identity provider.
Prova la funzione reale: login, navigazione e lettura innocua.
Prova un utente esterno al gruppo: il rifiuto deve essere tracciabile.
Per una policy Agent modifica lo stato solo in una finestra controllata: la condizione deve scattare.
Confronta i log ZTNA, gateway, identity provider, DNS e firewall allo stesso timestamp.
Documenta utente, dispositivo, FQDN, ora, risultato previsto e reale.

Le web app si aprono direttamente o dal portale utente ZTNA, il cui indirizzo è il FQDN del gateway. Con piattaforma Sophos Firewall, un amministratore deve prima configurare una risorsa per l’accesso al portale. Il portale mostra le app agentless consentite di tutti i gateway, non quelle con agente. Dopo sette giorni senza accesso serve un nuovo login. Cinque autenticazioni fallite consecutive bloccano altre risorse per 60 minuti.

Risoluzione dei problemi per sintomo

Prova in My Products > ZTNA > Identity providers.
Controlla Client ID, Tenant ID, scadenza secret e Redirect URI.
Verifica utente e gruppo sincronizzati e security-enabled.
Per AD controlla Bind DN, Base DN, porta, certificato TLS ed e-mail valida.
Dopo cinque errori attendi il blocco di 60 minuti.

Un provider non si abilita con setup incompleto o dati non validi. Per Verification failed due to invalid Client ID, verifica app ID e login utente abilitato in Entra ID.

Apri esattamente il FQDN esterno.
Controlla i redirect e crea ogni ulteriore FQDN come risorsa.
Prova risoluzione interna e porta dalla rete gateway.
Confronta tipo risorsa, policy e agente.
Verifica che il FQDN sia pubblico senza agente e non pubblico con agente.
Controlla se una nuova policy ha sostituito l’assegnazione.
Se l’accesso diretto funziona ma il portale su Sophos Firewall no, verifica che la risorsa portale richiesta esista e sia assegnata al gruppo corretto.

Utente senza accesso inatteso

Verifica l’appartenenza effettiva.
Attendi fino a un’ora dopo una modifica.
Riassegna gruppi Entra rinominati.
In AD, verifica che non appartenga solo al gruppo primario.
Controlla filtri e Base DN.

DNS o certificato errato

Confronta A e CNAME carattere per carattere. Controlla TXT solo per Certbot manuale o verifica dominio dell’accesso federato Fusion.
Per il certificato gestito verifica il CNAME _acme-challenge.<domain>, conservalo per i rinnovi e rigenera il certificato dopo modifiche ai domini.
Verifica se il provider ha aggiunto il dominio al CNAME.
Controlla catena, ambito wildcard, scadenza e tipo chiave.
Prova separatamente pubblico e interno: la LAN non prova la risoluzione pubblica.

Agente installato, ma tunnel o stato non funzionano

Controlla sistema, versione Endpoint e componente ZTNA.
Policy e risorsa devono essere entrambe agent-based.
Considera il tempo minimo configurato.
Con Do not monitor local traffic, FQDN e IP nel DNS interno devono coincidere con Central.
L’estensione Protected Browser non fornisce l’integrità endpoint; prova nel browser completo o con l’agente ZTNA.

Escalation a Sophos Support

In Global Settings > Products and Services > ZTNA imposta la scadenza dell’accesso supporto, poi genera un token temporaneo nelle impostazioni gateway. Non inviare credenziali permanenti; revoca o lascia scadere il token.

Ripristino sicuro e offboarding

Annullare un pilota fallito

Ferma l’estensione ad altri utenti.
Rimuovi il gruppo dalla risorsa o imposta Policy bypassed; gli utenti non potranno accedere alle risorse gestite.
Ripristina il percorso documentato, ad esempio VPN o LAN, e non ritirarlo prima dell’accettazione ZTNA.
Rimuovi il componente ZTNA solo dai dispositivi pilota se nessun’altra risorsa lo usa.
Rimuovi i CNAME pubblici solo dopo il ritorno confermato; non cancellare DNS gateway o certificato ancora usati.
Con test positivo e negativo verifica il vecchio percorso e l’assenza di esposizione pubblica involontaria.

Non disabilitare Use access control conditions come bypass d’emergenza: rimuoveresti la verifica dello stato. Se non puoi ripristinare accesso sicuro, fermati ed esegui escalation senza ampliare la policy.

Offboarding di utente o guest

Rimuovi il gruppo nella directory autorevole o disabilita l’account nel provider.
Considera fino a un’ora per l’effetto sul gateway; la disabilitazione forza poi il logout e blocca le risorse.
Verifica che nessun altro gruppo conceda lo stesso accesso.
Controlla i log con un test negativo.
Rimuovi account guest orfani, inviti e gruppi temporanei dall’origine.

Gli utenti restano connessi fino a sette giorni di inattività. Solo un amministratore può oggi forzare il logout immediato; consideralo sui dispositivi condivisi.

Ritirare risorsa o gateway

Inventaria gruppi, policy, risorse, DNS e dipendenze certificati.
Rimuovi prima l’accesso e osserva i log.
Elimina la risorsa.
Rimuovi DNS pubblici solo se nessun altro percorso li usa.
Elimina il gateway solo dopo migrazione e convalida del nuovo percorso.
Revoca secret e certificati inutili e rimuovi vecchie regole firewall/NAT.

Gestione, review e lifecycle

Almeno ogni trimestre e dopo cambi importanti verifica:

utenti attivi e licenze degli ultimi 30 giorni,
appartenenze di gruppi e guest,
assegnazione risorsa-policy e Application Owner,
scadenza certificati e rotazione secret,
versioni gateway, agente, SFOS e hypervisor,
PoP, failover e messaggi di stato,
risorse agentless irraggiungibili e trend alert,
eccezioni firewall in uscita, NAT e vecchi DNS,
test positivo e negativo per app critica,
percorso di emergenza e ripristino documentato.

La dashboard mostra numero di alert e cinque applicazioni con maggior trasferimento nelle ultime 24 ore. Usa Gateway bandwidth e Resource bandwidth per utenti autenticati e volume dati.

Una licenza ZTNA attiva include release funzionali e di manutenzione, supporto 24x7 e funzioni Sophos Fusion. Sophos prevede feature release ogni 6-12 mesi e maintenance release ogni 1-3 mesi. Vengono mantenute la versione funzionale corrente e un’altra selezionata; per ciascuna dovrebbero essere supportate le ultime due maintenance release. Il supporto previsto è circa 24 mesi, normalmente con 90 giorni di preavviso pubblico.

Usa queste indicazioni per pianificare, non come garanzia. Prima degli upgrade verifica release note ZTNA, limitazioni, compatibilità agente e stato dei PoP. Affermazioni storiche su transizione, entitlement, migrazione o EOL senza comunicazione attuale non appartengono al piano operativo.