Planifier et vérifier en toute sécurité les politiques de conformité Sophos Mobile

Une politique de conformité n’est ni un certificat ni un profil d’appareil. Elle évalue certaines règles pour les appareils inscrits et peut déclencher des actions en cas de violation. Les facteurs déterminants sont l’édition réellement utilisée (Sophos Mobile ou Sophos Mobile Threat Defense), la plateforme et la version du système d’exploitation, le statut professionnel ou personnel de l’appareil, le mode d’inscription et de gestion, le cas échéant l’application Intercept X for Mobile (IXM) gérée par Sophos Mobile, ainsi que le groupe d’appareils auquel la politique est attribuée. La présence d’une règle ou d’un modèle PCI/HIPAA ne prouve ni son applicabilité à chaque appareil ni une certification.

Avant toute intervention en production : Check now vérifie tous les appareils inscrits et exécute les actions configurées. La création ou la modification d’une politique et son attribution à un groupe ne sont pas non plus de simples consultations. Définir d’abord l’ensemble des appareils concernés et la procédure de retour arrière ; ne pas utiliser une flotte de production pour faire des essais.

Qu’est-ce qui est réellement évalué ?

Choisir d’abord l’édition du produit, puis vérifier la plateforme, le système d’exploitation et le mode d’inscription : avec Android Enterprise fully managed, le MDM gère tout l’appareil ; Apple User Enrollment inscrit des appareils Apple personnels avec des capacités de gestion limitées ; supervised désigne les iPhone/iPad supervisés. Une application IXM gérée par Sophos Mobile ne prouve pas à elle seule que l’appareil relève d’une gestion complète des appareils mobiles (MDM). Comparer, dans son propre tenant, les règles disponibles pour l’édition et le mode effectivement utilisés ; ne pas confondre les règles ni les actions de Sophos Mobile avec celles de Sophos Mobile Threat Defense.

Les règles définissent les fonctions ou les états de l’appareil qui sont autorisés, interdits ou requis. La réaction à une violation est choisie séparément ; un critère de conformité ne prouve pas à lui seul qu’un réglage de l’appareil est activement modifié ou imposé.

Pour créer une politique dans Sophos Mobile ou dans l’édition autonome Sophos Mobile Threat Defense, ouvrir le menu Compliance policies, cliquer sur Create compliance policy et sélectionner le modèle Default, PCI ou HIPAA. Saisir un nom et, éventuellement, une description ; le choix du modèle ne limite pas les réglages ultérieurs. Seul le modèle Default ne comporte aucune action prédéfinie ; les modèles PCI/HIPAA peuvent déjà contenir des actions. Sophos décrit les règles et les actions de ces modèles comme fondées sur HIPAA et PCI DSS. L’ordre des modèles et des normes dans la documentation reste toutefois ambigu ; ne pas en déduire ici une correspondance entre un modèle particulier et une norme. Il faut activer l’onglet de la plateforme avec Enable platform : si la case n’est pas cochée, aucune vérification de conformité n’a lieu pour les appareils de cette plateforme. Les niveaux de gravité high, medium, low sont attribués aux règles de manière fixe ; ils ne correspondent pas à une action de réaction librement choisie. Lors de la planification de la politique, ils aident à évaluer l’importance de chaque règle et à choisir une réaction adaptée à une violation. Cela n’autorise pas l’exécution d’une action lors d’un incident. Dans l’édition complète, Highlight rules aide à mettre en évidence un type de gestion, mais ne prouve pas qu’une règle s’applique à tous les appareils de ce type.

Cliquer sur Save uniquement après avoir configuré et vérifié les règles et les réactions associées pour toutes les plateformes nécessaires. La politique est alors enregistrée sous le nom saisi ; son attribution ultérieure à un groupe s’effectue séparément, après les vérifications décrites ci-dessous.

Sophos Mobile (édition complète/MDM) : Outre les règles de gestion et de système d’exploitation propres à chaque plateforme, les signaux IXM peuvent être utilisés si Sophos Mobile gère l’application. Les réactions proposées pour chaque règle sont Deny email, Lock container, Set health, Create alert et Transfer task bundle ; les conditions propres à chaque plateforme et à chaque action restent applicables.
Sophos Mobile Threat Defense (édition distincte) : Son catalogue de règles distinct comprend notamment les autorisations IXM et les détections de malwares et d’applications sous Android, le Web Filtering sous iOS ainsi que des règles de sécurité pour Chromebook. Pour cette édition, la réaction décrite est Create alert, et non les actions MDM relatives à la messagerie, au conteneur, à la Health ou aux task bundles.

Dans l’édition autonome, Installed apps et Mandatory apps s’appliquent uniquement aux Chromebooks. Pour Installed apps, choisir d’abord Allowed apps ou Forbidden apps, puis le groupe d’applications contenant les applications ou extensions autorisées ou interdites. Pour Mandatory apps, choisir le groupe d’applications contenant les applications ou extensions qui doivent être installées. Les correspondances Android, iOS et Mac décrites plus bas, ainsi que les précisions sur les applications système et les mises à jour d’applications Android, relèvent du catalogue général de l’édition complète Sophos Mobile, et non de ces deux règles de l’édition Threat Defense autonome.

Le catalogue distinct Mobile Threat Defense compliance rules, dans l’aide de Sophos Mobile, décrit un sous-ensemble de règles pour les appareils Android/iOS dont l’application IXM est gérée par Sophos Mobile : notamment le root/jailbreak, les limites du système d’exploitation, la synchronisation IXM et les analyses d’applications Android. Une application gérée ne prouve pas à elle seule que l’appareil est entièrement administré en MDM ; ce sous-ensemble n’est pas non plus le catalogue de règles de l’édition autonome Sophos Mobile Threat Defense. Sous Android, la règle Intercept X for Mobile permissions can be denied définit si le refus des autorisations de l’application IXM rend l’appareil non conforme. Si l’Accessibility Service est refusé, elle peut signaler comme violation une interruption du Web Filtering ; Sophos recommande la valeur No lorsque le Web Filtering est utilisé. La règle iOS Web Filtering turned on figure dans le catalogue général des règles Sophos Mobile et dans celui de l’édition Threat Defense autonome, pas dans le sous-ensemble IXM précité. Elle exige que la fonction Web Filtering d’Intercept X for Mobile soit activée sur les iPhone et iPad ; c’est un critère distinct de la règle Android relative aux autorisations. Les règles Chromebook ne sont pas automatiquement des règles Android/iOS.

Le sous-ensemble IXM géré est documenté dans les deux aides, pour Sophos Mobile et pour Sophos Mobile Threat Defense. Pour les appareils dont Sophos Mobile gère l’application IXM, il indique les correspondances suivantes :

Managed required s’applique à Android et iOS. La règle définit la réaction lorsqu’un appareil n’est plus géré. Elle ne doit pas être assimilée à Device administrator management allowed et ne prouve pas une gestion MDM complète.
Minimum OS version et Maximum OS version s’appliquent à Android et iOS dans ce sous-ensemble. Elles définissent respectivement la version minimale requise et la version maximale autorisée du système d’exploitation. L’absence de liste de plateformes dans le catalogue général ci-dessous ne change pas cette correspondance.
Malware apps allowed s’applique ici uniquement à Android. Cette règle définit si les applications malveillantes détectées par IXM sont autorisées.
PUAs allowed s’applique ici uniquement à Android. Cette règle définit si les applications potentiellement indésirables détectées par IXM sont autorisées.

Ces deux règles relatives aux applications évaluent la conformité. Elles ne sont ni des paramètres d’analyse ni une autorisation de débloquer les applications détectées ou de les exclure des analyses futures. Les conséquences des détections et les exceptions sont examinées séparément dans le guide de réponse à un incident de conformité lié plus bas.

Une règle Maximum interval between … synchronizations est une règle de conformité configurable pour la source de synchronisation concernée : le logiciel MDM natif du système d’exploitation, Sophos Mobile Control, IXM ou Sophos Chrome Security. Dans le catalogue général, la répartition est la suivante :

Native MDM: iPhone/iPad sans Sophos Mobile Control ni IXM, ainsi que Mac et ordinateurs Windows.
SMC (Sophos Mobile Control): appareils Android et iPhone/iPad.
Intercept X for Mobile: appareils Android et iPhone/iPad.
Sophos Chrome Security: Chromebooks.

Chacune de ces règles limite l’intervalle maximal autorisé entre les synchronisations de l’agent concerné avec Sophos Fusion ; ne pas intervertir les agents ni les valeurs de durée. En revanche, Maximum interval between Intercept X for Mobile scans limite, sous Android, l’intervalle entre les analyses antimalware IXM, et non entre les synchronisations. Un dépassement de la limite ne peut être évalué qu’en vérifiant la règle effectivement activée et enfreinte ainsi que l’heure de synchronisation ou d’analyse correspondante. Séparément, une synchronisation retardée ou échouée peut rendre obsolète le statut de conformité affiché ; elle ne prouve à elle seule ni une violation de règle ni la conformité. Un statut inconnu du proxy EAS constitue encore un autre cas, relevant du processus de quarantaine Exchange configuré séparément, et non automatiquement une violation de la règle d’intervalle maximal.

Choisir les règles selon les vérifications à effectuer

Les groupes suivants organisent le catalogue général des règles de l’édition complète Sophos Mobile pour la planification. Ils ne constituent pas une liste de valeurs par défaut recommandées. Vérifier d’abord l’édition et le mode de gestion, puis sélectionner uniquement les critères adaptés et examiner séparément la réaction de chaque règle.

Statut de gestion, versions et mises à jour

Managed required / Device administrator management allowed: La première règle concerne les appareils qui ne sont plus gérés ; la seconde définit les actions applicables aux appareils Android sur lesquels Sophos Mobile lui-même est utilisé comme Device Administrator. Ce mode de gestion est obsolète dans Sophos Mobile et n’est disponible que sous Android 9 ou une version antérieure ; il ne peut pas être utilisé sous Android 10 ou une version ultérieure. Sophos recommande la migration vers Android Enterprise. Il s’agit d’une limite propre à ce mode de gestion Sophos Mobile, et non d’une affirmation selon laquelle les API Android Device Administrator auraient été supprimées de manière générale, ni d’une procédure d’inscription de nouveaux appareils dans ce mode.
Minimum SMC version: Version minimale autorisée de l’application Sophos Mobile Control, pour Android et iPhone/iPad. Ne pas la confondre avec la version d’IXM ou du système d’exploitation.
Minimum OS version / Maximum OS version: Version minimale ou maximale autorisée du système d’exploitation. Le catalogue ne fournit pas de liste de plateformes spécifique pour ces deux entrées ; vérifier leur disponibilité dans l’onglet de la plateforme concernée.
Mandatory OS updates: Pour les iPhone/iPad supervisés, et non pour Apple User Enrollment. Latest available update exige la dernière mise à jour disponible ; Latest critical update, la dernière mise à jour classée comme critique par Apple. La dernière mise à jour disponible peut être plus récente que la dernière mise à jour critique. Latest critical update n’est plus disponible à partir d’iOS/iPadOS 27. Pour la gestion des mises à jour de ces appareils, Sophos mentionne une politique déclarative avec Software update settings ou Enforced software update ; ne pas en déduire que le choix de conformité antérieur conserve les mêmes effets. Software update settings exige iOS/iPadOS 26 ou une version ultérieure, le mode de gestion Apple Device Enrollment et un appareil supervisé. Pour Enforced software update, Sophos indique comme prérequis iOS/iPadOS 26 ou une version ultérieure et Apple Device Enrollment, sans mentionner d’exigence supplémentaire de supervision. Cette version minimale 26 est à distinguer du seuil 27 pour le choix antérieur Latest critical update.

Les informations de mise à jour Apple nécessitent un chemin réseau distinct : pour obtenir les informations sur les mises à jour disponibles sur iPhone, iPad et Mac, mesu.apple.com doit être accessible via HTTPS 443. Si cette destination est inaccessible, Sophos Mobile ne dispose pas d’informations de mise à jour ; les règles de conformité relatives aux mises à jour obligatoires sont alors sans effet. Vérifier le chemin réel avec l’administration réseau avant de considérer le statut d’une telle règle comme fiable. Cela n’élargit pas les limites de plateforme, de système d’exploitation ou d’inscription de Mandatory OS updates indiquées ci-dessus et n’affirme pas que toutes les installations de mises à jour Apple échouent.

Protection de l’appareil et séparation des données professionnelles

Root access allowed (Android): Définir si les appareils disposant de droits root sont autorisés. L’autorisation documentée couvre aussi les appareils Sony avec Enterprise API Level 4 ou ultérieur et les appareils Samsung avec Knox Standard SDK 5.5 (API Level 17) ou antérieur considérés comme non sécurisés par le système d’exploitation. Il s’agit de précisions historiques de l’aide de la règle, et non d’une recommandation d’utiliser ces appareils aujourd’hui.
Android Debug Bridge (ADB) allowed (Android): Définir si l’interface de débogage ADB est autorisée ou interdite.
Allow jailbreak (iPhone/iPad): Définir séparément si les appareils jailbreakés sont autorisés ; ne pas transposer la règle Android relative au root.
Screen lock required (Android, iPhone/iPad, Windows): Définir si un mot de passe d’appareil ou un autre mécanisme de verrouillage est requis. Sous Android, Pattern, PIN et Password sont pris en compte, mais pas Swipe. Avec Apple User Enrollment, la règle est satisfaite si la politique attribuée contient une configuration Password policies.
Encryption required (Android, Mac, Windows): Exiger le chiffrement ; sous macOS, la règle porte sur le chiffrement intégral FileVault. Selon l’aide de la règle, les iPhone et iPad sont toujours chiffrés et ne figurent pas dans la liste des appareils auxquels cette règle s’applique.
Container configured (Android): Un conteneur doit être configuré et activé, par exemple un profil professionnel Android ou un conteneur Samsung Knox. Il s’agit d’un critère d’état, et non de la réaction Lock container.
Data roaming allowed: Autoriser ou interdire l’itinérance des données pour Android et les iPhone/iPad sans Apple User Enrollment.

Ne pas appliquer une réparation généralisée du chiffrement Android : L’aide actuelle de la règle mentionne encore Require PIN to start device ou Require Password to start device lors de la configuration d’un verrouillage d’écran. Cela ne prouve pas que ces options de PIN ou de mot de passe au démarrage soient disponibles sur les versions Android actuelles ou dans tous les modes Android Enterprise. La KBA-000004067 distincte décrit un cas d’erreur où la clé de chiffrement standard est affichée et propose un PIN au démarrage et une synchronisation manuelle comme mesures correctives, sans préciser de version du système d’exploitation ni de mode d’inscription ; ce n’est pas une solution universelle pour les versions Android actuelles ou les modes Android Enterprise. Avant toute intervention sur l’appareil, établir l’erreur réellement observée, la version du système d’exploitation prise en charge et le mode d’inscription ; ne pas recommander de changement généralisé du PIN ni Synchronize now.

Applications, profils et autorisations

Installed apps: Choisir d’abord Allowed apps ou Forbidden apps, puis le groupe d’applications contenant les applications autorisées ou interdites. S’applique aux appareils Android, aux iPhone/iPad sans Apple User Enrollment, aux Mac et aux Chromebooks. Les applications système Android sont toujours autorisées ; les groupes d’applications Chrome OS peuvent contenir des applications et des extensions.
Mandatory apps: Sélectionner dans la liste le groupe d’applications dont les applications doivent être installées. Les groupes Chrome OS peuvent aussi contenir des extensions. Sous iOS, ne définir aucune application système comme application obligatoire : Sophos Mobile ne peut pas détecter son installation et, selon l’aide de cette règle, considère alors tous les appareils concernés comme non conformes. Pour Android, Sophos indique dans SMCAND-3159 que des mises à jour d’applications effectuées en parallèle pendant une synchronisation de l’application Control avec le backend Mobile peuvent faire passer temporairement le statut à non conforme, puis le ramener à conforme, en particulier sur les appareils plus anciens. Pour analyser la situation en lecture seule, comparer la règle effectivement enfreinte, les horaires des mises à jour et de la synchronisation, ainsi que le statut observé ensuite. Cela ne justifie pas d’assouplir la règle relative aux applications obligatoires. Un statut conforme ultérieur ne permet de conclure ni à un fonctionnement sans conséquences ni au rétablissement de l’accès aux applications, à la messagerie ou au Wireless ; le retour automatique à la conformité décrit dans la documentation n’est pas un résultat observé ici et ne garantit aucun délai.
Suspicious apps allowed (Android): Définir si les applications suspectes détectées par IXM sont autorisées. Il s’agit d’un choix de conformité distinct, qui n’équivaut pas automatiquement aux paramètres d’analyse des applications de faible réputation.
Third-party profiles allowed (iPhone/iPad, sans Apple User Enrollment): Définir si les profils de configuration non gérés par Sophos Mobile sont autorisés.
Unmanaged apps from unknown sources allowed (iPhone/iPad): Définir si les applications développées en interne, installées manuellement au moyen d’un fichier IPA et signées avec un profil de provisionnement ad hoc, sont autorisées. Ne pas assimiler cette règle à la règle Chromebook concernant les applications provenant de l’extérieur du Chrome Web Store.
SMC permissions can be denied (Android): L’application Control a besoin, pour fonctionner, d’autorisations qui doivent être accordées lors de l’installation. La règle définit si leur refus entraîne une violation de conformité. Il s’agit d’une autre application que celle concernée par Intercept X for Mobile permissions can be denied ci-dessus.
Locate permission required (Android): Pour la fonction Locate, définir si l’autorisation accordée lors de l’installation à l’application Control pour récupérer les données de localisation est requise pour la conformité.
App is able to locate (iPhone/iPad): Les services de localisation doivent être activés et l’application Control doit être autorisée à les utiliser. Cette combinaison est distincte du critère d’installation Android. Aucune des règles de localisation n’accorde d’autorisation organisationnelle ou juridique de recueillir la localisation.

Vérifier de manière ciblée les Chromebooks, les Mac et Windows

Chromebooks : Les règles suivantes concernent Sophos Chrome Security, et non l’application Control Android :

Tamper protection turned off: Sélectionner les réactions à appliquer si la Chrome Security policy a été altérée.
Minimum Sophos Chrome Security version: Définir la version minimale autorisée de l’extension Chrome Security.
Apps from unknown sources allowed: Définir si les applications et extensions provenant de l’extérieur du Chrome Web Store sont autorisées.

Mac : Les critères portent sur l’activation de chaque protection, et non sur une preuve que la règle de conformité l’active elle-même :

Firewall required: Le pare-feu macOS doit être activé.
System Integrity Protection required: SIP doit être activée. Cette fonction de protection macOS limite les actions de l’utilisateur root ; sa configuration est possible au démarrage depuis macOS Recovery. Cela n’accorde aucune autorisation de modifier SIP en cours d’exploitation.
Security updates required: L’installation automatique des mises à jour de sécurité macOS doit être activée. L’aide de la règle limite son application à macOS 26 (Tahoe) ou antérieur ; cette limite n’est pas celle d’iOS/iPadOS 27 pour la règle de mise à jour mobile.

Ordinateurs Windows : Sélectionner trois critères Defender distincts et ne pas les déduire d’un seul statut :

Windows Defender must be turned on: La protection en temps réel de Windows Defender doit être activée. L’exigence définie ci-dessus reste applicable. Pour Windows 10, Sophos décrit toutefois dans SMCSRV-13801 une limite de la vérification : la règle vérifie uniquement si le service Defender est en cours d’exécution, et non si la protection en temps réel est activée. Un appareil peut donc apparaître comme conforme alors que la protection est désactivée. Avant de se fier à cette protection, vérifier séparément et uniquement en lecture seule l’état réel de la protection en temps réel sur l’appareil Windows 10 concerné, sans modifier les paramètres de protection ni les stratégies. Un service en cours d’exécution et le statut de conformité ne remplacent pas cette vérification sur l’appareil.
Clean status from Windows Defender required: L’appareil est non conforme si Windows Defender affiche des avertissements.
Up-to-date Windows Defender definitions required: Windows Defender doit utiliser les dernières définitions de logiciels espions.

Ne pas confondre les réactions avec les règles

Create alert crée, dans l’édition complète, un événement visible sur la page de détails de l’appareil et une alerte ; Threat Defense décrit des alertes dans Sophos Fusion. Une alerte n’équivaut pas à un blocage configuré de la messagerie ou du conteneur. Sélectionner uniquement Create alert ne garantit toutefois ni une Health inchangée de l’appareil ni un accès Wireless inchangé ; une non-conformité peut également avoir d’autres conséquences.
Deny email est une réaction configurée à la violation d’une règle de politique dans l’édition complète ; elle nécessite une connexion configurée au proxy EAS de Sophos Mobile et est prévue pour Android, iPhone/iPad et Windows. La seule présence d’un proxy EAS ne prouve ni l’authentification du service de messagerie concerné ni l’interruption ou le rétablissement effectif de la distribution des messages. Séparément, Sophos décrit une quarantaine Exchange pour les appareils non inscrits uniquement avec un proxy EAS en mode PowerShell et une règle d’accès Exchange par défaut configurée en conséquence. Dans ce cadre, des appareils inscrits peuvent également être placés en quarantaine si le proxy ignore leur statut de conformité à cause d’une synchronisation trop ancienne ou d’une absence de connexion à Sophos Mobile. La notification d’inscription envoyée par Exchange dans ce processus de quarantaine n’est ni Create alert ni une preuve que Deny email a été déclenché. Ne déduire ni une quarantaine générale ni un rétablissement automatique de la messagerie d’une violation de règle ou d’une alerte ; l’investigation relève de la réponse à incident et non de cette planification des politiques.
Lock container est prévu, dans l’édition complète actuelle, pour Android Enterprise ; il ne faut pas en déduire un verrouillage garanti d’un conteneur iOS. Le tableau général des actions de conformité de l’édition complète décrit cette action configurée comme verrouillant toutes les applications sauf Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages et Phone. Cette description générale ne précise pas l’effet sur les applications du profil personnel BYOD ; ni les six exceptions ni l’exemple du profil professionnel ci-dessous ne prouvent que les applications personnelles restent accessibles. Pour un profil professionnel Android pris en charge, Sophos documente, dans le réglage distinct du contrôle d’accès, Auto (valeur par défaut sans autorisation d’accès manuelle : profil professionnel verrouillé si une règle de conformité enfreinte contient Lock container), Deny (profil professionnel verrouillé) et Allow (profil professionnel déverrouillé). Lorsque le profil est verrouillé, ses applications et données sont inaccessibles ; le réglage ne s’applique qu’après la synchronisation de l’appareil. Ce contrôle d’accès au profil professionnel est distinct de la commande de verrouillage de tout l’appareil ; il ne prouve ni l’effet de l’action de conformité configurée sur les applications personnelles, ni sa disponibilité pour tous les scénarios BYOD/d’inscription, ni une procédure de retour arrière testée. Vérifier le périmètre et l’effet sur un appareil autorisé avant toute approbation.
Distinguer Set health de la Health calculée : Dans l’édition complète, Set health est une action explicitement sélectionnée pour chaque règle : si la règle est enfreinte, la valeur choisie rouge/jaune/vert lui est attribuée ; si plusieurs règles sont enfreintes, la moins bonne valeur de Health attribuée s’applique. Pour Android, iPhone et iPad, cette action exige que Synchronized Security soit activée ; pour obtenir l’effet Wireless recherché, il faut aussi configurer dans la politique la valeur de Health associée à la non-conformité ainsi que les règles Wireless. Par ailleurs, Fusion affiche une Health de l’appareil fondée sur les violations des règles de conformité ; lorsque Synchronized Security est activée, cette valeur peut être remplacée manuellement, tandis que Auto rétablit le calcul à partir du statut de conformité. Il n’est pas établi quelle valeur est produite sans action Set health dans toutes les éditions et tous les modes, ni comment sont arbitrés un remplacement manuel et une action de règle simultanée ; ne déduire de Create alert ni une attribution automatique du rouge/jaune ni une Health inchangée. Vérifier séparément la règle enfreinte/la non-conformité, l’action Set health enregistrée, la Health affichée et son mode manuel/Auto, la valeur transmise à Wireless et l’accès effectif. Selon sa configuration, Sophos Wireless peut limiter l’accès au réseau ; un affichage dans la console ne prouve pas à lui seul un effet Wireless précis.
Transfer task bundle peut entraîner une mauvaise configuration des appareils, voire leur effacement. Ne pas définir de tâches Wipe/Reset ni de task bundles automatiques comme réaction par défaut ; ici, None signifie seulement qu’aucun task bundle n’est transféré, et non que la non-conformité reste sans conséquence.

Cas particulier : Dans l’édition complète, lorsqu’un appareil Android Enterprise fully managed est non conforme, toutes ses applications sont automatiquement désactivées, quelle que soit la réaction choisie pour chaque règle. Ce comportement ne doit pas être confondu avec l’action configurable Lock container et n’est pas établi pour les appareils Android BYOD/à profil professionnel, ceux utilisant uniquement MTD ou les autres modes Android. Pour Android BYOD, l’effet de Lock container dépend du mode de gestion effectivement pris en charge et de la configuration ; ne pas déduire d’un éventuel verrouillage de l’espace professionnel un verrouillage de l’appareil entier. Vérifier l’accessibilité du téléphone, de l’espace professionnel, des moyens de récupération et des applications critiques sur un appareil de test autorisé avant toute approbation.

Synchronized Security n’est pas disponible pour tous les appareils : Sophos exclut les Chromebooks, Apple User Enrollment et les appareils dotés d’une adresse MAC propre au réseau, privée ou aléatoire, car ils ne transmettent pas leur adresse MAC à Sophos Mobile. La possibilité distincte de transmettre l’adresse MAC par la configuration de l’application IXM avec un EMM tiers ne prouve aucune exception pour les adresses MAC privées/aléatoires. Ne prévoir un pilote Wireless que pour une combinaison appareil/mode d’inscription effectivement prise en charge, après vérification de la configuration MAC et de Synchronized Security ; un affichage de la Health ne remplace pas un test d’accès.

Attribuer progressivement plutôt que tester globalement

Recenser l’existant et les prérequis : Consigner le tenant, la licence/l’édition, le mode de gestion, la plateforme et le système d’exploitation, le propriétaire de l’appareil, le statut de gestion IXM, la dernière synchronisation, les règles existantes et les dépendances actives au proxy EAS et à Sophos Wireless. Documenter l’éligibilité à Synchronized Security et les limites MAC, la Health affichée de l’appareil et son mode manuel/Auto, les règles Wireless existantes, ainsi que les politiques et leurs attributions.
Évaluer individuellement les règles et les actions : Ouvrir le catalogue de règles actuel de la bonne édition du produit ; pour chaque plateforme activée, inventorier chaque règle héritée du modèle ou définie manuellement, ainsi que sa réaction. Vérifier le signal, le mode et les conditions de l’action avant Save et avant l’attribution ; ne pas considérer PCI/HIPAA comme passifs. Pour un pilote approuvé, prévoir une nouvelle politique isolée sans actions bloquantes ou destructrices et contrôler à nouveau les actions réellement enregistrées. L’absence de Set health ne prouve ni que la Health calculée ou définie manuellement restera inchangée ni que l’accès Wireless sera conservé. Important : Même Create alert seul ou None pour un task bundle n’empêche pas la désactivation automatique documentée des applications sur un appareil Android Enterprise fully managed non conforme. Exclure ces appareils de ce pilote jusqu’à ce qu’un test propre à l’appareil, portant sur l’accès aux applications et la récupération pour la version et le mode réels, soit autorisé et préparé.
Choisir un groupe pilote restreint : Examiner séparément les appareils professionnels et personnels prévus. Si un nouveau groupe est nécessaire pour le pilote approuvé, commencer par préparer le groupe d’appareils et vérifier son périmètre. Si les deux types de propriété sont gérés, Sophos recommande des politiques de conformité distinctes pour les appareils professionnels et personnels ; la présence de deux champs d’attribution séparés ne signifie pas à elle seule que des politiques différentes sont utilisées. Sous Device groups > [nom du groupe] > Compliance policies, les politiques corporate et personal sont attribuées séparément. Avant Save, vérifier pour chaque appareil ciblé son unique groupe d’appareils actuel (y compris le groupe Default existant, s’il lui est attribué), son type de propriété (corporate/personal) et la politique attribuée à ce groupe, afin de repérer toute portée involontaire. Après avoir sélectionné les politiques corporate et personal et vérifié la portée de l’attribution, cliquer sur Save pour enregistrer l’attribution au groupe. Sur la page Device groups, comparer ensuite, pour le groupe choisi, les deux colonnes Compliance policy (corporate) et Compliance policy (personal) à l’attribution prévue. Avant de modifier une politique existante et partagée, vérifier tous les groupes auxquels cette politique est attribuée ; la modification peut toucher d’autres groupes, non pas parce qu’un appareil appartient à plusieurs groupes. Un nouveau pilote isolé ne doit pas modifier implicitement une politique partagée.
Vérifier les effets dans le pilote autorisé : Avant de provoquer volontairement une violation, confirmer de nouveau qu’aucun appareil Android Enterprise fully managed ne fait partie du pilote limité aux alertes ou sans action ; Create alert ou None ne protège pas ses applications. Comparer d’abord l’attribution au groupe et l’appareil concerné, avec sa nouvelle valeur de conformité, la règle enfreinte, l’heure de synchronisation et, le cas échéant, l’alerte/l’événement. Sur un appareil de test pris en charge, observer séparément avant et après la violation l’action Set health réellement enregistrée, la Health affichée et le mode manuel/Auto, ainsi que, si Synchronized Security est activée, la Health transmise, la règle Wireless et l’accès Wireless effectif ; vérifier également le flux de messagerie et l’accès aux applications si la configuration le justifie. Même en l’absence d’action Set health, ne pas présumer que l’accès au réseau reste inchangé ; ne pas interpréter une synchronisation tardive ou absente comme une preuve de conformité. Ne tester une violation volontaire qu’avec un retour arrière confirmé et sans risque pour les données de production. Avant d’étendre le périmètre aux appareils Android Enterprise entièrement gérés, vérifier d’abord sur un appareil autorisé si la conséquence automatique documentée se produit pour la version et le mode réels et si le retour arrière fonctionne.
N’élargir qu’après validation : Comparer les appareils touchés et les violations inattendues à la situation initiale. En cas d’écart, arrêter le déploiement, rétablir après approbation les attributions de groupes et la configuration des règles/actions précédemment documentées, puis vérifier de nouveau le rétablissement sur l’appareil et dans les services externes. Supprimer une règle n’annule pas automatiquement les task bundles, effacements ou blocages d’accès externes déjà exécutés.

Ne pas utiliser comme test : Compliance policies > Check now concerne tous les appareils inscrits et exécute les actions configurées, même si seul un petit groupe était visé. Avant une vérification globale planifiée, tous les groupes et toutes les réactions doivent être contrôlés et le changement approuvé ; cet article n’autorise pas l’utilisation de ce bouton dans un tenant de production.

Exemple de planification uniquement, non testé : Un groupe spécialement approuvé comprenant un iPhone professionnel (sans Apple User Enrollment et sans Android Enterprise fully managed), une règle non destructive préalablement vérifiée comme applicable et Create alert pourrait servir de pilote limité. Avant l’attribution, relever toutes les paires règle/action, les appartenances aux groupes et, si Wireless fait partie du test, l’éligibilité à Synchronized Security ainsi que la configuration MAC et Wireless. Lors d’une violation de test autorisée et réversible, vérifier dans l’édition complète la violation/la non-conformité et l’événement sur la page de détails de l’appareil dans la console, ainsi que l’alerte dans la console ; dans l’édition autonome Sophos Mobile Threat Defense, vérifier l’alerte sur la page Alerts de Sophos Fusion. Séparément, vérifier la Health affichée (manuel/Auto) et, sur l’appareil ciblé, le flux de messagerie, l’accès aux applications et l’accès Wireless réel avant et après la synchronisation. Ne pas s’attendre à voir l’alerte sur l’appareil physique ciblé. Ne pas déduire de Create alert que la Health ou le réseau resteront inchangés. Arrêter si d’autres appareils sont touchés, si la synchronisation n’a pas lieu ou si la Health/l’accès présentent un écart inattendu ; ne pas élargir le périmètre, rétablir après approbation l’attribution antérieure et vérifier à nouveau ses effets. Il s’agit d’un plan de vérification, pas d’un résultat de test observé.

Périmètre et prérequis pour l’utilisation

L’investigation d’un appareil déjà signalé ou bloqué, le triage des alertes, le traitement des faux positifs et le rétablissement de l’accès à la messagerie ou à Wireless ne font pas partie de ce guide de planification des politiques. Celui-ci ne remplace pas une procédure de réponse à incident ou de réinitialisation. Sans vérification de l’erreur précise et de la combinaison appareil/mode d’inscription prise en charge, le recours au PIN de démarrage Android ou à la synchronisation manuelle indiqué dans la KBA-000004067 ne constitue pas une réparation générale. Pour le triage initial en lecture seule et la vérification de l’accès Wi-Fi, consulter le guide consacré à la réponse à un incident de conformité ; lui non plus n’accorde aucune autorisation opérationnelle.

Les procédures décrites n’ont été validées ni sur des appareils ni dans un tenant. Cet article n’accorde aucune autorisation opérationnelle. La relation entre l’action Set health choisie, la Health calculée automatiquement ou remplacée manuellement et les effets Wireless n’est pas résolue ici pour tous les modes. Les combinaisons de règles et d’actions propres à chaque édition, système d’exploitation et mode, ainsi que les procédures de retour arrière pour EAS/Wireless et l’accès aux applications Android, doivent être autorisées et vérifiées sur les appareils concernés avant toute utilisation opérationnelle.