Asegurar el acceso a la API XML de Sophos Firewall

La API XML de Sophos Firewall es útil para automatización, monitoreo, copias de seguridad, análisis e integraciones. Precisamente por eso, también forma parte de la superficie de ataque de gestión. Permitir acceso a la API otorga a un sistema la capacidad de leer datos de configuración o realizar cambios según los permisos.

Por lo tanto, el acceso a la API no debe permitirse ampliamente desde redes internas o fuentes arbitrarias. Es mejor tener un conjunto pequeño y documentado de redes de gestión, hosts de automatización o accesos de socios fijos.

Desde SFOS 22, Sophos ha ampliado el control de acceso a la API. Las configuraciones de acceso a la API se encuentran en el área de Administration, y las fuentes permitidas pueden definirse como hosts IP. Esto permite modelar no solo direcciones IP individuales, sino también rangos de IP y redes de manera ordenada.

Cuándo es útil el acceso a la API XML

La API XML no es un acceso estándar para el trabajo administrativo normal. Su uso es adecuado cuando hay un proceso técnico concreto detrás.

Casos de uso típicos:

• Monitoreo o inventario.
• Verificaciones de configuración automatizadas.
• Procesos de copia de seguridad o documentación.
• Plataformas MSP o de integración.
• Scripts para tareas administrativas recurrentes.
• Cambios preparados desde herramientas como Sophos Firewall Config Studio.

Si un proceso puede funcionar sin la API, no se debe dejar el acceso a la API activado por precaución. Cada interfaz adicional necesita un propietario, una fuente, un concepto de acceso y un control.

Cambios con SFOS 22

Con SFOS 22, el control de acceso a la API XML se ha vuelto mucho más manejable en operación:

• Las configuraciones de acceso a la API se han movido al menú Administration.
• El acceso a la API puede restringirse a hosts IP.
• Como fuentes, son posibles direcciones IP, rangos de IP y redes.
• Se pueden permitir hasta 64 hosts IP.
• Al actualizar, las direcciones IP permitidas anteriormente se convierten automáticamente en objetos de host IP.
• Los objetos migrados reciben el prefijo apiconfig.

Esto es útil en operación porque las fuentes de la API ya no tienen que mantenerse solo como direcciones individuales sueltas. Se puede nombrar de manera ordenada una red de gestión, un host de automatización o un grupo de hosts dedicado y reconocerlos en revisiones posteriores.

Regla básica: permitir API solo desde fuentes definidas

El acceso a la API debe tratarse con el mismo principio que WebAdmin o SSH: tan estrecho como sea posible, tan amplio como sea necesario.

Fuentes razonables son, por ejemplo:

• un servidor de automatización dedicado,
• un sistema de monitoreo,
• un host de gestión de configuración,
• una red de gestión interna,
• una red VPN o de administración,
• una dirección de origen de socio o MSP claramente definida.

No son razonables:

• redes de clientes completas,
• redes de invitados o IoT,
• Any,
• permisos vagos de “red de servidores completa”,
• direcciones IP de prueba temporales que luego se olvidan.

Si los proveedores externos necesitan acceso a la API, la fuente debe definirse de manera lo más específica posible. Además, debe documentarse para qué se utiliza el acceso y cuándo se eliminará.

Procedimiento recomendado

La ruta exacta de la interfaz de usuario puede variar ligeramente según la versión de SFOS. En SFOS 22, la configuración de la API se encuentra bajo Administration.

Procedimiento práctico:

1. Verificar qué sistema necesita acceso a la API.
2. Crear un objeto de host IP único para este sistema.
3. Si se necesitan varias fuentes, nombrar de manera ordenada los hosts IP o redes.
4. Permitir acceso a la API solo para estos objetos.
5. No ingresar redes de clientes o servidores amplias.
6. Probar el acceso con la herramienta afectada.
7. Eliminar fuentes que ya no se necesiten.
8. Documentar el cambio en el proceso de cambios.

En instalaciones existentes después de una actualización a SFOS 22, también se debe buscar objetos con el prefijo apiconfig. Estos objetos se generaron a partir de entradas de permiso de API anteriores y deben revisarse, nombrarse o limpiarse.

Acceso a la API y derechos de usuario

Una IP de origen por sí sola no es un concepto de seguridad completo. La restricción solo limita desde dónde es accesible la API. Además, debe estar claro con qué cuenta se realiza el acceso a la API y qué derechos tiene esa cuenta.

Para entornos productivos, se debe verificar:

• ¿Se utiliza una cuenta de servicio o API propia?
• ¿La cuenta solo tiene los permisos necesarios?
• ¿Está claramente documentado qué persona o equipo es responsable de la cuenta?
• ¿Se almacena la contraseña o secreto de manera segura?
• ¿Se elimina el acceso cuando la integración ya no se utiliza?
• ¿Son rastreables los cambios a través de registros de auditoría?

Las cuentas de administrador compartidas son problemáticas para los procesos de API. Si varios sistemas o personas utilizan la misma cuenta, la trazabilidad se debilita. Para los análisis de cambios, es relevante revisar los registros de auditoría de Sophos Firewall.

MFA y usuarios de API después de SFOS 22

MFA es importante para accesos administrativos interactivos. Sin embargo, para procesos de API y automatización, se debe planificar conscientemente cómo funcionará la autenticación. Un script, herramienta de monitoreo o sistema de integración no puede ingresar fácilmente un código OTP si el usuario utilizado impone MFA.

En la lista de problemas conocidos, se documenta un caso especial de SFOS 22: después de una actualización, los cambios de configuración basados en API pueden fallar para usuarios migrados si MFA está activo y no se proporciona un token de un solo uso. Los usuarios no migrados pueden comportarse de manera diferente en ciertos casos. Para la operación, es importante no hacer un “MFA desactivado en todas partes” desordenado, sino separar adecuadamente las cuentas de API.

Enfoque recomendado:

1. Utilizar una cuenta de servicio propia para procesos de API.
2. Equipar la cuenta solo con los derechos necesarios.
3. Limitar el acceso a la API adicionalmente a hosts IP fijos o redes de gestión.
4. Verificar si MFA es técnicamente y operativamente viable para esta cuenta.
5. Si MFA no es práctico para la cuenta de API, controlar especialmente de cerca la fuente, derechos, almacenamiento de secretos y registro de auditoría.
6. Después de una actualización a SFOS 22, probar todos los procesos de API con operaciones de lectura y escritura.

⚠️ Los usuarios de API sin MFA no son un pase libre para derechos amplios. Si una cuenta de API se opera sin MFA por razones técnicas, se deben controlar más estrictamente la IP de origen, los derechos, el almacenamiento de contraseñas, la responsabilidad y la auditabilidad.

Este punto es especialmente importante en automatizaciones que no solo leen, sino que cambian la configuración. Antes de cambios API productivos, debe haber una copia de seguridad actual de Sophos Firewall. En cambios masivos preparados desde Sophos Firewall Config Studio, también se debe verificar si las llamadas API o curl generadas funcionan con la cuenta planificada.

Distinción con Device Access

El control de acceso a la API no es lo mismo que Device Access. Device Access controla servicios locales de firewall como WebAdmin, SSH, User Portal, VPN Portal, DNS o Ping. Las configuraciones de acceso a la API controlan el acceso a la interfaz de gestión de la API XML.

Sin embargo, ambos temas pertenecen al endurecimiento de la gestión. Cada capa limita una parte diferente de la superficie de ataque:

Si una red de administración puede utilizar WebAdmin, SSH y API, esa red debe estar especialmente bien protegida. Un cliente comprometido en la red de gestión es de otro modo una entrada directa a la gestión del firewall.

Operación y revisión

El acceso a la API debe revisarse regularmente. Especialmente después de migraciones, cambios de proveedores, proyectos de automatización o actualizaciones de firewall, a menudo quedan fuentes antiguas.

Preguntas de revisión útiles:

• ¿Qué hosts IP pueden actualmente utilizar el acceso a la API?
• ¿Existen objetos con el prefijo apiconfig?
• ¿Son necesarios estos objetos?
• ¿Coinciden los nombres y descripciones con el propósito real?
• ¿Existen responsables documentados?
• ¿Se consideran los accesos a la API en un proceso de cambio o auditoría?
• ¿Existe una copia de seguridad actual antes de cambios importantes basados en API?

Antes de cambios basados en API, siempre debe haber una copia de seguridad. El artículo Crear o restaurar una copia de seguridad de Sophos Firewall describe en qué se debe prestar atención en cuanto a copia de seguridad, restauración y compatibilidad.

Errores típicos

Solución de problemas

Si una herramienta no alcanza la API XML, se debe verificar de manera estructurada:

1. ¿La IP de origen es correcta desde la perspectiva del firewall?
2. ¿La fuente está permitida como host IP, rango de IP o red?
3. ¿Se generó un objeto apiconfig después de una actualización, pero no se ajustó adecuadamente?
4. ¿La herramienta utiliza la dirección y puerto correctos del firewall?
5. ¿Son correctos el nombre de usuario, contraseña o secreto?
6. ¿La cuenta tiene los derechos necesarios?
7. ¿La cuenta impone MFA, aunque la herramienta no puede proporcionar un token de un solo uso?
8. ¿Existen efectos de enrutamiento, NAT o proxy entre la herramienta y el firewall?
9. ¿Se eliminó el acceso intencionalmente mediante una medida de endurecimiento?

Si un cambio en la API tiene efectos inesperados, primero asegure la última copia de seguridad y luego revise el registro de auditoría, la comparación de Config Studio y los objetos de firewall afectados. En problemas de tráfico en vivo, el Log Viewer y el Packet Capture son más útiles que la propia API.

Lista de verificación

Antes de la activación:

• Documentar el propósito del acceso a la API.
• Determinar claramente el sistema de origen.
• Crear un objeto de host IP con un nombre descriptivo.
• Verificar la cuenta de servicio y los permisos.
• Establecer conscientemente el comportamiento de MFA de la cuenta de API.
• Establecer un proceso de copia de seguridad y reversión.

Durante la operación:

• Permitir acceso a la API solo para fuentes definidas.
• No permitir redes amplias de clientes, invitados o IoT.
• Revisar objetos apiconfig después de actualizaciones.
• Controlar accesos de proveedores en términos de tiempo y función.
• Almacenar secretos de manera segura y renovarlos en caso de cambios de personal o herramientas.
• Probar operaciones de lectura y escritura de API después de actualizaciones de SFOS.

Durante la revisión:

• Revisar regularmente las fuentes de API permitidas.
• Eliminar hosts IP que ya no se necesiten.
• Comparar cambios con el registro de auditoría y tickets de cambio.
• Probar procesos de automatización después de actualizaciones de firmware.

FAQ