Aller au contenu
Avanet

Sophos Mobile : comprendre les stratégies pour Apple User Enrollment

Vérifier d’abord le mode de gestion : dans Sophos Mobile, la iOS user policy s’adresse aux iPhone et iPad inscrits avec Apple User Enrollment. Ce mode d’inscription est destiné aux appareils personnels (BYOD). Il ne s’agit pas d’Apple Device Enrollment, mode dans lequel Sophos Mobile gère l’appareil entier, ni d’Automated Device Enrollment (ADE) via Apple Business. Les iPhone et iPad inscrits automatiquement par ce dernier mode sont supervisés (supervised). Un appareil supervisé ne peut pas être inscrit avec Apple User Enrollment. Ne pas transposer sans vérification les paramètres d’une iOS device policy ou d’un guide ADE à une stratégie utilisateur.

Ce que signifie concrètement la séparation

Apple User Enrollment utilise un compte Apple géré en plus du compte Apple personnel. Les données professionnelles résident dans un volume APFS géré : elles comprennent les apps gérées et leurs données, un trousseau géré ainsi que les données du compte Apple géré. Lors de la désinscription de Sophos Mobile, iOS supprime ce volume géré de l’appareil. Cela ne signifie pas qu’un administrateur peut effacer l’ensemble de l’appareil personnel ou consulter ses contenus privés. Avec ce mode d’inscription, Sophos Mobile ne peut interroger ni les données personnelles ni les identifiants de l’appareil tels que l’UDID, l’IMEI et l’adresse MAC ; faute d’adresse MAC, le NAC n’est pas disponible pour ces appareils.

Avant tout déploiement, confirmer que l’appareil est bien inscrit en mode User Enrollment et que l’utilisateur dispose d’un compte Apple géré pour l’inscription. Selon Sophos, la variante fondée sur un profil n’est disponible que jusqu’à iOS/iPadOS 17 ; ne pas fonder les déploiements plus récents sur cet ancien parcours. Le guide Apple User Enrollment décrit les identités, la préparation du tenant et le parcours d’inscription approprié ; cet article reste une aide à la décision pour la stratégie utilisateur qui suit.

Cette gestion MDM nécessite Sophos Mobile Device Management ou la licence combinée Sophos Mobile ; Sophos Mobile Threat Defense seul ne couvre pas ce volet. Avant l’attribution, vérifier les droits réels dans le tenant prévu à l’aide du contrôle des licences Mobile.

Choisir les stratégies selon leur objectif

  • Code d’accès de l’appareil : lorsqu’une configuration Password policies est attribuée à un appareil inscrit avec Apple User Enrollment, Sophos exige un code PIN à six chiffres pour l’appareil et interdit les codes composés de chiffres répétés ou consécutifs (Sophos cite par exemple 555555 et 987654). Cette exigence touche aussi l’accès personnel à l’appareil. Sophos Mobile ne peut pas réinitialiser un code d’accès oublié. Si l’appareil ne satisfait pas aux exigences de code d’accès au moment où cette configuration lui est attribuée, un délai de 60 minutes commence selon Sophos. Pendant ce délai, l’appareil demande de modifier le code d’accès à chaque ouverture de l’écran d’accueil. À l’expiration du délai, il peut devenir impossible de lancer une quelconque app, y compris les apps intégrées et personnelles. Ne pas traiter ce réglage comme une simple règle de l’espace professionnel ni le déployer sans en informer les utilisateurs au préalable.
  • Comptes professionnels : Email account ajoute Exchange Online ou Exchange Server à Apple Mail ; ce compte est géré. IMAP/POP configure séparément les serveurs de messagerie entrants et sortants. Google account ajoute un compte Google à l’app Mail ; lors de l’attribution, l’utilisateur doit saisir ses identifiants Google. CalDAV et CardDAV concernent respectivement la synchronisation des calendriers et des contacts. Les serveurs, ports, modes d’authentification et paramètres TLS doivent correspondre au service réellement utilisé ; les URL d’exemple ne sont pas des valeurs de référence universelles. %_USERNAME_% et %_EMAILADDRESS_% figurent tous deux dans Email account et dans IMAP/POP, avec des rôles différents selon le champ. Pour les deux configurations, les champs utilisateur Exchange Login et Email Address doivent être renseignés dans Sophos Fusion.
  • Connexion Exchange : dans Email account, User est l’identifiant de connexion, tandis que Email address est l’adresse du compte. Pour Exchange Online, l’identifiant de connexion est normalement l’adresse e-mail ; %_EMAILADDRESS_% reprend à cet effet Email Address de l’utilisateur attribué à l’appareil. Pour Exchange Server, Sophos indique %_USERNAME_% sous User ; l’aide générale sur les espaces réservés associe cette valeur à Exchange Login du même utilisateur. Sous Email address, %_EMAILADDRESS_% reprend l’adresse du compte depuis Email Address. Ni le nom d’utilisateur visible ni un espace réservé apparemment correct ne prouvent que l’identifiant de connexion convient. Distinguer d’abord le cloud et le mode d’authentification. Sans OAuth, Sophos indique outlook.office365.com dans Server name pour le cloud Microsoft 365 mondial. Ne pas utiliser cet hôte pour les autres clouds Microsoft 365 ; déterminer séparément leurs points de terminaison. Pour Exchange Server, saisir l’URL du serveur ; si le Sophos Mobile EAS proxy est utilisé, saisir plutôt l’URL de ce proxy. Domain reste vide pour Exchange Online ; pour Exchange Server, ce champ doit contenir le domaine du compte utilisateur. Turn on OAuth 2.0 prévoit une connexion avec les identifiants Microsoft. Avec OAuth, Server name reste vide selon Sophos, car l’hôte Exchange est déterminé automatiquement. La saisie d’un OAuth authorization endpoint constitue une exception : cette détection automatique n’a alors pas lieu et l’URL du serveur de messagerie doit figurer dans Server name. Ne renseigner le point de terminaison d’autorisation et OAuth token endpoint que si le fournisseur d’authentification l’exige. Selon Sophos, un champ Password vide signifie que l’utilisateur doit saisir le mot de passe sur l’appareil. Ce n’est pas une solution de repli vers Basic Authentication ou les mots de passe d’application pour Exchange Online EAS ; Microsoft documente leur suppression. La documentation Microsoft examinée mentionne également une restriction pour l’app Mail native d’iOS dans Gallatin et y recommande Outlook mobile. Cela ne vaut pas validation d’Apple Mail dans tous les clouds.
  • Transport Exchange et certificats : selon Sophos, SSL/TLS sécurise la connexion au serveur Exchange avec SSL ou TLS, selon ce que le serveur prend en charge ; Sophos recommande de cocher cette case. Pour l’utilisation, vérifier une connexion TLS conforme aux exigences de sécurité de l’organisation et la confiance accordée à ses certificats ; ne pas considérer la case cochée comme une preuve de connexion. Identity certificate concerne l’identité de connexion au serveur Exchange lorsque ce mode d’authentification est prévu. Séparément, Enable S/MIME permet de chiffrer les messages ; Signing certificate et Encryption certificate servent respectivement à signer et à chiffrer les messages. Avant leur sélection, les certificats nécessaires doivent être chargés au format PKCS #12 (.pfx) via Client certificate > File > Upload a file dans la même stratégie. Les autres stratégies nécessitent un nouveau chargement ; ne pas supposer une réutilisation automatique. Ces branches de certificats ne sont pas obligatoires pour chaque compte Exchange. Allow user to send unencrypted emails permet à l’utilisateur de choisir, pour chaque message sortant, s’il souhaite le chiffrer ; ce choix n’est pas un paramètre TLS.
  • Synchronisation Exchange : les cinq options contrôlent des données de compte distinctes : Synchronize calendar → Calendar (rendez-vous et réunions), Synchronize contacts → Contacts, Synchronize mail → Mail, Synchronize notes → Notes et Synchronize tasks → Reminders (tâches). Chaque domaine possède une autorisation de modification distincte : User can change calendar synchronization, User can change contacts synchronization, User can change mail synchronization, User can change notes synchronization ou User can change tasks synchronization. Elle permet à l’utilisateur d’activer ou de désactiver la synchronisation correspondante. Définir donc séparément le périmètre des données et le droit de modification ; activer la synchronisation n’autorise pas en soi l’utilisateur à la modifier sur l’appareil.
  • Compte Google : Google email address contient l’adresse e-mail complète du compte Google. User name désigne ici le nom de l’utilisateur pour les messages sortants, et non l’identifiant de connexion à un serveur de messagerie. Ne pas appliquer à ce champ la correspondance avec Exchange Login utilisée dans d’autres configurations.
  • Connexion IMAP/POP : Account type permet de choisir IMAP ou POP pour les messages entrants. User display name est le nom d’affichage pour les messages sortants ; l’aide IMAP/POP indique %_USERNAME_% pour ce champ et décrit sa valeur comme le nom de l’utilisateur attribué à l’appareil. En revanche, l’aide générale de Sophos sur les espaces réservés associe explicitement ce même espace réservé au champ utilisateur Exchange Login. Pour %_EMAILADDRESS_%, elle indique Email Address ; cet espace réservé doit être utilisé ici dans Email address, l’adresse du compte. La correspondance documentée entre les champs est ainsi précisée, mais la différence de description de %_USERNAME_% n’est pas résolue quant au comportement du produit. Ne pas supposer que cet espace réservé fournit un nom d’affichage personnel indépendant de cette valeur. Avant de l’utiliser, vérifier que la valeur renseignée dans Exchange Login convient comme nom d’affichage pour les messages sortants. Pour chacun des serveurs de messagerie entrant et sortant, définir User name comme identifiant de connexion et Authentication type comme méthode d’authentification ; Password n’est nécessaire dans chaque cas que si le serveur l’exige. Use same password as for incoming email permet au compte sortant de reprendre le mot de passe du compte entrant. Cela ne suppose pas que les noms d’utilisateur, les ports, les méthodes d’authentification ou les options de transport soient identiques. Chaque sens dispose de sa propre option SSL/TLS. Selon Sophos, celle-ci sécurise la connexion correspondante avec SSL ou TLS, selon ce que le serveur prend en charge. Pour l’utilisation, une connexion TLS conforme aux exigences de sécurité de l’organisation est nécessaire dans les deux sens ; ces options ne prouvent ni la confiance accordée aux certificats, ni la réussite de l’authentification ou du transfert des e-mails.
  • S/MIME pour IMAP/POP : si le chiffrement des messages est nécessaire, Enable S/MIME permet, selon Sophos, d’envoyer et de recevoir des messages chiffrés. Pour Signing certificate et Encryption certificate, les certificats doivent être chargés dans la configuration Client certificate de la même stratégie avant de pouvoir être sélectionnés. Allow user to send unencrypted emails permet à l’utilisateur de choisir, pour chaque message sortant, s’il souhaite le chiffrer. Ce chiffrement facultatif des messages est distinct de SSL/TLS pour le transport ; ni la confiance accordée aux certificats ni la compatibilité avec les destinataires ne sont vérifiées ici.
  • Compte CalDAV : dans la stratégie utilisateur, Account name est le nom d’affichage du compte sur l’appareil, et non l’identifiant de connexion. Server désigne le nom d’hôte ou l’adresse IP du serveur CalDAV ; User name et Password sont les identifiants du compte CalDAV. Si le serveur l’exige, saisir dans Principal URL l’URL du principal de la ressource de calendrier. Elle désigne la ressource de calendrier requise et ne doit pas être confondue avec le nom du serveur ou le nom d’affichage du compte. Selon Sophos, l’option SSL/TLS sécurise la connexion au serveur CalDAV avec SSL ou TLS, selon ce que le serveur prend en charge. Sophos recommande de cocher cette case. Pour l’utilisation, le service doit prendre en charge une connexion TLS conforme aux exigences de sécurité de l’organisation ; cette case à cocher ne confirme à elle seule ni la confiance accordée aux certificats, ni la réussite de l’authentification ou de la synchronisation.
  • Compte CardDAV : Account name est le nom d’affichage sur l’appareil ; User name et Password sont les identifiants du compte CardDAV. Server contient le nom d’hôte ou l’adresse IP du serveur CardDAV ; le port doit correspondre à ce service. Si le serveur l’exige, saisir dans Principal URL l’URL du principal de la ressource de contacts. Cette adresse de ressource n’est ni le nom du serveur ni le nom d’affichage du compte. Selon Sophos, SSL/TLS sécurise la connexion avec SSL ou TLS, selon ce que le serveur prend en charge ; Sophos recommande de cocher cette case. Pour l’utilisation, le service doit prendre en charge une connexion TLS conforme aux exigences de sécurité de l’organisation. Cette case à cocher ne prouve à elle seule ni la confiance accordée aux certificats, ni la réussite de l’authentification ou de la synchronisation des contacts.
  • Flux des e-mails : ni un compte de messagerie géré à lui seul ni le volume APFS géré ne garantissent une isolation complète. Pour Email account et IMAP/POP, vérifier séparément si Allow move permet de déplacer des messages vers d’autres comptes ou d’y répondre et de les transférer avec un autre compte, si Allow recent address syncing synchronise les adresses récentes via iCloud vers d’autres appareils, et si Use in Mail only limite l’utilisation du compte pour envoyer depuis d’autres apps. Pour IMAP/POP, examiner aussi Allow Mail Drop comme un flux de données distinct. Aucune de ces options ne constitue à elle seule une garantie démontrée de prévention des fuites de données.
  • Flux de données : Restrictions comporte des règles distinctes pour les documents allant du domaine géré → non géré et du domaine non géré → géré, pour la lecture des contacts gérés par des apps non gérées, ainsi que pour le presse-papiers et la synchronisation iCloud. La séparation documentée des pièces jointes de messagerie gérées nécessite un compte géré et des apps gérées. Si la règle relative aux documents dans les apps et comptes gérés est désactivée, les deux options suivantes (partage des contacts et règle relative aux documents pour les apps et comptes non gérés) sont désactivées. Selon Sophos, les contacts des comptes gérés peuvent alors être partagés avec des apps non gérées. Avec Force AirDrop documents to be used as unmanaged documents, AirDrop est traité comme une destination non gérée selon Sophos ; cette option ne constitue pas un blocage général d’AirDrop. Si les deux règles relatives aux documents sont désactivées, la restriction du presse-papiers n’a aucun effet. Vérifier séparément le sens de transfert voulu, le partage des contacts, la synchronisation iCloud et les flux de données observables sur un appareil de test ; ne pas promettre une isolation générale des données.
  • Fonctions de l’appareil et vie privée : Restrictions > Device comprend aussi des choix qui touchent l’usage de l’appareil personnel. Allow screen capture autorise les captures d’écran ; cette capacité est distincte des règles de partage de documents et ne constitue pas une garantie DLP. Si Allow Siri est désactivé, Siri, les commandes vocales et la dictée ne sont pas utilisables selon Sophos. Si seul Allow Siri while device is locked est désactivé, l’utilisateur doit déverrouiller l’appareil en saisissant son mot de passe avant d’utiliser Siri. Force local translation empêche la connexion aux serveurs Siri pour les traductions, et non toute transmission de données. Force Wrist Detection impose la détection du poignet sur une Apple Watch jumelée. Force pairing password for outgoing AirPlay requests exige un mot de passe de jumelage sur les autres appareils recevant une demande AirPlay de cet appareil ; ce n’est pas un blocage général d’AirPlay.
  • Écran verrouillé et Safari : Allow Control Center on lock screen, Allow Notification Center on lock screen et Allow Today view on lock screen permettent de décider séparément de l’accès au centre de contrôle, au centre de notifications et à la vue Aujourd’hui lorsque l’écran est verrouillé. Selon Sophos, décocher la case correspondante rend cette zone indisponible dans cet état. Sous Restrictions > Applications, Force fraud warning maintient toujours activé le réglage de sécurité de Safari qui avertit lors de la visite d’un site soupçonné de phishing ; il impose un avertissement, sans garantir le blocage des sites de phishing. Convenir de ces choix avec l’utilisateur avant l’attribution et vérifier leurs effets souhaités dans le pilote autorisé ; ni des valeurs par défaut ni des effets testés ici ne sont promis.
  • Données de diagnostic et sauvegardes : dans Restrictions, Allow diagnostic data to be sent to Apple contrôle l’envoi des informations de diagnostic à Apple. Si cette case est décochée, ces informations ne sont pas envoyées à Apple selon Sophos. Selon Sophos, Force encrypted backups impose aux utilisateurs de chiffrer leurs sauvegardes dans iTunes. Ne pas étendre cette exigence documentée à toutes les méthodes de sauvegarde ni aux sauvegardes iCloud ; elle ne remplace pas non plus une politique de sauvegarde et de conservation. L’option de diagnostic ne garantit pas que toute autre transmission de données soit empêchée.
  • SSO Kerberos : Single sign-on décrit le SSO Kerberos pour les apps tierces ; la configuration documentée ne s’applique que jusqu’à iOS 26 ou iPadOS 26. Kerberos principal name contient le nom du principal ; si le champ reste vide, l’utilisateur doit le saisir selon Sophos. Saisir le realm Kerberos en majuscules dans Realm. La liste URLs contient les préfixes d’URL qui doivent correspondre pour l’authentification Kerberos via HTTP. Les entrées doivent commencer par http:// ou https:// ; si le / final manque, Sophos Mobile l’ajoute. Pour la correspondance des URL, un astérisque unique (*) est autorisé comme caractère générique représentant n’importe quelle valeur. App IDs contient les identifiants de bundle des apps : soit des valeurs exactes, soit des préfixes se terminant par .*. Ces règles déterminent le périmètre cible de la configuration ; la source ne décrit pas comment la correspondance des URL et celle des identifiants d’apps sont combinées. Elles ne prouvent pas la réussite de l’authentification sur l’appareil.
  • Imprimantes : AirPrint ajoute des imprimantes à la liste des imprimantes. L’adresse IP et le chemin de ressource doivent correspondre au service d’impression ; Port désigne le port sur lequel l’imprimante AirPrint accepte les connexions. Selon Sophos, Force TLS sécurise les connexions AirPrint avec TLS. La valeur du port et la prise en charge de TLS doivent correspondre au service d’impression concerné ; cela n’implique ni un port par défaut, ni une garantie de confiance accordée aux certificats ou de réussite de l’impression.
  • Web Clip : Web Clip crée un raccourci sur l’écran d’accueil. Selon Sophos, le préfixe https:// ne peut être omis dans URL que pour un simple nom de domaine. Dans tous les autres cas, l’URL complète est nécessaire, par exemple en présence d’un chemin, d’un port ou d’un schéma d’URL personnalisé. Selon Sophos, Full screen ouvre l’URL sous forme d’app web en plein écran, et non d’app native installée. Show external pages in full-screen détermine si le plein écran est conservé lors du passage à d’autres pages web ; si la case est décochée, le navigateur s’affiche. Browser app permet de sélectionner l’une des apps installées sur les iPhone et iPad gérés. Device default utilise le navigateur par défaut défini sur l’appareil. Si l’app sélectionnée n’est pas disponible sur un appareil ou ne peut pas ouvrir de pages web, le Web Clip s’ouvre dans Safari selon Sophos. Ce choix ne garantit donc ni un navigateur particulier, ni un mode kiosque, ni l’accessibilité de la destination. Selon Sophos, un Web Clip défini comme non supprimable ne peut disparaître qu’après la suppression de la stratégie qui l’a installé ; prévoir donc une procédure de retrait avant d’activer cette option.

Apps gérées et VPN par app : éviter les raccourcis

Une app gérée n’est pas n’importe quelle app présente sur l’appareil personnel. Pour User Enrollment, Sophos ne décrit que les apps acquises via Apple Business : elles sont distribuées par Sophos Mobile ou attribuées au compte Apple géré. Si la même app est déjà installée à titre personnel, elle ne peut pas être installée en plus comme app gérée. Une app gérée supprimée par l’utilisateur reste gérée si elle est réinstallée. En revanche, Mail, Notes et Calendar peuvent contenir des données du compte personnel comme du compte géré : ne pas classer leurs données d’après le seul nom de l’app.

Apple autorise la charge utile AppLayerVPN avec User Enrollment ; cette possibilité offerte par la plateforme ne prouve pas que Sophos Mobile peut attribuer à une app une connexion provenant d’une stratégie utilisateur. Sophos répertorie VPN pro App (aide en anglais : Per app VPN) parmi les configurations d’une stratégie utilisateur iOS et renvoie vers un guide d’attribution aux apps. Ce guide exige toutefois une ou plusieurs stratégies d’appareil comportant VPN pro App et décrit les connexions sélectionnables exclusivement comme des configurations issues de stratégies d’appareil ; il renvoie en même temps à la stratégie utilisateur iOS. Il existe donc une tension non résolue dans la documentation entre la page consacrée aux stratégies utilisateur et la description de l’attribution limitée aux stratégies d’appareil ; cela ne prouve pas un comportement contradictoire du produit. La disponibilité effective d’une connexion issue d’une stratégie utilisateur dans le sélecteur VPN des apps sous Apple User Enrollment reste non résolue. Ce brouillon ne demande donc pas d’attribuer une telle connexion à une app et ne propose ni parcours de clics ni garantie sur l’effet du VPN ; aucune attribution VPN à une app installée à titre personnel ne peut non plus en être déduite. Toute future consigne d’exploitation exige une confirmation indépendante dans le tenant User Enrollment autorisé : app gérée sous licence appropriée, présence de la configuration de stratégie utilisateur dans le sélecteur, comportement à la demande, trajet réel des données de l’app et retrait de l’attribution. Le champ Alle Daten über VPN übertragen (aide en anglais : Send all traffic through VPN) du profil Per-App ne prouve pas que le trafic de tout l’appareil passe par le VPN.

Préparer les comptes pour un pilote limité

Pour Email account et IMAP/POP, vérifier d’abord l’utilisateur réellement attribué à l’appareil. Dans Sophos Fusion, sous My Environment > Users & Groups > Users, ouvrir la bonne personne et, via Edit, vérifier ou renseigner Exchange Login et Email Address, puis sélectionner Save. Les détails de compte importés depuis Active Directory ne peuvent pas être modifiés à cet endroit. Dans ce cas, clarifier les valeurs avec l’administration de l’annuaire concernée plutôt que de créer un deuxième objet utilisateur. Ne pas étendre cette restriction AD documentée à toutes les identités Entra ID. Pour IMAP/POP, vérifier également que la valeur Exchange Login convient comme nom d’affichage sortant ; la différence de description de l’espace réservé citée plus haut reste non résolue.

La création de stratégie et l’attribution ciblée décrivent le parcours commun. Choisir expressément une iOS & iPadOS user policy, modifier les configurations nécessaires et enregistrer. Pour un pilote autorisé séparément, utiliser une stratégie isolée et uniquement les appareils autorisés. Avant chaque modification, consigner les paramètres précédents et toutes les attributions de cette stratégie : une stratégie partagée n’est pas un test sur un seul appareil. Les stratégies utilisateur se synchronisent automatiquement à chaque connexion à Sophos Mobile ; ne reprendre pour elles ni Update devices ni l’écran de planification de l’attribution directe des stratégies d’appareil.

Les contrôles suivants sont des critères de validation prévus, non des résultats observés ici sur des appareils. Utiliser uniquement des comptes de test autorisés et des données de test sans données clients ; définir le périmètre de données souhaité avant l’attribution.

  • Exchange et IMAP/POP : sur le bon compte, comparer au plan l’adresse du compte et l’identifiant de connexion réellement obtenus après substitution ainsi que, pour IMAP/POP, le nom d’affichage sortant. Confirmer séparément l’authentification, la connexion TLS conforme aux exigences et la confiance accordée aux certificats. Vérifier séparément la réception d’un message de test et sa livraison sortante, plutôt que de considérer le seul affichage du compte comme un succès. Pour Exchange, vérifier les domaines de synchronisation choisis dans les apps correspondantes et les modifications utilisateur autorisées séparément. Observer avec des données de test les flux d’e-mails souhaités, autorisés et bloqués. Uniquement si l’utilisation de certificats est prévue, vérifier également l’identité de connexion ou la signature S/MIME, le chiffrement et la compatibilité avec les destinataires.
  • CardDAV : comparer le compte créé et la ressource de contacts prévue. Vérifier la présence sur l’appareil d’un contact de test clairement identifiable provenant de la ressource serveur autorisée, puis comparer son contenu. Ne vérifier le sens inverse que s’il est prévu et autorisé pour le service concerné ; ne promettre ni écriture universelle ni synchronisation bidirectionnelle. Si le contact manque ou apparaît dans le mauvais compte, vérifier d’abord la correspondance compte/ressource, Server et Port, puis les identifiants et l’éventuelle Principal URL requise. En cas d’erreur de connexion ou de confiance, clarifier aussi la prise en charge TLS et la confiance accordée aux certificats ; ne pas désactiver la protection du transport pour diagnostiquer le problème.

En cas d’identité incorrecte ou d’écart d’authentification, de transport ou de flux de données, arrêter l’extension du déploiement et clarifier la situation avec les responsables du service ou de Mobile. Un état comme Applied, une nouvelle version de stratégie ou une date de connexion récente ne remplace aucun de ces contrôles de compte.

Planifier les modifications et le retrait selon le mode de gestion

Pour corriger une stratégie utilisateur, l’aide générale sur les stratégies indique de modifier la stratégie ou d’en attribuer une autre. Pour une restauration prévue, utiliser les paramètres précédents documentés des charges utiles, puis observer à nouveau l’état des comptes et des données après la prochaine connexion et synchronisation. Ce n’est pas une méthode de retour arrière démontrée sans perte.

Selon le guide de désinstallation, l’action directe Devices > [appareil] > Policies > Uninstall est limitée à certaines stratégies d’appareil et n’est pas prévue pour la iOS user policy. Cela ne signifie pas qu’aucune tâche de retrait prise en charge n’existe : pour User Enrollment, Sophos documente expressément Unassign iOS user policy dans le parcours des bundles de tâches. Sous Select source > Policies, y sélectionner la stratégie utilisateur vérifiée et transférer le bundle uniquement aux appareils cibles autorisés. Sur iOS/iPadOS, Uninstall policy relève du mode Device Enrollment ; l’action générale Unassign du guide de désinstallation concerne tous les appareils ayant cette attribution et n’est pas une voie de retour ciblée pour le pilote.

Avant une telle tâche, consigner la bonne stratégie, les appareils cibles et les comptes/contacts présents, puis sauvegarder les données professionnelles nécessaires par la voie approuvée. Comparer ensuite l’état des tâches et de la synchronisation ainsi que l’état réel des comptes, contacts et données ; vérifier séparément la conservation prévue des données nécessaires. En cas d’écart, arrêter et escalader, sans recourir à Unenroll, Wipe ou à la suppression de groupes. Une tâche réussie ne confirme à elle seule ni la suppression complète des charges utiles ni la conservation des données.

Points à résoudre avant validation

Avant un déploiement en production, il faut obtenir le consentement de la personne concernée, convenir d’une stratégie de sauvegarde et de conservation, puis effectuer un test sur un appareil autorisé à cet effet : relever le mode d’inscription, la version de l’OS, l’édition et la licence, la licence et le statut de gestion de l’app, les comptes et les données existantes. Définir une voie d’escalade en cas d’oubli du code d’accès, plutôt que de compter sur une réinitialisation indisponible dans Sophos ; après l’expiration du délai documenté de 60 minutes, des apps privées peuvent elles aussi être bloquées. Ne valider les flux de documents, d’e-mails et de trafic VPN qu’à partir de résultats observables.

Tester le retrait pour chaque charge utile au lieu de supposer qu’il suffit de supprimer l’attribution de la stratégie : vérifier les comptes et le statut des apps après le retrait de la stratégie ; pour un Web Clip non supprimable, prendre en compte la stratégie qui l’a installé ; pour les apps gérées, vérifier aussi la désinstallation ou le retrait de la licence et l’état d’une app réinstallée. Déterminer à l’avance quelles données professionnelles doivent être conservées et comment les sauvegarder hors de l’appareil. La désinscription supprime le volume APFS géré et les données professionnelles qui s’y trouvent : ce n’est pas un retour arrière sans perte, même si les données personnelles de l’appareil ne sont pas effacées de façon générale. Ni tenant ni iPhone/iPad n’ont été testés ici ; l’ordre des opérations de retrait n’a pas été confirmé en pratique et les effets techniques des charges utiles n’ont pas été validés. La validation documentaire de cet article doit être distinguée de la validation technique d’un déploiement en production ; elle ne confirme aucun effet dans le tenant ou sur l’appareil. Ne pas utiliser notamment l’obligation de code d’accès, les autorisations de partage des documents et l’attribution VPN comme consignes de production sans cette validation technique.