Naar de inhoud
Avanet

Sophos Fusion Server Protection op RDS-terminalservers inzetten

Voor RDS-sessies is een Server Protection-licentie vereist; een afzonderlijke Endpoint Protection-licentie per sessie is niet nodig. Het concrete contract en de EULA blijven bepalend. Serverpolicies worden aan de host toegewezen, niet afzonderlijk aan de aangemelde gebruikers. Dit is een belangrijke planningsgrens voor RDS-, terminalserver- en Citrix-omgevingen.

De veilige volgorde is daarom: platform en licentie controleren, een representatieve session host als pilot gebruiken, vooraf besluiten nemen over serverbrede policies, actieve sessies gecontroleerd beëindigen, installeren en pas na technische én functionele acceptatie meer hosts vrijgeven. VDI-images maken en gebruikers op de firewall identificeren zijn afzonderlijke taken.

Toepassingsgebied en supportgrenzen

Voor deze handleiding is momenteel geen betrouwbaar raadpleegbare, RDS-specifieke Sophos-supportmatrix beschikbaar. Oudere lijsten met Windows- en Citrix-versies mogen niet als actuele goedkeuring voor nieuwe installaties worden gebruikt. Controleer vóór de uitrol de concrete combinatie van Windows-gast, Sophos-serveragent en build, RDS- of Citrix-release inclusief CU en virtualisatieomgeving aan de hand van de dan geldende supportvoorwaarden. Controleer bij Citrix ook de lifecycle en, waar van toepassing, contractueel overeengekomen extended support. Blijft de combinatie onduidelijk, vraag dan schriftelijke bevestiging aan Sophos Support; leid geen goedkeuring af uit de leeftijd of naam van een platform.

Voor de serveragent op een gevirtualiseerde RDS-gast is noch een algemene goedkeuring voor bepaalde hypervisors noch een algemene ondersteuning op basis van reasonable efforts aangetoond. Controleer het gastbesturingssysteem, het hostplatform en de Citrix-/RDS-laag afzonderlijk en verduidelijk met Sophos en de platformleverancier welke support- en reproductievoorwaarden voor het concrete geval gelden. Goedkeuring van een virtuele appliance of hypervisor betekent niet dat de beschermde RDS-gast is goedgekeurd.

Daaruit volgen drie duidelijke grenzen:

  • RDS- of Citrix-multi-userhost: installeer na bevestiging van de concrete platformcombinatie Server Protection op de Windows-gast; de serverpolicy geldt voor de host.
  • Gekloonde of niet-persistente VDI-machines: volg de afzonderlijke workflow voor Sophos in VDI-gold-images. Kloon niet zomaar een normaal geïnstalleerde agent.
  • Gebruikersgebaseerde firewallregels: deze serverinstallatie regelt die niet. Als meerdere sessies hetzelfde server-IP delen, beschrijft SATC voor Remote Desktop Services de afzonderlijke identiteitstoewijzing op Sophos Firewall.

Functies en policies vóór de uitrol bepalen

Controleer per functie in de doeltenant welke bescherming beschikbaar is op basis van de aangeschafte licentie, de Windows-gast en de geïnstalleerde agentcomponenten. Een volledige RDS-specifieke functiematrix voor de afzonderlijke serverlicentieniveaus is hier niet bevestigd. Stel met name een afzonderlijke XDR Sensor niet gelijk aan een beschermende Server Protection-installatie. Controleer licentie en contractvoorwaarden aan de hand van Sophos Fusion-licenties (voorheen Sophos Central) en de geldende EULA.

Voorzorgsmaatregel voor de pilot, geen aangetoonde RDS-supportgrens: wijs de session host voorlopig geen Update Cache- of Message Relay-hostrol toe en activeer noch de oudere Server Lockdown-functie noch Unauthorized File Protection (UFP) als nieuwe beveiligingsmaatregel. Sophos heeft Server Lockdown hernoemd tot Unauthorized File Protection; daarmee is voor RDS niet aangetoond dat de oude of nieuwe functie wordt ondersteund of uitgesloten. Laat vóór een wijziging specifiek voor RDS en afzonderlijk bevestigen of de host een cache of relay mag aanbieden dan wel zo’n dienst mag gebruiken, en welke voorwaarden gelden voor Lockdown en UFP, inclusief een eventuele migratie. Deze voorzichtige keuze voor de pilot is geen algemeen verbod en evenmin een goedkeuring; zij is ook geen reden om andere beschermingsmodules standaard uit te schakelen.

Serverbrede in plaats van gebruikersgebonden policies

Serverpolicies worden toegewezen aan de session host en vormen geen afzonderlijke serverpolicy per RDS-gebruiker. Via deze serverpolicy kan gebruiker A dus geen andere Web-, Application-, Peripheral- of DLP-controles krijgen dan gebruiker B op dezelfde host. Dit zegt niets over andere, zelfstandig geconfigureerde gebruikers- of firewallproducten.

Bespreek vóór de pilot de gevolgen met de applicatie- en proceseigenaren:

  • Welke applicaties en scripts draaien in alle sessies?
  • Welke randapparatuur hebben bepaalde rollen nodig, terwijl de beslissing serverbreed geldt?
  • Welke Web- of DLP-regel is voor alle gebruikers van deze host aanvaardbaar?
  • Welke shares en gebruikersprofielpaden moet Real-Time Scanning omvatten?
  • Welke uitzonderingen zijn technisch onderbouwd, nauw begrensd en met eigenaar en vervaldatum vastgelegd?

Als gebruikersgroepen werkelijk verschillende controles nodig hebben, verdeel ze dan over afzonderlijke session-hostcollecties met elk een passende serverpolicy. Een sterk versoepelde gedeelde policy vervangt deze scheiding niet.

Desktopmeldingen in meerdere sessies

Desktop Messaging meldt beveiligingsgebeurtenissen en staat in de serverpolicy voor Threat Protection standaard aan. Hoe een melding op een concrete terminalserver over gelijktijdige sessies wordt verdeeld, is hier niet als algemeen RDS-gedrag aangetoond. Ook een vaste lijst uitzonderingen bij het uitschakelen is niet bevestigd. Controleer in een pilot met meerdere sessies wie welke melding ziet en welke meldingen de daadwerkelijk gebruikte componenten ondanks een gewijzigde instelling nog produceren.

Helpdesk en gebruikers mogen een zichtbare melding niet zonder nader onderzoek aan een bepaalde sessie toeschrijven. Leg vóór de uitrol meldingsteksten, supportroute en correlatie via tijdstip, server, Fusion-alert en betrokken proces vast. Sluit een waarschuwing niet uitsluitend op basis van de terugkoppeling van één gebruiker.

Pilot en installatie plannen

Vereisten

Vóór de eerste host moet aan het volgende zijn voldaan:

  • De Windows-gast, de RDS- of Citrix-versie en het virtualisatieplatform vallen binnen de bevestigde supportvoorwaarden.
  • Een passende serverlicentie is beschikbaar; de host wordt als server ingepland en niet met een normale Endpoint-installer.
  • De host kan Sophos Fusion bereiken via de gedocumenteerde netwerkpaden, rechtstreeks of via een voor deze RDS-gast bevestigde proxy- of relayarchitectuur. Controleer het gebruik van cache en relay afzonderlijk van het aanbieden van die diensten op de host.
  • Een representatieve pilothost, een onderhoudsvenster, technische en functionele acceptatiecriteria en een verantwoordelijke voor de rollback zijn aangewezen.
  • Actieve RDS-sessies kunnen ordelijk worden afgemeld en nieuwe aanmeldingen kunnen tijdens de wijziging worden geblokkeerd.
  • Back-up, snapshot of een ander herstelpunt voldoet aan de procedure van de platformbeheerder en is buiten deze wijziging op herstelbaarheid getest.
  • De geplande serverpolicy is aan de pilotgroep toegewezen; de cache-/relay-hostrol en Lockdown/UFP worden uit voorzorg niet geactiveerd zolang de RDS-specifieke voorwaarden niet zijn opgehelderd.

Download in Sophos Fusion Admin in de juiste tenant de Windows Server Installer via My Environment > Installers > Server Protection > Full malware protection, niet de installer voor alleen de XDR Sensor. Voor een geautomatiseerde uitrol gelden dezelfde basisregels als bij de gecontroleerde Windows-uitrol: bescherm het tenantgebonden installatiepakket, voer het uit als lokale administrator of onder het systeemaccount, leg de werkelijke exitcode vast en leid uit het starten van een proces alleen niet af dat de bescherming volledig actief is. De productkeuze, doelgroep en licentie moeten echter op Server Protection zijn afgestemd.

De pilot uitvoeren

  1. Blokkeer nieuwe aanmeldingen op de pilothost, informeer gebruikers en meld actieve sessies ordelijk af. Forceer geen agentwijziging tijdens productieve gebruikerssessies.
  2. Leg de uitgangssituatie vast: hostnaam, OS- en RDS-/Citrix-versie, Fusion-groep, toegewezen policies, geïnstalleerde beveiligingssoftware, agentstatus en herstelpunt.
  3. Verwijder concurrerende producten en hun filterdrivers volgens het goedgekeurde migratieplan of pas bevestigde co-existentie toe. Laat niet zonder controle twee Real-Time-scanners tegelijk draaien.
  4. Voer de actuele serverinstaller uit de doeltenant uit met beheerdersrechten. Geef bij softwaredistributie de exitcode van de installer ongewijzigd door aan het deployment-systeem.
  5. Voltooi vereiste herstarts binnen het onderhoudsvenster. Sta pas daarna aanmeldingen voor de technische controle toe.
  6. Test met enkele testaccounts gangbare applicaties, profielen, printers, shares en Web- en DLP-processen. Laat pas daarna echte pilotgebruikers toe.
  7. Observeer de host gedurende de afgesproken periode onder normale multi-userbelasting. Er bestaat geen universele Sophos-norm voor sessieaantal of CPU-/RAM-reserve; de eigen baseline en acceptatiecriteria van het platformteam zijn bepalend.

Wijzig niet meerdere hosts tegelijk. Eén geslaagde aanmelding bewijst noch serverbrede applicatiecompatibiliteit noch het gedrag onder normale multi-userbelasting.

Acceptatie en beheer

Een pilot is pas geslaagd als alle volgende onderdelen in orde zijn:

  • Lokaal: de serveragent meldt een gezonde status; de installatie en vereiste herstarts zijn afgerond.
  • Fusion: de host verschijnt precies eenmaal als server in de juiste tenant en groep, is actueel en ontvangt de verwachte serverpolicies.
  • Bescherming: de afgesproken beschermingscomponenten zijn geïnstalleerd; de uit voorzorg uitgestelde cache-/relay-hostrol en Lockdown/UFP zijn niet geactiveerd.
  • Sessies: meerdere testgebruikers kunnen tegelijk aanmelden, kernapplicaties starten, profielen laden en benodigde middelen gebruiken.
  • Policies: de daadwerkelijk beschikbare Web-, Application-, Peripheral- en DLP-controles werken tijdens de testsessies zoals afgesproken; de zichtbaarheid van meldingen in andere sessies is gecontroleerd.
  • Beheer: vergelijk CPU, geheugen, aanmeldduur en applicatierespons met de vóór de pilot vastgelegde platformbaseline. Onderzoek afwijkingen in plaats van ze met onbewezen uitzonderingen te verhullen.

Plan de volgende kleine hostgolf pas na deze acceptatie. Test policywijzigingen ook daarna op een pilotgroep, omdat één serverpolicy gelijktijdig veel gebruikerssessies raakt.

Problemen oplossen en veilig terugrollen

Een gebruiker krijgt de verkeerde policy

Op een RDS-host bestaan geen gebruikersspecifieke serverpolicies. Controleer eerst de Fusion-groep, policytoewijzing en prioriteit van de server. Hebben gebruikersgroepen verschillende controles nodig, dan is scheiding in hostcollecties de betrouwbare oplossing, niet een uitzondering per aangemelde gebruiker.

Een melding verschijnt in meerdere sessies

Documenteer zo’n waarneming in de eigen pilot en beschouw haar niet als algemene garantie voor alle RDS-installaties. Correleer tijdstip en server met alerts en events in Fusion en achterhaal het veroorzakende proces. Test de Desktop Messaging-instelling van de geldende serverpolicy en welke meldingen per component in de tenant zichtbaar blijven. Een melding bewijst op zichzelf niet dat elke sessie waarin zij zichtbaar was, getroffen is.

Applicaties of aanmeldingen vertonen na de pilot afwijkingen

Stop verdere uitrolgolven. Verzamel eerst Fusion-events, agentstatus, Windows-gebeurtenissen en informatie over het betrokken proces. Zet vervolgens de laatst gewijzigde pilotpolicy terug naar de eerder vastgelegde stand en test opnieuw. Maak alleen uitzonderingen voor een bevestigd proces of pad en met een beperkte reikwijdte; gebruik geen algemene uitzonderingen voor schijven, profielen of processen als vermeende prestatieverbetering.

Blijft het probleem bestaan, haal de host dan uit gebruikersdienst en bewaar logs en gegevens van Sophos Diagnostic Utility voor Support. Treedt een fout alleen op onder Citrix of een ander virtueel platform, stem dan de vereiste reproductiestappen en verantwoordelijkheden af met Sophos Support en de platformleverancier.

Vermoeden van een SSPService-storing bij een instabiele host

Als services opnieuw starten, de host instabiel is of meldingen over SSPService verschijnen, bewaar dan vóór wijzigingen de exacte agent- en componentbuild, het besturingssysteem, de tijdstippen, Windows-gebeurtenissen en diagnostische logs. Ook vermeldingen zoals Process registration over the secure quota in sed.log zijn slechts een diagnostische aanwijzing: een RDS-specifiek defect met vast versiebereik, logverloop en oplossing is hiervoor niet bevestigd. Stel andere storingen met een vergelijkbare servicenaam hier niet aan gelijk.

Stop verdere uitrolgolven en haal de getroffen host volgens de onderhouds- en incidentprocedure uit gebruikersdienst. Vraag Sophos Support naar de incident-ID, de verwachte aanwezigheid van de service na een herstart, de getroffen builds, de versie met een oplossing en een voor deze host goedgekeurde herstelmaatregel. Wijzig Tamper Protection niet uitsluitend op basis van deze aanwijzing en presenteer een herstart niet als bevestigde oplossing.

Rollback

Leg de rollback vóór de pilot vast en voer deze uit volgens het type fout:

  1. Stop verdere toewijzingen en uitrolgolven; blokkeer nieuwe aanmeldingen op de getroffen host.
  2. Herstel bij een policyfout de eerder vastgelegde policytoewijzing en test opnieuw na synchronisatie met Fusion.
  3. Beëindig bij een platform- of agentfout de sessies ordelijk, bewaar de diagnostische gegevens en herstel de host volgens de goedgekeurde procedure voor verwijdering van de serveragent of platformherstel. Alleen het apparaatobject in Fusion verwijderen deïnstalleert de agent niet.
  4. Plaats de host pas terug in de brokerpool wanneer applicaties, gelijktijdige sessies, Fusion-status en bescherming of bevestigde vervangende bescherming zijn gecontroleerd.

Zet een snapshot niet blind terug over een actieve host die bij Fusion is geregistreerd. Of herstel of een nieuwe opbouw de veilige weg terug is, hangt af van de geteste procedure voor het RDS-/Citrix- en virtualisatieplatform. Onderzoek na een rollback de oorzaak en plan een nieuwe pilot; zet de mislukte uitrolgolf niet zomaar voort.