Använd Sophos Fusion Server Protection på RDS-terminalservrar

RDS-sessioner kräver en Server Protection-licens; ingen separat Endpoint Protection-licens behövs för varje session. Det enskilda avtalet och licensvillkoren (EULA) är avgörande. Serverpolicyer tilldelas värden, inte de enskilda inloggade användarna. Det är en central planeringsgräns för RDS-, terminalserver- och Citrix-miljöer.

Den säkra ordningen är därför att kontrollera plattform och licens, pilottesta en representativ sessionsvärd, besluta om serverövergripande policyer i förväg, avsluta aktiva sessioner under kontrollerade former, installera och godkänna fler värdar först efter teknisk och verksamhetsmässig verifiering. Att skapa VDI-avbilder och att identifiera användare i brandväggen är separata uppgifter.

Användningsområde och supportgränser

Någon tillförlitlig och för närvarande tillgänglig Sophos-supportmatris specifikt för RDS ligger inte till grund för den här guiden. Äldre listor över Windows- och Citrix-versioner får inte användas som aktuellt godkännande för nya installationer. Kontrollera före utrullningen den exakta kombinationen av Windows-gäst, Sophos-serveragent och dess version, RDS- eller Citrix-version inklusive CU samt virtualiseringsmiljö mot gällande supportvillkor. Kontrollera också livscykeln för Citrix och, om det är aktuellt, avtalsbundet utökat stöd. Om kombinationens status förblir oklar, begär skriftlig bekräftelse från Sophos Support; dra inga slutsatser om stöd utifrån plattformens ålder eller namn.

För serveragenten på en virtualiserad RDS-gäst finns det varken belägg för ett generellt godkännande av vissa hypervisorer eller för att support enligt principen ”reasonable efforts” gäller generellt. Kontrollera gästoperativsystemet, värdplattformen och Citrix-/RDS-lagret var för sig och klarlägg med Sophos och plattformstillverkaren vilka support- och reproduktionsvillkor som gäller i det enskilda fallet. Att en virtuell appliance eller en hypervisor stöds innebär inte att den skyddade RDS-gästen stöds.

Det ger tre tydliga avgränsningar:

RDS- eller Citrix-värd för flera användare: Installera Server Protection på Windows-gästen när stöd för den exakta plattformskombinationen har bekräftats; serverpolicyn gäller för hela värden.
Klonade eller icke-beständiga VDI-maskiner: Följ den separata processen för Sophos i VDI-guldavbilder. Klona inte en agent som har installerats på vanligt sätt.
Användarbaserade brandväggsregler: Den här serverinstallationen sköter inte dessa. Om flera sessioner delar samma server-IP beskriver SATC för Remote Desktop Services den separata kopplingen mellan användare och identitet i Sophos Firewall.

Bestäm funktioner och policyer före utrullningen

Kontrollera vilket skydd varje funktion ska ge i den avsedda tenantmiljön utifrån den tecknade licensen, Windows-gästen och de installerade agentkomponenterna. En fullständig RDS-specifik funktionsmatris för de olika serverlicensnivåerna är inte bekräftad här. Likställ framför allt inte en ren XDR-sensor med en skyddande Server Protection-installation. Kontrollera licens och avtalsvillkor utifrån licensiering för Sophos Fusion (tidigare Sophos Central) och gällande EULA.

Försiktighetsåtgärd under piloten, inte en belagd RDS-supportgräns: Tilldela tills vidare inte sessionsvärden rollen som värd för Update Cache eller Message Relay och aktivera varken den äldre funktionen Server Lockdown eller Unauthorized File Protection (UFP) som ny härdningsåtgärd. Sophos har bytt namn på Server Lockdown till Unauthorized File Protection; detta belägger varken stöd eller förbud för den gamla eller nya funktionen specifikt för RDS. Innan något ändras behöver det bekräftas separat och specifikt för RDS om värden får driva en cache eller ett relay respektive använda en sådan tjänst, och vilka förutsättningar som gäller för Lockdown och UFP, inklusive eventuell migrering. Det försiktiga pilotvalet innebär varken ett generellt förbud eller ett godkännande och är inget skäl att stänga av andra skyddsmoduler generellt.

Serverövergripande i stället för användarspecifika policyer

Serverpolicyer tilldelas sessionsvärden och fungerar inte som separata serverpolicyer per RDS-användare. Det går alltså inte att via den här serverpolicyn ge användare A andra Web-, Application-, Peripheral- eller DLP-kontroller än användare B på samma värd. Det säger inget om andra användar- eller brandväggsprodukter som konfigureras separat.

Klargör konsekvenserna med applikations- och verksamhetsansvariga före piloten:

Vilka applikationer och skript körs i alla sessioner?
Vilken kringutrustning behöver vissa roller trots att beslutet gäller hela servern?
Vilken Web- eller DLP-regel är godtagbar för samtliga användare på värden?
Vilka filresurser och sökvägar för användarprofiler måste Real-Time Scanning omfatta?
Vilka undantag är tekniskt belagda, snävt avgränsade och dokumenterade med ansvarig och slutdatum?

Om användargrupper faktiskt behöver olika kontroller ska de fördelas på separata samlingar av sessionsvärdar med var sin lämplig serverpolicy. En gemensam policy med alltför generösa undantag ersätter inte denna uppdelning.

Skrivbordsmeddelanden i flera sessioner

Desktop Messaging rapporterar skyddshändelser och är aktiverat som standard i serverpolicyn för Threat Protection. Hur ett meddelande visas i parallella sessioner på en viss terminalserver är här inte belagt som ett generellt RDS-beteende. Det finns inte heller någon bekräftad, fast lista över undantag när funktionen stängs av. Testa under en pilot med flera sessioner vem som ser vilka meddelanden och vilka aviseringar de komponenter som faktiskt används fortfarande skapar efter en ändrad inställning.

Helpdesk och användare bör inte utan kontroll hänföra ett synligt meddelande till en viss session. Bestäm före utrullningen meddelandetexter, supportväg och hur händelser ska korreleras med hjälp av tidpunkt, server, Fusion-larm och berörd process. Stäng inte en varning enbart utifrån en enskild användares uppgifter.

Planera pilot och installation

Förutsättningar

Följande måste vara klart före den första värden:

Windows-gästen, RDS- eller Citrix-versionen och virtualiseringsplattformen omfattas av bekräftat stöd.
En lämplig serverlicens finns tillgänglig; värden planeras som server, inte för installation med en vanlig Endpoint-installerare.
Värden kan nå Sophos Fusion via dokumenterade nätverksvägar, direkt eller via en proxy- eller relayarkitektur som bekräftats för just denna RDS-gäst. Kontrollera användning av cache och relay separat från att driva dessa tjänster på värden.
En representativ pilotvärd, ett underhållsfönster, tekniska och verksamhetsmässiga godkännandekriterier samt en ansvarig för återgång har utsetts.
Aktiva RDS-sessioner kan avslutas ordnat och nya inloggningar förhindras under ändringen.
Säkerhetskopia, ögonblicksbild eller annan återgångspunkt följer plattformsoperatörens rutin och har återställningstestats utanför denna ändring.
Den planerade serverpolicyn har tilldelats pilotgruppen; rollerna som värd för cache eller relay samt Lockdown/UFP aktiveras av försiktighetsskäl inte under piloten förrän de RDS-specifika förutsättningarna har klarlagts.

Hämta Windows Server Installer i rätt tenant i Sophos Fusion Admin under My Environment > Installers > Server Protection > Full malware protection, inte installeraren för enbart XDR-sensor. Vid automatiserad utrullning gäller samma grundregler som för kontrollerad Windows-utrullning: skydda det tenantbundna installationspaketet, kör det som lokal administratör eller SYSTEM, registrera den verkliga exitkoden och dra inte slutsatsen att skyddet är fullständigt bara för att processen startade. Produktval, målgrupp och licens måste dock avse Server Protection.

Genomför piloten

Blockera nya inloggningar på pilotvärden, informera användarna och avsluta aktiva sessioner ordnat. Tvinga inte fram ett agentbyte under pågående produktionssessioner.
Dokumentera utgångsläget: värdnamn, OS- och RDS-/Citrix-version, Fusion-grupp, tilldelade policyer, installerade säkerhetsprogram, hälsostatus och återgångspunkt.
Ta bort konkurrerande produkter och deras filterdrivrutiner enligt godkänd migreringsplan eller genomför bekräftad samexistens. Kör inte två realtidsskannrar parallellt utan föregående kontroll.
Kör den aktuella serverinstalleraren från måltenanten med administratörsrättigheter. Vid programvarudistribution ska installerarens exitkod vidarebefordras oförändrad till distributionssystemet.
Slutför begärda omstarter inom underhållsfönstret. Tillåt först därefter inloggningar för teknisk kontroll.
Testa typiska applikationer, profiler, skrivare, filresurser samt Web- och DLP-flöden med några få testkonton. Släpp först därefter in riktiga pilotanvändare.
Kontrollera värden under en överenskommen observationsperiod med normal fleranvändarlast. Det finns inget universellt Sophos-värde för antal sessioner eller CPU-/RAM-reserv; den egna baslinjen och plattformsteamets godkännandekriterier är avgörande.

Ändra inte flera värdar samtidigt. En lyckad enskild inloggning bevisar varken att applikationerna fungerar för hela servern eller hur värden beter sig under normal fleranvändarlast.

Godkännande och drift

Piloten är godkänd först när alla följande nivåer stämmer:

Lokalt: Serveragenten visar god hälsostatus; installation och nödvändiga omstarter är slutförda.
Fusion: Värden visas exakt en gång som server i rätt tenant och grupp, är uppdaterad och får förväntade serverpolicyer.
Skydd: De överenskomna skyddskomponenterna är installerade; rollerna som värd för cache eller relay och Lockdown/UFP, som av försiktighetsskäl har skjutits upp, har inte aktiverats.
Sessioner: Flera testanvändare kan logga in samtidigt, starta kärnapplikationer, läsa in profiler och använda nödvändiga resurser.
Policyer: De Web-, Application-, Peripheral- och DLP-kontroller som faktiskt finns tillgängliga fungerar enligt beslutet i testsessionerna; det har kontrollerats om meddelanden syns i andra sessioner.
Drift: CPU, minne, inloggningstid och applikationernas svarstid jämförs med plattformens baslinje som dokumenterats före piloten. Avvikelser utreds i stället för att döljas med obelagda undantag.

Först efter detta godkännande planeras nästa lilla våg av värdar. Fortsätt testa policyändringar på en pilotgrupp, eftersom en enda serverpolicy påverkar många användarsessioner samtidigt.

Felsökning och säker återgång

En användare får fel policy

Det finns inga användarspecifika serverpolicyer på en RDS-värd. Kontrollera först Fusion-grupp, policytilldelning och prioritet för servern. Om användargrupper behöver olika kontroller är separata värdsamlingar den hållbara lösningen, inte undantag per inloggad användare.

Ett meddelande visas i flera sessioner

Dokumentera en sådan observation i den egna piloten i stället för att behandla den som ett generellt löfte för alla RDS-installationer. Korrelera tidpunkt och server med larm och händelser i Fusion och identifiera den utlösande processen. Testa inställningen för Desktop Messaging i den gällande serverpolicyn samt kvarvarande meddelanden per komponent i tenantmiljön. Tolka inte själva meddelandet som bevis för att varje session där det syntes var berörd.

Applikationer eller inloggningar uppvisar problem efter piloten

Stoppa ytterligare utrullningsvågor. Samla först in Fusion-händelser, agentens hälsostatus, Windows-händelser och uppgifter om den berörda processen. Återställ därefter den senast ändrade pilotpolicyn till tidigare dokumenterat läge och testa igen. Skapa undantag bara för den bekräftade processen eller sökvägen och med snäv omfattning; inför inte generella undantag för diskar, profiler eller processer som en förment prestandaoptimering.

Om problemet kvarstår, ta värden ur användardrift och spara loggar samt data från Sophos Diagnostic Utility för supporten. Om ett fel bara uppträder under Citrix eller på en annan virtuell plattform, klarlägg nödvändiga reproduktionssteg och ansvarsfördelningen med Sophos Support och plattformstillverkaren.

Misstanke om SSPService-störning på en instabil värd

Om tjänsten startar om, värden blir instabil eller meddelanden om SSPService visas, spara före varje ändring exakt version av agent och komponenter, operativsystem, tidpunkter, Windows-händelser och diagnostikloggar. Även poster som Process registration over the secure quota i sed.log är bara en diagnostisk ledtråd: Någon RDS-specifik defekt med fastställt versionsintervall, loggförlopp och åtgärd är inte bekräftad här. Likställ inte andra felbilder med liknande tjänstenamn med detta.

Stoppa ytterligare utrullningsvågor och ta den berörda värden ur användardrift enligt rutinerna för underhåll och incidenthantering. Fråga Sophos Support efter incident-ID, förväntad tjänststatus efter omstart, berörda versioner, korrigerad version och en åtgärd som är godkänd för just denna värd. Ändra inte Tamper Protection enbart på grund av denna ledtråd och framställ inte en omstart som en bekräftad lösning.

Återgång

Bestäm återgångsförfarandet före piloten och välj åtgärd efter feltyp:

Stoppa ytterligare tilldelningar och utrullningsvågor; blockera nya inloggningar på den berörda värden.
Vid policyfel: återställ den tidigare dokumenterade policytilldelningen och testa igen efter synkronisering med Fusion.
Vid plattforms- eller agentfel: avsluta sessioner ordnat, spara diagnostik och återför värden enligt godkänd rutin för avinstallation av serverskyddet eller återställning av plattformen. Att bara ta bort enhetsobjektet i Fusion avinstallerar inte agenten.
Återför värden till brokerpoolen först när applikationer, samtidiga sessioner, Fusion-status och skydd eller bekräftat ersättningsskydd har kontrollerats.

Återställ inte blint en ögonblicksbild över en aktiv värd som är registrerad i Fusion. Om återställning eller nyuppbyggnad är den säkra återgången avgörs av den testade rutinen för RDS-/Citrix- och virtualiseringsplattformen. Utred orsaken efter återgången och genomför en ny pilot; fortsätt inte bara med den misslyckade utrullningsvågen.