Distribuire Sophos Fusion Server Protection sui server RDS

Le sessioni RDS richiedono una licenza Server Protection; non occorre una licenza Endpoint Protection separata per ogni sessione. Restano determinanti il contratto specifico e l’EULA. Le policy server vengono assegnate all’host, non ai singoli utenti connessi. Questo è un vincolo fondamentale nella pianificazione degli ambienti RDS, terminal server e Citrix.

La sequenza sicura consiste quindi nel verificare piattaforma e licenza, testare un session host rappresentativo in un progetto pilota, definire in anticipo le policy valide per l’intero server, liberare ordinatamente le sessioni attive, installare il prodotto e autorizzare altri host solo dopo il collaudo tecnico e funzionale. La creazione delle immagini VDI e l’identificazione degli utenti sul firewall sono attività distinte.

Ambito di impiego e limiti del supporto

Per questa guida non è attualmente disponibile una matrice di supporto Sophos specifica per RDS sufficientemente verificabile. Gli elenchi meno recenti di versioni Windows e Citrix non devono essere considerati un’autorizzazione aggiornata per nuove installazioni. Prima del rollout, verificare la combinazione specifica di guest Windows, agent server Sophos e relativa build, release RDS o Citrix inclusa la CU e ambiente di virtualizzazione rispetto al supporto applicabile al momento. Per Citrix chiarire anche il ciclo di vita ed eventualmente l’Extended Support previsto dal contratto. Se la combinazione resta incerta, richiedere una conferma scritta al supporto Sophos; non dedurre il supporto dall’età o dal nome della piattaforma.

Per l’agent server su un guest RDS virtualizzato non è dimostrato né un supporto generale per determinati hypervisor né un supporto generalizzato secondo il principio dei «reasonable efforts». Verificare separatamente sistema operativo guest, piattaforma host e livello Citrix/RDS e chiarire con Sophos e il produttore della piattaforma le condizioni di supporto e riproduzione applicabili al caso specifico. Il supporto di un’appliance virtuale o dell’hypervisor non implica il supporto del guest RDS protetto.

Ne derivano tre distinzioni precise:

Host multiutente RDS o Citrix: dopo la conferma della combinazione di piattaforme, installare Server Protection sul guest Windows; la policy server si applica all’host.
Macchine VDI clonate o non persistenti: per il ciclo di vita dell’immagine seguire la procedura separata per le gold image VDI Sophos. Non clonare semplicemente un agent installato con la procedura ordinaria.
Regole firewall basate sull’utente: non sono gestite da questa installazione server. Se più sessioni condividono lo stesso IP del server, SATC per Remote Desktop Services descrive l’attribuzione separata delle identità su Sophos Firewall.

Decidere funzioni e policy prima del rollout

Verificare nel tenant di destinazione le funzionalità di protezione previste per ciascuna funzione in base alla licenza sottoscritta, al guest Windows e ai componenti agent installati. Non è qui confermata una matrice funzionale RDS completa per i singoli livelli di licenza server. In particolare, non equiparare un semplice sensore XDR a un’installazione Server Protection che offre protezione. Chiarire licenza e condizioni contrattuali consultando le informazioni sulle licenze Sophos Fusion (in precedenza Sophos Central) e l’EULA applicabile.

Precauzione per il progetto pilota, non limite di supporto RDS dimostrato: inizialmente non assegnare al session host il ruolo di Update Cache o Message Relay e non attivare né la precedente funzione Server Lockdown né Unauthorized File Protection (UFP) come nuova misura di hardening. Sophos ha rinominato Server Lockdown in Unauthorized File Protection; questo non dimostra che la funzione precedente o quella nuova sia consentita o vietata specificamente su RDS. Prima di apportare modifiche, far confermare separatamente per RDS se l’host può ospitare una cache o un relay oppure utilizzare tali servizi e quali prerequisiti valgono per Lockdown e UFP, compresa un’eventuale migrazione. Questa scelta prudenziale per il progetto pilota non equivale né a un divieto generale né a un’autorizzazione e non giustifica la disattivazione indiscriminata degli altri moduli di protezione.

Policy valide per tutto il server anziché per il singolo utente

Le policy server vengono assegnate al session host e non costituiscono policy server distinte per ciascun utente RDS. Tramite queste policy non è quindi possibile applicare all’utente A controlli Web, Application, Peripheral o DLP diversi da quelli applicati all’utente B sullo stesso host. Ciò non riguarda altri prodotti per utenti o firewall configurati indipendentemente.

Prima del progetto pilota, chiarire gli effetti con i responsabili delle applicazioni e delle attività interessate:

Quali applicazioni e script vengono eseguiti in tutte le sessioni?
Di quali periferiche hanno bisogno i singoli ruoli, anche se la decisione si applica a tutto il server?
Quale regola Web o DLP è accettabile per tutti gli utenti dell’host?
Quali condivisioni e percorsi dei profili utente devono essere coperti dal Real-Time Scanning?
Quali esclusioni sono tecnicamente giustificate, strettamente circoscritte e documentate con responsabile e data di scadenza?

Se gruppi di utenti hanno effettivamente bisogno di controlli diversi, distribuirli su raccolte separate di session host, ciascuna con la policy server appropriata. Una policy comune e ampiamente permissiva non sostituisce questa separazione.

Messaggi desktop in più sessioni

Desktop Messaging segnala gli eventi di protezione ed è attivato per impostazione predefinita nella policy Server Threat Protection. Non è qui dimostrato un comportamento RDS universalmente valido per la distribuzione di un messaggio tra sessioni parallele su un determinato terminal server. Non è confermato neppure un elenco fisso di eccezioni alla disattivazione. Durante il progetto pilota, con più sessioni aperte, verificare chi vede quali messaggi e quali notifiche continuano a essere generate dai componenti effettivamente installati nonostante la modifica dell’impostazione.

L’helpdesk e gli utenti non dovrebbero attribuire un messaggio visibile a una sessione specifica senza verificarlo. Prima del rollout definire testi dei messaggi, canale di assistenza e correlazione tramite ora, server, alert Fusion e processo interessato. Non chiudere un avviso basandosi soltanto sulla segnalazione di un singolo utente.

Pianificare il progetto pilota e l’installazione

Prerequisiti

Prima del primo host devono essere soddisfatte le seguenti condizioni:

Il guest Windows, la versione RDS o Citrix e la piattaforma di virtualizzazione rientrano nell’ambito di supporto confermato.
È disponibile una licenza server adeguata; l’host è pianificato come server e non con un normale installer Endpoint.
L’host può raggiungere Sophos Fusion attraverso i percorsi di rete documentati, direttamente o tramite un’architettura proxy o relay confermata per questo guest RDS. Verificare separatamente l’utilizzo di cache e relay rispetto al loro esercizio sull’host.
Sono stati designati un host pilota rappresentativo, una finestra di manutenzione, criteri di collaudo tecnici e funzionali e un responsabile del rollback.
Le sessioni RDS attive possono essere chiuse in modo ordinato e si possono impedire nuovi accessi durante la modifica.
Backup, snapshot o altro punto di ripristino rispettano la procedura del gestore della piattaforma e la loro ripristinabilità è stata verificata indipendentemente da questa modifica.
La policy server prevista è assegnata al gruppo pilota; il ruolo host di cache/relay e Lockdown/UFP non vengono attivati, per precauzione, finché non siano chiariti i prerequisiti specifici per RDS.

Nel tenant corretto di Sophos Fusion Admin, scaricare il Windows Server Installer da My Environment > Installers > Server Protection > Full malware protection, non l’installer del solo sensore XDR. Per il rollout automatizzato valgono gli stessi principi del rollout Windows controllato: proteggere il pacchetto di installazione associato al tenant, eseguirlo come amministratore locale o nel contesto di sistema, acquisire il codice di uscita effettivo e non dedurre una protezione completa dal solo avvio riuscito del processo. La scelta del prodotto, del gruppo di destinazione e della licenza deve però essere riferita a Server Protection.

Eseguire il progetto pilota

Bloccare nuovi accessi all’host pilota, informare gli utenti e chiudere ordinatamente le sessioni attive. Non forzare un cambio di agent durante sessioni utente produttive.
Documentare lo stato iniziale: nome host, versioni OS e RDS/Citrix, gruppo Fusion, policy assegnate, software di sicurezza installato, stato di integrità e punto di ripristino.
Rimuovere i prodotti concorrenti e i relativi driver di filtro secondo il piano di migrazione approvato oppure attuare la coesistenza confermata. Non eseguire senza verifica due scanner Real-Time in parallelo.
Eseguire con privilegi amministrativi l’installer server aggiornato del tenant di destinazione. Nel caso di distribuzione software, trasmettere al sistema di deployment il codice di uscita dell’installer senza alterarlo.
Completare i riavvii richiesti nella finestra di manutenzione. Solo dopo consentire nuovi accessi per le verifiche tecniche.
Con pochi account di test verificare applicazioni tipiche, profili, stampanti, condivisioni e procedure Web e DLP. Ammettere utenti pilota reali soltanto in seguito.
Osservare l’host per un periodo concordato sotto il normale carico multiutente. Non esiste un valore Sophos universale per il numero di sessioni o per la riserva CPU/RAM: fanno fede la propria baseline e i criteri di collaudo del team responsabile della piattaforma.

Non modificare più host contemporaneamente. Un singolo accesso riuscito non dimostra né la compatibilità delle applicazioni su tutto il server né il comportamento sotto un tipico carico multiutente.

Collaudo e gestione operativa

Il progetto pilota ha successo solo se risultano soddisfatti tutti i criteri seguenti:

Locale: l’agent server mostra uno stato integro; installazione e riavvii necessari sono conclusi.
Fusion: l’host compare una sola volta come server nel tenant e nel gruppo corretti, è aggiornato e riceve le policy server previste.
Protezione: i componenti di protezione concordati sono installati; il ruolo host di cache/relay e Lockdown/UFP, sospesi per precauzione, non sono stati attivati.
Sessioni: più utenti di test possono accedere contemporaneamente, avviare le applicazioni principali, caricare i profili e usare le risorse necessarie.
Policy: i controlli Web, Application, Peripheral e DLP effettivamente disponibili si comportano nelle sessioni di test come concordato; è stata verificata la visibilità dei messaggi nelle altre sessioni.
Gestione operativa: CPU, memoria, tempo di accesso e tempi di risposta delle applicazioni vengono confrontati con la baseline della piattaforma rilevata prima del progetto pilota. Gli scostamenti vanno indagati, non mascherati con esclusioni ingiustificate.

Solo dopo questo collaudo si pianifica la successiva piccola ondata di host. Le modifiche alle policy continuano a essere verificate su un gruppo pilota, poiché una sola policy server coinvolge contemporaneamente molte sessioni utente.

Risoluzione dei problemi e ripristino sicuro

Un utente riceve la policy sbagliata

Su un host RDS non esistono policy server specifiche per utente. Verificare anzitutto gruppo Fusion, assegnazione delle policy e priorità del server. Se gruppi di utenti necessitano di controlli diversi, la soluzione affidabile è una raccolta separata di host, non un’eccezione per ciascun utente connesso.

Un messaggio compare in più sessioni

Documentare questa osservazione nel proprio progetto pilota, senza considerarla una garanzia generale per tutte le installazioni RDS. Correlare ora e server con alert ed eventi in Fusion e identificare il processo responsabile. Verificare nel tenant l’impostazione Desktop Messaging della policy server applicata e i messaggi ancora generati dai singoli componenti. Non interpretare il messaggio come prova che ogni sessione in cui è visibile sia stata interessata dall’evento.

Applicazioni o accessi presentano anomalie dopo il progetto pilota

Fermare le successive ondate di rollout. Raccogliere prima gli eventi Fusion, lo stato dell’agent, gli eventi Windows e le informazioni sul processo interessato. Ripristinare quindi la policy pilota modificata più di recente allo stato documentato in precedenza e ripetere il test. Creare esclusioni soltanto per processi o percorsi confermati e con ambito ristretto; non introdurre esclusioni generiche di unità, profili o processi come presunta ottimizzazione delle prestazioni.

Se il problema persiste, togliere l’host dal servizio per gli utenti e raccogliere log e dati di Sophos Diagnostic Utility per il supporto. Se un errore compare solo su Citrix o su un’altra piattaforma virtuale, chiarire con il supporto Sophos e il produttore della piattaforma i passaggi di riproduzione necessari e le rispettive responsabilità.

Sospetta anomalia di SSPService su un host instabile

Se si verificano riavvii del servizio, instabilità dell’host o messaggi relativi a SSPService, prima di apportare modifiche acquisire le build esatte dell’agent e dei componenti, il sistema operativo, gli orari, gli eventi Windows e i log diagnostici. Anche voci come Process registration over the secure quota in sed.log sono soltanto indizi diagnostici: qui non è confermato un difetto specifico per RDS con una gamma precisa di versioni, una sequenza di eventi nei log e una soluzione. Non equiparare problemi diversi solo perché presentano un nome di servizio simile.

Fermare le successive ondate di rollout e togliere l’host interessato dal servizio per gli utenti secondo le procedure di manutenzione e gestione degli incidenti. Chiedere al supporto Sophos l’ID dell’incidente, se il servizio debba essere presente dopo un riavvio, quali build siano interessate, la versione che contiene la correzione e una soluzione approvata per questo host. Non modificare Tamper Protection in base a questo solo indizio e non presentare un riavvio come soluzione confermata.

Rollback

Definire il rollback prima del progetto pilota e applicarlo in base alla classe di errore:

Fermare ulteriori assegnazioni e ondate di rollout; bloccare nuovi accessi all’host interessato.
In caso di errore di policy, ripristinare l’assegnazione precedentemente documentata e ripetere il test dopo la sincronizzazione con Fusion.
In caso di errore della piattaforma o dell’agent, chiudere ordinatamente le sessioni, conservare i dati diagnostici e riportare l’host allo stato precedente secondo la procedura approvata di disinstallazione server o ripristino della piattaforma. Eliminare soltanto l’oggetto dispositivo in Fusion non disinstalla l’agent.
Reinserire l’host nel pool del broker solo dopo aver verificato applicazioni, sessioni parallele, stato Fusion e protezione o protezione sostitutiva confermata.

Non ripristinare alla cieca uno snapshot su un host attivo registrato in Fusion. La scelta tra ripristino e nuova installazione dipende dalla procedura verificata per RDS/Citrix e per la piattaforma di virtualizzazione. Dopo un rollback, chiarire la causa e avviare un nuovo progetto pilota; non riprendere semplicemente l’ondata fallita.