Registro de auditoría¶

El registro de auditoría responde a una sola pregunta: quién ha hecho esto. Cada cambio hecho a través del panel o de la API — un stream creado, una entrega retirada, un ajuste de una máquina modificado, un administrador añadido — deja en él un apunte con la hora, el autor y el nombre de la cosa que cambió. Allí van también los accesos al panel, los logrados y los fallidos.

Esto no son logs ni monitorización. Los logs responden a «qué ocurrió dentro del proceso»; el registro, a «qué hizo una persona». Por eso hay pocos apuntes, están hechos para leerse con los ojos, y el panel no puede borrarlos.

Agora se instala en el perímetro del cliente, y de las acciones de los operadores se ocupa el servicio de seguridad del propio cliente: el registro está pensado para él.

Quién ve el registro¶

La sección Registro de auditoría la ven dos roles:

• security — el rol de supervisión: el registro de auditoría y su propia cuenta (acceso, cambio de su propia contraseña, salida). Los ajustes, los streams y el estado observado le están cerrados por completo, incluida la lectura.
• superadmin — como todo lo demás del panel.

Los roles admin y viewer no tienen acceso: la supervisión de los operadores no pertenece a los propios operadores, y a un observador el registro le revelaría los logins de los administradores y las direcciones desde las que entran. La prohibición la sostiene el servidor, no la forma del menú: a un rol sin acceso se le rechaza también por enlace directo.

Los roles se asignan en la sección Cuentas. A la persona que vigila las acciones de los operadores se le crea una cuenta propia con el rol security, en vez de darle un superadmin.

Qué entra en el registro¶

Deja apunte un cambio que ocurrió de verdad y un acceso al panel:

• ediciones de ajustes — de un stream, una máquina, una plantilla, una zona de entrega, el acceso, la propia instalación de control;
• trabajo con las máquinas del clúster — registro, revocación, retirada, apertura y cierre de la ventana de incorporación;
• trabajo con cuentas — creación, edición, borrado, cambio de contraseña;
• trabajo con ficheros y trabajos de VOD;
• una ejecución manual de la colocación;
• el acceso de un administrador y un intento fallido de acceso.

Una operación masiva deja un apunte por cada objeto afectado, no uno por llamada: editar trescientos streams se ve como trescientos apuntes, y una búsqueda por nombre encuentra cualquiera de ellos.

Aparte queda la revelación de un token de acceso vigente: es una lectura, pero revelar un secreto equivale a entregarlo, así que el apunte se queda. El valor del token nunca entra en él.

Qué no lleva el registro¶

El registro calla sobre lo que no es acción de una persona:

• Intentos fallidos. Una negativa por permisos, una negativa de validación, un conflicto de versiones de documento: nada de eso es un cambio. Esos intentos se ven en los logs y en los contadores. Hay una excepción: el acceso fallido sí se apunta, porque adivinar contraseñas es justo lo que la supervisión persigue.
• Un repetido que no cambia nada. Guardar un documento idéntico al ya guardado no deja apunte.
• Las decisiones propias de la máquina. La colocación planificada de streams, las limpiezas por retención, el cambio de titular de un mandato pertenecen a los logs y al registro de decisiones de colocación, no a la auditoría. Una ejecución manual de la colocación sí se apunta: la lanzó una persona.
• El visionado. El registro va de gestión, no de espectadores: quién vio qué está en la sección Sesiones.
• La renovación y el cierre de sesión. Se apuntan el acceso y el intento fallido; renovar la sesión y salir, no.

En los apuntes nunca hay secretos: ni contraseñas, ni claves, ni tokens, ni documentos de ajustes completos. De una edición se apunta qué campos cambiaron, no qué se escribió en ellos.

La lista y sus columnas¶

Los apuntes van de los nuevos a los antiguos. El botón Mostrar más trae la siguiente página: la lista no se acaba en los primeros cincuenta apuntes.

La tabla tiene cinco columnas:

• Hora — el momento de la acción.
• Actor — quién actuó. Es o bien el login de un administrador, o bien uno de los tipos de servicio: clave estática (acceso con las credenciales de emergencia de /etc/agora/secrets.env, comunes a todos, por lo que no hay nombre detrás) y nodo (el registro de una máquina del clúster, donde el actor es su identificador).
• Acción — qué se hizo, con un nombre de máquina de la forma <recurso>.<verbo>: stream_config.put, node_config.patch, admin.create, auth.login. Los nombres son estables, y por eso resultan cómodos para buscar y filtrar.
• Recurso — sobre qué: tipo y nombre, por ejemplo stream/conference-a.
• Resultado — éxito en una acción que ocurrió y negativa en un acceso fallido.

La flecha a la izquierda de la fila despliega los detalles del apunte: la dirección desde la que llegó la petición, el rol del administrador, la versión del documento tras la edición, la lista de campos modificados y — si la petición llegó con una cabecera de trazado — su identificador, con el que el apunte se casa con los logs.

Buscar en el registro¶

Sobre la lista hay cinco campos, y trabajan juntos:

• Tipo de recurso y Nombre del recurso — «todo lo que se hizo con este stream».
• Actor — «todo lo que hizo esta persona».
• Desde y Hasta — una ventana de tiempo en formato RFC 3339, por ejemplo 2026-08-14T14:00:00Z.

El botón Aplicar relee la lista desde el principio. Un campo vacío significa «no filtrar».

Un incidente suele desmontarse en dos consultas: primero por recurso — qué le pasó a este stream —, después por el actor del apunte encontrado — qué más hizo esa misma persona aquel día.

Retención y protección¶

El registro vive en la misma base de datos que el resto del estado de la máquina y sobrevive a un reinicio del proceso. No crea ficheros en disco.

Los apuntes solo se añaden: editar o borrar un apunte suelto no existe ni en el panel ni en la API. La retención — siete días por defecto — la fija el ajuste de proceso audit_log_ttl_secs en /etc/agora/, y desde el panel no se puede cambiar. Está hecho a propósito: quien quiera esconder su acción no debe poder acortar la retención con el mismo acceso con el que la cometió. Un valor cero significa «guardarlo todo», no «borrarlo todo».

Frente a quien tenga acceso a la base de datos misma, el registro no da protección ni la promete.

Exportación a SIEM¶

Hacia fuera el registro se entrega de una única manera: leyéndolo. Agora no crea ficheros, sockets ni conexiones salientes a un colector.

Un colector externo lee GET /central/api-v4/audit-log con la misma autorización de operador que el resto de la API de gestión, y avanza por el registro con un cursor: en la respuesta hay un campo next, que se pasa como parámetro cursor en la petición siguiente. El orden es estable — de nuevos a antiguos — y cada evento tiene un identificador global derivado de la identidad de la instalación y del número de apunte. Por eso una página releída tras un corte da los mismos identificadores, y el colector descarta los duplicados por su cuenta; los eventos de dos instalaciones distintas no chocan entre sí.

Los filtros son los mismos que en el panel: resource_type, resource_name, actor, from, to, limit (hasta 1000 apuntes por página).

Como fichero listo en formato CEF, que un SIEM acepta sin adaptación, el registro se exporta con el botón Exportar a CEF sobre la lista y con una petición aparte a la API: véase Exportación a SIEM (CEF).

El registro y la licencia¶

El registro de auditoría es una opción de licencia aparte. Mientras no está concedida, no se apunta nada en absoluto, y la sección lo dice sin rodeos: la lista está vacía y sobre ella hay un mensaje de que el registro no entra en la licencia. Una lista vacía sin explicación sería indistinguible de «no hay nada en el registro», y una supervisión rota parecería una supervisión funcionando.

La opción se lee en cada petición, así que una vez concedida el registro empieza a funcionar sin reiniciar: las acciones nuevas se apuntan, la lista se abre. Lo ocurrido mientras la opción no estaba concedida no aparecerá: esos apuntes nunca se crearon.