Configurer le tenant Sophos Mobile et transmettre son administration

Sophos Mobile se configure dans un tenant Sophos Fusion existant. Cette procédure s’arrête à la préparation et à la décision d’autorisation d’un pilote limité : elle ne comprend ni enrôlement effectué ni déploiement massif en production. Mobile Device Management (MDM) et Mobile Threat Defense correspondent à des licences et des fonctionnalités distinctes. Avant toute modification, consigner le tenant, l’édition, le rôle, la plateforme des appareils, leur mode de propriété et la procédure de retour arrière. L’activation générale du tenant et la sécurisation transversale de ses administrateurs sont traitées dans Mettre en service un tenant Sophos Fusion en toute sécurité.

1. Vérifier au préalable la licence et les droits

Dans Profile icon > Licensing, au sein du bon tenant Fusion, comparer le produit, l’édition et les droits disponibles à la commande. Sophos Mobile Device Management (anciennement Central Mobile Standard) couvre la gestion MDM d’Android, iPhone/iPad, Mac et Windows ; Sophos Mobile Threat Defense (anciennement Intercept X for Mobile) concerne la gestion d’Intercept X for Mobile et de Sophos Chrome Security. Sophos Mobile (anciennement Central Mobile Advanced) regroupe les deux. La présence d’une interface Mobile ne prouve pas l’existence de droits MDM particuliers. Ne pas activer une licence par supposition : activation, renouvellement et conséquences des licences relèvent de la procédure de gestion des licences Fusion, après vérification du tenant et de la commande.

Établir la région séparément : dans le compte Fusion concerné, ouvrir My Products > Mobile, relever la région dans l’URL du navigateur après smc-user-if-cloudstation- et la consigner pour la validation de l’infrastructure et du réseau. Les destinations des serveurs Sophos Mobile dépendent de la région ; le responsable réseau confronte les connexions nécessaires pour la région et la plateforme réelles à la documentation réseau Sophos en vigueur. Ne déduire la région ni de l’emplacement ou de la langue de l’entreprise ni du fuseau horaire personnel de l’administrateur. Sans région attestée ni autorisation réseau requise, pas de Go pour la voie pilote concernée.

Utiliser un Admin ou un Super Admin habilité pour la configuration initiale. Les rôles Fusion se traduisent ainsi dans Mobile :

Définir dans Fusion les personnes responsables et leurs rôles selon Attribuer correctement les rôles d’administration, puis vérifier dans Mobile, à l’aide de comptes distincts Help Desk et Read-only, les menus et actions effectivement accessibles. Ne pas rétrograder le seul compte administrateur opérationnel. La documentation MDM autorise également le Helpdesk à inscrire des appareils et à installer des applications. Les fonctions critiques telles que la définition des paramètres ainsi que la création, la modification et la suppression d’appareils, de groupes d’appareils et de paquets sont exclues pour ce rôle Mobile. La description des rôles de Threat Defense ne mentionne, parmi les actions autorisées au Helpdesk, que des tâches générales d’assistance ; les fonctions critiques citées y sont également expressément exclues. Ne pas en déduire un droit universel d’enrôlement pour Helpdesk, quelle que soit l’édition. Le raccordement d’un annuaire/LDAP et la synchronisation des identités exigent leur propre procédure d’autorisation et de retour arrière ; ils ne découlent pas de l’attribution des rôles.

2. Définir les réglages de base sans modifier les appareils

Les réglages d’affichage personnels de Sophos Mobile Admin ne s’appliquent qu’au compte administrateur connecté. Sophos mentionne également la langue de l’interface utilisateur parmi les réglages configurables, mais la page consacrée aux paramètres personnels ne décrit ni sélecteur de langue, ni son emplacement, ni son utilisation. La langue de l’interface est distincte de celle des e-mails sortants décrite ci-dessous ; cela ne prouve pas qu’elle soit automatiquement reprise de la langue de Fusion.

Dans Sophos Mobile Admin > Setup > General, distinguer la portée de chaque paramètre :

1. Personal : régler le fuseau horaire, les unités de mesure, le nombre de lignes des tableaux, Expert mode et les plateformes d’appareils affichées pour le compte administrateur connecté, puis sélectionner Save. Chaque paramètre a les effets suivants :

   • Time zone définit le fuseau horaire dans lequel les dates et les heures sont affichées.
   • Unit system définit le système d’unités utilisé pour les longueurs : Metric ou Imperial.
   • Lines per page in tables définit le nombre maximal d’entrées affichées par page de tableau.
   • Lorsque Expert mode est activé, la page Show device contient l’onglet Custom properties, avec les propriétés personnalisées de l’appareil, et l’onglet Internal properties, avec des propriétés supplémentaires transmises par l’appareil. Plusieurs pages de configuration des stratégies affichent également la section Extra settings, qui permet de configurer des paramètres facultatifs.

   Les plateformes activées déterminent la visibilité des pages et paramètres correspondants ; elles n’activent ni licence ni enrôlement d’appareil. Après l’enregistrement, vérifier que la plateforme attendue figure dans la navigation. Si une vue manque, contrôler d’abord le filtre personnel des plateformes et le rôle ; rétablir la sélection précédente si nécessaire.

2. IT contact : renseigner une adresse d’assistance surveillée et un contact joignable, choisir Save, puis contrôler le texte sur un appareil de test prévu à cet effet, uniquement après l’autorisation distincte du pilote. Ces coordonnées apparaissent sur les appareils des utilisateurs. Ne pas saisir de numéro privé ni de données personnelles non autorisées. Enregistrer toute correction dans le même onglet et la vérifier à nouveau sur l’appareil de test.

3. Email configuration : définir la langue des e-mails envoyés par Sophos Mobile et sélectionner Save. Il ne s’agit pas de configurer un relais SMTP, une boîte Exchange ou un proxy EAS. Vérifier une véritable occasion d’envoi de message Mobile pendant le pilote : Save seul ne prouve pas la distribution. Si la langue est incorrecte, rétablir la valeur précédente et examiner un autre message de test.

La section Setup contient aussi des options liées aux plateformes, à la confidentialité et aux intégrations. Ne pas activer systématiquement les certificats APNs, Android Enterprise, la synchronisation des appareils, les autorisations de traitement des données ou EAS. Le fuseau horaire personnel n’est pas celui du tenant dans son ensemble ; le contact informatique et la langue des e-mails relèvent, en revanche, de la configuration générale de Mobile. Le guide de démarrage mentionne en outre le Fusion Self Service Portal comme étape de configuration distincte.

3. Préparer seulement les appareils et l’enrôlement

Pour le MDM, clarifier d’abord la propriété (entreprise ou personnelle), la plateforme cible, le mode de gestion, le groupe d’utilisateurs concerné, le nombre d’appareils et les textes relatifs au consentement et à la protection des données. Pour Android, faire approuver séparément le mode Android Enterprise et ses prérequis ; pour iPhone, iPad et Mac, faire valider avant tout enrôlement le certificat APNs nécessaire à Sophos Mobile, son responsable, sa validité d’un an et son renouvellement. Lors d’un renouvellement ultérieur, le responsable Apple doit attester le compte Apple initial et le bon certificat à l’aide du Topic APNs : un certificat nouveau ou erroné associé à un autre Topic peut interrompre la gestion des appareils déjà enrôlés et imposer un nouvel enrôlement. Ne pas supprimer le certificat APNs comme méthode de retour arrière pour les appareils existants.

Si le certificat manque et qu’aucun n’a jamais été importé dans ce tenant, confier la première création du certificat APNs au responsable APNs ; la création et l’importation nécessitent une autorisation distincte et ne sont pas effectuées accessoirement dans cette préparation. Pour un certificat existant, le responsable APNs prend en charge la vérification de l’identité et le renouvellement. Pour la transmission, demander les détails affichés du certificat, sa date d’expiration, le compte Apple concerné et la responsabilité du renouvellement ; ne copier aucun identifiant dans le compte rendu de vérification et ne pas assimiler une importation à la validation du pilote. L’Apple-Business-Service-Token est distinct. Le manuel Threat Defense ne présente pas la même arborescence de configuration Apple/EAS que l’édition MDM : des réglages de base communs ne garantissent pas des fonctionnalités identiques pour les appareils.

Uniquement si l’enrôlement automatisé via Apple Business est retenu : le responsable Apple/de l’enrôlement atteste l’existence d’une organisation enregistrée dans Apple Business (anciennement Apple Business Manager), d’un compte Apple Business habilité, d’un certificat APNs enregistré dans Sophos Mobile ainsi que de la connexion distincte au moyen de l’Apple-Business-Service-Token. Consigner la validité d’un an du jeton et la responsabilité de son renouvellement ; celui-ci nécessite le même compte Apple que le jeton initial. Une réinitialisation de l’intégration supprime dans Sophos Mobile le jeton, les appareils Apple Business et les profils : ce n’est pas un retour arrière anodin. Sans ces justificatifs, pas de Go pour cette voie ; Apple Business n’est pas une condition générale de toutes les voies d’enrôlement Apple. Ne créer ni réinitialiser de jeton ou de profil dans cette procédure de configuration de base du tenant.

Uniquement si Android Enterprise est retenu : avant le premier pilote Android, le responsable Android/Google atteste la licence MDM adaptée, le mode de gestion Android Enterprise, l’enregistrement de l’organisation et la connexion du bon compte d’entreprise Google à Sophos Mobile. Le choix du mode modifie à lui seul les types de stratégies disponibles ; il n’enregistre pas une organisation. Vérifier le mode d’enregistrement et d’enrôlement réellement en place ainsi que l’origine et la disponibilité des comptes Google gérés pour les utilisateurs de test : selon la configuration, Sophos Mobile gère les comptes ou les utilisateurs doivent déjà exister dans Google Workspace/Cloud Identity ; uniquement si l’organisation a été enregistrée en mode managed Google domain avant le 9 avril 2024 et si l’option Use managed Google domain device enrollment est désactivée, Sophos Mobile vérifie lors de l’enrôlement SSP si un compte Google géré existe déjà à l’adresse obtenue en associant la partie précédant @ dans l’adresse e-mail de l’utilisateur Sophos Fusion au domaine Google géré de l’organisation ; sinon, il le crée, mais n’en gère pas le cycle de vie par la suite. Ce compte utilisateur géré n’est ni le compte Google d’entreprise servant à enregistrer l’organisation pour Android Enterprise ni, automatiquement, un compte autorisé à déverrouiller l’appareil via FRP ; vérifier séparément la correspondance des identités et la procédure de récupération du compte avant le pilote. Vérifier une stratégie adaptée au type d’appareil choisi ; en cas d’enrôlement SSP, valider le paquet d’enrôlement attribué avec son bundle de tâches Android Enterprise (Enroll et Assign policy) ainsi que l’autorisation de l’application Sophos Mobile Control dans Managed Google Play pour les mises à jour automatiques. Vérifier que la voie d’enrôlement concrète convient au mode : les appareils Android entièrement gérés ne peuvent être enrôlés qu’à l’état non configuré ou après une réinitialisation d’usine autorisée. Si un appareil déjà utilisé doit être réinitialisé à cette fin, son responsable doit vérifier au préalable l’état réel de Factory Reset Protection (FRP), la méthode de réinitialisation prévue et la procédure autorisée de déverrouillage ou de récupération du compte. S’assurer à cette occasion que l’organisation dispose de l’accès aux comptes Google autorisés pour FRP sur cet appareil : le compte d’enregistrement Android Enterprise ou le compte utilisateur n’est pas nécessairement un compte de déverrouillage FRP. Selon la méthode de réinitialisation, FRP peut demander la connexion à un compte après l’opération. Ne pas consigner d’identifiants dans le dossier du pilote. Ce contrôle concerne les réinitialisations prévues d’appareils Android entièrement gérés, et non tous les profils professionnels ou appareils Apple. Ne procéder accessoirement ni à l’enregistrement de l’entreprise auprès de Google, ni à une migration de comptes, ni à une réinitialisation d’appareil dans cette procédure de base.

Avant toute invitation, relever dans Setup > Self Service Portal la configuration envisagée pour le pilote : types d’appareils autorisés, mode de propriété, groupe d’appareils et paquet d’enrôlement appropriés, ainsi qu’actions en libre-service permises. Le nombre maximal d’appareils limite les appareils par utilisateur, pas le nombre d’utilisateurs pilotes ni la portée de la configuration. Délimiter séparément le groupe pilote au moyen de l’affectation réelle des utilisateurs et groupes. Avant toute modification d’une configuration SSP partagée, examiner et documenter la configuration Default effective (solution de repli en l’absence d’affectation plus précise), tous les groupes applicables aux utilisateurs pilotes et non pilotes, leurs priorités, les actions permises et les conséquences pour les appareils déjà enrôlés. Avant toute écriture dans des réglages SSP partagés, faire autoriser séparément la modification concrète et sa portée par une personne habilitée indépendante ; consigner les réglages précédents, y compris Default, groupes, priorités, actions et affectations des plateformes, ainsi que la procédure de retour arrière. Sans cette autorisation, ne rien modifier. Après Save, avant toute invitation ou tout enrôlement, vérifier et documenter l’affectation réellement effective pour les identités pilotes et non pilotes, y compris Default et l’appartenance à plusieurs groupes, ainsi que les conséquences pour les appareils déjà enrôlés et leurs actions SSP. Si la portée est inattendue, arrêter toute autre modification et invitation, rétablir les réglages précédents, puis vérifier à nouveau l’affectation effective et les conséquences pour les appareils ; si les effets ne peuvent pas être annulés de façon sûre, pas de Go et transmettre aux responsables concernés. Cette autorisation d’écriture est distincte du Go ultérieur pour l’enrôlement pilote. Une configuration pilote apparemment restreinte peut toucher d’autres utilisateurs par le biais de Default ou de l’appartenance à plusieurs groupes. Uniquement si la voie pilote autorisée exige l’acceptation des conditions d’utilisation du SSP : le responsable SSP/de l’enrôlement contrôle, pour l’identité de test et la plateforme choisie, le contenu autorisé des Enrollment texts effectifs et du champ Terms of use propre à la plateforme. Si Terms of use est vide, aucun texte de ce type n’est présenté avant l’enrôlement et aucune acceptation correspondante n’est recueillie : pas de Go pour cette voie de consentement SSP. Si le consentement est obtenu au moyen d’une procédure distincte autorisée, documenter celle-ci ; les conditions d’utilisation du SSP ne sont pas un préalable général aux autres voies d’enrôlement. Stratégies, conformité et paquets d’enrôlement constituent des prérequis distincts, et non des conséquences automatiques des réglages de base.

Point de décision avant tout enrôlement pilote : dans le tenant réel, une deuxième personne habilitée vérifie l’édition et la licence, les droits Mobile disponibles pour les utilisateurs pilotes désignés ou les appareils sans utilisateur, les rôles, la région attestée et l’autorisation réseau ; pour les voies SSP, l’affectation SSP effective pour l’identité de test et pour une identité non pilote, notamment Default, les priorités et la portée des groupes plutôt que la limite d’appareils par utilisateur ; pour les Dedicated Devices sans utilisateur, à la place, la voie d’enrôlement Android entièrement géré autorisée séparément et l’affectation des appareils ; ainsi que la plateforme et le mode de gestion, le consentement, les stratégies et le paquet, et les responsabilités concernant les sauvegardes, les réinitialisations et le retrait des appareils. Si la voie autorisée exige l’acceptation via SSP, le Go/No-go porte aussi sur les Enrollment texts effectifs, sur un champ Terms of use propre à la plateforme rempli avec le texte approuvé et sur l’identité de test ; sinon, documenter la procédure distincte de consentement approuvée. Pour les voies MDM Apple choisies, inclure la preuve fournie par le responsable APNs ; pour les voies Apple Business ou Android Enterprise choisies, demander en outre les justificatifs des responsables propres à chaque voie décrits ci-dessus. Si une réinitialisation d’usine d’un appareil Android entièrement géré est prévue, inclure expressément l’état FRP attesté avant l’opération, la méthode de réinitialisation et la procédure autorisée de déverrouillage ou de récupération pour les comptes effectivement autorisés par FRP. Les voies non retenues ne sont pas des motifs de blocage systématiques. La deuxième personne consigne un Go/No-go explicite pour les comptes et appareils de test désignés. Si une preuve manque ou en cas de No-go : aucune invitation, aucun enrôlement, aucune modification des appareils ; renvoyer le dossier aux responsables concernés. Cette documentation n’accorde pas elle-même d’autorisation et ne prouve pas qu’un tenant ou un appareil a été testé.

Seulement après un Go distinct, pour les voies liées à un utilisateur, le responsable de l’enrôlement procède à un essai pilote limité avec un utilisateur de test nommé et créé à cette fin pour chaque plateforme approuvée. Il consigne sur cet appareil l’identité d’enrôlement, l’enregistrement, le groupe attribué, la stratégie cible, l’état des tâches, le contact informatique, la réception des messages et la procédure de retour arrière. Uniquement pour un pilote de Dedicated Device sans utilisateur autorisé séparément, le responsable des appareils/de l’enrôlement vérifie à la place, sur l’appareil de test désigné, la voie de gestion et d’enrôlement choisie sans affectation à un utilisateur, l’identité d’enrôlement ou l’affectation de l’appareil, la stratégie cible et la configuration kiosque, l’état des tâches ainsi que la procédure attestée de restauration et de retrait de l’appareil ; ne pas présupposer d’utilisateur de test ni de correspondance avec un groupe SSP pour cette voie. Uniquement si la voie autorisée exige le consentement SSP, observer et documenter également l’affichage des Terms of use approuvées avant l’enrôlement et leur acceptation par l’identité de test ; si le consentement relève d’une procédure distincte, utiliser le mode de preuve approuvé pour celle-ci. Sophos recommande de tester avant d’inviter de vrais utilisateurs : l’autorisation décrite ici ne remplace ni cette observation ni la décision ultérieure de déploiement. Selon le mode, les voies d’inscription comprennent l’assistant d’ajout d’appareil, l’enrôlement manuel, le Self Service Portal ou l’enrôlement automatisé propre à la plateforme ; aucun parcours de clics universel n’est proposé ici pour tous les appareils.

4. Retour arrière et transfert de responsabilité

Documenter les valeurs et les droits initiaux avant le pilote. Pour rétablir Personal, IT contact et Email configuration, restaurer les valeurs antérieures et cliquer de nouveau sur Save ; vérifier ensuite le résultat dans le compte concerné, sur l’appareil de test ou à l’aide d’un nouveau message de test, selon le cas. Corriger dans Fusion tout rôle accordé trop largement par erreur au moyen d’un compte administrateur encore disponible, puis reconnecter le compte concerné. Ne retirer les configurations des groupes pilotes et du SSP qu’après vérification des affectations effectives : le simple retrait d’une configuration ne prouve pas que les appareils déjà enrôlés ont été désinscrits ni que d’autres enrôlements ont été arrêtés.

Confier explicitement le retrait des appareils au responsable des appareils/de l’enrôlement : Pour un pilote d’appareils dédiés sans utilisateur, le responsable doit aussi arrêter la voie d’enrôlement autorisée, vérifier qu’aucun autre appareil ne peut être enrôlé par cette voie et inventorier les appareils de test déjà enrôlés ; bloquer les invitations destinées aux utilisateurs ou groupes ne suffit pas à arrêter cette voie. Si le pilote s’interrompt ou s’achève, faire d’abord arrêter les nouvelles invitations et voies d’enrôlement, pour le périmètre réel des utilisateurs et groupes concernés, par le responsable désigné et vérifier l’effet de cet arrêt ; lui remettre ensuite l’inventaire des appareils de test déjà enrôlés, avec leur plateforme, leur mode, leur propriétaire et leur affectation. Le responsable des appareils décide, appareil par appareil, de la désinscription, des affectations utilisateur/appareil et des contrôles ultérieurs, puis consigne les résultats. Unenroll n’est pas un retour arrière des réglages : selon la plateforme, des profils, applications, certificats, comptes et données gérés sont supprimés ; la désinscription d’un appareil Android Enterprise entièrement géré exige sa réinitialisation d’usine. Avant celle-ci, demander aussi au responsable de l’appareil de justifier l’état FRP, la méthode de réinitialisation prévue et la procédure autorisée de déverrouillage ou de récupération pour les comptes effectivement autorisés par FRP ; sans ces justificatifs, ne pas réinitialiser. Avant une désinscription effective, vérifier le mode de gestion, la sauvegarde, la propriété, l’autorisation et les conséquences officielles propres à la plateforme. La suppression n’est pas un simple nettoyage d’inventaire : désinscrire d’abord l’appareil selon sa plateforme et vérifier le résultat, puis supprimer une entrée qui n’est plus gérée. Si un appareil encore enrôlé est supprimé à la place, il se désinscrit à la synchronisation suivante ; supprimer un appareil Android Enterprise entièrement géré provoque une réinitialisation d’usine et peut détruire des données. Avant la suppression, déterminer quelles informations sur l’appareil et quelles données enregistrées doivent être conservées ; la disparition de sa ligne dans la console ne prouve ni sa désinscription effective ni la récupération de ses données. En revanche, supprimer l’entrée d’un appareil Windows enrôlé ne le désinscrit pas automatiquement : vérifier son état sur l’appareil. Pour les appareils Apple, faire également vérifier par le responsable Apple/des appareils l’état d’Activation Lock et la procédure de réactivation applicable avant réinitialisation, désinscription ou remise en service ; ne pas réinitialiser ou supprimer un certificat APNs ou une intégration Apple Business sous prétexte de retirer les appareils. L’option de l’application Unenroll et l’action SSP Unenroll device sont des commandes distinctes : masquer l’une ne bloque pas automatiquement l’autre. Ne présenter ni la suppression des appareils, ni le retrait des licences, ni l’annulation des réglages du tenant comme une méthode d’arrêt réversible.

Pour le transfert à l’exploitation, faire contrôler par une deuxième personne habilitée le tenant et la licence Mobile, les droits effectifs des rôles délégués, les réglages de base enregistrés, la portée réelle du SSP et la transmission des décisions d’autorisation ou d’arrêt et du retrait des appareils. Le proxy EAS et le flux de messagerie Exchange restent sous la responsabilité distincte du responsable EAS ; la synchronisation LDAP/des annuaires relève du responsable des identités. En l’absence de procédures approuvées pour les appareils et l’enrôlement ainsi que pour EAS/LDAP, ne pas laisser entendre que ces opérations sont autorisées ni ajouter de liens morts. Ce guide informatif ne certifie pas qu’un tenant ou un appareil pilote ait été testé ; toute modification réelle d’un appareil nécessite toujours une autorisation distincte.