Remplacer le conteneur Sophos Mobile : transférer les données et les appareils en sécurité

Décision en bref : Ne plus déployer le conteneur Sophos, désormais non pris en charge, avec Sophos Secure Email et Sophos Secure Workspace. Une stratégie de conteneur Samsung Knox relève d’un autre mode de gestion : la fin du conteneur Sophos ne signifie pas la fin générale de Samsung Knox Workspace. Pour les appareils existants, déterminer d’abord le type de conteneur, le mode de gestion et les données professionnelles présentes. Ni une nouvelle inscription ni le retrait de l’ancien appareil ne transfèrent automatiquement les données du conteneur.

Quel conteneur est concerné ?

Conteneur Sophos : Le conteneur Sophos, avec Secure Email et Secure Workspace, a atteint sa fin de prise en charge. Sophos indique le profil professionnel Android Enterprise et Apple User Enrollment comme futurs modes de gestion pour les scénarios Android et Apple correspondants. Ce sont des modèles cibles de gestion, pas une garantie de transfert des fichiers, messages, comptes ou paramètres d’applications.

Le 6 mai 2024, les applications Secure Workspace pour Android et iOS ont cessé de pouvoir télécharger des documents professionnels depuis Sophos Mobile. Le 7 octobre 2024, Sophos a annoncé retirer la possibilité de créer de nouvelles stratégies de conteneur Android/iOS ainsi que d’ajouter et de mettre à jour des documents professionnels. Le 21 octobre 2024, Sophos a indiqué commencer à supprimer les documents professionnels Secure Workspace précédemment chargés dans Sophos Mobile. Cela ne prouve pas que toutes les copies ont été supprimées ni qu’une méthode de récupération est aujourd’hui prise en charge ; une entrée de fichier encore visible ne prouve pas que son contenu reste accessible dans le service.

Conteneur Samsung Knox : Les pages Sophos encore accessibles sur les Knox container policies décrivent les conteneurs Samsung Knox : exigences de mot de passe, restrictions et compte de messagerie. Elles ne prouvent pas qu’un nouveau déploiement Knox soit actuellement pris en charge sur un appareil donné.

Samsung distingue les anciens conteneurs CL/COM, Knox Workspace en tant que conteneur géré et les profils professionnels Android Enterprise. Même si Samsung décrit toujours Knox Workspace comme un conteneur géré sur les appareils compatibles, cela ne garantit ni sa prise en charge par Sophos Mobile dans votre propre tenant ni la disponibilité de nouvelles fonctions Knox.

Dans Sophos Mobile, le mode Android Device administrator est obsolète et n’est disponible que pour Android 9 ou une version antérieure. Aucun de ces éléments ne fournit de date générale d’arrêt de Knox.

Faire l’inventaire sans rien modifier

Établir pour chaque appareil une liste de travail indiquant les responsables et l’état des validations :

Relever l’appareil, son type de propriété (entreprise ou personnel), son modèle, la version d’Android ou d’iOS, l’utilisateur et le service concerné. Comparer le type de conteneur et le mode de gestion réels sur l’appareil et dans le tenant. Dans Sophos, la page Show device fournit notamment des indices sous Status, Policies, Device properties, Installed apps et, pour Samsung, Knox apps et Knox system apps. Une application affichée ne constitue pas une sauvegarde de ses données.
Examiner les stratégies Knox attribuées, notamment les exigences de mot de passe, Restrictions et Email account, sans les modifier. Noter les comptes professionnels, fichiers, pièces jointes et applications présents dans le conteneur, ainsi que les responsables de ces données. La présence d’un compte Exchange dans la configuration ne prouve ni que la connexion fonctionne encore ni que les courriels peuvent être exportés localement.
Vérifier avec le responsable des données si les contenus se trouvent dans le service d’origine ou uniquement en local dans le conteneur, si une sauvegarde autorisée existe déjà et si l’accès fonctionne aujourd’hui. Pour Knox, contrôler la licence liée à l’appareil et sa date d’expiration : une licence Workspace expirée peut bloquer l’accès, surtout sur les anciennes versions d’Android, sans nécessairement effacer les données. Cela ne constitue pas une méthode universelle de récupération.

Arrêt si l’accès aux données manque : Ne pas essayer des mots de passe au hasard ni réinitialiser le conteneur. Une stratégie de mot de passe Knox peut effacer le conteneur après un trop grand nombre d’échecs. L’ancienne page en libre-service ResetContainerPassword ne contient aujourd’hui qu’un avis sur la fin de prise en charge du conteneur Sophos et un renvoi vers l’équipe informatique, sans procédure de réinitialisation ou de récupération.

Valider le transfert des données avant toute désinscription

Avant toute modification, l’équipe informatique, l’utilisateur et le responsable des données doivent, selon le type de propriété et les règles de protection des données, définir pour chaque catégorie de données concernée une méthode autorisée d’exportation propre à l’application ou de nouvel accès côté serveur, ainsi que la nouvelle destination.

Une liste de noms de fichiers ou d’applications installées ne suffit pas : pour un petit groupe pilote, ouvrir dans la destination les documents approuvés et les messages nécessaires avec l’identité prévue, puis vérifier les droits d’accès. Ne considérer une restauration comme démontrée que s’il existe effectivement une procédure de sauvegarde et de restauration approuvée. Rouvrir un document côté serveur ne restaure pas les données locales effacées du conteneur.

Condition de sauvegarde : Pour chaque appareil, catégorie de données nécessaire et identité prévue, vérifier soit un accès autorisé et indépendant sur la nouvelle destination approuvée, soit une sauvegarde effectivement restaurée sur une destination distincte et approuvée pendant le pilote. Vérifier les contenus et droits restaurés avec le responsable des données ; documenter et faire approuver explicitement tout contenu uniquement local exclu. Une restauration sur le seul ancien appareil ne permet pas sa réinitialisation, sa désinscription ou sa suppression. Si un élément nécessaire manque, arrêter et laisser l’appareil inchangé.

Si l’accès échoue, ou si une restauration nécessaire échoue, ne pas désinscrire l’appareil ni effacer ses données. Transmettre le cas, avec le type d’appareil, le mode de gestion, l’état de la licence et la nature de l’erreur, aux interlocuteurs Sophos ou Samsung compétents et au responsable des données. La solution de repli peut consister à laisser l’ancien appareil inchangé ; aucune récupération technique ne doit être présumée. Pour Secure Workspace, il n’existe pas de preuve d’une possibilité générale de téléchargement aujourd’hui ni de restauration des documents supprimés du service.

L’option Knox Allow data export permet aux applications personnelles d’accéder aux données du conteneur ; ce n’est ni une fonction de sauvegarde prête à l’emploi ni une autorisation générale de transférer des données professionnelles vers l’espace personnel. Allow all certificates, dans l’ancien profil de messagerie Knox, n’est pas non plus une solution acceptable pour contourner des problèmes de connexion ou de certificats. Ne pas activer ces options à titre préventif.

Validation et pilote

Planifier le mode de gestion adapté à chaque appareil seulement une fois les données du pilote lisibles dans la nouvelle destination et la marche à suivre en cas d’échec du transfert définie. La réussite du pilote ne prouve pas que les données stockées uniquement en local soient accessibles sur tous les autres appareils. Pour chaque appareil concerné et chaque catégorie de données, vérifier la méthode d’accès autorisée et l’accord du responsable des données avant toute désinscription, suppression, désinstallation d’une stratégie ou d’une application, ou opération Wipe.

Mode de gestion selon le type de propriété

Avant l’une ou l’autre procédure, vérifier pour chaque appareil l’accès aux données et l’accord du responsable des données comme indiqué plus haut. Pour une ancienne inscription en mode Device administrator, Unenroll désactive l’administrateur d’appareil Sophos Mobile Control, retire les identifiants de connexion au serveur et les autres données reçues de celui-ci, puis réinitialise Sophos Intercept X for Mobile ; Delete supprime ensuite la fiche de l’appareil et les données qui le concernent stockées par Sophos Mobile. Désinscrire avant de supprimer : supprimer un appareil encore inscrit peut le rendre inutilisable. Cette procédure ne transfère aucun contenu local des conteneurs Knox ou Sophos. Ne pas l’appliquer à un profil professionnel Android Enterprise existant : son retrait efface toutes les applications et données du profil. La désinscription d’un appareil Android Enterprise entièrement géré exige une réinitialisation d’usine. Vérifier le mode réel et faire valider les risques de perte de données avant toute action.

Contrôle avant action destructive (avant Wipe ou Delete) : Sur un appareil Android Enterprise entièrement géré, Delete déclenche lui-même une réinitialisation d’usine ; Unenroll avant Delete ne permet pas de l’éviter. Pour cet appareil précis, confirmer son identité, le sort approuvé des données et la personne responsable de la réinitialisation et de la réinscription, ainsi que la Factory Reset Protection (FRP) : valider les identifiants des comptes Google configurés et vérifier que le responsable peut utiliser ou récupérer leurs identifiants de connexion après la réinitialisation. Des comptes FRP invalides ou des identifiants inconnus peuvent rendre l’appareil inutilisable. Si la responsabilité de l’appareil ou des comptes n’est pas établie, arrêter et transmettre le cas sans Wipe, Unenroll ni Delete. Le retrait d’un profil professionnel efface ses applications et données ; la procédure Device administrator ci-dessous exige de confirmer d’abord cet ancien mode.

Pour les appareils Android appartenant à l’entreprise déjà inscrits dans Sophos Mobile en mode Device administrator, le passage documenté par Sophos à la gestion complète Android Enterprise impose d’abord une réinitialisation d’usine (dans la console d’administration, page Show device : Actions > Wipe), puis seulement la nouvelle inscription. Avant le Wipe, configurer Android Enterprise, vérifier l’identité de l’appareil et les pertes de données possibles, et confirmer pour chaque appareil l’accès aux données ainsi que l’accord du responsable des données ; sans ces preuves, ne pas lancer le Wipe. Pour les appareils Android personnels, l’autre procédure documentée ne s’applique qu’à une inscription existante en mode Device administrator : après la configuration d’Android Enterprise, dans la console d’administration, page Show device, effectuer d’abord Actions > Unenroll, puis Actions > Delete, et enfin inscrire l’appareil avec un profil professionnel Android Enterprise. Il ne s’agit pas d’une action du portail libre-service (SSP) destinée à retirer un profil professionnel déjà présent. Ces procédures concernent les modes de gestion, et non la migration des contenus locaux des conteneurs Knox ou Sophos.

Les effets des actions Unenroll, Delete, désinstallation d’une stratégie, désinstallation d’une application et Wipe diffèrent ; un Wipe, en particulier, peut supprimer des données de façon irréversible. Une tâche réussie dans la console ne suffit jamais, à elle seule, à prouver que les données ont été intégralement transférées.

Contrôle final et condition d’arrêt

Après la transition contrôlée sur les appareils pilotes, vérifier séparément la connexion, le profil professionnel ou User Enrollment, les applications gérées et l’accès aux données professionnelles approuvées.

Arrêt pour chaque appareil : Avant toute modification, il faut disposer de l’accord requis et, soit d’un accès confirmé et autorisé aux données professionnelles approuvées dans la nouvelle destination, soit, si cela s’applique, d’une restauration dont la réussite a été démontrée. Si l’accès manque et qu’aucune restauration applicable n’a été démontrée, laisser l’ancien appareil inchangé et transmettre le cas aux responsables compétents. Sans accord non plus, ne pas toucher à l’ancien appareil. Ni le pilote ni la désinscription ne prouvent que des données locales effacées pourront être restaurées.

Une sauvegarde restaurée uniquement sur l’ancien appareil ne satisfait jamais cette condition. Pour chaque catégorie de données et identité requises, il faut une destination approuvée accessible indépendamment ou une sauvegarde restaurée et validée sur une autre destination approuvée pendant le pilote, avec l’accord du responsable pour tout contenu uniquement local exclu. Sans accès indépendant prouvé, contrôle des comptes FRP, le cas échéant, ou validation, aucune action destructive.