Migrer des appareils Endpoint entre tenants Central
Lors d’acquisitions, de consolidations de tenants ou de changements de partenaire, il peut être nécessaire de déplacer des Endpoints gérés vers un autre Sophos Central Tenant. Il ne s’agit pas d’un simple déplacement d’appareil : le tenant cible possède ses propres licences, Policies, exceptions, administrateurs et règles de conservation des données.
Avant la migration
La source et la cible sont inventoriées :
- structure des tenants et de l’organisation,
- licences Endpoint et XDR actives,
- Agent Mode et systèmes d’exploitation,
- Policies, groupes, exceptions et Website Lists,
- Update Caches, Message Relays et Proxies,
- appareils isolés, Alerts ouverts et investigations en cours,
- plateformes VDI, Server et Legacy.
Il ne faut pas présumer que les Policies et exceptions sont transférées avec l’ordinateur. Une protection au moins équivalente doit être préparée à l’avance dans le tenant cible.
Utiliser le processus de migration pris en charge
Sophos propose une migration Endpoint basée sur API pour les scénarios pris en charge. Des API Credentials avec les droits strictement nécessaires sont utilisés. Ils sont stockés dans un Secret Store puis renouvelés ou supprimés après le projet.
L’authentification, le Tenant ID, la région des données, les rôles, les Rate Limits et le traitement sécurisé des erreurs sont expliqués dans Automatiser l’API Sophos Central Endpoint en sécurité.
La disponibilité exacte et les restrictions dépendent du type de tenant, de la licence, de la plateforme et de la version de l’Agent. Le Workflow Sophos actuel est vérifié avant le projet. La modification manuelle de fichiers MCS ou de Tenant IDs ne constitue pas une alternative prise en charge.
Device Migration est activé pour une durée limitée dans les tenants émetteur et récepteur. L’administrateur doit disposer de droits Admin dans les deux comptes et de Service Principal Super Admin API Credentials.
Un Receiving Job est d’abord créé dans la cible. Sa Job ID et son Access Token servent ensuite au Sending Job contenant la liste précise des Endpoints. Ces Tokens ne sont conservés ni dans des tickets ni dans le Shell History.
Déplacer un groupe Pilot
Quelques appareils représentatifs sont migrés en premier. Les points suivants sont ensuite vérifiés :
- L’appareil apparaît uniquement dans le tenant cible attendu.
- La communication et Last Activity sont à jour.
- La licence et l’Agent Mode sont corrects.
- Le groupe cible et les Policies effectives sont corrects.
- Updates, Protection Tests, Alerts et Isolation fonctionnent.
- Les anciens Caches ou Relays liés au tenant ne sont plus nécessaires.
La migration progressive ne commence qu’après cette validation. Les Critical Servers, VDI et Remote Devices constituent des vagues séparées.
Sophos conserve un ordinateur jusqu’à 14 jours dans la Migration Queue. Un appareil qui reste Offline échoue ensuite et doit être remis manuellement dans la file. Les appareils de collaborateurs absents et les systèmes rarement connectés ne sont donc pas comptés silencieusement comme réussis.
Cas particuliers
Un appareil Offline ou endommagé ne peut pas être transféré à distance de manière fiable. Une réparation ou une nouvelle installation avec l’Installer du tenant cible peut être nécessaire.
Lorsque Tamper Protection est activé, aucun contournement non autorisé de Removal ou Registry n’est utilisé. La procédure correcte est décrite dans Désinstaller Sophos Endpoint avec Tamper Protection activé.
Travaux de clôture
Après la dernière vague, la source et la cible sont comparées. Les appareils orphelins du tenant source ne sont supprimés qu’après confirmation de l’enregistrement cible et de la conservation des Incident Data pertinents. Les API Credentials, groupes temporaires et Migration Exceptions sont supprimés.
Les Event Logs et Audit Logs des deux tenants servent au contrôle. L’API Status est comparé à l’enregistrement réellement visible et à la Policy effective dans la cible.
Dans le tenant source, l’événement d’audit Send endpoints to another tenant confirme l’envoi. Sur l’ordinateur, Device registered with new account <AccountID> confirme la réussite, tandis que Device failed to register with new account <AccountID> signifie que le tenant source continue à gérer l’appareil. Dans le tenant cible, l’événement Allow endpoints to migrate to this tenant est attendu. Il faut ensuite contrôler l’enregistrement, l’utilisateur attribué et le statut de mise à jour réussie de l’agent sur l’appareil migré.