De Server Lockdown à Unauthorized File Protection : pilote et migration

En bref : Choisir un groupe de stratégies encore soumis à Lockdown, conserver son état initial et préparer la restauration, puis créer une copie Monitor désactivée et non attribuée avant tout déverrouillage. Pendant la fenêtre de changement approuvée seulement, déverrouiller les serveurs pilotes, attribuer cette copie exclusivement à ces serveurs et l’activer. Après chaque modification de stratégie, attendre au moins 24 heures avant d’analyser les événements UFP ; autoriser précisément les exécutions légitimes et répéter le cycle. Ne tester la copie Monitor affinée en mode Block qu’ensuite, au moyen d’une stratégie distincte dont l’attribution reste strictement limitée. La stratégie Lockdown d’origine et ses attributions aux serveurs encore verrouillés restent inchangées.

Situation initiale et autorisation

La fin du support de Server Lockdown a été annoncée pour octobre 2026, sans date précise. Les stratégies Lockdown existantes portent désormais le nom d’Unauthorized File Protection (UFP/SUFP). Leurs entrées autorisées et bloquées subsistent après ce changement de nom. Celui-ci ne fait toutefois migrer aucun hôte verrouillé : un hôte doit être déverrouillé avant qu’une stratégie UFP activée puisse s’y appliquer. Lockdown fait aussi confiance aux fichiers créés ou modifiés par des logiciels autorisés ; des entrées de stratégie identiques ne constituent donc pas une base de confiance identique sous UFP. Cette procédure concerne les serveurs Windows utilisant déjà Server Lockdown, et non une nouvelle installation de Lockdown ; Server Lockdown n’est pas disponible avec XDR Sensor.

Avant toute intervention : Pour chaque tenant et groupe de stratégies, relever les serveurs, leurs responsables, les fenêtres de maintenance et le Lockdown status sous My Products > Server > Servers. Dans la vue du serveur, consigner les versions des produits et agents sous Summary, ainsi que la stratégie effectivement appliquée à chaque hôte sous Policies. Documenter la stratégie d’origine, ses entrées, ses attributions et sa priorité comme référence à ne pas modifier. Définir les services, tâches planifiées, mises à jour et installations MSI à tester avec une charge représentative et des responsables identifiés ; une installation MSI réussie ne prouve pas que les fichiers PE extraits pourront ensuite s’exécuter. Vérifier la licence, le système d’exploitation, les versions et les droits. Confirmer la sauvegarde des applications, la procédure de restauration et les contacts d’escalade. Ne pas commencer sans fenêtre approuvée, sans procédure de retour testée ni sans acceptation du risque lié au déverrouillage. Les vues du portail ne prouvent pas à elles seules l’efficacité de la protection sur l’hôte.

Migrer un groupe de stratégies en pilote

Délimiter le pilote. Désigner quelques serveurs de test représentatifs, leur groupe et la stratégie attendue. Consigner au préalable leur état Lockdown, l’état des services et les principaux parcours applicatifs. Arrêter si l’effet des stratégies n’est pas clair ou si la restauration n’est pas assurée ; ne pas migrer un deuxième groupe en parallèle.
Préparer Monitor avant le déverrouillage. Sous My Products > Server > Policies, cloner la stratégie UFP existante (anciennement Lockdown) et nommer la copie Monitor – [Originalname]. Immédiatement dans la copie, vérifier et retirer les Assigned Servers et Assigned Server Groups hérités : un clone ne doit pas englober largement le groupe encore verrouillé ni d’autres serveurs. Supprimer toutes les entrées reprises sous Allowed items (dans les anciennes vues Lockdown, Allowed files/folders) uniquement dans cette copie ; ne pas effacer les autorisations de la stratégie d’origine. Vérifier les entrées héritées sous Blocked items (anciennement Blocked files/folders) et repérer celles qui sont obsolètes ou nécessaires. Sous Settings, activer Enable tracking of unauthorized file changes et sélectionner Monitor execution of unauthorized files without blocking. Enregistrer la copie pour le moment désactivée et sans attribution. Ne modifier ni la stratégie d’origine activée, ni sa priorité, ni les attributions des hôtes encore verrouillés.
Déverrouiller le pilote et activer Monitor. Pendant la fenêtre de changement, sous My Products > Server > Servers > [Servername], sélectionner Unlock pour chaque hôte retenu et confirmer, puis vérifier son état. Le déverrouillage ne supprime pas automatiquement le composant Lockdown local ; sa désinstallation ne fait pas partie du pilote. Alors seulement, sous My Products > Server > Policies, ajouter à la copie Monitor exclusivement les serveurs pilotes déverrouillés ou leur groupe de test délimité dans Assigned Servers/Assigned Server Groups. Avant l’activation et Save, vérifier de nouveau qu’aucune attribution héritée ou autre attribution trop large n’y figure. Activer et enregistrer la copie. Sous My Products > Server > Servers > [Servername] > Policies, vérifier pour chaque serveur pilote que la copie Monitor est effectivement appliquée comme stratégie UFP ; si une autre stratégie s’applique, corriger d’abord le périmètre et la priorité de la copie pilote, sans modifier la stratégie d’origine ni les priorités des hôtes encore verrouillés. Le mode Monitor signale les exécutions non autorisées au lieu de les bloquer.
Observer et autoriser au cas par cas. Exercer les services, tâches, mises à jour et programmes d’installation représentatifs. Au plus tôt 24 heures après l’attribution ou toute modification ultérieure de la stratégie, examiner les événements UFP sous My Products > Server > Servers > [Servername] > Events ou Reports > General Logs > Events. Confronter le serveur, l’heure, le fichier et l’opération à la charge de test. N’ajouter sous Allowed items de la copie Monitor que les exécutions légitimes confirmées par les responsables métier, avec des autorisations strictement ciblées ; ne pas autoriser globalement des dossiers temporaires ou de téléchargement accessibles en écriture. Documenter la décision et les responsables, sélectionner Save sur la page de la stratégie, attendre de nouveau au moins 24 heures et examiner les nouveaux événements. Répéter jusqu’à ce qu’aucun événement inexpliqué ne subsiste pour les parcours légitimes testés. L’absence d’événements sans charge de test pertinente ne vaut pas autorisation de passer en mode Block ; enquêter sur les événements inconnus plutôt que de les autoriser aveuglément.
Tester Block séparément. Cloner la copie Monitor affinée et nommer ce nouveau clone Block – [Originalname]. Vérifier et retirer immédiatement tous les Assigned Servers/Assigned Server Groups hérités par la copie Block ; avant l’activation et Save, n’attribuer que les serveurs pilotes déverrouillés prévus, afin qu’aucun autre hôte ne soit soumis à Block par erreur. Sous Settings, sélectionner Block execution of unauthorized file, puis activer et enregistrer la copie. Conserver la copie Monitor comme solution de repli ciblée. Sous My Products > Server > Servers > [Servername] > Policies, vérifier que Block est effectivement appliqué à chaque serveur pilote ; si nécessaire, n’ajuster que le périmètre ou la priorité des copies pilotes. Tester effectivement les services, tâches et mises à jour, vérifier dans Events l’absence de blocages inattendus et refaire une analyse au plus tôt 24 heures après l’attribution ou toute modification. N’exécuter aucun fichier de test en production sans autorisation distincte. N’entamer le groupe de stratégies suivant selon la même procédure qu’après une validation documentée.

Arrêt, retour en arrière et escalade

En cas de blocages inexpliqués, d’applications indisponibles, d’absence d’événements malgré une charge de test censée en produire, ou si la mauvaise stratégie s’applique, arrêter l’extension du déploiement. Conserver le nom du serveur, l’heure, le fichier, la stratégie appliquée et l’état des services ; ne pas créer une autorisation générale en guise de correctif rapide. En cas de problèmes avec Block après validation, retirer l’attribution de la copie Block aux pilotes concernés ou désactiver cette copie pour leur périmètre. Cela ne suffit pas à revenir en arrière : la copie Monitor activée doit être attribuée à chaque hôte concerné et être la stratégie UFP correspondante de plus haute priorité ; sinon, une autre stratégie peut s’appliquer après le retrait de Block. Corriger en conséquence le périmètre et la priorité des copies pilotes, sans modifier la stratégie d’origine ni les attributions des hôtes encore verrouillés. Enregistrer et vérifier, pour chaque hôte sous My Products > Server > Servers > [Servername] > Policies, que la stratégie Monitor est effectivement appliquée ; retester ensuite les services et programmes d’installation et surveiller les événements. Ne retirer les entrées Allowed ou Blocked erronées qu’en se référant aux modifications documentées. Si la perturbation persiste, déclencher le plan de restauration des applications et faire intervenir les responsables de l’exploitation ainsi que le support Sophos.

Limites du retour en arrière : Revenir à Monitor ne rétablit ni l’état précédemment verrouillé de l’hôte, ni la base de confiance de Lockdown, ni les fichiers modifiés. Même la stratégie d’origine conservée ne garantit pas un nouveau verrouillage produisant les mêmes effets. Ne pas tenter de reverrouiller l’hôte ni de supprimer l’agent de manière improvisée ; si nécessaire, examiner avec le support Sophos la procédure de restauration propre à l’hôte. Entre le déverrouillage et la validation de Block, l’efficacité de la protection peut différer ; une migration sans période de protection potentiellement réduite n’est pas garantie.

Pour les entrées UFP et un pilote général sur des serveurs Windows déjà déverrouillés, voir Unauthorized File Protection pour les serveurs Windows.