Conectar Sophos Firewall con Sophos Fusion (antes Sophos Central)

No es obligatorio conectar un Sophos Firewall con Sophos Fusion. Un firewall individual puede gestionarse completamente de manera local a través de WebAdmin. Sin embargo, en muchos entornos, vale la pena conectarlo a Sophos Fusion, ya que proporciona funciones adicionales de gestión, copias de seguridad, informes y seguridad.

Este artículo ayuda a decidir cuándo es útil Sophos Fusion y cuándo es suficiente la gestión local.

El nombre actual de la plataforma es Sophos Fusion, antes Sophos Central. Los menús, botones y la alerta de registro del firewall pueden seguir mostrando Sophos Central; al seguir el procedimiento, se deben utilizar esas etiquetas tal como aparecen en la interfaz. Un firewall gestionado de forma centralizada también puede integrarse como gateway ZTNA para acceder a recursos internos. El registro por sí solo no configura ese gateway ni concede acceso a dichos recursos; el despliegue de ZTNA y su política de acceso deben planificarse por separado.

Respuesta breve

Si solo se gestiona un Sophos Firewall de forma local y no se desean utilizar las funciones de Central, no es necesario utilizar Sophos Fusion.

Si se gestionan varios firewalls, se desea analizar datos de registros de manera centralizada o almacenar copias de seguridad de configuraciones en la nube, o se utilizan otros productos de Sophos como Sophos Endpoint, Sophos Fusion ofrece ventajas significativas.

La decisión no debe limitarse a conectar o no conectar el firewall. Es más importante decidir qué funciones de Central se deben activar realmente. Un firewall puede estar registrado en Sophos Fusion sin que todas las funciones de gestión, informes o copias de seguridad se utilicen en producción.

Zero Touch: despliegue con un archivo de configuración

Además de la gestión de firewalls existentes, Sophos Fusion ofrece Zero Touch: los firewalls nuevos pueden instalarse con un archivo de configuración de Zero Touch. Para ello se necesita una cuenta de Sophos Fusion; la interfaz puede seguir llamándose Sophos Central. Esta opción es relevante al planificar instalaciones en nuevas sedes cuando se desea preparar el despliegue a través de Central. No es lo mismo que el posterior acceso remoto a WebAdmin ni que la distribución de una política de grupo.

Antes de elegir el método de despliegue, se deben definir el tenant previsto, los administradores responsables y sus permisos, el dispositivo y su número de serie, las necesidades de licencias y la conexión a Internet. Para la posterior gestión mediante Central sigue siendo necesaria una conexión IPv4 operativa; los requisitos de licencia descritos en este artículo siguen siendo aplicables. Zero Touch no es un requisito para el funcionamiento local ni un método de reparación para un firewall que ya está en producción.

Se deben distinguir claramente las tareas:

• Nueva instalación con Zero Touch: El archivo de configuración sirve para desplegar un firewall nuevo. Esta descripción general explica la funcionalidad, pero no ofrece instrucciones completas para crear o aplicar el archivo. Se debe planificar este método antes de la instalación; no se debe deducir un procedimiento de Zero Touch a partir de los pasos de OTP que se describen más adelante.
• Configuración local, claim y licencias: Configurar Sophos Firewall, realizar el claim y activar las licencias describe la configuración básica local, la asignación al tenant mediante el claim y la activación o sincronización de licencias como tareas independientes. Estas tareas no deben equipararse al registro para la gestión.
• Conectar un firewall existente: El método con OTP descrito más adelante requiere un firewall ya configurado y reclamado mediante claim en el tenant correcto. El OTP lo registra para Central Management, pero no sustituye ni al claim ni a la activación de suscripciones. La asignación del firewall a un cliente por parte de un partner tampoco sustituye al claim.
• Gestionar varios firewalls conjuntamente: Usar Sophos Fusion Firewall Groups de forma segura explica las políticas comunes y los efectos de Full Sync. La gestión de grupos es una tarea operativa independiente, no el método de instalación con Zero Touch.

Ventajas de conectar con Sophos Fusion

Vista centralizada

En Sophos Fusion, se pueden ver los firewalls registrados en un solo lugar. Esto es especialmente útil cuando se gestionan varias ubicaciones o dispositivos de la misma organización.

Ventajas típicas:

• Vista de estado de los firewalls
• Números de serie e información de licencias
• Estado de firmware y seguridad
• Informes centralizados
• Cambio rápido entre varios firewalls

Gestión a través de Sophos Fusion

Con Manage from Sophos Central, se puede acceder a la gestión del firewall a través de Sophos Fusion. Esto suele ser más seguro que publicar directamente la consola WebAdmin desde Internet.

El acceso de gestión no reemplaza una estrategia administrativa adecuada. Las cuentas de administrador, MFA, roles, Device Access y reglas ACL deben seguir configurándose conscientemente. Según Sophos, Central Firewall Management también requiere una suscripción activa de pago distinta de Base Firewall o una licencia de soporte de Sophos activa que incluya este derecho, como Enhanced Support. La licencia Base Firewall por sí sola no basta; no todo contrato de soporte concede automáticamente este derecho.

Un punto técnico se pasa por alto con frecuencia: Sophos Fusion solo puede gestionar firewalls si el firewall accede a Internet mediante IPv4. En entornos IPv6-only o muy segmentados, esta ruta debe comprobarse antes de la activación.

Si los cambios a través de Central no llegan al firewall como se esperaba, también se debe verificar la Sophos Fusion Firewall Management Task Queue. Allí se puede ver si las políticas de grupo o las tareas de firewall basadas en API están pendientes, han fallado o se han omitido.

Usar Sophos Fusion Firewall Groups de forma segura explica cómo varios firewalls reciben una política común y qué hacen realmente Full Sync y Skip full sync.

Para varias sedes, Central también puede orquestar conexiones VPN basadas en rutas, interfaces XFRM, rutas y reglas. Configurar y comprobar un grupo de conexiones SD-WAN en Sophos Fusion explica la planificación, la resolución de conflictos y la validación local.

Límites de Central Firewall Management

Central Firewall Management es una vía adicional de administración, pero no sustituye por completo la administración local del firewall, los logs locales ni un acceso de emergencia probado. Especialmente con varios administradores, grupos de firewalls y clústeres HA, conviene conocer sus límites para no confundir un comportamiento normal de la plataforma con un error de configuración.

Observaciones habituales durante la operación:

• Dos administradores abren el mismo firewall desde Central al mismo tiempo: Solo puede estar activa una sesión de Central Manager por firewall. Si un segundo administrador toma el control, el primero puede ver una pantalla de carga o un error de conexión. Coordinar quién mantiene la sesión y comprobar directamente en el WebAdmin local si es necesario.
• Un rol read-only o helpdesk no ve firewalls agrupados: Probar los roles en Central con cuentas reales antes de usarlos en producción. Algunas vistas o funciones de grupo no son visibles para todos los roles.
• Los pares HA aparecen dos veces o en varias páginas: Puede tratarse de un problema de visualización o paginación. Para la operación, el estado HA local sigue siendo determinante.
• Las reglas de firewall no se pueden mover a nivel de grupo como localmente: No todas las acciones del WebAdmin local se reproducen de la misma forma en los grupos de Central. Después de modificar un grupo, hay que validar localmente el orden y el efecto de las reglas.
• Grupos importados o reglas WAF se comportan de forma inesperada en Central: Tras importar configuración, hacer Full Sync o importar reglas WAF, comprobar la vista de Central, el firewall de destino y la Task Queue.

En la práctica: después de cambios desde Central, revisar la Task Queue, la vista WebAdmin local, el Log Viewer y, si hace falta, el Audit Trail. Si la interfaz de Central solo carga, un par HA aparece duplicado o una regla de grupo no se puede mover, no tiene por qué ser un problema de la regla de firewall.

Copias de seguridad de configuración en Sophos Fusion

El firewall puede enviar copias de seguridad de configuración a Sophos Fusion. Esto es útil si se necesita reemplazar o restaurar un dispositivo y no hay copias de seguridad locales disponibles.

En Sophos Fusion, se pueden configurar copias de seguridad programadas para los firewalls registrados. Los intervalos disponibles son Daily, Weekly y Monthly. Esto permite, por ejemplo, definir que los firewalls seleccionados envíen una copia de seguridad de configuración a Sophos Fusion diariamente, semanalmente o mensualmente.

La documentación actual de Sophos sobre copias de seguridad sitúa la programación en Global Settings > Products and Services > Firewall > Schedule Backup. Si la ruta Firewall Management > Backup mostrada en la captura no aparece en tu interfaz, utiliza este acceso.

Sophos Fusion no conserva indefinidamente todas las copias de seguridad automáticas. De forma predeterminada, se conservan las cinco copias más recientes y se descartan las anteriores. Además, una copia puede marcarse para conservarse permanentemente. En clústeres HA, Primary y Auxiliary aparecen en la planificación de backup, pero según Sophos solo se genera la copia del dispositivo Primary.

Para el funcionamiento diario importan dos detalles: Sophos Fusion intenta crear la copia de seguridad hasta cinco veces y, si falla de forma permanente, genera una alerta y un correo electrónico para el administrador de Sophos Fusion. Si un firewall se elimina de la administración de Sophos Fusion, Sophos Fusion elimina los archivos de copia de seguridad asociados. Por eso las copias de seguridad en la nube son útiles, pero no sustituyen una estrategia propia de copias de seguridad y restauración.

Sin embargo, no se debe confiar en un único método de copia de seguridad. Para los sistemas en producción, siguen siendo útiles las copias de seguridad locales o externas periódicas. También son importantes la contraseña de copia de seguridad y la clave maestra de almacenamiento seguro.

Central Firewall Reporting

Con Central Firewall Reporting, el firewall envía datos de registros e informes a Sophos Fusion. Esto permite evaluar informes durante períodos más largos y realizar búsquedas centralizadas.

En Sophos Fusion, están disponibles paneles de control, el Report Hub, el Report Generator, plantillas guardadas y exportaciones programadas. Se pueden crear informes para firewalls individuales o múltiples, filtrar períodos de tiempo, buscar eventos específicos y exportar resultados como PDF, CSV o HTML. Para evaluaciones regulares, los informes también se pueden programar y proporcionar automáticamente.

Según Sophos, guardar plantillas, programar exportaciones y descargar informes requiere una licencia Central Firewall Reporting Advanced. Para los informes de varios firewalls, todos los firewalls seleccionados deben disponer de la licencia correspondiente.

Las plantillas de informes típicas son:

• Antivirus
• Uso de ancho de banda
• Riesgos y uso de aplicaciones en la nube
• Firewall
• IPS
• Visor de registros y búsqueda
• SD-WAN
• Tendencia de SLA de SD-WAN
• Uso de ancho de banda de SD-WAN
• Evaluación de postura de seguridad
• Sincronizar aplicación
• Actividad geográfica de amenazas
• Amenazas y eventos bloqueados
• Uso de VPN
• Uso web
• Riesgos de usuarios web
• X-Ops
• Protección contra día cero

La duración del almacenamiento depende de la licencia:

• Suscripción activa de Firewall: hasta 7 días, para informes básicos y revisiones cortas.
• Xstream Protection / Central Orchestration: hasta 30 días, dependiendo del paquete y de los derechos de licencia.
• Central Firewall Reporting Advanced: hasta 365 días; 100 GB de almacenamiento adicional por licencia.

La activación exacta y la selección de registros se describen en el artículo detallado Activar Central Firewall Reporting.

Synchronized Security y Security Heartbeat

Cuando Sophos Endpoint y Sophos Firewall se utilizan conjuntamente a través de Sophos Fusion, se puede utilizar Synchronized Security. En este caso, el firewall y el endpoint intercambian información de seguridad.

Ejemplos:

• El firewall ve el Security Heartbeat de los endpoints.
• Los dispositivos con un Heartbeat rojo pueden ser restringidos automáticamente.
• Se obtiene una visión más integrada de la red y de los endpoints.
• En incidentes, es más rápido ver qué usuario o dispositivo está afectado.

Este es uno de los mayores valores añadidos cuando, además del firewall, también se utiliza Sophos Endpoint, MDR o XDR.

Security Heartbeat también puede transmitir al firewall la identidad de dominio de Windows de un endpoint administrado. Configurar Synchronized User ID Authentication explica el procedimiento seguro para el piloto, la regla y HA.

Validar Security Heartbeat después del registro

Que el firewall sea visible en Sophos Fusion todavía no demuestra que Security Heartbeat funcione para los endpoints. Se necesita una cuenta de Sophos Fusion, al menos un endpoint gestionado por Sophos Fusion con licencia de prueba o completa y una suscripción válida a Network Protection en el firewall. Al registrar el firewall, SFOS activa automáticamente Security Heartbeat y Synchronized Application Control.

Para una primera validación controlada se puede utilizar un único endpoint piloto gestionado:

1. En System > Sophos Central, comprobar que el firewall está registrado y que Security Heartbeat está activo.

2. En Sophos Fusion, en My Products > Firewall Management > Firewalls, confirmar la alerta A new firewall has been successfully registered to Sophos Central. Esta alerta demuestra el registro, pero todavía no el efecto de una regla.

3. Para el endpoint piloto en Sophos Fusion, comprobar el tenant, el estado de salud actual y los eventos del mismo periodo.

4. En Control Center > User & device insights > Security Heartbeat, comprobar si el contador Connected refleja de forma plausible el estado esperado del endpoint piloto. Según Sophos, la vista detallada permanece vacía cuando todos los endpoints están en verde; solo enumera individualmente los endpoints rojos y amarillos.

5. Comprobar la regla de firewall que coincide realmente y los requisitos mínimos de heartbeat configurados por separado para el origen y el destino en Configure Synchronized Security Heartbeat. Sin una condición de heartbeat configurada, el estado solo es visible. Revisar también las excepciones aplicables: Sophos documenta que una excepción para comprobaciones de políticas en Web > Exceptions puede permitir solicitudes web aunque la regla tenga Block clients with no heartbeat seleccionado. No inferir un bloqueo universal del estado mostrado; comprobar el resultado del flujo autorizado.

6. Solo después de establecer esta referencia, activar una condición de heartbeat en una regla piloto de alcance limitado, habilitar el logging y probar tráfico permitido con un endpoint sano.

Contradicción en la documentación de Sophos: La descripción general de Security Heartbeat para SFOS 22 y 23 afirma de forma general en la sección sobre VPN que, en el estado Missing, el firewall bloquea todo el tráfico de ese endpoint. En cambio, la descripción detallada de Heartbeat supedita el efecto sobre el acceso a las reglas y menciona expresamente la excepción para las comprobaciones de políticas en Web > Exceptions: las solicitudes web no se bloquean a pesar de Block clients with no heartbeat. Estas afirmaciones no son compatibles entre sí como garantía general de aislamiento. Por ello, para una validación segura se comprueban la regla que realmente se aplica, los requisitos mínimos independientes de Source heartbeat y Destination heartbeat, las excepciones aplicables y el resultado real del acceso. La indicación Missing por sí sola no demuestra un aislamiento completo.

No se debe generar un estado rojo para esta prueba desactivando o manipulando la protección del endpoint. Si Central, Control Center y el efecto de la regla no coinciden, o aparece Missing, analizar sistemáticamente las alertas Missing Heartbeat mediante la zona, la ruta, Rule ID y los logs.

Para la vista más amplia de Control Center > User & device insights, consultar Evaluar User & Device Insights de forma segura. El artículo explica los contadores de Heartbeat y aplicaciones, los hallazgos de Zero-Day, UTQ, los errores SSL/TLS y las sesiones de firewall, incluidos sus distintos períodos de tiempo y la diferencia entre ocultar un error y cambiar una política de descifrado. Estas señales locales no equivalen a Central Reporting ni demuestran que todos los endpoints o conexiones estén protegidos.

Definir el alcance de la supervisión de Heartbeat y comprobar la ruta

En System > Sophos Central > Optional configurations > Missing heartbeat zones, seleccionar únicamente las zonas en las que se espera que haya endpoints Sophos gestionados. Los heartbeats ausentes solo se detectan en las zonas seleccionadas; las impresoras, los invitados, los dispositivos IoT y los clientes con otro EDR no adquieren un Sophos Heartbeat por el mero registro. La lista de zonas y las condiciones de heartbeat de las reglas de firewall que coincidan deben ser coherentes. Sophos documenta un caso especial: si una política de heartbeat bloquea una zona, pero no se añade ninguna zona en este campo, el widget de Control Center puede seguir mostrando Missing. Por tanto, una lista vacía no demuestra que ninguna política esté afectando al tráfico.

Antes de cambiar el alcance o una regla piloto, documentar la lista original de zonas, el Rule ID, las opciones de heartbeat y la IP, la MAC y el estado actual del endpoint piloto. Aplicar únicamente el cambio limitado previsto. Después, comparar el mismo endpoint en Central y Control Center, generar un flujo de prueba autorizado con el endpoint sano y verificar en el Log Viewer el Rule ID que coincide y el resultado del acceso. Si el acceso cambia de forma inesperada, restaurar la lista de zonas y las opciones de regla documentadas, repetir el mismo flujo e investigar la ruta, en lugar de reducir globalmente los requisitos de heartbeat.

El canal de Heartbeat documentado utiliza TLS cifrado hacia 52.5.76.173 por TCP 8347. Central proporciona certificados que permiten al firewall asociar los endpoints con la organización correcta; un puerto abierto por sí solo no establece esa confianza. Antes de diagnosticar un estado ausente, comprobar estas limitaciones de la topología:

• Una VPN establecida antes de la conexión de heartbeat puede desviar ese tráfico del firewall local. Para Sophos Connect IPsec, comprobar Remote access VPN > IPsec > Advanced settings > Send Security Heartbeat through tunnel según la política de conexión prevista.
• Detrás de un router intermedio sin NAT, un endpoint puede seguir compartiendo su estado de salud, pero el firewall no puede detectar un heartbeat ausente. Ver un estado de salud no demuestra que la supervisión de Missing funcione en esa ruta.
• Detrás de un gateway NAT, los endpoints no pueden compartir su estado de salud con el firewall. Esta limitación es distinta de la del caso enrutado sin NAT.
• En modo TAP, los endpoints deben poder acceder al menos a una interfaz de la zona LAN conectada permanentemente a la red. El tráfico replicado por sí solo no basta: los endpoints reciben las direcciones de las interfaces LAN a través de Central e intentan enviar su heartbeat a una de ellas.

Interpretar el estado de salud sin asumir un aislamiento automático

Connected (green) indica el estado saludable comunicado por el endpoint, pero no garantiza que se hayan descartado todas las amenazas. Warning (yellow) puede indicar una PUA, malware inactivo o eliminado, o firmas que no se han actualizado durante 24 horas. At risk (red) requiere investigación, por ejemplo, por malware activo que no se ha podido eliminar, tráfico de red malicioso o protección que no funciona correctamente. Missing (red) es distinto: el firewall detecta tráfico, pero no recibe el estado de salud correspondiente. Comparar los eventos del endpoint antes de tratar ambas etiquetas rojas como si fueran el mismo incidente.

La vista detallada de los estados rojo y amarillo muestra el nombre de host, la IP, el usuario y el tiempo transcurrido desde el cambio de estado. Una entrada Missing puede permanecer en Control Center y en los informes después de que el endpoint abandone la red; cambia cuando el endpoint vuelve a conectarse. No se debe eliminar una entrada de este tipo solo para que el panel aparezca en verde. La guía enlazada sobre Missing Heartbeat explica la recopilación de evidencias, las implicaciones de los temporizadores, el comportamiento compatible de Modern Standby y la limpieza de alcance limitado. Los endpoints envían su heartbeat cada 15 segundos; la distribución de listas de endpoints rojos y amarillos cada 30 segundos y el tiempo de espera predeterminado de 60 segundos para detectar Missing son mecanismos independientes. Ampliar el tiempo de detección o retrasar el envío del estado también puede retrasar alertas reales.

La protección contra el movimiento lateral es otro control independiente: los demás endpoints solo dejan de comunicarse con un endpoint rojo cuando se aplica la política de endpoints correspondiente de Central. El firewall comparte direcciones MAC y estados de salud como proxy de capa 2 dentro del mismo dominio de difusión. No se debe asumir que esto aísla los endpoints entre redes enrutadas ni que sustituye las condiciones de heartbeat para el tráfico que atraviesa el firewall.

La descripción general de SFOS 22 documenta la identidad de usuario sincronizada con nombre de dominio, nombre de usuario y Active Directory. La descripción general de SFOS 23 documenta además User Principal Name (UPN) y la validación de cuentas mediante Active Directory o Microsoft Entra ID. No se debe aplicar esa descripción de SFOS 23 a un despliegue de SFOS 22 ni asumir que el registro por sí solo configura la autenticación de identidad; antes de utilizar reglas basadas en identidad, comprobar el firmware real y la configuración del servidor de autenticación.

Lo que Sophos Fusion no reemplaza

Sophos Fusion es útil, pero no reemplaza una configuración adecuada del firewall.

Central no reemplaza:

• Planificación adecuada de zonas e interfaces
• Reglas de firewall restrictivas
• Endurecimiento de Device Access
• MFA para administradores y portales
• Solución de problemas local con Log Viewer y Packet Capture
• Copias de seguridad documentadas y pruebas de restauración
• Un sistema Syslog externo, si se requiere cumplimiento o almacenamiento prolongado

Por lo tanto, Sophos Fusion es una capa adicional de gestión e informes, pero no un atajo para una configuración básica segura.

Verificar antes de registrar

Antes de conectar con Sophos Fusion, se debe aclarar qué se quiere lograr con el registro. Esto evita responsabilidades poco claras, tenants duplicados o servicios activados innecesariamente más adelante.

Preguntas previas importantes:

• ¿En qué tenant de Sophos Fusion se debe registrar el firewall?
• ¿Quién tiene en el tenant los derechos necesarios para Firewall Management, Reporting, Backup y temas de licencias?
• ¿El firewall ya está registrado en otra cuenta de Central?
• ¿Tiene el firewall una suscripción activa de pago distinta de Base Firewall o una licencia de soporte de Sophos activa que incluya Central Firewall Management, como Enhanced Support? Comprobar la licencia concreta, no solo la existencia de un contrato de soporte.
• ¿Tiene el firewall una conexión IPv4 funcional a Internet?
• ¿Se utilizará Central solo para la vista de licencias e inventario o también para gestión, reporting y backups?
• ¿Se utilizan grupos de firewalls, y se han probado en la práctica los roles de Admin, Helpdesk y Read-only?
• ¿Se pueden enviar logs de firewall a Sophos Fusion desde el punto de vista de privacidad o cumplimiento?
• ¿Existe un backup local actual y una Secure Storage Master Key documentada?
• ¿Está claro quién revisará las alertas, informes y tareas fallidas después del registro?

Si el firewall ya está en la cuenta incorrecta, primero se debe revisar Transferir Sophos Firewall a otra cuenta de Sophos Fusion. Para la clasificación de las diferentes cuentas y portales, ayuda Portales de Sophos: SophosID, Central, Soporte y accesos a Firewall.

Cuándo no es necesario conectar el firewall

No es necesario conectar con Sophos Fusion si:

• solo se gestiona un firewall individual localmente
• no se necesitan informes de Central
• no se planea la integración de Sophos Endpoint
• la gestión en la nube no es deseada por razones organizativas
• los registros ya se envían a un SIEM propio o a un servidor Syslog

En tales casos, se puede operar el firewall localmente. Sin embargo, es importante organizar adecuadamente las copias de seguridad, las actualizaciones de firmware, el monitoreo y el registro de otra manera.

Cuándo es recomendable Sophos Fusion

Sophos Fusion es especialmente recomendable si:

• se gestionan varios firewalls
• los administradores trabajan desde diferentes ubicaciones
• los firewalls no deben ser accesibles directamente a través de WebAdmin desde Internet
• se deben almacenar copias de seguridad de configuración de manera centralizada
• se necesitan informes de firewall
• se utilizan Sophos Endpoint, MDR, XDR u otros productos de Sophos Fusion
• se desea utilizar Security Heartbeat y Synchronized Security

Activar la conexión

La conexión se configura en el firewall, en System > Sophos Central.

Los siguientes procedimientos utilizan las etiquetas de interfaz en inglés documentadas para SFOS 22 y SFOS 23; la interfaz local puede seguir mostrando Sophos Central. Un administrador local del firewall necesita acceso a este menú. Central Firewall Management sigue requiriendo una suscripción activa de pago distinta de Base Firewall o una licencia de soporte de Sophos activa que incluya este derecho, como Enhanced Support. Base Firewall por sí sola no basta y la ruta de administración por Internet solo funciona mediante IPv4.

Antes de generar un OTP: El firewall debe estar ya configurado y reclamado mediante claim en el tenant de Sophos Fusion previsto. Si aún falta la configuración o el claim, seguir primero Configurar Sophos Firewall, realizar el claim y activar las licencias y comprobar la asignación del dispositivo y de las licencias. El registro posterior con OTP conecta el firewall existente para Central Management; no reclama su propiedad ni activa suscripciones. La asignación del firewall a un cliente por parte de un partner tampoco sustituye al claim.

Hay dos métodos de registro típicos:

• OTP desde Sophos Fusion: útil cuando un partner, equipo de proyecto o admin de firewall no debe trabajar en el firewall con credenciales Super Admin del tenant Central. En Sophos Fusion, el firewall existente se añade bajo My Products > Firewall Management > Firewalls > Add Firewall mediante su número de serie y se genera un OTP.
• Credenciales de Sophos Fusion: útil cuando se registra directamente en el firewall con una cuenta de admin adecuada de Sophos Fusion. Sophos lo denomina Central Super Admin.

En pares HA conviene trabajar con especial cuidado. En el registro con OTP se introducen ambos números de serie en Sophos Fusion; en pares HA nuevos, el OTP se usa en el dispositivo Primary.

Generar un OTP en el tenant correcto

Para un firewall ya configurado y reclamado mediante claim, generar el OTP en Central antes de pasar a los pasos de registro local:

1. Iniciar sesión en el tenant previsto. Un partner debe asignar primero el firewall al cliente correcto en Partner Dashboard y abrir la consola Central Admin de ese cliente. La asignación a un cliente no sustituye al claim.
2. Abrir My Products > Firewall Management > Firewalls > Add Firewall y seleccionar Join a firewall that is configured or deployed.
3. En Enter Device Serial Number, introducir el número de serie previsto y hacer clic en Next. Para HA, introducir ambos números de serie separados por una coma y comprobar que corresponden al par previsto.
4. Mantener seleccionada la opción Register using OTP y elegir Copy OTP and Finish. El OTP es válido durante 14 días. Compartirlo únicamente con el administrador autorizado del firewall a través del canal aprobado para compartir secretos; no incluir el OTP, contraseñas ni capturas de credenciales sin ocultar los datos sensibles en la documentación de soporte.
5. En el firewall, seleccionar Register > Use OTP, pegarlo en Enter OTP y hacer clic en Register. Para un par HA nuevo, introducir el OTP únicamente en el dispositivo primario. Después, activar los servicios de Central previstos y obtener la aprobación de servicios descrita más abajo.

Si el OTP ha caducado o el registro falla, comprobar primero el tenant previsto, el claim, los números de serie y la conectividad IPv4. Obtener un OTP nuevo del tenant correcto cuando sea necesario; no dar de baja repetidamente el firewall ni cambiar su propiedad para sortear el error. El registro solo se considera validado cuando los números de serie y el estado de los servicios coinciden en ambas vistas.

El procedimiento alternativo con credenciales requiere un Central Super Admin. No se puede utilizar para este registro una cuenta de administrador perteneciente a un Central Enterprise sub-estate. La cuenta del tenant y el rol de administrador local del firewall deben mantenerse diferenciados; el OTP permite al administrador local realizar el registro sin recibir la contraseña de Super Admin del tenant.

Proceso típico en el firewall:

1. Iniciar sesión en el firewall.
2. Abrir System > Sophos Central.
3. Seleccionar Register.
4. Seleccionar Use OTP o Use email address.
5. Introducir el OTP o las credenciales de Sophos Fusion.
6. Completar el registro.
7. Activar Sophos Central services.
8. Seleccionar los servicios deseados.

Según sea necesario, se pueden activar estas opciones:

• Use Sophos Central reporting / Send reports and logs to Sophos Central: envía datos de logs e informes a Sophos Fusion.
• Use Sophos Central management / Manage from Sophos Central: permite el acceso de gestión a través de Sophos Fusion.
• Send configuration backup to Sophos Central: guarda copias de seguridad de la configuración en Sophos Fusion. En la práctica, esta opción depende de la configuración de Central Management y debe aprobarse en Sophos Fusion.

Solo se deben activar las funciones que realmente se utilizarán. En entornos con requisitos de privacidad o cumplimiento, debe aclararse previamente qué datos de logs pueden enviarse a Sophos Fusion.

Después de activar los servicios, una cuenta con el rol Super admin en el tenant de Sophos Fusion correspondiente debe aceptarlos en Sophos Fusion:

1. Iniciar sesión en Sophos Fusion.
2. Abrir My Products > Firewall Management > Firewalls.
3. Buscar el firewall con Approval Pending.
4. Seleccionar accept-services.
5. En el firewall, comprobar si el estado cambia de Waiting for approval from Sophos Central a Managed o conectado.

El cambio de estado puede tardar unos minutos. Si la indicación no cambia de inmediato, no se debe registrar repetidamente. Primero conviene comprobar el estado de Central, la conexión a Internet, el DNS y la hora.

Si hay un filtro de egreso delante del firewall, también deben ser accesibles los servicios y puertos salientes de Sophos correspondientes para Central, reporting y backups.

Incorporar un par HA a la gestión de Central

Antes de realizar cambios, distinguir entre dos situaciones iniciales. Documentar ambos números de serie, las versiones de firmware, los roles primario y auxiliar, el estado HA local y los estados de los servicios de Central. Mantener disponibles copias de seguridad actuales de la configuración, sus contraseñas, la Secure Storage Master Key y un acceso de administración local operativo. La creación del par HA es un cambio de mantenimiento independiente, no un atajo para resolver problemas de registro; Planificar y operar las variantes HA de Sophos Firewall explica qué configuración prevalece, la sincronización y el plan de recuperación.

• Dos firewalls independientes ya se gestionan de forma centralizada: preparar HA localmente con la configuración prevista para el primario. Ambos dispositivos deben ejecutar la misma versión de firmware. Sophos documenta tanto Active-Active como Active-Passive; después de formar el par, Central debe mostrar un único par HA, no dos dispositivos independientes para la gestión. Seguir el procedimiento de preparación de HA antes de permitir que la sincronización sustituya la configuración del auxiliar.
• Ya existe un par HA, pero no se gestiona de forma centralizada: trabajar en el primario. La documentación específica de HA denomina la vista de registro Central synchronization y la acción Register both HA devices. Después del registro, activar la gestión de Central y, junto al firewall primario en Central, seleccionar Approval Pending > accept-services con el Super Admin autorizado. Para el método OTP, utilizar ambos números de serie e introducirlo solo en el primario, como se describe arriba, en lugar de registrar cada nodo por separado.

Esperar unos minutos y confirmar después que Central muestra un único par con un HA icon y los números de serie previstos. Verificar localmente los roles primario y auxiliar y la sincronización, además del acceso de gestión y un flujo de prueba autorizado en producción. Los cambios de configuración de Central se aplican a ambos firewalls; que se muestre un único objeto no demuestra que solo se vea afectado el primario.

Si la vista sigue mostrando dispositivos separados o duplicados, comparar el estado HA local, ambos números de serie, el tenant, la aprobación de servicios y la Task Queue antes de cambiar el registro. Para revertir únicamente el cambio de gestión, restaurar los estados documentados de los servicios de Central y verificar el acceso local y el estado de HA. No disolver el par HA, volver a ejecutar el asistente de configuración ni forzar la baja mediante CLI para corregir la vista. Revertir la formación de HA requiere el plan de recuperación de HA aprobado por separado; los problemas de registro sin resolver o las dudas sobre qué nodos quedan afectados deben remitirse a Sophos Support con los estados recopilados.

Delimitar de forma segura un registro bloqueado

Con Approval Pending o Waiting for approval from Sophos Central, no se debe repetir el registro ni dar de baja el firewall precipitadamente. Primero se comprueban el tenant y el número de serie correctos, la aprobación por un Super admin del tenant correspondiente en My Products > Firewall Management > Firewalls, el acceso a Internet mediante IPv4, DNS, la hora y los servicios salientes necesarios. En HA deben constar ambos números de serie en Sophos Fusion y el OTP se introduce en el nodo primario. Si el estado sigue bloqueado tras corregir estos requisitos, se guardan capturas de ambas vistas de estado, la hora, los números de serie y los roles HA para Sophos Support.

Eliminar la configuración de Synchronized Security solo como operación aprobada por soporte. La documentación de Device Console para SFOS 22 y 23 describe system synchronized-security central_registration deregister para eliminar la configuración de Synchronized Security de Sophos Fusion o Sophos Central cuando bloquea el registro o la baja. El caso previsto aquí es un firewall existente cuyo registro sigue bloqueado por Synchronized Security después de las comprobaciones anteriores, con esa causa confirmada por Sophos Support. No es la baja completa del dispositivo mediante Deregister del apartado siguiente ni una limpieza de la base de datos interna mediante SQL. El comando modifica el estado; no es una prueba de diagnóstico de solo lectura ni una solución general para Approval Pending.

Antes de cualquier ejecución, documentar en el caso de soporte el tenant previsto y el actual, el dispositivo y su número de serie, la versión exacta de SFOS incluido el build, el estado de registro, los servicios de Central activos, Security Heartbeat, Synchronized Application Control y las reglas afectadas y su efecto actual. En HA, incluir ambos números de serie, los roles primario y auxiliar, el estado de sincronización y el alcance expresamente confirmado de los nodos afectados. Probar y mantener el acceso local autorizado a WebAdmin y a la consola, independiente de la vía de gestión de Central. Conservar una copia de seguridad local actual, su contraseña y la Secure Storage Master Key.

No ejecutar sin aprobación específica para el build. Sophos Support debe confirmar previamente que la eliminación de la configuración es adecuada para este caso, el impacto previsto sobre el registro, los servicios, el tráfico dependiente de Heartbeat y HA, y el procedimiento de recuperación, incluidos el registro y las aprobaciones de servicios que sean necesarios. La sintaxis documentada no garantiza que los servicios permanezcan intactos ni que se pueda restaurar de forma reversible el estado anterior; una copia de seguridad por sí sola tampoco demuestra esa vía de recuperación. Si el impacto, los nodos afectados o la recuperación no están claros, no ejecutar y mantener el caso con soporte. No sustituir la operación por cambios SQL ni por una baja completa forzada.

Tras una operación expresamente aprobada, verificar según el plan de soporte el registro en el tenant correcto y ambas vistas de estado, los servicios previstos y el acceso local independiente. Comprobar también Security Heartbeat con el endpoint piloto gestionado, el reconocimiento de aplicaciones cuando corresponda, el efecto de las reglas afectadas, el tráfico de producción, los logs y, en HA, los roles y la sincronización. Que el firewall vuelva a ser visible no basta para demostrar el éxito. Ante resultados inesperados, guardar el estado y seguir el plan de recuperación aprobado con Sophos Support, en lugar de repetir el comando.

Cambiar servicios de Central o dar de baja el firewall

Desactivar Security Heartbeat, Synchronized Application Control o Sophos Central management no elimina el registro en Central. Sin embargo, los servicios no son independientes: desactivar Security Heartbeat también desactiva Synchronized Application Control, y los endpoints y el firewall dejan de intercambiar información sobre su estado de salud. Por tanto, pausar Heartbeat afecta a más de un servicio.

Antes del cambio, se anotan en System > Sophos Central los estados previos de activación o desactivación tanto de Security Heartbeat como de Synchronized Application Control, además del estado del servicio afectado. Después se desactiva el servicio previsto, se guarda y se comprueban tanto los estados de los servicios afectados como que el firewall siga registrado.

Para revertirlo, se restaura el servicio afectado y ambos estados documentados, y un Super admin del tenant correspondiente acepta en Central cualquier nueva solicitud de aprobación. Se comprueban expresamente Security Heartbeat y Synchronized Application Control por separado, sin asumir que activar Heartbeat basta para restaurar ambos correctamente. Si Heartbeat estaba activo, se utiliza un endpoint piloto gestionado para comprobar el estado de salud actual y el contador Connected correspondiente en Control Center, como se describe arriba. Si Synchronized Application Control estaba activo, también se verifica el reconocimiento de aplicaciones en Applications > Synchronized Application Control con el endpoint piloto; Utilizar Application Control de forma específica explica el procedimiento de validación correspondiente.

La baja completa es un paso independiente que debe planificarse:

1. Crear una copia de seguridad local actual y conservar su contraseña y la Secure Storage Master Key. Documentar tenant, números de serie, servicios activos, grupos de firewalls, tareas pendientes, reporting y backups de Central. En HA, registrar ambos nodos y sus roles.
2. Probar el acceso WebAdmin local con una cuenta autorizada. Finalizar las tareas de Central pendientes o documentar su estado y elegir una ventana de mantenimiento. No usar los backups de Central como única vía de recuperación, pues se eliminan al retirar el firewall de Central Management.
3. En el firewall, abrir System > Sophos Central y elegir Deregister. No utilizar comandos no documentados de Device Console o Advanced Shell como atajo.
4. Comprobar localmente que el firewall ya no aparece administrado por Central. En My Products > Firewall Management > Firewalls, revisar el estado del objeto del dispositivo; un objeto restante no equivale a un registro operativo. Después, verificar acceso local, tráfico productivo, logging y, en HA, estado del clúster.

Para revertir el cambio, se registra de nuevo el firewall mediante el flujo normal de OTP o superadministrador, un Super admin del tenant correspondiente acepta los servicios necesarios en Central y se repiten las pruebas específicas de cada servicio. Si Deregister no está disponible, la baja queda bloqueada o el alcance HA no está claro, no se fuerza por CLI. Los estados guardados se entregan a Sophos Support.

Verificar después de la conexión

Después del registro, no solo se debe verificar si el firewall es visible en Sophos Fusion. Lo importante es si los servicios activados realmente funcionan y si las responsabilidades están claras.

Verificación posterior útil:

1. En Sophos Fusion, verificar si el modelo, el número de serie y el estado de la licencia se muestran correctamente.
2. En el firewall, bajo System > Sophos Central, verificar si los servicios deseados están activos y conectados.
3. Si se utiliza Manage from Sophos Central, abrir My Products > Firewall Management > Firewalls en Central y hacer clic en el nombre del firewall para abrir su consola WebAdmin. Esperar unos segundos y verificar el acceso con el rol de administrador previsto; mantener disponible la vía de administración local operativa durante la prueba.
4. Si la función de informes está activa, verificar en el Log Viewer y en Sophos Fusion si llegan eventos actuales.
5. Si las copias de seguridad en la nube están activas, configurar la copia de seguridad programada y documentar cuándo se realizó la última copia de seguridad correctamente.
6. Verificar alertas, roles y responsabilidades en Sophos Fusion.
7. Si se distribuyen cambios a través de Central, controlar la Central Firewall Management Task Queue.

Especialmente en el caso de varios firewalls, el registro debe incluirse en la documentación interna: tenant, número de serie, ubicación, servicios de Central activos, retención de informes, intervalo de copia de seguridad y persona responsable.

Validar los servicios de Central por separado

Después del registro no basta con comprobar el estado global de Central. Cada servicio tiene síntomas de error distintos y por eso debe validarse por separado.

• Registro e inventario: el firewall aparece en el tenant correcto, y el número de serie, modelo, licencia y ubicación son correctos.
• Manage from Sophos Central: el acceso mediante Central funciona con el rol de administrador previsto, sin dejar WebAdmin abierto innecesariamente desde WAN.
• Central Reporting: un evento provocado de forma consciente aparece en el Report Hub con el firewall, hora, ID de regla o tipo de log correctos.
• Copias de seguridad de Central: una copia programada o manual finaliza correctamente, y el intervalo, la contraseña y la Secure Storage Master Key están documentados.
• Retención de backups: se conocen las cinco copias de Central más recientes y una posible copia guardada permanentemente. En HA está claro que el Primary genera el backup.
• Alertas de backup: los backups de Central fallidos generan alertas y correos que revisa una persona responsable.
• Central Tasks: después de un cambio en Central, se revisa la Task Queue hasta que la tarea finaliza correctamente o el problema se remite al equipo responsable con la información necesaria.
• Security Heartbeat: Sophos Fusion muestra el estado esperado del endpoint piloto y el contador correspondiente de Control Center es coherente. Las restricciones basadas en reglas solo se prueban paso a paso después de establecer esta referencia.
• Alertas y responsabilidad: está claro quién revisa regularmente tareas fallidas, problemas de copia de seguridad, lagunas de reporting y avisos de licencia.

Esta separación evita un error operativo típico: un firewall puede ser visible en Sophos Fusion mientras el reporting, las copias de seguridad o las tareas de Central no funcionan correctamente.

Errores típicos

El firewall está registrado en la cuenta de Central incorrecta

Esto ocurre frecuentemente con cambios de proveedor, cuentas de prueba o múltiples cuentas históricas de SophosID. En este caso, no se debe intentar simplemente un segundo registro. Primero, aclarar dónde está registrado actualmente el firewall, quién tiene acceso al tenant y si es necesario transferirlo a otra cuenta.

Se confunde Central Management con WebAdmin local

Manage from Sophos Central es una vía de acceso adicional. La consola WebAdmin local, los usuarios administradores locales, MFA, Device Access y SSH siguen siendo controles de seguridad independientes. Es especialmente importante que WebAdmin no siga siendo accesible desde la WAN solo porque Central Management aún no se ha probado.

La vista de Central no se valida localmente

Para políticas de grupo, clústeres HA, reglas WAF y tareas de firmware, Central no debe tratarse como la única fuente de verdad. Central puede mostrar que un cambio está planificado, aplicado o visible. Lo decisivo es si el firewall afectado ha procesado el cambio y si el tráfico o servicio real funciona después.

En la práctica: después de cambios en Central, revisar la Task Queue, la vista local de WebAdmin, el Log Viewer y, si es necesario, el Audit Trail. Si la interfaz de Central se queda cargando, un par HA aparece duplicado o una regla de grupo no se puede mover, no necesariamente se trata de un problema con una regla de firewall.

El informe está activado, pero no llegan datos útiles

Entonces, primero se debe verificar si Send reports and logs to Sophos Central está activo, si los tipos de registros adecuados están activados y si el firewall puede alcanzar Central. Luego, en el artículo Activar Central Firewall Reporting, revisar los puntos detallados sobre selección de registros, retención e informes.

La copia de seguridad en la nube se entiende como la única copia de seguridad

Las copias de seguridad de Central son prácticas, pero no reemplazan una planificación completa de recuperación. Para ubicaciones críticas, también debe estar claro dónde se encuentran las copias de seguridad locales, quién conoce la contraseña de copia de seguridad, si la clave maestra de almacenamiento seguro está documentada y cómo se llevaría a cabo una restauración o reimagen.

Nadie revisa las tareas y alertas de Central

Central solo ayuda si se gestionan las notificaciones y tareas fallidas. Especialmente en políticas de grupo, tareas de firmware, informes y copias de seguridad, debe estar claro quién revisa las advertencias y cómo se escalan internamente los errores.

Preguntas frecuentes