Sophos Fusion Server Protection auf RDS-Terminalservern einsetzen

Für RDS-Sitzungen ist eine Server-Protection-Lizenz erforderlich; eine separate Endpoint-Protection-Lizenz je Sitzung ist nicht nötig. Massgeblich bleiben der konkrete Vertrag und die EULA. Server-Richtlinien werden dem Host zugewiesen, nicht einzeln den angemeldeten Benutzern. Das ist eine zentrale Planungsgrenze für RDS-, Terminalserver- und Citrix-Umgebungen.

Der sichere Ablauf lautet deshalb: Plattform und Lizenz prüfen, einen repräsentativen Session Host pilotieren, serverweite Policy-Entscheidungen vorab treffen, aktive Sitzungen kontrolliert entlasten, installieren und erst nach technischer sowie fachlicher Abnahme weitere Hosts freigeben. Die VDI-Image-Erstellung und die Benutzeridentifikation an der Firewall sind eigene Aufgaben.

Einsatzbereich und Supportgrenzen

Eine derzeit belastbar lesbare RDS-spezifische Sophos-Freigabematrix liegt für diesen Leitfaden nicht vor. Ältere Listen mit Windows- und Citrix-Versionen dürfen nicht als aktuelle Zulassung für neue Installationen verwendet werden. Vor dem Rollout die konkrete Kombination aus Windows-Gast, Sophos-Server-Agent und Build, RDS- beziehungsweise Citrix-Release einschliesslich CU sowie Virtualisierungsumgebung gegen den jeweils gültigen Supportumfang prüfen. Bei Citrix auch Lifecycle und gegebenenfalls vertraglich gebundenen Extended Support klären. Bleibt die Kombination ungeklärt, eine schriftliche Bestätigung von Sophos Support einholen; aus dem Alter oder Namen einer Plattform keine Freigabe ableiten.

Für den Server-Agent auf einem virtualisierten RDS-Gast ist weder eine allgemeine Freigabe bestimmter Hypervisoren noch ein pauschaler Reasonable-Efforts-Supportumfang belegt. Gastbetriebssystem, Hostplattform und Citrix-/RDS-Schicht getrennt prüfen und die für den konkreten Fall geltenden Support- und Reproduktionsbedingungen bei Sophos und dem Plattformhersteller klären. Eine Freigabe einer virtuellen Appliance oder des Hypervisors ist keine Freigabe des geschützten RDS-Gasts.

Daraus folgen drei klare Abgrenzungen:

RDS oder Citrix Multi-User-Host: Nach Bestätigung der konkreten Plattformkombination Server Protection auf dem Windows-Gast installieren; die Server-Policy gilt für den Host.
Geklonte oder nicht persistente VDI-Maschinen: Der Image-Lifecycle folgt dem separaten Ablauf für Sophos in VDI-Gold-Images. Einen normal installierten Agent nicht einfach klonen.
Benutzerbasierte Firewallregeln: Dafür ist nicht diese Server-Installation zuständig. Wenn mehrere Sitzungen dieselbe Server-IP teilen, beschreibt SATC für Remote Desktop Services die separate Identitätszuordnung an Sophos Firewall.

Funktionen und Richtlinien vor dem Rollout entscheiden

Den vorgesehenen Schutzumfang pro Funktion im Ziel-Tenant anhand der gebuchten Lizenz, des Windows-Gasts und der installierten Agent-Komponenten prüfen. Eine vollständige RDS-spezifische Funktionsmatrix für die einzelnen Server-Lizenzstufen ist hier nicht bestätigt. Insbesondere einen reinen XDR Sensor nicht mit einer schützenden Server-Protection-Installation gleichsetzen. Lizenz und Vertragsbedingungen anhand der Sophos-Fusion-Lizenzierung (ehemals Sophos Central) sowie der geltenden EULA klären.

Vorsichtsmassnahme für den Pilot, keine nachgewiesene RDS-Supportgrenze: Dem Session Host vorerst keine Update-Cache- oder Message-Relay-Hostrolle zuweisen und weder die ältere Server-Lockdown-Funktion noch Unauthorized File Protection (UFP) als neue Härtungsmassnahme aktivieren. Sophos hat Server Lockdown in Unauthorized File Protection umbenannt; eine Freigabe oder Sperre der alten und neuen Funktion speziell für RDS ist damit nicht belegt. Vor einer Änderung RDS-spezifisch und getrennt bestätigen lassen, ob der Host einen Cache oder Relay betreiben beziehungsweise einen solchen Dienst nutzen darf und welche Voraussetzungen für Lockdown und UFP einschliesslich einer möglichen Migration gelten. Die vorsichtige Pilotwahl bedeutet weder ein generelles Verbot noch eine Freigabe und ist kein Anlass, andere Schutzmodule pauschal abzuschalten.

Serverweite statt benutzerbezogene Policies

Server-Policies werden dem Session Host zugewiesen und wirken nicht als getrennte Server-Policy je RDS-Benutzer. Damit lässt sich über diese Server-Policy nicht Benutzerin A ein anderer Web-, Application-, Peripheral- oder DLP-Umfang geben als Benutzer B auf demselben Host. Das ist keine Aussage über andere, eigenständig konfigurierte Benutzer- oder Firewall-Produkte.

Vor dem Pilot werden die Auswirkungen mit den Applikations- und Fachverantwortlichen geklärt:

Welche Anwendungen und Skripte laufen in allen Sitzungen?
Welche Peripheriegeräte benötigen einzelne Rollen, obwohl die Entscheidung serverweit wirkt?
Welche Web- oder DLP-Regel ist für sämtliche Benutzer dieses Hosts vertretbar?
Welche Dateifreigaben und Benutzerprofilpfade muss Real-Time Scanning abdecken?
Welche Ausnahmen sind technisch nachgewiesen, eng begrenzt und mit Owner sowie Ablaufdatum dokumentiert?

Wenn Benutzergruppen tatsächlich unterschiedliche Kontrollen benötigen, werden sie auf getrennte Session-Host-Sammlungen mit jeweils passender Server-Policy verteilt. Eine breit gelockerte gemeinsame Policy ist kein Ersatz für diese Trennung.

Desktop-Meldungen in mehreren Sitzungen

Desktop Messaging meldet Schutzereignisse und ist in der Server-Threat-Protection-Policy standardmässig eingeschaltet. Wie sich eine Meldung auf einem konkreten Terminalserver auf parallele Sitzungen verteilt, ist hier nicht als allgemeingültiges RDS-Verhalten belegt. Auch eine feste Liste von Ausnahmen beim Abschalten ist nicht bestätigt. Im Pilot mit mehreren Sitzungen prüfen, wer welche Meldung sieht und welche Benachrichtigungen die tatsächlich eingesetzten Komponenten trotz geänderter Einstellung noch erzeugen.

Helpdesk und Benutzer sollten eine sichtbare Meldung nicht ohne Prüfung einer bestimmten Sitzung zuordnen. Vor dem Rollout Meldungstexte, Supportweg und Korrelation über Zeitpunkt, Server, Fusion-Alert und betroffenen Prozess festlegen. Eine Warnung nicht allein aufgrund der Rückmeldung eines einzelnen Benutzers schliessen.

Pilot und Installation planen

Voraussetzungen

Vor dem ersten Host müssen folgende Punkte erfüllt sein:

Der Windows-Gast, die RDS- oder Citrix-Version und die Virtualisierungsplattform befinden sich im bestätigten Supportumfang.
Eine passende Server-Lizenz ist verfügbar; der Host wird als Server und nicht mit einem normalen Endpoint-Installer geplant.
Der Host erreicht Sophos Fusion über die dokumentierten Netzwerkwege, direkt oder über eine für diesen RDS-Gast bestätigte Proxy- oder Relay-Architektur. Cache-Nutzung und Relay-Nutzung getrennt von deren Betrieb auf dem Host prüfen.
Ein repräsentativer Pilothost, ein Wartungsfenster, technische und fachliche Abnahmekriterien sowie ein Rollback-Verantwortlicher sind bestimmt.
Aktive RDS-Sitzungen können geordnet abgemeldet und neue Anmeldungen während der Änderung verhindert werden.
Backup, Snapshot oder anderer Rückkehrpunkt entsprechen dem Verfahren des Plattformbetreibers und wurden ausserhalb dieses Changes auf Wiederherstellbarkeit geprüft.
Die geplante Server-Policy ist der Pilotgruppe zugeordnet; Cache-/Relay-Hostrolle und Lockdown/UFP werden im Pilot vorsorglich nicht aktiviert, bis RDS-spezifische Voraussetzungen geklärt sind.

In Sophos Fusion Admin im richtigen Tenant unter My Environment > Installers > Server Protection > Full malware protection den Windows Server Installer beziehen, nicht den XDR-Sensor-only-Installer. Für einen automatisierten Rollout gelten dieselben Grundregeln wie beim kontrollierten Windows-Rollout: tenantgebundenes Installationspaket schützen, im lokalen Administrator- oder Systemkontext ausführen, echten Exitstatus erfassen und nicht allein aus einem erfolgreichen Prozessstart auf vollständigen Schutz schliessen. Produktauswahl, Zielgruppe und Lizenz müssen jedoch für Server Protection festgelegt werden.

Pilot durchführen

Neue Anmeldungen auf dem Pilothost sperren, Benutzer informieren und aktive Sitzungen geordnet abmelden. Kein Agentwechsel während produktiver Benutzersitzungen erzwingen.
Ausgangszustand dokumentieren: Hostname, OS- und RDS-/Citrix-Version, Fusion-Gruppe, zugewiesene Policies, installierte Sicherheitssoftware, Health und Rückkehrpunkt.
Konkurrenzprodukte und deren Filtertreiber gemäss freigegebenem Migrationsplan entfernen oder die bestätigte Koexistenz umsetzen. Nicht ungeprüft zwei Real-Time-Scanner parallel betreiben.
Den aktuellen Server-Installer aus dem Ziel-Tenant mit administrativen Rechten ausführen. Bei Softwareverteilung den Installer-Code unverändert an das Deployment-System zurückgeben.
Angeforderte Neustarts im Wartungsfenster abschliessen. Erst danach Anmeldungen für die technische Prüfung freigeben.
Mit wenigen Testkonten typische Anwendungen, Profile, Drucker, Dateifreigaben sowie Web- und DLP-Abläufe testen. Danach erst reale Pilotbenutzer zulassen.
Den Host über einen vereinbarten Beobachtungszeitraum unter normaler Mehrbenutzerlast prüfen. Es gibt keinen universellen Sophos-Wert für Sitzungszahl oder CPU-/RAM-Reserve; die eigene Baseline und die Abnahmekriterien des Plattformteams sind massgeblich.

Nicht mehrere Hosts gleichzeitig verändern. Eine erfolgreiche Einzelanmeldung beweist weder serverweite Anwendungsverträglichkeit noch Verhalten unter typischer Mehrbenutzerlast.

Abnahme und Betrieb

Ein Pilot ist erst erfolgreich, wenn alle folgenden Ebenen stimmen:

Lokal: Der Server-Agent zeigt einen gesunden Zustand; Installation und erforderliche Neustarts sind abgeschlossen.
Fusion: Der Host erscheint genau einmal als Server im richtigen Tenant und in der richtigen Gruppe, ist aktuell und erhält die erwarteten Server-Policies.
Schutz: Die vereinbarten Schutzkomponenten sind installiert; die vorsorglich ausgesetzten Cache-/Relay-Hostrolle und Lockdown/UFP wurden nicht aktiviert.
Sitzungen: Mehrere Testbenutzer können sich parallel anmelden, Kernanwendungen starten, Profile laden und benötigte Ressourcen verwenden.
Policies: Die tatsächlich verfügbaren Web-, Application-, Peripheral- und DLP-Kontrollen verhalten sich für die Testsitzungen wie beschlossen; die Sichtbarkeit von Meldungen in anderen Sitzungen wurde geprüft.
Betrieb: CPU, Arbeitsspeicher, Login-Dauer und Anwendungsantwortzeit werden gegen die vor dem Pilot erfasste Plattform-Baseline verglichen. Abweichungen werden untersucht, nicht mit unbelegten Ausschlüssen kaschiert.

Erst nach dieser Abnahme wird die nächste kleine Hostwelle geplant. Policy-Änderungen werden weiterhin auf einer Pilotgruppe geprüft, weil eine einzige Server-Policy gleichzeitig viele Benutzersitzungen betrifft.

Troubleshooting und sicherer Rückweg

Benutzer erhält die falsche Policy

Auf einem RDS-Host gibt es keine benutzerspezifischen Server-Policies. Zuerst Fusion-Gruppe, Policy-Zuweisung und Priorität des Servers prüfen. Benötigen Benutzergruppen unterschiedliche Kontrollen, ist die belastbare Lösung eine getrennte Host-Sammlung und keine Ausnahme pro angemeldetem Benutzer.

Meldung erscheint in mehreren Sitzungen

Eine solche Beobachtung im eigenen Pilot dokumentieren, nicht als allgemeine Zusage für alle RDS-Installationen behandeln. Zeitpunkt und Server mit Alerts und Events in Fusion korrelieren und den auslösenden Prozess ermitteln. Die Desktop-Messaging-Einstellung der wirksamen Server-Policy und verbleibende Meldungen pro Komponente im Tenant testen. Die Meldung selbst nicht als Beweis interpretieren, dass jede sichtbare Sitzung betroffen war.

Anwendungen oder Logins werden nach dem Pilot auffällig

Weitere Rollout-Wellen stoppen. Zuerst Fusion-Events, Agent Health, Windows-Ereignisse und den betroffenen Prozess erfassen. Danach die zuletzt geänderte Pilot-Policy auf den vorher dokumentierten Stand zurücksetzen und erneut testen. Ausnahmen nur für den bestätigten Prozess oder Pfad und mit engem Scope erstellen; keine pauschalen Laufwerks-, Profil- oder Prozessausnahmen als vermeintliche Performance-Optimierung einführen.

Bleibt das Problem bestehen, den Host aus dem Benutzerbetrieb nehmen und Logs sowie Sophos Diagnostic Utility-Daten für den Support sichern. Bei einem Fehler, der nur unter Citrix oder einer anderen virtuellen Plattform auftritt, die nötigen Reproduktionsschritte und Zuständigkeiten mit Sophos Support und dem Plattformhersteller klären.

Verdacht auf SSPService-Störung bei instabilem Host

Wenn Dienstneustarts, ein instabiler Host oder Meldungen zu SSPService auftreten, vor einer Änderung den genauen Agent- und Komponenten-Build, Betriebssystem, Zeitpunkte, Windows-Ereignisse und Diagnose-Logs sichern. Auch Einträge wie Process registration over the secure quota in sed.log sind nur ein Diagnosehinweis: Ein RDS-spezifischer Defekt mit festem Versionsbereich, Log-Ablauf und Abhilfe ist dafür hier nicht bestätigt. Andere Fehlerbilder mit ähnlichem Dienstnamen nicht gleichsetzen.

Weitere Rollout-Wellen stoppen und den betroffenen Host gemäss Wartungs- und Incident-Verfahren aus dem Benutzerbetrieb nehmen. Sophos Support nach Incident-ID, erwarteter Dienstpräsenz nach einem Neustart, betroffenen Builds, Fix-Version und einer für diesen Host freigegebenen Abhilfe fragen. Tamper Protection nicht aufgrund dieses Hinweises umschalten und keinen Neustart als bestätigten Fix ausgeben.

Rollback

Ein Rollback wird vor dem Pilot festgelegt und nach der Fehlerklasse ausgeführt:

Weitere Zuweisungen und Rollout-Wellen stoppen; neue Anmeldungen auf dem betroffenen Host sperren.
Bei einem Policy-Fehler die vorher dokumentierte Policy-Zuweisung wiederherstellen und nach Fusion-Synchronisation erneut testen.
Bei einem Plattform- oder Agentfehler Sitzungen geordnet beenden, Diagnose sichern und den Host nach dem freigegebenen Server-Deinstallations- beziehungsweise Plattform-Restore-Verfahren zurückführen. Das Geräteobjekt nur in Fusion zu löschen, deinstalliert den Agent nicht.
Den Host erst wieder in den Broker-Pool aufnehmen, wenn Anwendungen, parallele Sitzungen, Fusion-Zustand und Schutz beziehungsweise bestätigter Ersatzschutz geprüft sind.

Einen Snapshot nicht blind über einen aktiven, in Fusion registrierten Host zurückschreiben. Ob Restore oder Neuaufbau der sichere Rückweg ist, richtet sich nach dem getesteten Verfahren der RDS-/Citrix- und Virtualisierungsplattform. Nach einem Rollback wird die Ursache geklärt und ein neuer Pilot angesetzt; die fehlgeschlagene Welle wird nicht einfach fortgesetzt.