Implementar Sophos Fusion Server Protection en servidores RDS

Las sesiones RDS requieren una licencia de Server Protection; no se necesita una licencia de Endpoint Protection por cada sesión. Prevalecen las condiciones del contrato concreto y del EULA. Las políticas de servidor se asignan al host, no individualmente a los usuarios conectados. Este es un límite esencial al planificar entornos RDS, servidores de terminales y Citrix.

Por tanto, la secuencia segura es comprobar la plataforma y la licencia, probar con un host de sesiones representativo, decidir previamente las políticas para todo el servidor, desalojar de forma controlada las sesiones activas, instalar y autorizar más hosts solo después de la aceptación técnica y funcional. La creación de imágenes VDI y la identificación de usuarios en el firewall son tareas independientes.

Ámbito de aplicación y límites del soporte

No se dispone, para esta guía, de una matriz de compatibilidad de Sophos específica para RDS que pueda consultarse con garantías en este momento. No se deben utilizar listas antiguas de versiones de Windows y Citrix como autorización vigente para instalaciones nuevas. Antes del despliegue, compruebe el soporte de la combinación concreta de sistema Windows invitado, agente de servidor Sophos y su versión, versión de RDS o Citrix (incluidas las CU) y entorno de virtualización. En Citrix, compruebe también el ciclo de vida y, si corresponde, el soporte ampliado sujeto a contrato. Si la combinación sigue sin aclararse, solicite confirmación por escrito al soporte de Sophos; no deduzca la compatibilidad de la antigüedad ni del nombre de una plataforma.

Para el agente de servidor instalado en un invitado RDS virtualizado, no está acreditada ni una compatibilidad general con determinados hipervisores ni una cobertura de soporte universal basada en esfuerzos razonables. Compruebe por separado el sistema operativo invitado, la plataforma host y la capa Citrix/RDS, y aclare con Sophos y el fabricante de la plataforma las condiciones de soporte y reproducción aplicables al caso concreto. La compatibilidad de un dispositivo virtual o del hipervisor no implica la compatibilidad del invitado RDS protegido.

De ello se derivan tres distinciones:

Host RDS o Citrix multiusuario: tras confirmar la combinación concreta de plataformas, instale Server Protection en el invitado Windows; la política de servidor se aplica al host.
Máquinas VDI clonadas o no persistentes: el ciclo de vida de la imagen sigue el procedimiento independiente para imágenes maestras VDI de Sophos. No clone sin más un agente instalado de forma convencional.
Reglas de firewall basadas en el usuario: esta instalación de servidor no se encarga de ellas. Cuando varias sesiones comparten la misma IP del servidor, SATC para Remote Desktop Services explica la asignación de identidades independiente en Sophos Firewall.

Decidir funciones y políticas antes del despliegue

Compruebe el alcance de protección previsto para cada función en el tenant de destino según la licencia contratada, el sistema Windows invitado y los componentes del agente instalados. No se ha confirmado aquí una matriz funcional completa específica para RDS que abarque los distintos niveles de licencia de servidor. En particular, no confunda un sensor XDR independiente con una instalación de Server Protection que proporciona protección. Aclare la licencia y las condiciones contractuales mediante la información sobre licencias de Sophos Fusion (antes Sophos Central) y el EULA vigente.

Medida de precaución para el piloto, no un límite de soporte RDS acreditado: no asigne por ahora al host de sesiones la función de servidor de Update Cache ni de Message Relay, ni active como nueva medida de refuerzo la función antigua Server Lockdown o Unauthorized File Protection (UFP). Sophos cambió el nombre de Server Lockdown a Unauthorized File Protection; esto no demuestra que la función antigua o la nueva estén permitidas o prohibidas específicamente en RDS. Antes de introducir cambios, solicite una confirmación específica para RDS y por separado de si el host puede prestar servicios de caché o relay o utilizarlos, y de los requisitos de Lockdown y UFP, incluida una posible migración. La elección prudente para el piloto no equivale ni a una prohibición general ni a una autorización, y no justifica desactivar indiscriminadamente otros módulos de protección.

Políticas para todo el servidor, no para cada usuario

Las políticas de servidor se asignan al host de sesiones y no funcionan como políticas de servidor separadas para cada usuario RDS. Por tanto, mediante esa política no se pueden aplicar a la usuaria A controles Web, Application, Peripheral o DLP distintos de los del usuario B en el mismo host. Esto no supone ninguna afirmación sobre otros productos de usuario o firewall configurados por separado.

Antes del piloto, aclare las consecuencias con los responsables de aplicaciones y de las áreas usuarias:

¿Qué aplicaciones y scripts se ejecutan en todas las sesiones?
¿Qué periféricos necesitan determinados roles aunque la decisión afecte a todo el servidor?
¿Qué regla Web o DLP resulta aceptable para todos los usuarios de este host?
¿Qué recursos compartidos y rutas de perfiles de usuario debe cubrir Real-Time Scanning?
¿Qué excepciones están justificadas técnicamente, tienen un alcance limitado y están documentadas con responsable y fecha de caducidad?

Si distintos grupos de usuarios necesitan controles diferentes, distribúyalos en colecciones separadas de hosts de sesiones, cada una con la política de servidor adecuada. Una política común excesivamente permisiva no sustituye esta separación.

Mensajes de escritorio en varias sesiones

Desktop Messaging notifica los eventos de protección y está activado de forma predeterminada en la política Server Threat Protection. No se ha acreditado aquí que la forma en que se distribuye un mensaje entre sesiones simultáneas en un servidor de terminales concreto sea un comportamiento RDS universal. Tampoco se ha confirmado una lista fija de excepciones al desactivarlo. En un piloto con varias sesiones, compruebe quién ve cada mensaje y qué notificaciones siguen generando los componentes realmente instalados pese al cambio de configuración.

Ni el equipo de soporte ni los usuarios deben atribuir un mensaje visible a una sesión determinada sin comprobarlo. Antes del despliegue, defina los textos de los mensajes, el canal de soporte y la correlación por hora, servidor, alerta de Fusion y proceso afectado. No cierre una alerta basándose solo en lo comunicado por un único usuario.

Planificar el piloto y la instalación

Requisitos previos

Antes del primer host deben cumplirse los siguientes requisitos:

El sistema Windows invitado, la versión de RDS o Citrix y la plataforma de virtualización están dentro del alcance de soporte confirmado.
Se dispone de una licencia de servidor adecuada; se prevé instalar el host como servidor, no mediante un instalador normal de Endpoint.
El host puede acceder a Sophos Fusion por las rutas de red documentadas, directamente o mediante una arquitectura de proxy o relay confirmada para ese invitado RDS. Compruebe por separado el uso de caché y relay y la prestación de esos servicios en el host.
Se han determinado un host piloto representativo, una ventana de mantenimiento, criterios de aceptación técnicos y funcionales y un responsable de la reversión.
Es posible cerrar ordenadamente las sesiones RDS activas e impedir nuevos inicios de sesión durante el cambio.
La copia de seguridad, instantánea u otro punto de retorno se ajusta al procedimiento del operador de la plataforma y su capacidad de restauración se ha comprobado fuera de este cambio.
La política de servidor prevista está asignada al grupo piloto; por precaución, no se activan la función de servidor de caché/relay ni Lockdown/UFP en el piloto hasta aclarar los requisitos específicos de RDS.

En Sophos Fusion Admin, dentro del tenant correcto, obtenga el instalador de Windows Server en My Environment > Installers > Server Protection > Full malware protection, no el instalador del sensor XDR solamente. Para un despliegue automatizado se aplican los mismos principios que en el despliegue controlado de Windows: proteja el paquete de instalación vinculado al tenant, ejecútelo en el contexto de administrador local o del sistema, registre el código de salida real y no equipare el mero inicio correcto del proceso con una protección completa. Sin embargo, el producto, el grupo de destino y la licencia deben corresponder a Server Protection.

Ejecutar el piloto

Bloquee los nuevos inicios de sesión en el host piloto, informe a los usuarios y cierre ordenadamente las sesiones activas. No fuerce un cambio de agente durante sesiones de usuarios en producción.
Documente el estado inicial: nombre del host, versiones del SO y de RDS/Citrix, grupo de Fusion, políticas asignadas, software de seguridad instalado, estado de salud y punto de retorno.
Elimine los productos de la competencia y sus controladores de filtro conforme al plan de migración aprobado, o aplique la coexistencia confirmada. No ejecute dos escáneres en tiempo real en paralelo sin comprobarlo previamente.
Ejecute con privilegios administrativos el instalador de servidor actual del tenant de destino. Si utiliza distribución de software, transmita sin alteraciones el código de salida del instalador al sistema de despliegue.
Complete los reinicios solicitados dentro de la ventana de mantenimiento. Solo después permita inicios de sesión para las comprobaciones técnicas.
Con unas pocas cuentas de prueba, compruebe las aplicaciones habituales, los perfiles, las impresoras, los recursos compartidos y los flujos Web y DLP. Solo entonces admita a usuarios piloto reales.
Observe el host bajo una carga multiusuario normal durante el periodo acordado. Sophos no establece un valor universal para el número de sesiones ni para la reserva de CPU o RAM; rigen la referencia inicial propia y los criterios de aceptación del equipo de plataforma.

No modifique varios hosts a la vez. Un único inicio de sesión satisfactorio no demuestra la compatibilidad de todas las aplicaciones del servidor ni su comportamiento bajo la carga multiusuario habitual.

Aceptación y operación

El piloto solo se considera satisfactorio si se cumplen todos los puntos siguientes:

Local: el agente de servidor muestra un estado saludable; la instalación y los reinicios necesarios han concluido.
Fusion: el host aparece exactamente una vez como servidor en el tenant y grupo correctos, está actualizado y recibe las políticas de servidor previstas.
Protección: están instalados los componentes de protección acordados; no se han activado la función de servidor de caché/relay ni Lockdown/UFP, aplazados por precaución.
Sesiones: varios usuarios de prueba pueden iniciar sesión simultáneamente, abrir las aplicaciones principales, cargar sus perfiles y utilizar los recursos necesarios.
Políticas: los controles Web, Application, Peripheral y DLP realmente disponibles se comportan en las sesiones de prueba como se acordó; se ha comprobado la visibilidad de los mensajes en otras sesiones.
Operación: se comparan la CPU, la memoria, la duración del inicio de sesión y el tiempo de respuesta de las aplicaciones con los valores de referencia de la plataforma registrados antes del piloto. Se investigan las desviaciones, en vez de ocultarlas con exclusiones no justificadas.

Solo después de esta aceptación se planifica la siguiente pequeña oleada de hosts. Los cambios de política se siguen probando en un grupo piloto, porque una sola política de servidor afecta simultáneamente a muchas sesiones de usuario.

Resolución de problemas y retorno seguro

Un usuario recibe una política incorrecta

En un host RDS no existen políticas de servidor específicas para cada usuario. Compruebe primero el grupo de Fusion, la asignación de políticas y la prioridad del servidor. Si distintos grupos de usuarios necesitan controles diferentes, la solución fiable es separarlos en colecciones de hosts, no crear una excepción por cada usuario conectado.

Aparece un mensaje en varias sesiones

Documente esta observación en el propio piloto; no la trate como una garantía general para todas las instalaciones RDS. Correlacione la hora y el servidor con las alertas y eventos de Fusion e identifique el proceso que la desencadenó. Pruebe la configuración de Desktop Messaging de la política de servidor aplicable y las notificaciones que siguen apareciendo por componente en el tenant. No interprete el mensaje como prueba de que todas las sesiones en que se mostró estuvieran afectadas.

Las aplicaciones o los inicios de sesión presentan anomalías tras el piloto

Detenga las siguientes oleadas de despliegue. Registre primero los eventos de Fusion, el estado del agente, los eventos de Windows y el proceso afectado. Después, restablezca la política piloto modificada más recientemente al estado previamente documentado y vuelva a probar. Cree excepciones solo para el proceso o la ruta confirmados y con un alcance limitado; no introduzca exclusiones generales de unidades, perfiles o procesos como supuesta optimización del rendimiento.

Si el problema persiste, retire el host del servicio a usuarios y conserve los registros y los datos de Sophos Diagnostic Utility para soporte. Si el fallo solo ocurre en Citrix u otra plataforma virtual, aclare con el soporte de Sophos y el fabricante de la plataforma los pasos de reproducción necesarios y las responsabilidades correspondientes.

Sospecha de fallo de SSPService en un host inestable

Si se producen reinicios del servicio, inestabilidad del host o mensajes relativos a SSPService, antes de efectuar cambios guarde las versiones exactas del agente y sus componentes, el sistema operativo, las horas de los eventos, los eventos de Windows y los registros de diagnóstico. Incluso entradas como Process registration over the secure quota en sed.log son solo indicios diagnósticos: aquí no se ha confirmado para ellas un defecto específico de RDS con un intervalo de versiones, una secuencia de registros y una solución determinados. No equipare otros fallos que mencionen un servicio con un nombre similar.

Detenga las siguientes oleadas y retire el host afectado del servicio a usuarios conforme a los procedimientos de mantenimiento e incidentes. Pregunte al soporte de Sophos por el identificador del incidente, si el servicio debe estar presente tras reiniciar, las versiones afectadas, la versión con la corrección y una solución autorizada para este host. No cambie Tamper Protection basándose en ese indicio ni presente un reinicio como solución confirmada.

Reversión

Defina la reversión antes del piloto y ejecútela según el tipo de fallo:

Detenga nuevas asignaciones y oleadas de despliegue; bloquee nuevos inicios de sesión en el host afectado.
Si se trata de un fallo de política, restablezca la asignación documentada anteriormente y vuelva a probar tras la sincronización con Fusion.
Ante un fallo de la plataforma o del agente, cierre ordenadamente las sesiones, conserve los datos de diagnóstico y recupere el host según el procedimiento aprobado de desinstalación del servidor o restauración de la plataforma. Eliminar solo el objeto de dispositivo de Fusion no desinstala el agente.
No reincorpore el host al grupo de hosts del broker hasta haber comprobado las aplicaciones, las sesiones paralelas, el estado de Fusion y la protección o una protección sustitutiva confirmada.

No restaure a ciegas una instantánea sobre un host activo registrado en Fusion. El retorno seguro mediante restauración o reconstrucción depende del procedimiento probado para RDS/Citrix y la plataforma de virtualización. Tras la reversión, aclare la causa y programe un nuevo piloto; no reanude sin más la oleada fallida.