Sophos Mobile : planifier prudemment les règles de mot de passe et les stratégies de sécurité Windows

Pour les stratégies Windows dans Sophos Mobile, la décision essentielle n’est pas de choisir le paramètre le plus strict, mais de mener un pilote dont on peut revenir en arrière : confirmer l’édition et l’état de gestion, vérifier la possibilité de récupérer BitLocker avant un éventuel redémarrage, inventorier les comptes locaux, puis attribuer une seule modification à un appareil de test. Une stratégie Windows n’est pas la stratégie Device Encryption de Sophos Fusion et ne remplace pas une procédure de récupération BitLocker. Pour la gestion des clés et la récupération, voir Gérer BitLocker avec Sophos Fusion.

Avant la première attribution

Plateforme et périmètre : L’appareil cible doit réellement être géré comme ordinateur Windows par Sophos Mobile ; Sophos Endpoint Protection seul ne constitue pas un enrôlement MDM. La liste des prérequis de Sophos Mobile mentionne Windows 10/11 Enterprise, Education et Pro, mais pas Home ; elle ne garantit pas que chaque configuration de stratégie fonctionne sur chaque édition ou build répertoriée. Selon Sophos, Restrictions ne s’applique pas à Pro, et Device Guard ne s’applique ni à Pro ni à Windows en mode S. Vérifier sur l’appareil concerné l’édition, la version de Windows, les prérequis matériels et les paramètres GPO/MDM effectivement en vigueur ; une ancienne page d’aide ne vaut pas validation actuelle.
Cycle de vie : Le support Microsoft des éditions standard de Windows 10 a pris fin le 14 octobre 2025 ; les éditions LTSC/LTSB et les appareils bénéficiant d’Extended Security Updates (ESU) admissibles et activées doivent être examinés séparément selon l’édition et la version. Les ESU ne prolongent ni le cycle de vie du produit Microsoft ni le support standard : elles fournissent temporairement des mises à jour de sécurité aux appareils admissibles et correctement enregistrés. La liste des prérequis de Sophos Mobile (version 2026.38 du 21 septembre 2026) mentionne néanmoins Windows 10 Enterprise/Education/Pro à partir de 20H2 ainsi que Windows 11 Enterprise/Education/Pro. Il s’agit d’une liste de plateformes Sophos, pas d’une garantie de support Microsoft pour les anciennes builds de Windows 10, ni d’une preuve que chaque stratégie Windows fonctionne. Le support de Windows 11 dépend lui aussi de la version et de l’édition : par exemple, 23H2 Pro ne reçoit déjà plus de mises à jour dans le cadre du support Microsoft, tandis que 23H2 Enterprise/Education est soumis à d’autres échéances. Avant le pilote, vérifier la version précise dans le cycle de vie Microsoft Release Health et tester le paramètre souhaité sur cet appareil précis.
Accès et retour arrière : Prévoir un accès local de récupération autorisé, une personne pouvant intervenir sur l’appareil et une fenêtre de changement. Avec BitLocker, garder accessible, selon la procédure approuvée, la clé de récupération correspondant à l’appareil concerné et à son protecteur actuel, et vérifier sa disponibilité avant la modification ; ne pas considérer une entrée simplement présente ou périmée comme une récupération testée. Identifier d’abord le gestionnaire réel et l’emplacement de stockage de la clé de récupération BitLocker actuelle de cet appareil (par exemple Fusion Device Encryption ou une autre gestion de clés autorisée). Le seul MDM Sophos Mobile ne prouve pas qu’une clé est enregistrée dans Fusion. Ne pas révéler une clé Fusion de production au moyen de Show Key dans le seul but de vérifier qu’elle est disponible. Documenter les règles de mot de passe et les GPO existantes. Pour Device Guard, vérifier également l’état initial de VBS/Credential Guard ainsi que Secure Boot et la prise en charge de DMA.
Petit groupe pilote : Ne pas attribuer d’abord la stratégie à un vaste groupe d’appareils. Documenter l’état initial, les utilisateurs concernés et le changement visible attendu. Selon Sophos, il n’existe pas de procédure générale Uninstall policy pour revenir en arrière sur une stratégie Windows ; il faut corriger les paramètres en mettant à jour la stratégie ou en en attribuant une autre. Un appareil désenrôlé ou qui ne se synchronise pas ne recevra pas nécessairement cette correction immédiatement.

Règles de mot de passe : éviter les redémarrages et les comptes bloqués

La configuration Password policies contrôle Maximum number of failed attempts, Time in minutes until the device is locked, Password history et Maximum password age in days.

Time in minutes until the device is locked définit après combien de minutes d’inactivité l’appareil est verrouillé. L’utilisateur peut le déverrouiller lui-même. Ce verrouillage pour inactivité est distinct du seuil de tentatives infructueuses qui peut provoquer un redémarrage avec demande de récupération BitLocker. Maximum password age in days définit après combien de jours les utilisateurs doivent changer leur mot de passe.

Password history désigne le nombre d’anciens mots de passe que Sophos Mobile conserve pour empêcher leur réutilisation ; un nouveau mot de passe ne doit correspondre à aucun d’eux. Sophos autorise la valeur 0 pour ne pas appliquer de restriction correspondante aux tentatives infructueuses, au délai de verrouillage ou à l’âge maximal du mot de passe. Il ne s’agit pas d’une recommandation de désactiver toutes les protections : choisir des valeurs adaptées au modèle de comptes et aux possibilités de récupération, puis les tester séparément. Cette stratégie Mobile ne permet pas de définir la complexité des mots de passe (longueur ou catégories de caractères, par exemple) ; elle relève de Windows et dépend notamment du type de compte. Ne pas prendre des valeurs de complexité historiques documentées pour des paramètres Windows actuels universels.

Si une stratégie de complexité Windows correspondante est activée et effectivement appliquée au compte concerné, des vérifications portant sur le nom du compte et sur des éléments du nom complet ou du nom d’affichage peuvent également intervenir lors de la création ou de la modification du mot de passe. L’application de ces vérifications et leurs modalités dépendent de la stratégie effective et du type de compte ; clarifier ces points pour les comptes concernés avant le pilote. Cela ne constitue ni une règle universelle concernant n’importe quelle suite de caractères du nom, ni une preuve des exigences actuelles applicables aux comptes Microsoft.

Avant d’activer « Maximum number of failed attempts » : Pour les ordinateurs Windows, Sophos indique qu’atteindre le seuil entraîne un redémarrage avec demande de récupération BitLocker. Microsoft précise, pour la règle MDM Windows correspondante, que sur un ordinateur de bureau les données ne sont pas effacées : la récupération BitLocker est déclenchée ; si BitLocker n’est pas activé, la règle ne peut pas être appliquée. Ne donc considérer un seuil de tentatives infructueuses ni comme un effacement de données ni comme une protection effective sur un appareil non chiffré. Vérifier l’état de BitLocker et l’accès à la clé de récupération effectivement enregistrée sur l’appareil concerné avant l’attribution ; ne pas provoquer volontairement des échecs de connexion sur les appareils de production. Si d’autres utilisateurs locaux existent en plus de l’utilisateur enregistré dans Sophos Mobile et qu’au moins l’un d’eux n’est pas autorisé à changer son mot de passe, cette stratégie de mot de passe ne peut pas être attribuée selon Sophos. Examiner et corriger les droits des comptes dans une étape distincte et approuvée ; ne pas étendre aveuglément les droits des utilisateurs ni supprimer des comptes pour imposer la stratégie.

Pour le pilote, commencer par recenser les comptes et les stratégies existantes, définir une durée d’inactivité et un âge maximal du mot de passe adaptés aux pratiques de travail, et confirmer la capacité de récupération avant de fixer un seuil de tentatives infructueuses. Après l’attribution, vérifier en lecture seule quelle stratégie est associée à l’appareil et si la durée d’inactivité choisie et l’âge maximal du mot de passe prennent effet. Un test du seuil d’échecs doit avoir lieu exclusivement dans un environnement de test isolé et approuvé, avec une clé de récupération accessible. Si une demande de récupération BitLocker survient de façon inattendue, ne pas multiplier les essais ni deviner d’autres clés : rapprocher l’identifiant de l’appareil de celui de la clé et suivre la procédure de récupération autorisée du gestionnaire de clés effectivement compétent ; le processus de récupération Fusion ne s’applique que si Sophos Device Encryption conserve la clé actuelle.

Restrictions : anticiper les conséquences de chaque case à cocher

Restrictions n’est pas un moyen général de renforcer la sécurité de Pro : Sophos exclut expressément Windows Pro. La configuration comprend notamment Forbid resetting the computer (empêche la réinitialisation depuis les paramètres et Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level et Forbid manual MDM unenrollment. Le blocage de la réinitialisation ou du désenrôlement MDM peut notamment empêcher une procédure prévue d’assistance ou de retrait du parc. Ne sélectionner qu’un seul paramètre justifié par modification pilote et en vérifier le fonctionnement sur l’appareil avant et après l’attribution.

Forbid manual configuration, dans la section Wi-Fi, présente un risque particulier : les profils déjà configurés par l’utilisateur ainsi que les profils Wi-Fi Sense sont supprimés lors de son application. Décocher cette case ne recrée pas automatiquement les profils supprimés. Avant cette intervention, assurer un autre accès de gestion et au réseau déjà testé, ainsi qu’une procédure documentée pour restaurer les profils Wi-Fi nécessaires. Les profils Wi-Fi, les certificats et SCEP relèvent d’une procédure Windows distincte consacrée au réseau et aux certificats ; sans cette garantie, ne pas activer ici le blocage du Wi-Fi.

Dans la liste de Sophos, Telemetry level désigne les niveaux Full, Enhanced, Basic et Security. Leur effet réel dans Windows et leur disponibilité dépendent de l’édition actuelle et de la stratégie Microsoft ; la liste Sophos ne prouve pas que chaque niveau fonctionne sur chaque appareil pilote. De même, d’anciens termes d’interface comme Cortana ou Wi-Fi Sense ne prouvent pas qu’un réglage agit sur les versions actuelles de Windows.

Device Guard : choisir d’abord une voie réversible

La configuration Device Guard de Sophos peut activer la sécurité basée sur la virtualisation (VBS) et Credential Guard. Turn on virtualization-based security (VBS) est le champ dédié à l’activation de VBS ; le choix dans Credential Guard configuration est distinct. Selon Sophos, les paramètres sont appliqués au premier démarrage de l’ordinateur Windows après l’attribution de la stratégie. Avant l’attribution, vérifier le matériel et les paramètres GPO/MDM existants, et planifier un redémarrage contrôlé.

Dans Platform security level, Sophos distingue deux options :

Secure Boot exploite les fonctions de protection prises en charge par l’appareil. Sans Input/Output Memory Management Units (IOMMUs), VBS utilise la fonction Secure Boot d’UEFI ; avec des IOMMUs, VBS utilise Secure Boot avec une protection contre les accès directs à la mémoire (DMA).
Secure Boot and DMA protection exige Secure Boot avec protection DMA. Si l’appareil ne prend pas en charge la protection DMA, VBS n’est pas activé avec ce choix.

Vérifications préalables de Credential Guard avant l’attribution : Seulement si Credential Guard doit être activé sur l’appareil pilote, recenser les parcours de connexion et d’accès réellement utilisés dans le tenant concerné : Wi-Fi ou 802.1X filaire, VPN (notamment PEAP/EAP-MSCHAPv2), SSO avec NTLMv1, RDP/assistance à distance avec des identifiants Windows enregistrés ou CredSSP, ainsi que les applications utilisant la délégation Kerberos non contrainte. Microsoft documente les conséquences pour l’authentification : avec MS-CHAP et NTLMv1, le SSO peut ne plus fonctionner et une nouvelle connexion manuelle peut être nécessaire ; ces protocoles ne sont pas pour autant systématiquement et entièrement bloqués. L’authentification Wi-Fi/VPN par certificat n’est pas bloquée. Le client Bureau à distance ne peut pas transmettre des identifiants Windows enregistrés à l’hôte cible ; CredSSP ne peut plus utiliser des identifiants enregistrés ou SSO, mais la saisie explicite d’identifiants reste possible. En revanche, la délégation Kerberos non contrainte est bloquée. N’examiner les dépendances supplémentaires que si elles existent réellement dans le pilote : Avec les responsables de l’identité et des applications, déterminer si Kerberos PKINIT avec RSA plutôt que Diffie-Hellman ou Kerberos DES est requis : Credential Guard bloque PKINIT avec RSA et DES ; ressaisir un mot de passe ne résout pas ces cas. Recenser aussi les Security Support Providers/Authentication Packages (SSP/AP) personnalisés ou non Microsoft en usage et les applications qui lisent les identifiants Windows enregistrés : ces intégrations peuvent cesser de fonctionner, notamment si elles nécessitent les hachages de mots de passe LSA ou des interfaces non prises en charge. Pour les parcours réellement concernés, prévoir avant l’attribution une solution compatible et un test fonctionnel représentatif ; ne pas attribuer Credential Guard si un parcours critique reste incertain. N’évaluer que les parcours pertinents pour l’appareil choisi avec les responsables de l’identité et du réseau concernés ; avant le redémarrage, disposer d’un accès de gestion ou à la console locale testé indépendamment et d’une procédure de retour arrière approuvée sans verrou UEFI. Si la connexion réseau ou d’assistance à distance habituelle est le seul moyen d’accès, ne pas encore attribuer Credential Guard.

Pour un pilote nécessitant une désactivation à distance, le choix pertinent est Credential Guard configuration: Turn on without lock : Sophos décrit Turn off ou une stratégie de groupe Windows comme moyens de retour arrière. Turn on with UEFI lock ne doit pas être envisagé comme un interrupteur réversible à distance. Sophos indique qu’une présence physique auprès de l’ordinateur est nécessaire pour le désactiver ; Microsoft documente à cette fin une procédure spécifique EFI/de démarrage avec confirmation avant le démarrage du système. Ne pas activer ce mode sans avoir expressément préparé une procédure de retour arrière locale. Turn off ne permet pas de supprimer un verrou UEFI déjà défini. Même sans verrou UEFI, d’autres paramètres de gestion peuvent prévaloir sur la modification ou Windows peut déjà activer Credential Guard par défaut.

Comparer l’état initial et l’état attendu sur l’appareil de test dans System Information (msinfo32.exe), à la rubrique Virtualization-based Security Services Running : Credential Guard doit y figurer comme service en cours d’exécution si son activation était l’objectif du pilote. Une tâche de stratégie réussie ne prouve pas à elle seule que le service s’exécute effectivement. Après le redémarrage, tester sur l’appareil pilote représentatif, avec un compte de test autorisé, les connexions et accès précédemment recensés et réellement utilisés (notamment 802.1X/Wi-Fi, VPN, RDP/assistance à distance et applications SSO/de délégation concernées ; le cas échéant, aussi les intégrations PKINIT-RSA/DES et SSP/AP, ainsi que les applications lisant des identifiants Windows enregistrés) et la voie de retour arrière indépendante ; ne pas conclure que les accès au réseau et à l’assistance fonctionnent du seul fait que Credential Guard est actif. En cas d’écart, vérifier d’abord l’édition, Secure Boot/DMA, les autres stratégies et l’état du redémarrage ; ne pas expérimenter en basculant le verrou UEFI. Pour revenir en arrière avec without lock, utiliser la stratégie Windows préparée ou la GPO compétente, synchroniser l’appareil et vérifier de nouveau son état après redémarrage. Avec with UEFI lock, arrêter la procédure et suivre le processus local de récupération Microsoft approuvé, avec accès physique.

Ne pas déployer aveuglément les configurations de messagerie

L’aide de Mobile présente Email account pour Exchange Online/Server et IMAP/POP comme configurations Windows. Pour les espaces réservés tels que %_EMAILADDRESS_% et %_USERNAME_%, les champs Exchange Login et Email Address doivent être renseignés dans Sophos Fusion pour l’utilisateur concerné. Si plusieurs comptes Exchange ont des stratégies de boîte aux lettres différentes, Windows ne peut, selon Sophos, appliquer qu’une seule stratégie ; l’utilisateur peut en outre refuser les changements apportés à la configuration Exchange. Les champs de mot de passe d’un projet de stratégie ne remplacent pas une procédure approuvée de gestion des identités et des secrets.

Important conflit d’actualité : Sophos décrit expressément la configuration de messagerie Exchange pour l’application Mail de Microsoft ; Microsoft a mis fin au support de Windows Mail/Calendar/People le 31 décembre 2024 et indique qu’il n’est plus possible d’y envoyer ou d’y recevoir des e-mails ou des événements. La page Sophos concernant IMAP/POP ne nomme aucun client cible actuellement pris en charge ; la reprise de cette configuration dans le nouvel Outlook n’est pas non plus démontrée. Il n’y a donc ici aucune procédure pas à pas pour déployer cette application Mail en production ou supposer une reprise automatique dans le nouvel Outlook. Clarifier d’abord le client cible, l’authentification, la stratégie de boîte aux lettres et la prise en charge actuelle dans le tenant concerné, puis effectuer un test distinct.

Déploiement, contrôle et retour arrière

Après les vérifications préalables, créer dans Sophos Mobile, sous Policies > Windows, une nouvelle stratégie réservée exclusivement au pilote. Avant toute modification d’une stratégie existante, vérifier d’abord tous les appareils et groupes qui y sont associés : les modifications d’une stratégie Windows déjà attribuée sont automatiquement synchronisées lors de la prochaine connexion de ces appareils et ne constituent pas un test limité à un seul appareil. Avec Add configuration, n’ajouter que la configuration vérifiée, enregistrer et sélectionner exclusivement l’appareil pilote choisi avec Assign. Pour les stratégies Windows, la page Schedule task décrite dans la boîte de dialogue Sophos est disponible pour les stratégies Android, Knox et iOS, mais pas pour Windows ; ne pas promettre ici une attribution Windows différée. Le test ne commence donc que lorsque la personne chargée de l’accompagnement est prête.

Après l’attribution, comparer la vue Policies de l’appareil concerné, l’état des tâches et le comportement réel de l’appareil. Les stratégies Windows se synchronisent automatiquement à la connexion de l’appareil ; un affichage dans l’interface ne prouve pas à lui seul leur effet local. En cas de modification inattendue, ne pas activer un second paramètre de sécurité : maintenir l’appareil accessible, corriger de manière contrôlée uniquement la stratégie réservée à cet appareil pilote ou attribuer une stratégie de remplacement vérifiée, attendre la synchronisation et le redémarrage nécessaire, puis vérifier de nouveau sur place. Avant de modifier une stratégie partagée également attribuée à l’appareil, vérifier ses attributions aux appareils et aux groupes. Les profils Wi-Fi déjà supprimés, un verrou UEFI ou une demande de récupération BitLocker déjà déclenchée ne sont pas automatiquement annulés par ces opérations.

Périmètre : Les certificats racines/clients, SCEP et les profils Wi-Fi relèvent d’une procédure Windows distincte consacrée au réseau et aux certificats. Les protecteurs BitLocker et la gestion des clés de récupération relèvent de Device Encryption. Le mode kiosque et l’enrôlement Windows ont chacun leurs propres prérequis et procédures de retour arrière ; aucune de ces tâches n’est automatiquement accomplie par la stratégie de sécurité examinée ici.