Sophos Fusion Admin: transizione da Sophos Central

Sophos Fusion è il nome attuale della piattaforma precedentemente denominata Sophos Central. Occorre distinguere due cambiamenti: la transizione dei nomi dei portali e dell’accesso e l’upgrade graduale delle soluzioni EDR, XDR e MDR. Il solo logo Fusion non conferma che un determinato tenant abbia già ricevuto l’upgrade del prodotto. La sola transizione dell’accesso non richiede di ricreare tenant, dispositivi, policy, ruoli o endpoint tecnici. Dopo l’upgrade del prodotto possono invece essere necessari interventi mirati sulle integrazioni.

Questo runbook guida la transizione locale dell’accesso e la verifica operativa del tenant. I passaggi concreti per creare nuove connessioni o autorizzarle nuovamente sono descritti in Configurare le integrazioni MDR e XDR.

Upgrade del prodotto: verificare tenant e conseguenze operative

Stato verificato all’11 ottobre 2026: le informazioni di settembre sul rollout descrivono una transizione già in corso, distribuita su più mesi, non la migrazione completata di tutti i clienti. Sophos gestisce l’upgrade; non è prevista una data liberamente selezionabile dal cliente. Circa una settimana prima compare un avviso nella console. Al termine segue un altro avviso con una breve presentazione guidata. Documentare per il tenant interessato l’annuncio, il completamento e le funzioni effettivamente accessibili, anziché dedurne lo stato da una newsletter o dal nome del portale.

Per i tenant gestiti da MSP, Sophos indica un avvio successivo, a partire dal quarto trimestre del 2026. I tenant dello stesso MSP dovrebbero essere aggiornati insieme, affinché il partner operi su una piattaforma uniforme. Anche all'11 ottobre, questa indicazione temporale non significa che tutti i tenant MSP siano già migrati. Fino all’upgrade effettivo rimane determinante la soluzione precedente; in caso di annuncio poco chiaro, verificare lo stato del cliente con il team partner.

L’upgrade del prodotto è automatico. Non richiede né una nuova distribuzione degli agenti né un cambio di licenza. Non sostituisce però le seguenti attività operative:

1. Dopo il completamento, verificare le Microsoft 365 Response Actions esistenti. La connessione o le relative credenziali devono essere configurate o autorizzate nuovamente nella nuova Security Operations. Un’integrazione dati che continua a funzionare non dimostra che tutte le azioni di risposta funzionino.
2. Se si utilizza Sophos Firewall, aprire un case e controllare se sono disponibili le azioni di risposta firewall. Creare una connessione Sophos Firewall (Actions) solo se mancano. Entrambe le attività sono descritte nel runbook delle integrazioni collegato sopra.
3. Per le automazioni XDR, inventariare separatamente query di lettura, workflow di scrittura e API utilizzate. L’integrazione delle informazioni sulle API del 9 ottobre 2026 è una modifica successiva: non se ne deve presumere la disponibilità già al lancio di settembre. Il runbook delle integrazioni spiega la distinzione tra Classic e GraphQL.
4. Inventariare i collector Syslog SVA esistenti ed eventuali carichi NDR. Un XDR Data Collector predisposto automaticamente non è ancora distribuito. Per scelta dell’indirizzo, deployment, passaggio e ripristino, seguire Migrare i Log Collector SVA a XDR Data Collectors.

Aggiornare i nomi MDR e il reporting

I livelli precedenti Sophos MDR Essentials e Sophos MDR Complete si chiamano ora rispettivamente Sophos MDR e Sophos MDR Plus. Il prodotto rimane Sophos XDR; Sophos XDR Powered by Secureworks identifica la soluzione avanzata durante la transizione. Un nuovo nome non giustifica una modifica autonoma del contratto o del livello di servizio.

Con l’upgrade dell’account MDR termina il precedente invio automatico dei rapporti MDR settimanali e mensili. Concordare quindi con i destinatari chi, durante la transizione, utilizzerà MDR Dashboard, selezionerà il periodo necessario e creerà un’esportazione PDF per gli obblighi di reporting esistenti. Il dashboard offre intervalli flessibili e viste personalizzabili. Verificare l’esportazione per un periodo noto e documentare dove viene conservata; l’assenza di rapporti automatici dopo l’upgrade non dimostra da sola un’interruzione della protezione.

Una nuova generazione di rapporti self-service era prevista per una fase successiva del 2026. Questo non conferma né la disponibilità attuale né un invio automatico già funzionante. Solo una funzione di reporting disponibile e verificata nel proprio tenant può sostituire il processo transitorio concordato.

Per chi utilizza anche Sophos Managed Risk, questo upgrade non modifica il servizio Managed Risk. Cambiano il formato dei case e l’accesso: i case Managed Risk sono raggiungibili in Security Operations > Cases. Dopo l’upgrade, aprire un case Managed Risk atteso e verificare che sia accessibile nel tenant corretto. L’indicazione vale solo per i clienti con un servizio Managed Risk esistente e non conferisce un nuovo diritto al servizio.

Non confondere le estensioni facoltative con l’upgrade

Sophos AI Defense è disponibile in generale dal 13 ottobre 2026 ed è un add-on a pagamento per i clienti EDR, XDR e MDR idonei. Sophos indica inoltre Sophos EDR Endpoint Protection come prerequisito. La precedente fase EAP e l’obiettivo del quarto trimestre sono quindi contesto storico, non lo stato attuale di disponibilità. Il rilascio generale non dimostra però né il diritto contrattuale né l’abilitazione nel proprio tenant. I clienti Taegis idonei possono acquistarlo già dalla disponibilità generale, senza attendere la migrazione a Fusion; questa eccezione all’acquisto non elimina il prerequisito tecnico documentato per la configurazione. AI Defense non è AI Assistant né AI Search per le indagini XDR. Non rendere l’operatività di base dipendente da questo add-on.

La configurazione documentata richiede ancora un account Fusion aggiornato alla nuova piattaforma con Security Operations. Nell’assistente sono selezionabili Sophos Endpoint, Sophos Firewall e Sophos Linux Server. L’elenco più ampio di DNS Protection, Protected Browser e Sophos Data Lake nella panoramica del prodotto non coincide con quello dei sensori selezionabili. Endpoint richiede caricamenti dei dati, decrittazione TLS, blocco di QUIC e impostazioni di Web Control e Application Control. Firewall richiede la gestione tramite gruppi e la registrazione dei log nelle policy web; i firewall non gestiti tramite gruppi non ricevono le regole di applicazione di AI Defense. Linux Server richiede il caricamento di Network Data nel Data Lake. La sola selezione di un sensore non conferma una protezione efficace.

AI Defense offre visibilità, policy di accesso alle app e reporting. La Base Policy si applica a tutte le persone dell’organizzazione; una Base Policy già presente rimane invariata durante l’onboarding. Per le policy aggiuntive, Save salva senza attivare, mentre Save & Enable attiva immediatamente con la priorità più alta. Ambito, regole e ordine devono essere verificati prima dell’approvazione. Nonostante formulazioni più ampie nei comunicati stampa della disponibilità generale, le successive informazioni per i partner collocano verifica e protezione dei prompt nella roadmap: non vanno quindi pianificate come protezione attuale garantita. Sophos AI Defense: rilevare e controllare l’uso dell’IA spiega il flusso completo, con requisiti dei sensori, progetto pilota limitato, convalida e ripristino.

Se si utilizzava Cloud Optix, verificare anche una lacuna separata: l’End of Life del 30 settembre 2026 è già passato. Le nuove connessioni di telemetria cloud non vengono configurate automaticamente dall’upgrade del prodotto e non sostituiscono le funzioni CSPM. Il runbook delle integrazioni spiega la distinzione e l’inventario ora necessario.

Distinguere i nomi visibili e i tipi di portale

A seconda del ruolo e del tipo di account viene visualizzata un’interfaccia diversa:

I tre nomi indicano contesti di gestione diversi e non sono intercambiabili. I clienti, i sub-estate o i prodotti visibili continuano a dipendere dall’account, dal ruolo e dalle autorizzazioni. Per orientarsi nel tenant cliente, consultare Configurare in sicurezza il tenant Sophos Fusion; per una panoramica dei diversi tipi di portale, consultare Panoramica dei portali Sophos.

Preparare la transizione

1. Documentare il tipo di account interessato, il tenant, la regione dei dati e il ruolo amministrativo utilizzato.
2. Verificare che l’accesso funzioni in un browser desktop aggiornato e supportato. Non modificare contemporaneamente l’autenticazione, il ruolo o l’Identity Provider.
3. Individuare i riferimenti locali al precedente punto di accesso al portale: segnalibri del browser, voce nel gestore di password, documentazione e pagine iniziali interne nonché, se in uso, regole di proxy o filtro web e definizioni delle destinazioni di Conditional Access.
4. Inventariare separatamente i riferimenti tecnici utilizzati: host API, Redirect URI, callback OIDC, webhook, link self-service, script ed endpoint di prodotto configurati in modo statico.
5. Predisporre per il test di accettazione un account di prova con il ruolo amministrativo previsto per l’operatività. Se vengono utilizzati anche il portale Enterprise o Partner, occorre un account di prova adeguato per ciascun tipo di portale in uso. Tenere inoltre a disposizione un secondo amministratore autorizzato e una finestra di navigazione privata.

MFA, passkey e ripristino non vengono modificati nell’ambito di questo runbook. A tale scopo, consultare Proteggere l’accesso a Sophos Fusion con MFA, passkey e IdP. Le modifiche a Entra ID, Conditional Access o OIDC devono seguire le istruzioni separate per Microsoft Entra ID o per OpenID Connect e Okta.

Aggiornare l’accesso e i riferimenti locali

L’attuale punto di accesso per gli utenti è:

➜ Aprire Sophos Fusion

1. Aprire direttamente https://fusion.sophos.com in una finestra di navigazione privata.
2. Completare la normale procedura di accesso e verificare tenant, tipo di account e ruolo.
3. Solo dopo aver completato il test con esito positivo, aggiornare il segnalibro del browser e il link al portale nella documentazione amministrativa interna impostandoli su https://fusion.sophos.com.
4. Nel gestore di password, aggiungere o aggiornare esclusivamente l’URI di accesso o l’associazione relativa a questo punto di accesso al portale. Non spostare indiscriminatamente credenziali, passkey e URL tecnici memorizzati.
5. Se un proxy, un servizio di sicurezza DNS o un filtro web in uso blocca il nuovo host, autorizzare l’host di destinazione effettivamente registrato con l’ambito minimo necessario, quindi ripetere il test. Non creare eccezioni wildcard non giustificate per *.sophos.com o per intere categorie e non disattivare indiscriminatamente la TLS Inspection.
6. Se per il percorso di accesso è configurato Conditional Access, verificare gli eventi di accesso effettivi. Un nuovo nome host non giustifica né un’eccezione estesa né una modifica delle condizioni relative a utenti, dispositivi, località o MFA.

Quando si apre fusion.sophos.com, il browser può essere reindirizzato tramite l’infrastruttura Central esistente e mantenuta per compatibilità. Gli host o i percorsi osservati contenenti central.sophos.com non indicano un rollback né costituiscono la prova di un tenant errato. Ciò che conta è una destinazione Sophos attendibile, l’accesso previsto e il contesto di gestione corretto.

Lasciare invariati gli identificatori tecnici di Central

La ridenominazione visibile non è un’operazione tecnica di ricerca e sostituzione. I valori seguenti devono rimanere esattamente invariati finché la relativa integrazione o documentazione non indica esplicitamente un nuovo valore:

• percorsi della documentazione Sophos contenenti /central/;
• nomi delle API Sophos Central, host API e URL di base esistenti;
• Redirect URI e valori di callback configurati, ad esempio https://federation.sophos.com/login/callback;
• il punto di accesso self-service tecnicamente necessario e mantenuto per compatibilità https://central.sophos.com/manage/self-service;
• webhook, variabili di script, secret, riferimenti a certificati e altri endpoint tecnici che contengono central nel nome;
• slug interni stabili, termini di ricerca e registrazioni storiche.

Questi valori possono essere contratti di protocollo o oggetto di confronti esatti. Una ridenominazione redazionale può interrompere SSO, client API o accessi degli utenti. Le attività relative alle licenze devono invece essere eseguite seguendo Attivare, verificare e rinnovare le licenze Sophos Fusion.

Convalida

La transizione è completata quando i seguenti punti applicabili sono stati verificati con un account di prova che dispone del ruolo amministrativo previsto per l’operatività. Per ogni ulteriore tipo di portale utilizzato, ripetere il test con l’account di prova previsto per tale portale:

• https://fusion.sophos.com apre la pagina di accesso Sophos prevista senza avvisi relativi a certificati o filtri.
• La MFA configurata e, se utilizzato, il percorso di accesso federato continuano a funzionare senza modifiche; sono visibili il ruolo previsto e il tenant corretto.
• Il contesto cliente, Enterprise o Partner mostra il nome visibile appropriato.
• My Environment, Global Settings, il profilo e Sophos Help sono accessibili in base al ruolo.
• Un eventuale smoke test delle API o dell’automazione viene completato senza modificare host o secret.
• Se configurati o utilizzati, il callback SSO, il link self-service e gli altri endpoint tecnici di Central continuano a funzionare senza modifiche.
• Se vengono utilizzati proxy, servizi di sicurezza DNS, filtri web, IdP o Conditional Access, i relativi log non mostrano nuovi blocchi o eccezioni impreviste.
• Le precedenti istruzioni interne rimandano all’URL di Fusion per l’accesso amministrativo, ma mantengono invariati i valori tecnici esatti di Central.

Risoluzione dei problemi

Reindirizzamento a un host Central

Non tornare a uno stato apparentemente precedente. Verificare innanzitutto il certificato, l’intera catena di reindirizzamento, il tenant di destinazione e il completamento dell’accesso. I nomi legacy nell’infrastruttura operativa possono essere ancora corretti.

Pagina bloccata o vuota

Eseguire il test in un browser senza estensioni o in una finestra di navigazione privata e registrare l’ora, l’URL iniziale, l’host finale e il testo dell’errore. Verificare quindi nei log dei sistemi proxy, DNS, di filtro web e di TLS Inspection in uso quale host specifico è stato bloccato. Modificare solo quanto giustificato da tale evidenza, senza autorizzare preventivamente wildcard.

Se sono interessati contemporaneamente più accessi o tenant indipendenti, consultare Sophos Status per verificare un’eventuale interruzione generale del servizio. La pagina di stato fornisce un’indicazione diagnostica; le modifiche locali devono comunque essere effettuate solo sulla base di cause comprovate.

Errore di accesso o di Conditional Access

Confrontare cronologicamente gli eventi dell’accesso Sophos e, se viene utilizzato un IdP, quelli dell’IdP. Non ricreare un’app IdP, un URL di callback o una policy di Conditional Access solo a causa del nuovo nome visibile. Per la diagnosi e il ripristino, attenersi esclusivamente al runbook SSO collegato sopra per il percorso di accesso interessato; mantenere disponibile l’amministratore alternativo già verificato.

Voce di menu mancante

Verificare innanzitutto il tipo di account e il ruolo. Cercare quindi in My Environment, tramite l’icona a forma di ingranaggio per Global Settings, nel profilo e in Sophos Help. Una voce di menu mancante può dipendere dai limiti del ruolo o della licenza e non dimostra che la ridenominazione non sia riuscita.

Tenant, prodotti o clienti mancanti

Terminare la sessione, accedere nuovamente in una finestra di navigazione privata con l’identità prevista e verificare il tipo di account e il tenant. Non creare tenant sostitutivi, versioni di prova o nuove associazioni partner come soluzione.

Se dopo queste verifiche l’accesso continua a non funzionare, raccogliere l’intervallo temporale con il fuso orario, l’identità interessata, il tenant o il Customer ID, il browser, l’host iniziale e quello di destinazione, il testo dell’errore e screenshot privi di dati sensibili. Procedere quindi con l’escalation tramite Aprire un ticket di supporto Sophos con Support Assistant.

Rollback locale

Il cliente non può annullare la ridenominazione di Sophos Central in Sophos Fusion effettuata dal fornitore. È possibile ripristinare solo le modifiche locali apportate nell’ambito di questo intervento:

• segnalibri e link nella documentazione interna;
• associazioni degli URI di accesso nel gestore di password;
• regole specifiche di proxy, DNS o filtro web.

Prima del rollback, recuperare il valore precedente dalla documentazione dell’intervento, ripristinarlo e quindi verificare nuovamente l’accesso. Le modifiche a IdP o Conditional Access non rientrano in questo rollback locale; devono essere annullate esclusivamente seguendo il runbook SSO collegato sopra per il percorso di accesso interessato e la relativa procedura di ripristino documentata. Il vecchio nome host di Central non è un percorso di rollback garantito. Gli host API, i callback, gli URL self-service e gli altri valori tecnici lasciati intenzionalmente invariati per questa transizione non devono essere modificati.