Desplegar Sophos Server Protection en AWS EC2 y máquinas virtuales de Azure

Una instancia EC2 o una máquina virtual de Azure se protege dentro del sistema operativo invitado mediante Sophos Server Protection. Para Windows Server se utiliza el Windows Server Installer; para servidores Linux compatibles, Sophos Protection for Linux (SPL). La ubicación de la máquina virtual no cambia la elección del agente de servidor. Sophos Firewall como dispositivo virtual en AWS o Azure protege y enruta el tráfico de red, pero no sustituye al agente instalado en el sistema invitado. Sophos Cloud Optix es un producto independiente de evaluación de la postura de seguridad e inventario en la nube, no un requisito para instalar la protección de servidores: según el aviso de fin de ciclo de vida de Sophos, el soporte y el acceso finalizan el 30 de septiembre de 2026. Por tanto, no debe servir de base para un proceso nuevo o permanente de inventario y limpieza en la nube. La disponibilidad de Server Protection y sus funciones, así como su cobertura contractual en el tenant propio, deben verificarse por separado.

Ruta rápida: Elige una máquina virtual representativa, valida el sistema operativo y el modo de protección, prueba la conexión con Sophos Fusion desde su red real en la nube, instala el instalador de servidor vinculado al tenant y comprueba My Products > Server > Servers y los detalles del servidor. Autoriza la siguiente tanda solo cuando funcionen el registro, la asignación al grupo, las políticas, el estado del agente y la aplicación. Para instancias de corta duración, planifica además una conciliación específica con el inventario de la nube.

Antes del piloto: definir la protección y la ruta de red

1. Máquina virtual y contrato: Registra la cuenta de AWS o la suscripción de Azure, la región, la función de la máquina virtual, la versión del sistema operativo o la distribución Linux, la arquitectura y el ciclo de vida. Comprueba la compatibilidad actual del sistema operativo invitado concreto y de los componentes necesarios. Confirma la licencia del tenant correspondiente y el SKU de servidor contratado, incluidas sus condiciones para estas máquinas virtuales; que aparezca un botón de descarga no demuestra el derecho de uso.
2. Modo de protección: Decide entre la protección completa contra malware de Sophos y XDR Sensor. XDR Sensor por sí solo no ofrece protección contra malware y requiere una solución activa de otro proveedor. Antes de cambiar de modo, identifica los posibles conflictos con el software de seguridad existente y prepara una vía de reversión para la máquina virtual afectada.
3. Conexión saliente: Comprueba desde la subred prevista si DNS, HTTPS, los destinos de Sophos necesarios para el tenant y, en su caso, el proxy o Message Relay son accesibles tanto durante la instalación como durante el funcionamiento. Security Groups, Network Security Groups, rutas de la nube, NAT, firewalls e inspección TLS pueden afectar a la conectividad. La lista de destinos permitidos y el diagnóstico del proxy están en Requisitos de red y proxy. No presupongas que una lista fija de direcciones IP de la nube sustituye a los destinos de Sophos.
4. Piloto y criterios de aceptación: Elige un grupo pequeño de máquinas virtuales que represente las funciones de servidor, las versiones del sistema operativo, los segmentos de red y, si procede, las rutas a través del proxy. Anota los nombres, el grupo de servidores esperado, las políticas previstas, la ventana de reinicio, la prueba de la carga de trabajo y los criterios para detener el despliegue. Si hay varias subredes o imágenes, prevé al menos una prueba adecuada para cada ruta diferente.

Ejemplo: una máquina virtual de aplicaciones Windows y una máquina virtual Linux de procesamiento en subredes privadas distintas son dos casos piloto, no una única prueba de red. Que el instalador funcione en la primera no demuestra que la segunda pueda acceder a su destino de actualización a través de su ruta NAT o proxy.

Instalar el agente en el sistema invitado y preparar correctamente las imágenes

En My Environment > Installers > Server Protection, selecciona Windows Server Installer o Linux Server Installer, según el modo de protección aprobado, desde el tenant correcto de Sophos Fusion. En una máquina virtual Windows individual, transfiere SophosSetup.exe de forma segura, ejecútalo con permisos de administrador local, atiende las comprobaciones previas que aparezcan y completa la instalación y el reinicio solicitado. En una máquina virtual Linux, transfiere SophosSetup.sh de forma segura, dale permisos de ejecución y ejecuta primero sudo ./SophosSetup.sh --test y, si la prueba se completa correctamente, sudo ./SophosSetup.sh. Después comprueba el registro en el tenant y el estado local del agente; no basta con que el instalador haya terminado. Los modos de protección, las opciones avanzadas de línea de comandos, los registros y la resolución de problemas se describen en Instalar y desplegar Windows Server Protection e Instalar y desplegar SPL. Guarda el instalador vinculado al tenant y su dirección de descarga solo en un repositorio de paquetes protegido, nunca en una imagen pública de máquina virtual ni en un repositorio público.

No clones sin cambios una máquina maestra ya registrada. Para incluir SPL en una imagen maestra de Linux, después de la instalación hay que dar de baja la máquina maestra con registerCentral --deregister conforme al procedimiento para imágenes maestras de Linux, apagarla inmediatamente y capturar la imagen mientras está apagada. Si se vuelve a encender, puede registrarse de nuevo; en ese caso, vuelve a darla de baja antes de guardar la imagen. Inicia dos clones y comprueba que tengan identidades distintas.

Windows Server requiere otro proceso para crear la imagen: Antes de prepararla, comprueba si Tamper Protection está desactivado para la configuración de la imagen y si Server Lockdown o Update Cache están activos; no crees una imagen maestra a partir de servidores que tengan activos estos dos últimos componentes. También quedan excluidas las máquinas maestras cifradas con BitLocker o que tengan componentes de Sophos Encryption. Ejecuta SophosSetup.exe --goldimage como administrador con el Windows Server Installer vinculado al tenant, siguiendo el procedimiento para imágenes maestras de Windows (también aplicable a servidores); comprueba la instalación y el estado del agente, vuelve a activar Tamper Protection y apaga la máquina maestra antes de capturar la imagen. En el primer arranque, cada clon debe recibir su nombre de equipo definitivo, distinto del de la máquina maestra, antes de que Sophos lo detecte: Sophos identifica los clones por el cambio de nombre, no por el ID de instancia en la nube. Si la asignación del nombre se retrasa, consulta el modo de tiempo de espera descrito en la guía; el modo de notificación se describe allí para VMware Horizon Instant Clone y no debe aplicarse indiscriminadamente a EC2 o Azure. No des por hecho que una instalación normal de Windows está lista para clonarse. También en este caso, valida por separado dos clones en Fusion.

Verificar la tanda en la nube y detenerla si hay errores

Tras la instalación o el arranque de un clon piloto, abre uno por uno los servidores previstos en My Products > Server > Servers. Si hay dos clones ejecutándose a la vez, deben aparecer dos objetos de servidor distinguibles. Como parte de la aceptación, registra una correspondencia externa entre la cuenta de AWS o suscripción de Azure, la región, el ID de instancia EC2 o ID de recurso de la máquina virtual de Azure, el ID de servidor de Fusion, el responsable y la fecha y hora de creación; la lista de servidores no muestra automáticamente los ID de la nube. En los detalles, comprueba Summary, Status y Policies, así como la última actividad, el estado del agente, los componentes instalados y las políticas de servidor aplicadas. La Default Policy asignada automáticamente al principio no tiene por qué ser la política de producción prevista. Después compara el servicio, el acceso a la aplicación, las copias de seguridad y el resultado de una prueba representativa de la carga de trabajo antes y después de cualquier reinicio necesario.

Si una máquina virtual no aparece en Fusion, comprueba primero el tenant y los filtros y, después, DNS, el proxy, la ruta de salida y los registros de instalación según el procedimiento de Windows o de Linux correspondiente. Si no se pueden distinguir los clones, detén el despliegue de la imagen y revisa el paso de identidad del procedimiento para imágenes maestras. Si los componentes son incorrectos, el estado del agente es deficiente o la carga de trabajo falla, no autorices otra tanda; investiga de forma aislada la tanda afectada en vez de volver a aplicar a ciegas instaladores y políticas.

Tratar por separado las instancias terminadas y los dispositivos inactivos

Una máquina virtual de corta duración puede haberse terminado mientras su entrada sigue visible en Sophos Fusion. Una fecha antigua en Last Active no demuestra que una instancia en la nube se haya terminado ni establece un plazo universal de limpieza automática. Coteja periódicamente la correspondencia externa entre cuenta o suscripción, región, ID de instancia o recurso en la nube e ID de servidor de Fusion con el inventario de AWS o Azure y el inventario de dispositivos de Fusion; registra el responsable, las fechas del ciclo de vida y la prueba del evento Terminate de EC2 o Delete de una máquina virtual de Azure. Un nombre de host reutilizado o una máquina virtual de Azure detenida no demuestran que el objeto de servidor correspondiente esté retirado.

La conciliación manual y el Delete selectivo siguen siendo la base: solo después de confirmar la terminación en la nube y la correspondencia inequívoca de los ID, conserva las alertas y los datos de investigación necesarios, comprueba posibles duplicados y documenta la retirada o la protección de reemplazo. Delete en Fusion no sustituye ni la desinstalación en una máquina virtual que siga en ejecución ni el proceso de gestión del ciclo de vida en la nube.

Por separado, Sophos documenta en Removal of inactive devices una regla configurable de Server para dispositivos inactivos: puede aplicarse a grupos concretos o globalmente con excepciones por grupo (las excepciones no se aplican a las reglas dirigidas a grupos concretos). La regla responde a la inactividad, no a un evento confirmado de EC2 Terminate o Azure Delete, y no desinstala el agente. Antes de activarla en el tenant propio, prueba con un conjunto de dispositivos de ensayo los grupos, el plazo, las excepciones, la conservación de datos y las consecuencias para máquinas virtuales de producción detenidas o temporalmente inaccesibles; no presupongas un plazo general ni un efecto determinado sobre las licencias. La antigua integración de Cloud Optix ofrecía, para entornos de AWS o Azure existentes y vinculados al mismo tenant con agentes de servidor, una función independiente de limpieza al terminar instancias, desactivada de forma predeterminada y activable solo por un Super Admin; no actuaba retroactivamente sobre instancias terminadas con anterioridad. Dado que el soporte y el acceso finalizan el 30 de septiembre de 2026, esto solo constituye contexto histórico, no una recomendación para nuevas instalaciones ni para una automatización permanente. No se promete ningún procedimiento no confirmado para hooks de eliminación en autoescalado, automatización mediante API o cómputo de licencias.