Déployer Sophos Server Peripheral Control sur les serveurs Windows

Server Peripheral Control régit les périphériques et supports amovibles sur les serveurs Windows. La méthode sûre consiste à activer une stratégie attribuée uniquement au serveur pilote : commencer par Monitor but do not block (all peripherals will be allowed), examiner les périphériques métier détectés, définir les exceptions nécessaires, puis seulement appliquer Read Only ou Block à certains types de périphériques. Le guide pour les endpoints concerne, lui, les ordinateurs et leur propre stratégie sous Endpoint > Policies ; il ne décrit pas l’attribution d’une stratégie serveur. Cette stratégie serveur n’est pas documentée pour les serveurs Linux ou macOS.

⚠️ Avant de bloquer Modem ou Wireless : si la connexion d’administration passe par l’un de ces périphériques, le serveur peut perdre le contact avec Sophos Fusion et, avec lui, la possibilité de recevoir une stratégie corrigée. Exempter d’abord les périphériques réseau nécessaires et disposer d’un accès local ou hors bande vérifié indépendamment. Sophos prévient qu’à défaut, un accès physique peut être nécessaire pour effectuer une dérogation locale.

Avant le pilote : recenser les périphériques et prévoir un retour en arrière

Choisir un serveur Windows représentatif, avec une fenêtre de maintenance documentée et un administrateur chargé de la remise en état. Recenser les supports USB effectivement nécessaires aux sauvegardes ou à la maintenance, les supports optiques, les périphériques MTP/PTP et les adaptateurs réseau. Sur un hôte RDS, la décision s’applique à l’ensemble du serveur, et non à chaque session ; tenir compte au préalable des contraintes d’exploitation RDS.

Avant toute mise en application, disposer d’un autre moyen d’administration testé et d’une copie des paramètres précédents de la stratégie ou de l’attribution pilote prévue. Ne pas bloquer un support de sauvegarde pendant une sauvegarde ou une restauration en cours : clarifier les besoins en lecture et en écriture avec les responsables des sauvegardes et effectuer le test en dehors des tâches de production. Il s’agit de précautions opérationnelles, et non de prérequis vérifiés automatiquement par Sophos.

Observer et attribuer la stratégie pilote

Dans Sophos Fusion, sous My Products > Server > Policies, créer avec Add Policy une stratégie Peripheral Control pour le pilote serveur. Choisir un nom identifiable, par exemple Server-Peripheral-Pilot ; ce nom est libre, ce n’est pas une valeur Sophos prédéfinie. Ne pas modifier la Base policy pour ce pilote à l’échelle de l’organisation : elle sert de repli aux serveurs auxquels aucune stratégie correspondante prioritaire ne s’applique.
Activer la stratégie, ouvrir Settings dans sa page de détails, puis sélectionner Monitor but do not block (all peripherals will be allowed) sous Manage peripherals. Dans ce mode, tous les périphériques restent autorisés, même si d’autres actions sont configurées par type ; les périphériques détectés sont inventoriés.
Dans la page de détails de la stratégie, utiliser l’onglet d’attribution pour ne l’affecter qu’au serveur pilote prévu, puis enregistrer les modifications. Consigner, par exemple, l’attribution de Server-Peripheral-Pilot au serveur de test choisi dans le journal du pilote ; le nom peut être adapté librement. Sous My Products > Server > Servers > [serveur pilote] > Policies, vérifier que cette stratégie est effectivement appliquée et contrôler sa priorité par rapport aux autres stratégies serveur. Ne passer au test en mode surveillance qu’après cette vérification.
Brancher les périphériques nécessaires au serveur pilote dans des conditions contrôlées et vérifier leur détection. Selon Sophos, Peripheral Exemptions > Add Exemptions répertorie les périphériques détectés par une stratégie de surveillance sur des ordinateurs ou serveurs administrés. Avant de créer une exception, comparer l’entrée du périphérique réellement détecté à l’inventaire approuvé, plutôt que de se fier à un simple nom de modèle ressemblant.

Sous Manage peripherals, l’option Disable peripheral control existe également : elle désactive à la fois la surveillance et le blocage. Elle ne convient donc pas à un inventaire. Une option verrouillée peut relever d’une règle globale définie par l’administrateur partenaire ou d’entreprise ; elle ne peut pas être remplacée dans la stratégie serveur locale.

Passer de la surveillance à Read Only et Block

Ne sélectionner Control access by peripheral type and add exemptions qu’après l’inventaire. Ce mode applique les actions par type de périphérique. Pour Secure removable storage, Floppy Drive, Optical Drive et Removable storage, les choix sont Allow, Read Only et Block. Pour Bluetooth, Camera, Infrared, Modem et MTP/PTP, les choix sont Allow ou Block. Pour Wireless, les choix sont Allow, Block Bridged et Block. Block Bridged empêche le pontage réseau, mais, selon Sophos, ne génère ni alertes ni événements de blocage. MTP/PTP couvre notamment les téléphones et appareils photo utilisant ces protocoles de transfert ; cette catégorie ne propose pas Read Only.

Un pilote limité peut, par exemple, choisir Removable storage: Read Only si des données doivent être lues sur un support de test sans pouvoir y être écrites. Ne choisir Block pour ce type qu’après avoir établi qu’aucune fonction nécessaire de sauvegarde ou de maintenance ne sera affectée. Ne pas bloquer les autres types sans les vérifier ; pour Wireless et Modem en particulier, sécuriser d’abord l’accès d’administration. Le choix concret dépend de l’inventaire, pas d’un paramétrage serveur uniforme.

Pour un périphérique approuvé, ouvrir Peripheral Exemptions > Add Exemptions, comparer l’entrée préalablement détectée à l’inventaire et définir dans Policy l’action moins restrictive souhaitée. Dans Enforce By, choisir entre Instance ID et Model ID : l’exception s’applique aux périphériques partageant respectivement le même identifiant d’instance ou de modèle ; une Instance ID ne garantit pas qu’il s’agisse d’un seul appareil physique. Pour un support métier approuvé, l’identifiant d’instance constitue généralement le choix initial le plus ciblé ; seule une gamme de modèles explicitement approuvée justifie une exception par modèle. Confirmer avec Add Exemption(s) et vérifier la portée réelle de l’exception sur le serveur pilote. Une exception ne peut pas rendre une règle de type plus stricte : Sophos ignore une action plus restrictive définie pour un périphérique et affiche une icône d’avertissement.

Selon Sophos, Desktop Messaging est activé par défaut. Un texte saisi dans le champ du message complète la notification standard ; si ce champ est vide, seule la notification standard apparaît. Si Desktop Messaging est désactivé, aucune notification Peripheral Control n’apparaît sur le serveur. Pour le pilote, un message complémentaire librement personnalisable, tel que « Support USB bloqué ? Contactez l’équipe informatique en indiquant le nom du serveur et l’heure. », peut expliquer la procédure interne d’autorisation ; sur un hôte RDS, les messages affichés sur le bureau ne sont pas propres à chaque utilisateur.

Vérifier les effets et revenir en arrière en sécurité

Après avoir enregistré les modifications des actions par type et des exceptions, vérifier de nouveau sous My Products > Server > Servers > [serveur pilote] > Policies que la stratégie Peripheral Control attendue est bien appliquée, comme lors du test de surveillance. Modifier une même stratégie affecte tous les serveurs auxquels elle est attribuée ; vérifier donc de nouveau son périmètre d’attribution avant chaque correction. Ensuite, effectuer les tests suivants avec des données de test, en dehors des tâches de production :

En mode surveillance, le support de test branché reste utilisable et apparaît parmi les périphériques détectés pour la sélection des exceptions.
Sous Read Only, un fichier de test existant reste lisible ; une tentative d’écriture volontairement sans conséquence sur le support est empêchée. Vérifier le résultat sur le serveur local, sans se fier uniquement à une notification sur le bureau.
Sous Block, un périphérique de test non exempté est inutilisable ; le périphérique explicitement exempté fonctionne dans les limites autorisées. Les deux tests sont nécessaires pour détecter une exception Model ID trop large.
Le serveur pilote reste accessible et continue de communiquer avec Sophos Fusion. Pour Block Bridged, tester séparément le comportement du pontage ; l’absence d’événements ne prouve pas l’absence d’effet. Dans les autres cas, les événements présents sous My Products > Server > Servers > [serveur pilote] > Events peuvent être consultés en complément ; le test d’accès réel reste décisif.

Retour en arrière en cas d’effet indésirable : si le serveur pilote reste accessible, remettre la stratégie pilote sur Monitor but do not block (all peripherals will be allowed) sous My Products > Server > Policies, ou supprimer son attribution au serveur pilote ; vérifier ensuite la stratégie appliquée au serveur sous Policies, ainsi que l’accès. Après la suppression de l’attribution, le serveur ne revient à la Base policy ou à la prochaine stratégie correspondante prévue que si aucune autre stratégie serveur prioritaire ne s’applique. Ne pas modifier à la légère une stratégie de production partagée. Si la connexion réseau est déjà perdue, utiliser l’accès local ou hors bande préparé et tenir compte de l’avertissement de Sophos concernant l’éventuelle nécessité d’un accès physique ; ne pas présumer qu’une correction de stratégie envoyée depuis la console centrale a déjà été reçue.

Si un périphérique nécessaire reste bloqué, comparer d’abord la stratégie appliquée, le mode de fonctionnement, l’action par type, ainsi que Policy et Enforce By pour l’exception, à l’entrée réellement détectée. Si un périphérique censé être bloqué reste autorisé, vérifier le mode surveillance, une exception Model ID trop large et la présence éventuelle d’une autre stratégie prioritaire. Si l’effet ne peut être expliqué sans ambiguïté, ne pas élargir le pilote ; conserver l’inventaire, l’état de la stratégie et un test reproductible pour approfondir l’analyse.