Gérer les appareils et groupes Sophos Endpoint

Les groupes d’ordinateurs donnent aux stratégies Endpoint une cible stable. Ils ne répondent toutefois pas à toutes les questions d’inventaire ou d’identité : les tags et les actions générales relèvent de la plateforme Central commune, tandis que les groupes d’utilisateurs suivent un modèle d’identité distinct.

Procédure rapide : définir le modèle de groupes, créer un groupe sous My Products > Endpoint > Computers > Computer Groups, affecter les ordinateurs, puis vérifier les stratégies réellement appliquées sur le groupe et sur chaque ordinateur pilote. Clarifier séparément le cycle de vie avant toute suppression, tout nettoyage ou toute migration.

Important : un ordinateur ne peut appartenir qu’à un seul groupe d’ordinateurs. Les tags ajoutent plusieurs attributs flexibles ; Agent Mode décrit l’étendue logicielle. Ces niveaux ne sont pas interchangeables.

Distinguer les groupes Endpoint des fonctions de plateforme

La vue commune My Environment > Computers & Servers sert de base aux filtres, colonnes, tags, à Tamper Protection, à l’étendue logicielle, au Health Reset et à la suppression générale. Gérer l’inventaire des appareils Sophos Fusion (anciennement Sophos Central) décrit cette procédure de plateforme sans la dupliquer ici.

Sophos remplace l’ancienne page My Products > Endpoint > Computers par cette vue unifiée. Pendant la transition, l’ancienne page peut encore apparaître dans un tenant et reste le chemin d’accès à Computer Groups ; les procédures de groupe ci-dessous utilisent donc ce chemin.

Utilisateurs, logins et groupes d’utilisateurs sont aussi des objets distincts. Affecter correctement les utilisateurs et groupes Sophos Fusion Endpoint explique si une stratégie doit suivre une personne ou un appareil et comment l’ordre s’applique lorsque plusieurs stratégies correspondent. Cet article reste centré sur les groupes d’ordinateurs et leur cycle de vie Endpoint.

Définir les groupes avant le déploiement

Les groupes d’ordinateurs conviennent aux limites organisationnelles stables. Un modèle pratique reflète des exigences de protection réellement différentes : appareils pilotes, postes standard, postes critiques, systèmes kiosque ou de production et postes virtuels non persistants. Les services ne constituent de bons groupes que s’ils exigent réellement des stratégies différentes.

1. Ouvrir My Products > Endpoint > Computers, puis Computer Groups.
2. Cliquer sur Add Computer Group.
3. Saisir un nom sans ambiguïté et une courte description.
4. Affecter uniquement les ordinateurs prévus dans la liste disponible, puis enregistrer.

L’affectation d’un ordinateur déjà groupé à un nouveau groupe le retire de l’ancien. Pour modifier un groupe, ouvrir son nom, choisir Edit dans le volet gauche, adapter Assigned Computers, puis enregistrer. Delete supprime uniquement le groupe, pas ses ordinateurs. Documenter les anciennes et nouvelles affectations et commencer par quelques appareils pilotes avant une modification en masse.

Utiliser les tags

Les tags complètent le groupe fixe par plusieurs attributs combinables, par exemple owner=finance, site=zuerich, criticality=high ou lifecycle=pilot. Un appareil accepte au maximum 15 tags et jusqu’à cinq tags peuvent être épinglés dans la liste commune. Ils facilitent les filtres, mais ne contrôlent pas l’appartenance au groupe. L’inventaire Central décrit leur création, leur vérification et leur retrait.

Vérifier les stratégies

1. Ouvrir le groupe sous My Products > Endpoint > Computers > Computer Groups.
2. Choisir Policies et contrôler les stratégies actives appliquées au groupe.
3. Ouvrir une stratégie si nécessaire. Sa modification affecte tous les utilisateurs et groupes auxquels elle est affectée ; vérifier donc la portée et l’ordre avant d’enregistrer.
4. Ouvrir un appareil pilote sous My Environment > Computers & Servers et comparer dans Policies la stratégie effective de chaque type.
5. Corriger la cible ou l’ordre, puis contrôler à nouveau après le prochain contact avec Central.

Le type de cible n’a aucune priorité automatique : si des stratégies utilisateur et ordinateur du même type correspondent, leur ordre décide. Voir Construire correctement les stratégies Sophos Fusion Endpoint.

Interpréter Agent Mode et l’état de l’appareil

Endpoint, XDR et XDR Sensor représentent des étendues logicielles différentes ; XDR Sensor n’inclut pas la protection Sophos contre les malwares. Dans l’objet ordinateur, Summary montre l’étendue et le groupe, Status les évaluations Health et Policies les stratégies effectives. L’inventaire Central couvre les colonnes, filtres et actions logicielles de la vue commune.

Examiner les appareils inactifs

Un objet inactif est d’abord un signal, pas un ordre de suppression. Avant de le retirer, il faut déterminer pourquoi le contact manque :

• l’appareil est hors service ou remplacé ;
• l’utilisateur est absent pour une longue période ;
• l’agent, le proxy ou la connexion réseau est défaillant ;
• l’ordinateur a été cloné depuis une ancienne image ;
• l’appareil appartient à un laboratoire, une infrastructure VDI ou un Update Cache.

La nouvelle vue commune montre aussi les appareils inactifs depuis plus de 30 jours. Les anciennes listes Endpoint exigent éventuellement le filtre Not online recently.

Last Active n’est actualisé en moyenne qu’une fois par heure. Un Event peut donc porter un horodatage plus récent que la valeur Last Active visible. Ce n’est pas automatiquement une erreur de données.

Le même modèle d’actualisation différée vaut pour Online et Last Activity. Après la connexion d’un nouvel utilisateur, Central peut déjà lui associer l’appareil alors que les horodatages montrent encore l’ancien état pendant environ une heure. Si l’appareil passe ensuite hors ligne, la correction prend davantage de temps.

Dans Computer Report, Online et Last User n’ont pas la même signification : Online repose sur le dernier message d’état traité. Last User ne change que lorsqu’un autre compte utilisateur unique se connecte pour la première fois à l’appareil. Une valeur Last User très ancienne ne prouve donc pas que l’Endpoint est hors ligne depuis cette date.

Nettoyage automatique

Sous Global Settings > Products and Services > Endpoint and Server > Removal of Inactive Devices, des règles distinctes peuvent être créées pour les Endpoints et les Servers.

Sophos distingue les Targeted rules pour les groupes sélectionnés et une Global rule pour tous les autres appareils. Le délai global doit être supérieur aux délais des règles ciblées. Les Update Caches, Message Relays et appareils spécialisés rarement démarrés appartiennent à des groupes explicitement exclus.

Il est possible de créer deux règles ciblées. Au maximum quatre groupes peuvent être exclus de la règle globale ; les sous-groupes comptent séparément et ne sont pas exclus automatiquement. Sophos évalue les règles chaque jour à minuit dans la région de données du tenant.

Les clients MSP et Marketplace doivent choisir au moins 31 jours d’inactivité pour une règle. Pour les clones VDI créés avec --nonpersistent, Permanently remove VDI desktops peut être activé ; ces appareils ne peuvent ensuite plus être restaurés. Le master Gold Image lui-même n’est pas supprimé par ces règles.

Les appareils supprimés restent 120 jours dans le Recovery Report. Ils peuvent être restaurés pendant les 30 premiers jours. Update Cache et Message Relay ne sont pas restaurés avec eux.

Retirer n’est pas désinstaller : la règle efface l’objet Central. Le traitement du logiciel local doit être défini auparavant.

Distinguer retrait automatique et suppression générale

Une règle de retrait automatique retire les appareils inactifs de la gestion, mais ne désinstalle pas le logiciel Sophos resté localement. Sur les systèmes Windows actuels pris en charge avec Core Agent 2023.2 ou ultérieur, Delete et l’expiration de licence déclenchent au contraire le back-off documenté : Tamper Protection et les composants de protection sont retirés, mais Sophos Endpoint Agent doit encore être désinstallé localement pour un retrait complet.

Le Recovery Report et le mot de passe Tamper Protection restent disponibles 120 jours ; l’appareil peut être restauré pendant les 30 premiers jours. Update Cache et Message Relay ne sont pas restaurés. Voir Désinstaller Sophos Fusion Endpoint sous Windows et l’inventaire Central.

Ne pas confondre migration et changement de groupe

Change group déplace l’objet dans le même tenant. Un transfert vers un autre tenant est une Device Migration par API avec des jobs d’envoi et de réception distincts. Les appareils restent en file jusqu’à 14 jours ; les appareils durablement hors ligne doivent ensuite être remis en file. Suivre Migrer des appareils Sophos Endpoint entre tenants Central.

Traiter correctement les appareils en double

Chaque installation Sophos reçoit un Device ID unique lors de l’enregistrement. Si un système déjà enregistré est cloné sans préparation, plusieurs Endpoints peuvent utiliser le même ID. Central ne montre d’abord qu’un objet d’appareil qu’ils écrasent à tour de rôle. Automatic Duplicate Detection reconnaît ce modèle sous Windows, macOS et Linux, réenregistre les appareils concernés et crée ainsi des objets supplémentaires.

L’appareil réenregistré hérite du groupe, des policies et de l’affectation de produits de l’objet d’origine. Contrôlez ces valeurs après la Deduplication, car l’affectation héritée peut ne pas convenir à chaque clone.

Sophos Fusion signale ce modèle à trois endroits : le Dashboard affiche l’Alert Duplicate device detection ; l’onglet Events de l’appareil contient Device has been detected as a duplicate device puis, après le réenregistrement, Device has been de-duplicated from: <DEVICENAME>. Les administrateurs reçoivent aussi un e-mail intitulé [Medium] Alert for Sophos Central: We’ve detected a cloned device.

Un Alert tel que Device has been detected as a duplicate device ne demande pas de supprimer immédiatement l’enregistrement marqué. D’autres clones utilisant le même ID peuvent encore dépendre de l’objet d’origine. S’il est retiré trop tôt, ils ne peuvent plus communiquer avec Central et doivent être réinstallés. Sophos recommande de conserver l’objet d’origine marqué pendant au moins deux semaines, sauf si tous les systèmes concernés ont été identifiés avec certitude.

Central affiche donc une case de confirmation supplémentaire lors de la suppression de cet enregistrement d’origine. Ne la cochez et ne poursuivez qu’après avoir vérifié qu’aucun autre appareil ne tente de communiquer avec l’ID marqué pour la Deduplication.

Procédure sûre :

1. Examiner l’Alert et les Events de l’appareil concerné.
2. Rechercher son nom et comparer les enregistrements actifs et plus anciens avec Last Active.
3. Vérifier le groupe, les policies et l’affectation de produits du nouvel objet.
4. Corriger la cause dans le Deployment, le Gold Image ou le Snapshot.
5. Supprimer uniquement lorsque tous les systèmes utilisant l’ancien ID sont connus et qu’aucun ne communique encore par son intermédiaire.

Dans un environnement VDI non persistant, chaque nouveau clone ou retour à un Snapshot peut déclencher un nouvel enregistrement. Les objets supplémentaires ne signalent donc pas nécessairement une nouvelle erreur de Deduplication. Préparez le Gold Image selon la procédure prise en charge décrite dans Déployer Sophos Fusion Endpoint pour les VDI et Gold Images.

Même avec une image correctement préparée, chaque nouvelle VM crée normalement un nouvel objet d’appareil dans Central ; en revanche, la restauration d’une VM existante vers un Snapshot ne devrait plus déclencher de Deduplication après la préparation prise en charge. Répétez cette préparation avant chaque Gold Image nouveau ou mis à jour. Sinon, l’image peut se réenregistrer, recevoir un ID et transmettre cet ID partagé à tous les clones suivants.

Les instances AWS et les VM Azure passent également par cette détection. Leur enregistrement d’instance ou de VM peut rester temporairement dissocié de l’enregistrement de serveur ; Central traite alors l’appareil comme un serveur normal. L’enregistrement le relie ensuite à un nouvel enregistrement de serveur. Les Windows Servers avec Server Lockdown actif sont exclus de la Deduplication. Les appareils partageant un ID mais utilisant des systèmes d’exploitation différents sont détectés comme doublons, mais ne sont pas réenregistrés automatiquement. Corrigez les Alerts récurrents à la source de l’image et de l’enregistrement au lieu de les masquer par des suppressions répétées.

Important : Central ne peut pas réparer la suppression accidentelle de l’objet d’origine partagé pour les clones qui ne communiquent plus. Il faut alors réinstaller Sophos Agent.

Interpréter correctement les redémarrages

Une première installation ou la suppression d’un produit concurrent peut exiger un redémarrage. Les mises à jour de produit n’en nécessitent souvent pas immédiatement. Toutefois, si un appareil n’a pas redémarré depuis plusieurs mois, deux états de mise à jour successifs peuvent chacun demander un redémarrage. Sophos recommande alors environ 20 minutes entre les deux cycles afin que la première mise à jour se termine complètement.

Les anciens Alerts Windows et macOS sont retirés de la vue détaillée après 90 jours. Un Health State rouge peut néanmoins persister jusqu’à ce que la cause soit corrigée et l’état réinitialisé. La disparition du vieil Alert ne prouve pas à elle seule une réparation.

Contrôle mensuel

Un contrôle mensuel court évite l’accumulation de zones aveugles :

1. filtrer les appareils sans activité récente et identifier leur propriétaire ;
2. traiter les problèmes Health selon leur cause et pas seulement leur couleur ;
3. vérifier Product unassigned, Upgrade available et les appareils non pris en charge ;
4. justifier et corriger Tamper Protection avec l’état Off ;
5. corriger les ordinateurs sans groupe ou avec des tags incorrects ;
6. exclure Update Caches, Message Relays et Golden Images VDI des règles de suppression ;
7. désinstaller de manière contrôlée les appareils inutiles, puis les supprimer.

Questions fréquentes