Sophos Fusion Admin : transition depuis Sophos Central

Sophos Fusion est le nom actuel de la plateforme auparavant appelée Sophos Central. Il faut distinguer deux changements : la transition des noms des portails et de l’accès, d’une part, et la mise à niveau progressive des solutions EDR, XDR et MDR, d’autre part. La seule présence d’un logo Fusion ne confirme pas qu’un tenant donné a déjà bénéficié de la mise à niveau du produit. La simple transition de l’accès n’implique pas de recréer les tenants, appareils, stratégies, rôles ou endpoints techniques. En revanche, des travaux d’intégration ciblés peuvent être nécessaires après la mise à niveau du produit.

Ce runbook accompagne la transition locale de l’accès et les vérifications opérationnelles propres au tenant. Les étapes concrètes pour les nouvelles connexions ou celles à autoriser de nouveau figurent dans Configurer les intégrations MDR et XDR.

Mise à niveau du produit : vérifier le tenant et les conséquences opérationnelles

État vérifié au 11 octobre 2026 : le point sur le déploiement publié en septembre décrit une transition déjà en cours, étalée sur plusieurs mois, et non la migration achevée de tous les clients. Sophos pilote la mise à niveau ; le client ne peut pas en choisir librement la date. Une notification apparaît dans la console environ une semaine à l’avance. Une fois la mise à niveau terminée, une autre notification propose une courte visite guidée. Documenter, pour le tenant concerné, l’annonce, l’achèvement et les fonctionnalités effectivement accessibles, plutôt que de déduire son état d’une newsletter ou du nom du portail.

Pour les tenants gérés par un MSP, Sophos indique un démarrage plus tardif, à partir du quatrième trimestre civil 2026. Les tenants d’un même MSP doivent être migrés ensemble afin que le partenaire travaille sur une plateforme opérationnelle homogène. Même au 11 octobre, cette indication de calendrier ne signifie pas que tous les tenants MSP ont déjà été migrés. Jusqu’à la mise à niveau effective, l’état antérieur de la solution reste la référence ; si l’annonce manque de clarté, clarifier la situation du client avec l’équipe partenaire.

La mise à niveau du produit est automatique. Elle ne nécessite ni de redéployer les agents ni de changer de licence. Elle ne remplace toutefois pas les opérations suivantes :

1. Une fois la mise à niveau terminée, vérifier les Microsoft 365 Response Actions existantes. La connexion ou ses identifiants doivent être configurés ou autorisés de nouveau dans le nouveau Security Operations. Une intégration de données qui continue de fonctionner ne prouve pas que toutes les actions de réponse fonctionnent.
2. Si Sophos Firewall est utilisé, ouvrir un Case et vérifier si les actions de réponse de Sophos Firewall sont proposées. Créer une connexion Sophos Firewall (Actions) uniquement si elles sont absentes. Ces deux opérations d’intégration sont décrites dans le runbook lié plus haut.
3. Pour les automatisations XDR, inventorier séparément les requêtes en lecture et les workflows en écriture, ainsi que les API qu’ils utilisent. L’ajout relatif aux API du 9 octobre 2026 constitue une modification ultérieure, et non un élément dont la disponibilité peut être présumée dès le lancement de septembre. Le runbook d’intégration explique la séparation entre Classic et GraphQL.
4. Recenser les collecteurs Syslog SVA existants et, le cas échéant, les charges de travail NDR. Un XDR Data Collector préprovisionné automatiquement n’est pas encore déployé. Pour le choix de l’adresse, le déploiement, la bascule et le retour arrière, suivre Migrer les collecteurs de logs SVA vers XDR Data Collectors.

Adapter les noms MDR et la production de rapports

Les anciens niveaux Sophos MDR Essentials et Sophos MDR Complete s’appellent respectivement Sophos MDR et Sophos MDR Plus. Le produit reste Sophos XDR ; Sophos XDR Powered by Secureworks désigne la solution enrichie pendant la transition. Un nouveau nom ne justifie pas de modifier de sa propre initiative le contrat ou le niveau de service.

La mise à niveau du compte MDR met fin à l’envoi automatique des rapports MDR hebdomadaires et mensuels tel qu’il existait jusqu’alors. Définir donc avec les destinataires des rapports qui utilisera le MDR Dashboard pendant la transition, sélectionnera la période requise et créera un export PDF pour répondre aux obligations existantes en matière de rapports. Le tableau de bord propose des périodes flexibles et des vues personnalisables. Vérifier l’export pour une période connue et documenter son emplacement de stockage ; l’absence de rapports automatiques après la mise à niveau ne prouve pas, à elle seule, une défaillance de la protection.

Une nouvelle fonctionnalité de création de rapports en libre-service était prévue pour plus tard en 2026. Cela ne confirme ni sa disponibilité actuelle ni le bon fonctionnement d’un envoi automatique. Seule une fonctionnalité de production de rapports disponible et vérifiée dans le tenant concerné peut remplacer le processus de transition convenu.

Pour les clients qui utilisent également Sophos Managed Risk, cette mise à niveau ne modifie pas le service Managed Risk. Les changements concernent le format des Cases et l’accès : les Cases Managed Risk sont accessibles sous Security Operations > Cases. Après la mise à niveau, ouvrir un Case Managed Risk attendu et vérifier qu’il est accessible dans le bon tenant. Cette indication s’applique uniquement aux clients disposant déjà du service Managed Risk et n’ouvre aucun nouveau droit à ce service.

Ne pas confondre les extensions optionnelles avec la mise à niveau

Sophos AI Defense est disponible de manière générale depuis le 13 octobre 2026 et constitue un module complémentaire payant pour les clients EDR, XDR et MDR éligibles. Sophos indique également Sophos EDR Endpoint Protection comme prérequis. L’ancienne phase EAP et l’objectif du quatrième trimestre relèvent donc du contexte historique, et non du statut de disponibilité actuel. La disponibilité générale ne prouve toutefois ni un droit contractuel ni une activation dans le tenant concerné. Les clients Taegis éligibles peuvent acheter le module dès sa disponibilité générale sans attendre leur migration Fusion ; cette exception à l’achat ne supprime pas le prérequis technique documenté pour la configuration. AI Defense n’est ni AI Assistant ni AI Search pour les investigations XDR. Ne pas faire dépendre l’exploitation de base de ce module complémentaire.

La configuration documentée nécessite toujours un compte Fusion mis à niveau vers la nouvelle plateforme avec Security Operations. L’assistant permet de sélectionner Sophos Endpoint, Sophos Firewall et Sophos Linux Server. La liste plus large de DNS Protection, Protected Browser et Sophos Data Lake dans la présentation produit n’est pas cette même liste de sélection des capteurs. Endpoint nécessite les transferts de données, le déchiffrement TLS, le blocage de QUIC ainsi que les paramètres de Web Control et d’Application Control. Firewall nécessite la gestion par groupes et la journalisation des stratégies web ; les firewalls qui ne sont pas gérés par groupes ne reçoivent pas les règles d’application d’AI Defense. Linux Server nécessite le transfert de Network Data vers le Data Lake. La seule sélection d’un capteur ne confirme pas une protection effective.

AI Defense offre de la visibilité, des stratégies d’accès aux applications et des rapports. La Base Policy s’applique à toutes les personnes de l’organisation ; une Base Policy existante reste inchangée pendant l’intégration initiale. Pour les stratégies supplémentaires, Save enregistre sans activer, tandis que Save & Enable active immédiatement avec la priorité la plus élevée. Le périmètre, les règles et leur ordre doivent être vérifiés avant approbation. Malgré les formulations plus larges de la presse lors de la disponibilité générale, les informations ultérieures destinées aux partenaires placent l’inspection et la protection des prompts sur la feuille de route ; il ne faut pas les prévoir comme une protection actuelle garantie. Sophos AI Defense : détecter et contrôler l’utilisation de l’IA explique la procédure complète avec les exigences des capteurs, un pilote limité, la validation et le retour arrière.

En cas d’utilisation antérieure de Cloud Optix, vérifier également une lacune distincte : la fin de vie du 30 septembre 2026 est déjà passée. Les nouvelles connexions de télémétrie cloud ne sont pas configurées automatiquement par la mise à niveau du produit et ne remplacent pas les fonctionnalités CSPM. Le runbook d’intégration décrit cette distinction et la vérification de l’existant désormais nécessaire.

Distinguer les noms visibles et les types de portails

L’interface affichée varie selon le rôle et le type de compte :

Ces trois noms désignent des contextes d’administration distincts et ne sont pas interchangeables. Les clients, sous-environnements ou produits visibles dépendent toujours du compte, du rôle et des autorisations. Pour des repères détaillés dans le tenant client, consultez Mettre en service un tenant Sophos Fusion en toute sécurité ; les différents types de portails sont présentés dans Vue d’ensemble des portails Sophos.

Préparer la transition

1. Documenter le type de compte concerné, le tenant, la région de données et le rôle d’administration utilisé.
2. Confirmer qu’une connexion fonctionne dans un navigateur de bureau récent et pris en charge. Ne pas modifier simultanément l’authentification, le rôle ou le fournisseur d’identité.
3. Recenser les références locales vers l’ancien point d’accès au portail : favori du navigateur, entrée du gestionnaire de mots de passe, documentation et pages d’accueil internes, ainsi que, le cas échéant, les règles de proxy ou de filtrage web et les définitions de destination de l’accès conditionnel.
4. Inventorier séparément les références techniques utilisées : hôtes d’API, URI de redirection, callbacks OIDC, webhooks, liens en libre-service, scripts et endpoints de produits configurés en dur.
5. Préparer pour le test de validation un compte de test doté du rôle d’administration prévu pour l’exploitation. Si le portail Enterprise ou Partner est également utilisé, un compte de test correspondant est nécessaire pour chaque type de portail utilisé. Prévoir aussi un second administrateur autorisé et une fenêtre de navigation privée.

Ce runbook ne modifie ni la MFA, ni les clés d’accès, ni les procédures de récupération. Pour ces sujets, consultez Sécuriser la connexion à Sophos Fusion avec la MFA, des clés d’accès et un IdP. Les modifications d’Entra ID, de l’accès conditionnel ou d’OIDC suivent les guides distincts pour Microsoft Entra ID et pour OpenID Connect et Okta.

Adapter la connexion et les références locales

Le point d’accès actuel destiné aux utilisateurs est le suivant :

➜ Ouvrir Sophos Fusion

1. Ouvrir directement https://fusion.sophos.com dans une fenêtre de navigation privée.
2. Effectuer la procédure de connexion habituelle jusqu’au bout, puis contrôler le tenant, le type de compte et le rôle.
3. Une fois le test réussi, et seulement à ce moment-là, remplacer par https://fusion.sophos.com le favori du navigateur et le lien vers le portail dans la documentation d’administration interne.
4. Dans le gestionnaire de mots de passe, ajouter ou mettre à jour uniquement l’URI de connexion ou l’association correspondant à ce point d’accès au portail. Ne pas déplacer en bloc les identifiants, les clés d’accès ni les URL techniques enregistrées.
5. Si un proxy, un service de sécurité DNS ou un filtre web bloque le nouvel hôte, autoriser l’hôte de destination effectivement consigné dans les journaux avec la portée minimale nécessaire, puis refaire le test. Ne pas créer d’exceptions génériques non justifiées pour *.sophos.com ou des catégories entières, et ne pas désactiver globalement l’inspection TLS.
6. Si l’accès conditionnel est configuré pour le parcours de connexion, vérifier les événements de connexion réels. Un nouveau nom d’hôte ne justifie ni une exception étendue ni la modification des conditions liées aux utilisateurs, appareils, emplacements ou à la MFA.

Lors de l’accès à fusion.sophos.com, le navigateur peut être redirigé via l’infrastructure Central existante et maintenue pour la compatibilité. La présence d’hôtes ou de chemins comportant central.sophos.com ne signale ni un retour en arrière ni un tenant incorrect. Les éléments déterminants sont une destination Sophos digne de confiance, la connexion attendue et le bon contexte d’administration.

Conserver les identifiants techniques Central à l’identique

Le changement de nom visible n’est pas une opération technique de recherche et remplacement. Les valeurs suivantes doivent rester strictement inchangées tant que la documentation ou l’intégration concernée n’indique pas expressément une nouvelle valeur :

• les chemins de la documentation Sophos comportant /central/ ;
• les noms d’API Sophos Central, hôtes d’API et URL de base existants ;
• les URI de redirection et valeurs de callback configurées, par exemple https://federation.sophos.com/login/callback ;
• le point d’accès libre-service techniquement requis et maintenu pour la compatibilité https://central.sophos.com/manage/self-service ;
• les webhooks, variables de script, secrets, références de certificats et autres endpoints techniques dont le nom comporte central ;
• les slugs internes stables, termes de recherche et historiques.

Ces valeurs peuvent constituer des contrats de protocole ou faire l’objet de comparaisons exactes. Un changement de nom purement éditorial peut interrompre le SSO, les clients API ou l’accès des utilisateurs. Les opérations sur les licences relèvent plutôt de Activer, vérifier et renouveler les licences Sophos Fusion.

Validation

La transition est terminée lorsque les points applicables ci-dessous ont été vérifiés avec un compte de test doté du rôle d’administration prévu pour l’exploitation. Pour chaque autre type de portail utilisé, répéter le test avec le compte de test correspondant :

• https://fusion.sophos.com ouvre la page de connexion Sophos attendue, sans avertissement de certificat ou de filtrage.
• La MFA configurée et, le cas échéant, le parcours de connexion fédérée fonctionnent sans modification ; le rôle attendu et le bon tenant sont visibles.
• Le contexte client, Enterprise ou Partner affiche le nom visible approprié.
• My Environment, Global Settings, le profil et Sophos Help sont accessibles conformément au rôle.
• Un test rapide d’API ou d’automatisation existant s’exécute sans modification de l’hôte ni du secret.
• S’ils sont configurés ou utilisés, le callback SSO, le lien en libre-service et les autres endpoints techniques Central fonctionnent sans modification.
• Si un proxy, un service de sécurité DNS, un filtre web, un IdP ou l’accès conditionnel sont utilisés, leurs journaux ne signalent aucun nouveau blocage ni aucune exception inattendue.
• Les anciens guides internes renvoient désormais à l’URL Fusion pour l’accès administrateur, tout en conservant les valeurs techniques Central exactes.

Dépannage

Redirection vers un hôte Central

Ne pas revenir à ce qui semblerait être l’ancien état. Vérifier d’abord le certificat, la chaîne de redirection complète, le tenant de destination et la réussite de la connexion. Les anciens noms dans l’infrastructure d’exécution peuvent rester corrects.

Page bloquée ou vide

Effectuer le test dans un navigateur sans extensions ou dans une fenêtre de navigation privée, puis relever l’heure, l’URL de départ, l’hôte final et le texte de l’erreur. Consulter ensuite les journaux des systèmes de proxy, de sécurité DNS, de filtrage web et d’inspection TLS utilisés pour identifier l’hôte précisément bloqué. Modifier uniquement ce besoin avéré, sans autoriser préventivement des caractères génériques.

Si plusieurs connexions ou tenants indépendants sont touchés en même temps, consulter Sophos Status pour détecter une éventuelle panne générale du service. La page d’état fournit un indice de diagnostic ; les modifications locales restent fondées exclusivement sur des causes avérées.

Erreur de connexion ou d’accès conditionnel

Comparer chronologiquement les événements de connexion Sophos et, si un IdP est utilisé, ceux de ce dernier. Ne pas recréer une application IdP, une URL de callback ou une stratégie d’accès conditionnel uniquement en raison du nouveau nom visible. Pour le diagnostic et le retour arrière, suivre exclusivement le runbook SSO lié plus haut qui correspond au parcours de connexion concerné ; conserver l’administrateur de secours testé.

Élément de menu manquant

Vérifier d’abord le type de compte et le rôle. Rechercher ensuite sous My Environment, à l’aide de l’icône en forme de roue dentée pour Global Settings, dans le profil et dans Sophos Help. L’absence d’un élément de menu peut résulter d’une restriction de rôle ou de licence ; elle ne prouve pas l’échec du changement de nom.

Tenants, produits ou clients manquants

Se déconnecter, recommencer dans une fenêtre de navigation privée avec l’identité prévue, puis vérifier le type de compte et le tenant. Ne pas créer de tenants de remplacement, d’essais ni de nouvelles associations de partenaires en guise de réparation.

Si l’accès reste perturbé après ces vérifications, rassembler la plage horaire avec le fuseau horaire, l’identité concernée, le tenant ou Customer ID, le navigateur, l’hôte de départ et l’hôte de destination, le texte de l’erreur ainsi que des captures d’écran expurgées. Effectuer ensuite l’escalade via Ouvrir un ticket de support Sophos avec Support Assistant.

Retour arrière local

Le client ne peut pas annuler le changement de nom de Sophos Central en Sophos Fusion effectué par l’éditeur. Seules les adaptations locales réalisées dans le cadre de ce changement peuvent être annulées :

• les favoris et liens de documentation internes,
• les associations d’URI de connexion dans le gestionnaire de mots de passe,
• les règles précises de proxy, de DNS ou de filtrage web.

Avant le retour arrière, reprendre la valeur précédente dans la documentation du changement, puis tester de nouveau l’accès. Les adaptations de l’IdP ou de l’accès conditionnel ne font pas partie de ce retour arrière local ; elles ne sont annulées qu’en suivant le runbook SSO lié plus haut pour le parcours de connexion concerné et sa procédure de retour arrière documentée. L’ancien nom d’hôte Central ne constitue pas un chemin de retour arrière garanti. Les hôtes d’API, callbacks, URL en libre-service et autres valeurs techniques volontairement laissées inchangées lors de cette transition ne doivent pas être modifiés.