Déployer Sophos Fusion Server Protection sur des serveurs RDS

Les sessions RDS nécessitent une licence Server Protection ; elles n’exigent pas chacune une licence Endpoint Protection distincte. Le contrat applicable et le CLUF restent déterminants. Les stratégies serveur sont attribuées à l’hôte, et non individuellement aux utilisateurs connectés. C’est une limite essentielle pour la planification des environnements RDS, serveurs de terminaux et Citrix.

La démarche sûre consiste donc à vérifier la plateforme et la licence, à piloter un hôte de session représentatif, à décider à l’avance des stratégies applicables à tout le serveur, à libérer les sessions actives de manière contrôlée, puis à installer la protection. Les autres hôtes ne seront déployés qu’après validation technique et métier. La création d’images VDI et l’identification des utilisateurs sur le pare-feu sont des tâches distinctes.

Périmètre et limites du support

Ce guide ne dispose actuellement d’aucune matrice de compatibilité Sophos propre à RDS dont la lecture permette de confirmer le support. Les anciennes listes de versions Windows et Citrix ne doivent pas servir d’autorisation actuelle pour de nouvelles installations. Avant le déploiement, vérifier que la combinaison précise de l’OS invité Windows, de l’agent serveur Sophos et de sa version, de la version RDS ou Citrix (CU compris) et de l’environnement de virtualisation entre dans le périmètre de support en vigueur. Pour Citrix, vérifier également le cycle de vie et, le cas échéant, le support étendu lié au contrat. Si la combinaison reste incertaine, demander une confirmation écrite au support Sophos ; ni l’âge ni le nom d’une plateforme ne constituent une preuve de compatibilité.

Pour l’agent serveur installé sur un invité RDS virtualisé, ni une approbation générale de certains hyperviseurs ni un niveau de support systématique « reasonable efforts » ne sont établis. Examiner séparément l’OS invité, la plateforme hôte et la couche Citrix ou RDS, puis clarifier avec Sophos et l’éditeur de la plateforme les conditions de support et de reproduction applicables au cas concret. La compatibilité d’une appliance virtuelle ou de l’hyperviseur ne vaut pas approbation de l’invité RDS protégé.

Trois distinctions en découlent :

Hôte RDS ou Citrix multi-utilisateurs : après confirmation de la combinaison de plateformes, installer Server Protection sur l’invité Windows ; la stratégie serveur s’applique à l’hôte.
Machines VDI clonées ou non persistantes : suivre la procédure distincte pour les images de référence VDI Sophos. Ne pas simplement cloner un agent installé de façon classique.
Règles de pare-feu par utilisateur : cette installation serveur ne les fournit pas. Lorsque plusieurs sessions partagent la même adresse IP du serveur, SATC pour Remote Desktop Services décrit l’association distincte des identités sur Sophos Firewall.

Décider des fonctions et des stratégies avant le déploiement

Vérifier, fonction par fonction dans le tenant cible, le périmètre de protection prévu selon la licence souscrite, l’invité Windows et les composants de l’agent installés. Aucune matrice exhaustive des fonctions propres à RDS pour chaque niveau de licence serveur n’est confirmée ici. En particulier, ne pas assimiler un simple capteur XDR à une installation Server Protection assurant la protection. Clarifier la licence et les conditions contractuelles à l’aide des informations sur les licences Sophos Fusion (anciennement Sophos Central) et du CLUF en vigueur.

Mesure de précaution pour le pilote, et non limite de support RDS démontrée : ne pas attribuer dans un premier temps à l’hôte de session un rôle d’hôte Update Cache ou Message Relay, et ne pas activer comme nouvelle mesure de durcissement l’ancienne fonction Server Lockdown ni Unauthorized File Protection (UFP). Sophos a renommé Server Lockdown en Unauthorized File Protection ; cela ne démontre ni la compatibilité ni l’incompatibilité de l’ancienne ou de la nouvelle fonction avec RDS. Avant toute modification, faire confirmer séparément, pour RDS, si l’hôte peut héberger un cache ou un relais, ou utiliser un tel service, et quelles conditions s’appliquent à Lockdown et à UFP, migration éventuelle comprise. Cette prudence pendant le pilote n’est ni une interdiction générale ni une approbation, et ne justifie pas de désactiver globalement les autres modules de protection.

Stratégies à l’échelle du serveur, et non par utilisateur

Les stratégies serveur sont attribuées à l’hôte de session ; elles ne constituent pas des stratégies serveur distinctes pour chaque utilisateur RDS. Elles ne permettent donc pas d’appliquer, sur un même hôte, des contrôles Web, Application, Peripheral ou DLP différents à l’utilisateur A et à l’utilisateur B. Cela ne préjuge pas du fonctionnement d’autres produits utilisateur ou pare-feu configurés séparément.

Avant le pilote, examiner les conséquences avec les responsables applicatifs et métier :

Quelles applications et quels scripts s’exécutent dans toutes les sessions ?
De quels périphériques certains rôles ont-ils besoin, alors que la décision s’applique à tout le serveur ?
Quelle règle Web ou DLP est acceptable pour l’ensemble des utilisateurs de cet hôte ?
Quels partages de fichiers et chemins de profils utilisateur l’analyse en temps réel doit-elle couvrir ?
Quelles exclusions sont techniquement justifiées, strictement limitées et documentées avec un responsable et une date d’expiration ?

Si des groupes d’utilisateurs ont réellement besoin de contrôles différents, les répartir dans des collections d’hôtes de session distinctes, chacune dotée de sa stratégie serveur adaptée. Une stratégie commune largement assouplie ne remplace pas cette séparation.

Messages de bureau dans plusieurs sessions

Desktop Messaging signale les événements de protection et est activé par défaut dans la stratégie Server Threat Protection. La manière dont un message se répartit entre les sessions parallèles d’un serveur de terminaux donné n’est pas établie ici comme un comportement RDS universel. Aucune liste fixe d’exceptions après désactivation n’est confirmée non plus. Pendant le pilote, avec plusieurs sessions, vérifier qui voit quel message et quelles notifications les composants effectivement installés produisent encore malgré la modification du paramètre.

Le support et les utilisateurs ne doivent pas attribuer un message visible à une session précise sans vérification. Avant le déploiement, définir les textes des messages, la voie de support et la corrélation par heure, serveur, alerte Fusion et processus concerné. Ne pas clore une alerte sur le seul témoignage d’un utilisateur.

Planifier le pilote et l’installation

Prérequis

Avant le premier hôte, les conditions suivantes doivent être réunies :

L’OS invité Windows, la version RDS ou Citrix et la plateforme de virtualisation entrent dans le périmètre de support confirmé.
Une licence serveur adaptée est disponible ; l’hôte est prévu comme serveur, et non avec un programme d’installation Endpoint ordinaire.
L’hôte peut joindre Sophos Fusion par les chemins réseau documentés, directement ou via une architecture proxy ou relais confirmée pour cet invité RDS. Vérifier séparément l’utilisation d’un cache ou d’un relais et l’hébergement de ces services sur l’hôte.
Un hôte pilote représentatif, une fenêtre de maintenance, des critères de validation techniques et métier ainsi qu’un responsable du retour arrière sont définis.
Les sessions RDS actives peuvent être fermées proprement et les nouvelles connexions empêchées pendant l’intervention.
La sauvegarde, l’instantané ou un autre point de retour suit la procédure de l’exploitant de la plateforme, et sa restaurabilité a été vérifiée en dehors de cette intervention.
La stratégie serveur prévue est attribuée au groupe pilote ; par précaution, ni le rôle d’hôte cache ou relais ni Lockdown/UFP ne sont activés pendant le pilote tant que les conditions propres à RDS ne sont pas clarifiées.

Dans Sophos Fusion Admin, au sein du bon tenant, télécharger le programme d’installation Windows Server sous My Environment > Installers > Server Protection > Full malware protection, et non le programme destiné uniquement au capteur XDR. Pour un déploiement automatisé, appliquer les mêmes principes que pour le déploiement Windows contrôlé : protéger le paquet d’installation lié au tenant, l’exécuter en tant qu’administrateur local ou sous le compte système, récupérer le véritable code de sortie et ne pas déduire d’un simple démarrage du processus que la protection est complète. Le produit, le groupe cible et la licence doivent toutefois être définis pour Server Protection.

Exécuter le pilote

Bloquer les nouvelles connexions sur l’hôte pilote, prévenir les utilisateurs et fermer proprement les sessions actives. Ne pas imposer un changement d’agent pendant des sessions utilisateur de production.
Consigner l’état initial : nom d’hôte, versions de l’OS et de RDS/Citrix, groupe Fusion, stratégies attribuées, logiciels de sécurité installés, état de santé et point de retour.
Retirer les produits concurrents et leurs pilotes de filtre selon le plan de migration approuvé, ou appliquer la coexistence confirmée. Ne pas faire fonctionner deux analyseurs en temps réel en parallèle sans vérification préalable.
Exécuter avec des droits d’administration le programme d’installation serveur actuel du tenant cible. En cas de distribution logicielle, transmettre sans modification le code de sortie du programme au système de déploiement.
Effectuer les redémarrages demandés pendant la fenêtre de maintenance. N’autoriser qu’ensuite les connexions nécessaires à la validation technique.
Avec quelques comptes de test, vérifier les applications habituelles, les profils, les imprimantes, les partages de fichiers ainsi que les usages Web et DLP. N’admettre les véritables utilisateurs pilotes qu’après ces tests.
Observer l’hôte sous une charge multi-utilisateurs normale pendant la période convenue. Sophos ne fixe aucune valeur universelle pour le nombre de sessions ou la réserve de CPU/RAM ; l’état de référence local et les critères de validation de l’équipe plateforme font foi.

Ne pas modifier plusieurs hôtes simultanément. Une seule connexion réussie ne prouve ni la compatibilité des applications à l’échelle du serveur ni leur comportement sous une charge multi-utilisateurs habituelle.

Validation et exploitation

Un pilote n’est réussi que si tous les niveaux suivants sont satisfaisants :

En local : l’agent serveur est en bon état ; l’installation et les redémarrages nécessaires sont terminés.
Dans Fusion : l’hôte apparaît une seule fois comme serveur dans le bon tenant et le bon groupe, est à jour et reçoit les stratégies serveur attendues.
Protection : les composants de protection convenus sont installés ; le rôle d’hôte cache ou relais et Lockdown/UFP, suspendus par précaution, n’ont pas été activés.
Sessions : plusieurs utilisateurs de test peuvent se connecter simultanément, lancer les applications principales, charger leurs profils et accéder aux ressources nécessaires.
Stratégies : les contrôles Web, Application, Peripheral et DLP effectivement disponibles se comportent comme prévu dans les sessions de test ; la visibilité des messages dans les autres sessions a été vérifiée.
Exploitation : comparer l’utilisation du CPU et de la mémoire, la durée de connexion et les temps de réponse des applications à l’état de référence de la plateforme relevé avant le pilote. Examiner les écarts au lieu de les masquer par des exclusions non justifiées.

Ne planifier la petite vague d’hôtes suivante qu’après cette validation. Continuer de tester les modifications de stratégies sur un groupe pilote : une seule stratégie serveur touche simultanément de nombreuses sessions utilisateur.

Dépannage et retour arrière sûr

Un utilisateur reçoit la mauvaise stratégie

Il n’existe pas de stratégie serveur propre à chaque utilisateur sur un hôte RDS. Vérifier d’abord le groupe Fusion, l’attribution et la priorité des stratégies du serveur. Si des groupes d’utilisateurs nécessitent des contrôles différents, la solution fiable est de séparer les collections d’hôtes, et non de créer une exception par utilisateur connecté.

Un message apparaît dans plusieurs sessions

Consigner une telle observation pendant le pilote local, sans la présenter comme une garantie générale pour toutes les installations RDS. Corréler l’heure et le serveur avec les alertes et événements Fusion, puis identifier le processus déclencheur. Tester dans le tenant le paramètre Desktop Messaging de la stratégie serveur effective ainsi que les messages encore émis par chaque composant. Ne pas interpréter le message lui-même comme une preuve que toutes les sessions où il est visible étaient concernées.

Les applications ou connexions présentent des anomalies après le pilote

Arrêter les vagues de déploiement suivantes. Recueillir d’abord les événements Fusion, l’état de santé de l’agent, les événements Windows et les informations sur le processus concerné. Rétablir ensuite la stratégie du pilote telle qu’elle était documentée avant la dernière modification, puis refaire les tests. Ne créer des exclusions que pour un processus ou un chemin confirmé et dans un périmètre strict ; ne pas introduire d’exclusions globales de disques, de profils ou de processus sous prétexte d’optimisation des performances.

Si le problème persiste, retirer l’hôte du service utilisateur et conserver les journaux ainsi que les données de Sophos Diagnostic Utility pour le support. Si une erreur ne se produit que sur Citrix ou une autre plateforme virtuelle, clarifier avec le support Sophos et l’éditeur de la plateforme les étapes de reproduction nécessaires et leurs responsabilités respectives.

Suspicion d’incident SSPService sur un hôte instable

En cas de redémarrages de service, d’instabilité de l’hôte ou de messages concernant SSPService, conserver avant toute modification les versions exactes de l’agent et de ses composants, l’OS, les heures des incidents, les événements Windows et les journaux de diagnostic. Même une entrée telle que Process registration over the secure quota dans sed.log n’est qu’un indice de diagnostic : aucun défaut propre à RDS, avec une plage de versions, une séquence de journaux et un correctif déterminés, n’est confirmé ici. Ne pas assimiler entre eux des incidents distincts sous prétexte qu’ils citent le même service.

Arrêter les vagues de déploiement suivantes et retirer l’hôte concerné du service utilisateur conformément aux procédures de maintenance et de gestion des incidents. Demander au support Sophos l’identifiant de l’incident, l’état attendu du service après un redémarrage, les versions touchées, la version corrigée et une mesure corrective approuvée pour cet hôte. Ne pas modifier Tamper Protection sur la seule base de cet indice ni présenter un redémarrage comme un correctif confirmé.

Retour arrière

Définir le retour arrière avant le pilote et l’appliquer selon la catégorie d’erreur :

Arrêter les nouvelles attributions et les vagues suivantes ; bloquer les nouvelles connexions sur l’hôte concerné.
En cas d’erreur de stratégie, rétablir l’attribution précédemment documentée, puis refaire les tests après la synchronisation avec Fusion.
En cas d’erreur de plateforme ou d’agent, fermer proprement les sessions, conserver les données de diagnostic, puis revenir à l’état antérieur selon la procédure approuvée de désinstallation de l’agent serveur ou de restauration de la plateforme. Supprimer seulement l’objet appareil dans Fusion ne désinstalle pas l’agent.
Ne réintégrer l’hôte dans le pool du broker qu’après avoir vérifié les applications, les sessions simultanées, l’état dans Fusion et la protection, ou une protection de remplacement confirmée.

Ne pas restaurer aveuglément un instantané sur un hôte actif enregistré dans Fusion. Le choix entre restauration et reconstruction dépend de la procédure testée pour la plateforme RDS/Citrix et sa virtualisation. Après un retour arrière, déterminer la cause et lancer un nouveau pilote ; ne pas simplement reprendre la vague qui a échoué.