Sophos Mobile : attribuer les stratégies de façon ciblée et vérifier leurs effets

Une stratégie Sophos Mobile contient des paramètres destinés aux appareils pris en charge. Le groupe d’appareils, l’utilisateur associé et le type de stratégie ne sont pas interchangeables : un appareil appartient à un seul groupe d’appareils Sophos Mobile ; des valeurs liées à l’utilisateur peuvent être insérées dans les stratégies au moyen de variables ; le déploiement et la marche arrière dépendent du type de stratégie. Cette procédure traite de l’attribution directe de stratégies dans Sophos Mobile. Les Task Bundles suivent un processus distinct ; leur création, leur déploiement et leur dépannage ne sont pas décrits ici.

Avant la mise en production : ce guide s’appuie sur les descriptions officielles du produit, et non sur des essais réalisés dans un tenant ou sur un appareil. Avant validation, vérifier indépendamment sur des appareils pilotes l’édition, la licence, le rôle administrateur, le système d’exploitation, le mode de gestion, le type de stratégie, le comportement réel lors d’un changement de groupe et la marche arrière. Les pages examinées ne permettent pas d’établir une règle générale de priorité entre plusieurs stratégies concurrentes.

Avant l’attribution : définir la cible et la marche arrière

1. Recenser les appareils cibles, leur système d’exploitation, leur mode de gestion et l’édition (Sophos Mobile avec gestion des appareils ou Mobile Threat Defense). La présence d’un type de stratégie dans l’interface ne prouve pas qu’un autre système d’exploitation ou que l’édition limitée à l’application prenne en charge la même charge utile MDM. Sur Android, les types disponibles dépendent aussi du mode de gestion.
2. La modification concerne-t-elle des appareils précis ou un groupe d’appareils ? Chaque appareil appartient à un seul groupe d’appareils. Sophos recommande de ne regrouper que des appareils utilisant le même système d’exploitation pour les tâches propres à l’installation et au système d’exploitation. Ces groupes sont ainsi plus faciles à utiliser pour les installations et les autres tâches propres au système d’exploitation. Les stratégies de conformité du groupe, distinctes pour les appareils professionnels et personnels, se sélectionnent lors de la création du groupe ; cela ne constitue pas en soi l’attribution d’une stratégie à un appareil.
3. Consigner l’état initial sur un appareil pilote représentatif : appartenance au groupe, utilisateur associé, nom et type de stratégie, configuration et attributions existantes. Documenter la fenêtre de changement, les responsables, les appareils concernés et la marche arrière approuvée. En cas de modification du Wi-Fi, des certificats ou des mots de passe, garantir la joignabilité des appareils ainsi qu’un accès indépendant permettant la marche arrière.
4. Ne pas supposer de priorité implicite : les pages examinées ne décrivent ni règle générale de résolution des conflits ou de préséance entre plusieurs stratégies sur un appareil, ni recalcul automatique garanti après un changement de groupe ultérieur. Si plusieurs stratégies agissent sur le même paramètre, mesurer le paramètre effectif sur l’appareil pilote avant d’élargir le périmètre. Dans le processus de changement, « priorité » signifie ici : commencer par un pilote restreint, puis passer au groupe cible approuvé ; il ne s’agit pas d’un indice de priorité prétendument attribué par le produit.

Préparer le groupe d’appareils et vérifier le périmètre

Dans Device groups > Create device group, saisir un nom et une description, sélectionner les Compliance policies appropriées pour les appareils professionnels et personnels, puis cliquer sur Save. Le nouveau groupe apparaît dans Device groups. L’option Enable iOS auto-enrollment, décrite dans la documentation de création de groupes de Sophos Mobile avec gestion des appareils, concerne l’inscription automatique des iPhone et iPad avec Apple Configurator ; ce n’est ni une priorité générale des stratégies ni un préalable pour les autres plateformes. La documentation de création de groupes de Mobile Threat Defense examinée ne décrit pas cette option, ce qui ne prouve pas qu’elle soit absente de tous ses tenants. Avant d’activer cette option, vérifier l’édition et l’interface réelle dans votre tenant. Lors de l’ajout d’un appareil, un groupe d’appareils lui est attribué.

Avant d’attribuer une stratégie à un groupe, contrôler la liste de ses membres. Une sélection dans Select device groups concerne les groupes sélectionnés, et non un ensemble d’utilisateurs défini librement. Les 20 pages examinées ne permettent pas d’établir si, ni quand, les nouveaux membres d’un groupe héritent des attributions de stratégies existantes. Tester séparément ce cas ainsi qu’un changement de groupe ultérieur avant validation ; ne pas présenter leur comportement comme acquis.

Ne pas supprimer un groupe pour annuler rapidement une modification. Les pages consacrées à la suppression ne garantissent ni un effet donné sur les stratégies ou la conformité, ni une modification de l’état d’inscription. Comme l’appartenance au groupe change, vérifier avant toute suppression nécessaire le bon groupe à l’aide de son nom et de sa liste de membres, recenser les appareils concernés, le groupe de destination, l’édition et la plateforme, puis définir avec le responsable de la plateforme une marche arrière vérifiée. Ce n’est qu’ensuite que l’on peut sélectionner Delete à l’aide du triangle bleu à côté du groupe vérifié dans Device groups. Pour un groupe contenant des appareils, choisir dans la boîte de confirmation un groupe de destination restant auquel ces appareils seront réattribués ; cette sélection n’est pas requise pour un groupe vide. Le dernier groupe restant ne peut pas être supprimé tant que des appareils lui sont attribués. Vérifier à nouveau le nom du groupe, les appareils concernés et, le cas échéant, le groupe de destination, puis seulement confirmer la suppression avec Yes. Contrôler ensuite l’appartenance au groupe et le périmètre réel des stratégies et de la conformité pour chaque appareil concerné ; en cas d’écart, ne pas poursuivre les suppressions et appliquer la marche arrière approuvée. Ces pages sur la suppression de groupes ne permettent de déduire ni une désinscription manuelle de Windows ni une réinitialisation automatique d’Android ; les conséquences propres aux plateformes exigent des sources officielles distinctes et une vérification technique.

Créer et attribuer une stratégie

Dans Policies, sélectionner d’abord la plateforme de l’appareil, puis Create et un type de stratégie pris en charge. Saisir un nom et une description ; pour les stratégies iOS, iPadOS et macOS, saisir aussi le nom de l’organisation. Ajouter les configurations nécessaires avec Add configuration. Cliquer ensuite sur le nom de chaque configuration pour modifier ses paramètres. Si une configuration SCEP est présente, sélectionner l’intervalle de renouvellement des certificats sous SCEP renewal interval avant d’enregistrer. Vérifier chaque configuration séparément et ne sélectionner Save qu’après avoir ajouté toutes les configurations nécessaires. La stratégie enregistrée peut ensuite être attribuée. Sophos Mobile ajoute automatiquement une configuration Restrictions pour les stratégies Android Enterprise et une configuration Network pour Mobile Threat Defense ; cela ne signifie pas que les éditions offrent les mêmes fonctionnalités.

Autre méthode pour les stratégies de base : Policies startup wizard

L’assistant est une méthode de création avant l’attribution, et non la preuve qu’une configuration est déjà active sur un appareil. Il convient pour créer d’abord des stratégies simples sur les plateformes prises en charge ; pour les types à configurer précisément et les autres paramètres, la méthode Policies > [plateforme] > Create décrite ci-dessus reste appropriée. L’ancien guide de démarrage cite Android et iOS/iPadOS comme exemples de sélection, tandis que l’aide administrateur ne précise pas les plateformes ; ces instructions concernant l’assistant ne s’appliquent pas aux appareils Chrome. Ne sélectionner que les plateformes et types de stratégies réellement proposés et compatibles avec l’édition, l’appareil et le mode de gestion prévu. Sur Android, le mode de gestion influe sur les types de stratégies disponibles ; Android Enterprise doit être configuré avant l’inscription des appareils concernés.

1. Sur le Dashboard, ouvrir Getting started tasks > Policies startup wizard ; si le widget est absent, sélectionner Add widget > Getting started. Dans Platforms, ne sélectionner que les plateformes vérifiées au préalable et, pour Android, définir le mode de gestion approprié. Sophos recommande ici Android Enterprise comme mode de gestion Android. Ne pas déduire d’un exemple iOS/iPadOS que les autres modes de gestion Apple ont le même fonctionnement ou le même effet.
2. Dans Policies, saisir un nom permettant d’identifier sans ambiguïté les stratégies : l’assistant crée sous ce nom une stratégie par plateforme sélectionnée. Sélectionner les domaines à gérer. L’assistant ignore ceux qui sont désélectionnés ; ils pourront être ajoutés ultérieurement à la stratégie enregistrée. Examiner Password requirements et Restrictions comme points de départ, sans les activer sans vérification pour tous les appareils cibles.
3. Dans Passwords, ne choisir que les exigences de mot de passe convenues et compatibles avec les appareils pilotes et le mode de gestion prévu. Dans Restrictions, ne définir que les restrictions approuvées ; ne pas reprendre, par exemple, le blocage de la caméra sans nécessité métier. Vérifier les valeurs et leurs effets sur le système d’exploitation avec un pilote avant une attribution étendue.
4. Ne configurer Wi-Fi qu’avec les informations approuvées pour le réseau de l’entreprise, une fois clarifiés le mode de connexion, le type de sécurité et un accès indépendant pour la marche arrière. Si le type de sécurité diffère de WPA/WPA2 PSK, vérifier et adapter ensuite le paramètre correspondant dans la stratégie ; ne saisir ni identifiants fictifs ni valeurs supposées. Ne configurer Email que pour l’accès Exchange Online ou Exchange local réellement utilisé ; avec %_USERNAME_% et %_EMAILADDRESS_%, vérifier sur le pilote l’utilisateur associé et les valeurs substituées. Ignorer les domaines inutiles et les ajouter ultérieurement au besoin.
5. Avant Finish, comparer les choix, les plateformes cibles, le mode et les configurations au changement approuvé. Finish crée les stratégies, mais ne les attribue pas automatiquement aux appareils ou aux groupes et ne prouve ni leur synchronisation ni leur effet sur le système d’exploitation. Ensuite, dans Policies > [plateforme], ouvrir chaque stratégie créée, vérifier son type et ses paramètres et, si nécessaire, la compléter avec Add configuration. En cas de mauvais choix, ne pas attribuer la stratégie : corriger d’abord celle qui a été enregistrée, puis la vérifier à nouveau.
6. Ce n’est qu’ensuite qu’il faut utiliser la procédure Assign ci-dessous pour un pilote restreint, puis vérifier le statut ainsi que les paramètres réels de l’appareil selon la section « Contrôler les effets et valider le déploiement ». En cas d’écart, arrêter l’élargissement : corriger la stratégie avant son attribution ou, après attribution, suivre la marche arrière adaptée à son type, décrite dans « Annuler plutôt que supprimer à l’aveugle ». Un Task Bundle ou une inscription SSP suit une procédure distincte ; le bouton Finish de l’assistant ne remplace ni l’un ni l’autre.

Pour l’attribution directe :

1. Dans Policies, ouvrir la plateforme ; sélectionner Assign à l’aide du triangle bleu à côté de la bonne stratégie.
2. Dans Select devices, choisir des appareils pilotes individuellement ou sélectionner les groupes d’appareils préparés avec Select device groups. Avant de terminer, comparer la liste et le nombre d’appareils concernés à la demande de changement.
3. Les étapes Schedule task documentées ne concernent explicitement que les Android device, Knox container et iOS device policies. Pour une exécution immédiate, choisir Now. Pour une exécution ultérieure, choisir Date, puis saisir le jour et l’heure prévus. La mention des stratégies iOS/iPadOS device dans la liste des types ne prouve pas que cette étape s’applique à iPadOS. Pour iPadOS et les autres types, ne pas supposer la présence d’un écran de programmation ; la vérifier sur place.
4. Sélectionner Finish et contrôler le résultat pour chaque appareil cible. Autre possibilité : l’onglet Policies de la fiche d’un appareil dans Sophos Mobile propose Assign policy ; pour plusieurs appareils sélectionnés, un processus par appareils est disponible sous Devices > Actions > Assign policy. Ne pas transposer ici la procédure distincte des Task Bundles.

Sans date d’exécution, la stratégie prend effet immédiatement selon Sophos. Cela vaut aussi pour l’attribution directe d’une stratégie d’appareil iOS, et pas seulement pour les types de stratégies synchronisés. Pour une fenêtre de changement ultérieure, vérifier donc le jour et l’heure sous Date avant Finish ; l’absence de date ne reporte pas l’exécution. L’effet immédiat décrit dans le guide d’attribution ne garantit pas l’application immédiate de chaque paramètre sur un appareil hors ligne. Continuer à vérifier le statut des tâches et les paramètres réels des appareils.

Les utilisateurs ne constituent pas un troisième type général de cible pour Assign : la sélection directe décrite ici porte sur les appareils et les groupes d’appareils, pas sur des groupes d’utilisateurs quelconques. Lors de l’attribution de la stratégie, Sophos Mobile remplace les variables dans ses paramètres par des propriétés de l’utilisateur, de l’appareil ou du client. %_EMAILADDRESS_% et %_USERNAME_% insèrent les valeurs de l’utilisateur associé à un appareil ; la seconde correspond à son Exchange Login, et pas nécessairement au nom affiché.

Pour les variables d’appareil, toutes les propriétés répertoriées dans les onglets Device properties et Custom properties de la page Show device de l’appareil concerné peuvent être utilisées. Y rechercher la propriété nécessaire et sa valeur. %_DEVPROP(IMEI)_% insère, par exemple, la valeur IMEI de l’appareil, si elle est disponible. Les propriétés du client sont créées dans Setup > Sophos setup > Customer properties > Add customer property : saisir le nom et la valeur de la propriété du client, puis sélectionner Apply et ensuite Save. Elles peuvent être référencées, par exemple, avec %_CUSTPROP(my property)_%. Vérifier les noms et les valeurs avant une attribution à grande échelle, puis contrôler sur un pilote, après l’attribution, que les valeurs sont correctement substituées et que leur confidentialité est préservée.

Pour macOS, Sophos utilise les propriétés de l’utilisateur Sophos Mobile associé pour les utilisateurs locaux du Mac, et celles provenant de LDAP pour les utilisateurs réseau ; une stratégie utilisateur macOS est attribuée aux utilisateurs du Mac lors de leur connexion. Ne pas en conclure que chaque stratégie d’appareil peut être attribuée séparément à chaque utilisateur.

Contrôler les effets et valider le déploiement

Selon la vue d’ensemble Policies, les types de stratégies synchronisés prennent effet immédiatement dès leur attribution et sont synchronisés à chaque connexion de l’appareil à Sophos Mobile ; cela ne garantit pas l’application immédiate de chaque paramètre du système d’exploitation sur un appareil hors ligne.

Les types de stratégies diffèrent quant au traitement des modifications apportées à une stratégie déjà attribuée :

Pour iPadOS device, les périmètres de la documentation se contredisent : la vue d’ensemble Policies classe Android device, Knox container et iOS/iPadOS device dans la même catégorie de stratégies installées : installation lors de l’attribution, mise à jour sur l’appareil après modification et désinstallation pour retirer les paramètres. En revanche, Apply policy changes to devices n’exige expressément la mise à jour manuelle que pour Android device, Knox container et iOS device ; toutes les autres stratégies sont censées se synchroniser automatiquement. Uninstall policy limite également expressément la désinstallation à ces trois types. Aucun des deux guides ne mentionne iPadOS séparément. Il reste donc indéterminé si leur appellation iOS device policies inclut iPadOS. Cela ne démontre ni une impossibilité générale ni une procédure de mise à jour ou de désinstallation iPadOS dont la prise en charge soit fiable. Avant toute modification sur iPadOS, vérifier le déroulement réel et la marche arrière dans son propre tenant et sur l’appareil pilote ; ne pas reprendre la suite de clics iOS sans vérification.

Pour les types expressément documentés Android device, Knox container et iOS device, après modification, déclencher Update devices au moyen du triangle de la stratégie dans Policies > [plateforme] : Sophos Mobile crée une tâche pour tous les appareils auxquels elle est attribuée. Ce n’est pas une opération limitée au pilote si la stratégie a déjà été largement attribuée. Pour iPadOS device, ne pas présumer que la même procédure de mise à jour s’applique : la vérifier sur un pilote dans le tenant. Pour les types synchronisés, attendre la prochaine connexion et constater la synchronisation ; pour les modifications des stratégies macOS appareil et déclaratives, c’est la prochaine synchronisation de l’appareil qui compte. En revanche, vérifier les modifications d’une stratégie macOS utilisateur dans les paramètres réels de l’utilisateur seulement après sa prochaine ouverture de session sur le Mac. Une synchronisation réussie de l’appareil seule ne prouve pas cet effet pour l’utilisateur. Le terme « immédiat » dans la description du type ne dispense pas de vérifier un appareil hors ligne.

Vérifier les attributions dans l’onglet Policies de Fusion

Sur l’appareil pilote, contrôler les attributions dans Sophos Fusion Admin, sous My Environment > Mobile Devices > [appareil] > Policies. Cet onglet affiche les stratégies Sophos Mobile et les Provisioning profiles attribués à l’appareil. Utiliser Refresh en haut à droite pour recharger les informations affichées. Dans le champ de recherche, filtrer par nom de stratégie et comparer le résultat au changement approuvé.

Les champs permettent d’identifier la bonne stratégie et l’état de son attribution :

• Name indique le nom de la stratégie et Type son type.
• Version indique la version de la stratégie. Sophos Mobile l’incrémente automatiquement lorsque la stratégie est modifiée. Une version supérieure ne prouve pas à elle seule que les paramètres modifiés prennent effet sur l’appareil.
• Assigned at indique quand Sophos Mobile a attribué la stratégie à l’appareil ou l’a réattribuée après une mise à jour. Ce n’est pas une preuve de la date à laquelle chaque paramètre du système d’exploitation a pris effet.
• Status décrit l’état d’attribution, par exemple Applied. Vérifier cet état conjointement avec la version et les paramètres réels de l’appareil.
• Component désigne le destinataire auquel Sophos Mobile a envoyé la stratégie lors de son attribution. Pour la plupart des types de stratégies, il s’agit de l’agent MDM de l’appareil.

Les Android Enterprise device policies et les work profile policies peuvent contenir des configurations que Sophos Mobile envoie à une API Google plutôt qu’à l’appareil. Dans ce cas, la liste affiche deux entrées de la même stratégie avec des composants différents et, éventuellement, des états différents. Vérifier les deux entrées ; Applied pour un composant ne prouve pas l’état de l’autre.

Pour les macOS user policies, l’attribution aux utilisateurs concernés intervient lors de leur connexion au Mac. La liste contient des entrées distinctes pour tous les utilisateurs auxquels la stratégie est attribuée, pas seulement ceux qui sont actuellement connectés. Il s’agit de l’utilisateur local qui a inscrit le Mac dans Sophos Mobile et des utilisateurs réseau connus de Sophos Mobile, issus de l’annuaire LDAP externe configuré pour le Sophos Fusion Self Service Portal. Cela n’implique pas une attribution à n’importe quel compte local. Cette limite concernant les utilisateurs est également décrite dans le guide d’inscription macOS.

Cette vue n’affiche pas les stratégies iOS/iPadOS device, Knox container, ni Android device en ancien mode administrateur d’appareil ; les stratégies iOS device ne contenant que des configurations d’itinérance/point d’accès ou de fond d’écran peuvent également manquer. Dans ces cas, utiliser Open in Sophos Mobile en haut à droite de la page de détail de l’appareil et vérifier séparément l’effet sur l’appareil ; ne pas interpréter l’absence de ligne comme un échec de l’attribution.

Condition de validation : avant d’élargir le déploiement, tester des appareils pilotes pour chaque combinaison d’édition, de système d’exploitation et de mode de gestion ; consigner les périmètres attendu et réel, les valeurs d’utilisateur et de variables, la version de la stratégie, les composants concernés, les paramètres de l’appareil et le statut des tâches. Ne pas déployer en cas de contradiction ou en l’absence d’une marche arrière. Après validation par les responsables compétents seulement, répéter la procédure pour le groupe cible convenu, puis réaliser les mêmes contrôles sur un échantillon et sur les exceptions. Aucun test dans un tenant n’a été réalisé pour ce guide.

Télécharger une stratégie pour le support

La procédure générale de téléchargement est documentée tant pour Sophos Mobile avec gestion des appareils que dans l’aide distincte de Mobile Threat Defense ; cela ne signifie pas que les deux éditions aient les mêmes types de stratégies, contenus exportés ou autorisations. Vérifier d’abord dans le tenant réel l’édition, la plateforme de l’appareil, le type exact de stratégie et le rôle ou les droits administrateur nécessaires ; ne sélectionner que la stratégie confirmée pour la demande de support.

1. Ouvrir Policies dans le menu latéral et sélectionner la plateforme de l’appareil. À l’aide du triangle bleu à côté de la stratégie vérifiée par son nom et son type, sélectionner Download.
2. Vérifier que le fichier a bien été enregistré localement sur son ordinateur et qu’il correspond à la stratégie choisie (édition, plateforme, nom et type). Ne pas déduire du seul nom du fichier ou du téléchargement que son contenu est exhaustif ou qu’il permet une restauration.
3. Avant de transmettre le fichier au support Sophos, faire autoriser son lieu de stockage et son destinataire, vérifier qu’il ne contient pas de paramètres ou de données confidentiels et ne communiquer que ce qui est nécessaire au diagnostic. Si le diagnostic reste possible, masquer de manière sûre les informations sensibles ; utiliser un canal de transfert sécurisé approuvé, faire confirmer la réception par le destinataire autorisé du support et supprimer de manière sûre les copies locales et transmises après la fin de leur utilisation, conformément à l’autorisation donnée.

Download n’attribue aucune stratégie, ne synchronise aucun appareil et ne prouve ni l’existence d’une sauvegarde ni la possibilité d’importer, de restaurer ou d’annuler la modification. Pour la marche arrière effective, suivre les étapes propres au type de stratégie dans la section suivante.

Annuler plutôt que supprimer à l’aveugle

• Types synchronisés : corriger la stratégie existante de manière ciblée ou attribuer une autre stratégie vérifiée. La fonction officielle de désinstallation n’est pas prévue pour ces types. Après la connexion et la synchronisation, vérifier le nouvel état sur l’appareil ; pour les stratégies macOS appareil et déclaratives, après la prochaine synchronisation de l’appareil, mais pour une stratégie macOS utilisateur modifiée, seulement après la prochaine ouverture de session de l’utilisateur concerné sur le Mac. Contrôler les paramètres réels de cet utilisateur avant de considérer la marche arrière comme effective ; la synchronisation de l’appareil seule ne suffit pas pour la stratégie utilisateur. Ne pas promettre que tous les paramètres propres à la plateforme disparaîtront immédiatement.
• Types installés : le guide Uninstall policy n’autorise expressément la désinstallation sur un appareil individuel que pour Android device, Knox container et iOS device policies. Pour iPadOS, la contradiction avec la vue d’ensemble Policies expliquée ci-dessus reste non résolue. Dans Devices > [appareil] > Policies > Uninstall, ne supprimer la bonne stratégie que pour un type dont la prise en charge est documentée, puis vérifier sur le pilote que le paramètre concerné a disparu. Tester séparément la marche arrière pour iPadOS dans le tenant actuel et sur l’appareil avant toute modification ; ne pas présenter la procédure iOS comme applicable à iPadOS. Pour tous les appareils auxquels l’une de ces stratégies est attribuée, Policies > [plateforme] > [triangle] > Unassign constitue une procédure bien plus large : ne pas l’utiliser pour annuler la modification sur un seul appareil. Pour plusieurs appareils, Sophos mentionne une tâche Uninstall policy dans un Task Bundle ; sa réalisation relève de la procédure distincte des Task Bundles et non de cet article.
• Le téléchargement pour le support n’est pas une marche arrière : pour le fichier local distinct et son transfert sécurisé au support, voir « Télécharger une stratégie pour le support » ci-dessus ; planifier une véritable marche arrière adaptée au type de stratégie et la vérifier sur un pilote.

Après chaque marche arrière, revérifier l’affectation initiale des appareils aux groupes, les entrées de stratégie pertinentes et les paramètres réels. Unassign, Uninstall, la modification d’une stratégie et la suppression d’un groupe sont des interventions distinctes, de périmètres différents. Si l’effet, le mode ou l’édition restent incertains, arrêter le changement et faire approuver par les responsables compétents la marche arrière propre à l’appareil.