Gestionar de forma segura las credenciales de API de Sophos Central
Sophos Central puede automatizarse mediante API y conectarse a plataformas SIEM, RMM, de reporting o de seguros. Para ello no se utilizan cuentas personales de administrador, sino API Credentials propias formadas por una Client ID y un Client Secret.
Estas credenciales son identidades de máquina. Quien posea un secreto puede ejecutar todas las acciones de API permitidas por el rol de Service Principal asignado. Por eso, un secreto debe tratarse como una contraseña privilegiada y no debe almacenarse en scripts, tickets, correos electrónicos ni repositorios Git.
Diferenciar API Credentials e Integration Credential Manager
En Global Settings > Access Control hay dos áreas con nombres similares:
| Área | Función |
|---|---|
| API Credentials | Identidad técnica con la que una aplicación llama a las API de Sophos Central |
| Integration Credential Manager | Credenciales de productos externos que Sophos utiliza para integraciones como Data Ingestion o Response Actions |
Para un script propio, una consulta SIEM o un cliente de API se crean API Credentials. En cambio, las credenciales de un producto externo que deba utilizar el propio Sophos Central pertenecen al Integration Credential Manager.
Requisitos y responsabilidad
Solo un Super Admin puede crear y administrar API Credentials. La aplicación posterior se autentica con independencia de ese administrador personal. Si se desactiva el administrador, la identidad técnica permanece hasta que caduque o se elimine.
Antes de crearla se documentan el propósito, el propietario, el sistema de destino, el rol necesario, la fecha de vencimiento y el contacto de emergencia. Se utiliza una credencial propia para cada aplicación y entorno. Un secreto compartido para el script de copia de seguridad, el SIEM y proveedores externos impide un bloqueo selectivo y dificulta el análisis de la causa.
Elegir el rol de Service Principal adecuado
Sophos ofrece varios roles:
- Service Principal Read-Only lee datos del tenant, pero no puede modificarlos ni ejecutar consultas de Live Discover.
- Service Principal Management puede consultar, crear, modificar y eliminar usuarios y grupos de usuarios; consultar y editar alertas; consultar endpoints y activar acciones como un análisis; además de ver y modificar configuraciones globales de Endpoint Protection. También administra administradores, roles y Security Policies, pero no tiene acceso a consultas de Live Discover.
- Service Principal Forensics crea, inicia y elimina consultas de Live Discover.
- Service Principal Active Directory Sync está previsto exclusivamente para la sincronización de AD y no puede ejecutar ninguna otra tarea de API.
- Service Principal Firewall limita la identidad a la administración del firewall y no permite tareas de la API de Central fuera de ella.
- Service Principal Super Admin posee amplios permisos de lectura, escritura y eliminación, además de acceso a consultas.
La selección siempre comienza por el rol más limitado. Una integración de reporting o de ciberseguro recibe Read-Only. AD Sync recibe el rol creado específicamente para ello. Super Admin solo se utiliza si los endpoints de API documentados necesitan realmente amplios permisos de escritura y no funciona ningún rol más restringido.
Crear una credencial
La ruta es Global Settings > Access Control > API Credentials. En el primer acceso deben aceptarse las condiciones de uso.
- Abrir Add Credential.
- Registrar un nombre inequívoco y una descripción con la aplicación, el entorno y el propietario.
- Seleccionar el rol de Service Principal mínimo necesario.
- Crear la credencial y copiar inmediatamente la Client ID y el Client Secret.
- Guardar el secreto en un almacén empresarial de secretos y vaciar el portapapeles temporal.
El Client Secret solo se muestra una vez. No se puede volver a visualizar más adelante. Si se pierde, no se recupera el secreto existente; se crea una credencial nueva y se elimina la antigua después de completar correctamente la migración.
Probar la autenticación de forma controlada
La primera prueba no consiste en una acción de escritura productiva. Primero se obtiene un OAuth Access Token mediante el endpoint de identidad de Sophos. Después, el endpoint whoami devuelve el Tenant ID, el host de API y el tipo de datos de la cuenta. Solo entonces se realiza una llamada de lectura no peligrosa al host de API proporcionado para el tenant.
El host de API no se copia de un ejemplo. Sophos opera varias regiones de datos, por lo que debe utilizarse la URL proporcionada por whoami. El Tenant ID y el Organization ID tampoco son intercambiables.
Para la prueba se documentan, como mínimo, estos casos:
- La autenticación con la nueva identidad funciona.
- Se devuelve el tenant esperado.
- Las operaciones de lectura permitidas funcionan.
- Una operación no permitida se rechaza con
403 Forbidden. - Los Audit Logs o registros de integración muestran la prueba de forma trazable.
Gestionar el vencimiento y la rotación
Sophos no envía ninguna advertencia cuando caduca una API Credential. Tras el vencimiento ya no puede utilizarse para autenticarse y Central la elimina automáticamente. Por tanto, la supervisión debe realizarse fuera de Central.
Un procedimiento de rotación correcto utiliza un solapamiento breve:
- Crear una nueva credencial con un rol idéntico o más restringido.
- Cambiar la aplicación a la Client ID y el secreto de la nueva credencial.
- Probar la autenticación y la función técnica.
- Eliminar la credencial antigua.
- Revisar el cambio en el Audit Log, el registro de secretos y la documentación operativa.
La credencial antigua no permanece activa durante meses por precaución. Si una aplicación solo admite un juego de secretos, se planifica una ventana de mantenimiento.
Sustituir los antiguos tokens de la API SIEM
API Token Management es el método de autenticación anterior para la SIEM Integration API. Sophos ya no emite allí tokens nuevos ni prolonga la vigencia de los existentes. Los tokens actuales solo funcionan hasta su vencimiento.
Por eso no se deja hasta el último día una integración que todavía los utilice. Se registran en un inventario el token, el sistema de destino, la fecha de vencimiento y los endpoints utilizados; se crea una API Credential adecuada, se migra la aplicación y se comprueba el flujo de datos completo. El token antiguo solo se elimina después de una comprobación paralela satisfactoria.
El cambio de un token heredado a API Credentials no es un simple cambio de nombre. La integración debe ser compatible con la autenticación OAuth, whoami, el host regional y el modelo de roles. Por eso, un conector SIEM se configura conforme a las instrucciones actuales de su fabricante, no con un ejemplo antiguo basado en tokens.
Proveedores externos y acceso de terceros
Para una entidad externa se crea una identidad Service Principal Read-Only propia si bastan permisos de lectura. La Client ID y el secreto se transmiten por un canal independiente y cifrado. Se fija una fecha de finalización para el acceso y se elimina al terminar el proyecto.
Este acceso de terceros puede leer mediante la API, en particular, Alerts and Events, resultados del Account Health Check, detalles de dispositivos y configuraciones de políticas. Read-Only impide añadir, modificar y eliminar contenido en Central, pero no limita automáticamente qué datos legibles consulta o almacena realmente la plataforma externa. Por eso, antes de habilitar el acceso se acuerdan contractualmente el alcance de los datos, su finalidad, el lugar de almacenamiento, la retención y la eliminación.
La creación sigue la ruta habitual Global Settings > Access Control > API Credentials > Add Credential. En el primer acceso se aceptan las condiciones de uso y protección de datos, se elige Service Principal Read-Only como rol y se copian de inmediato y de forma segura la Client ID y el Client Secret, que solo se muestra una vez. La transmisión se realiza por un canal cifrado autorizado, por ejemplo, el portal HTTPS del proveedor, no por correo electrónico ni en el texto de un ticket.
El host de API no se copia de una tabla regional estática. La aplicación determina mediante whoami el host de API válido para ese tenant concreto. De este modo, la integración sigue correctamente documentada aunque Sophos cambie regiones o endpoints. En cuanto el proveedor externo deje de necesitar acceso, se elimina la credencial; así se revoca de inmediato el permiso de API.
No es aceptable exportar la cuenta personal de Super Admin, utilizar una identidad de API compartida para varios clientes ni incluir un secreto en un ticket de soporte. El proveedor también debe indicar dónde se almacena el secreto, cómo se protege y cuándo se elimina.
Delimitar los errores de forma específica
401 Unauthorized
Por lo general, la Client ID, el secreto, el endpoint de token o la solicitud OAuth son incorrectos. Una credencial caducada y ya eliminada también produce este error. Primero se comprueba si la credencial sigue existiendo en Central y si la aplicación utiliza realmente el juego de secretos más reciente.
403 Forbidden
La autenticación se ha realizado correctamente, pero el rol no permite la acción. En lugar de asignar inmediatamente Super Admin, se relaciona el endpoint de API necesario con el rol de Service Principal apropiado.
Token correcto, región de datos incorrecta
El Access Token por sí solo no determina el host de API funcional. La aplicación debe utilizar el host regional proporcionado por whoami. Un host fijo de otra región provoca errores o consultas contra el límite de plataforma equivocado.
La integración falla sin advertencia
Si Central no muestra ninguna alerta abierta, se comprueban en el sistema de destino la fecha de vencimiento, la última llamada de API correcta y la versión del secreto. La supervisión del vencimiento forma parte del monitoring externo.
Revisión periódica
Al menos cada trimestre se revisan el nombre, el propietario, el rol, el último uso, el vencimiento y el sistema de destino de cada credencial. Las identidades que no puedan asignarse o no se utilicen se eliminan. Si se sospecha que un secreto se ha filtrado, la credencial se bloquea inmediatamente, se sustituye por una nueva y se examina el Audit Log en busca de acciones inusuales.
Los permisos personales de administrador se revisan por separado conforme a Asignar correctamente los roles de administración de Sophos Central. Las API Credentials no sustituyen ni MFA ni un acceso de administrador personal y trazable.