Registro de auditoría¶

El registro de auditoría responde a una sola pregunta: quién hizo esto. Cada cambio realizado desde el panel o por la API — un stream creado, una entrega retirada, los ajustes de una máquina modificados, un administrador dado de alta — deja una anotación con la hora, el autor y el nombre de lo que cambió. Allí van también los inicios de sesión en el panel, los correctos y los fallidos.

Esto no son los logs ni la monitorización. Los logs responden a «qué ocurrió dentro del proceso»; el diario responde a «qué hizo una persona». Por eso hay pocas anotaciones, se leen a simple vista y el panel no puede borrarlas.

Quién ve el diario¶

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 (entrar, cambiar su contraseña, salir). Los ajustes, los streams y el estado observado le están cerrados por completo, incluida la lectura.
• superadmin — como todo lo demás en el panel.

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

Los roles se asignan en la sección Cuentas. A quien vigila lo que hacen los operadores se le crea una cuenta propia con el rol security, en lugar de darle un superadministrador.

Qué entra en el diario¶

Deja anotación un cambio que llegó a producirse y el inicio de sesión:

• la edición de ajustes — de un stream, de una máquina, de una plantilla, de una fuente de la guía, del acceso, de la propia instalación de control;
• el trabajo con las máquinas del clúster — registro, revocación, eliminación, apertura y cierre de la ventana de unión;
• el trabajo con las cuentas — creación, edición, eliminación, cambio de contraseña;
• la migración de ajustes desde Flussonic v3 — tanto la construcción del plan como su aplicación;
• la ejecución manual de la asignación;
• el inicio de sesión de un administrador y el intento fallido;
• el trabajo con el registro de clientes — crear, editar y eliminar un cliente, vincular y desvincular una cuenta.

Una operación masiva deja una anotación por cada objeto afectado, no una por llamada: migrar trescientos streams se ve como trescientas anotaciones, y la búsqueda por nombre encuentra cualquiera de ellas.

Aparte queda la revelación de un token de unión vigente: es una lectura, pero revelar un secreto equivale a entregarlo, así que la anotación se mantiene. El valor del token nunca entra en ella.

Qué no hay en el diario¶

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

• Los intentos fallidos. Un rechazo por permisos, un rechazo de validación, un conflicto de versión del documento no son un cambio. Esos intentos se ven en los logs y en los contadores. Hay una excepción: el inicio de sesión fallido sí se anota, porque adivinar contraseñas es justamente lo que la supervisión vigila.
• La repetición sin cambio. Guardar un documento idéntico al ya guardado no deja anotación.
• Las decisiones propias de la máquina. La asignación programada de los streams, las limpiezas por retención, el cambio de titular del mandato pertenecen a los logs y al diario de decisiones de asignación, no a la auditoría. La ejecución manual de la asignación sí se anota: la hizo una persona.
• La renovación de sesión y la salida. Se anotan el inicio de sesión y el intento fallido; renovar la sesión y salir, no.

En las anotaciones nunca hay secretos: ni contraseñas, ni claves, ni tokens, ni documentos de ajustes completos. De una edición se anota qué campos se tocaron, no lo que se escribió en ellos.

El listado y sus columnas¶

Las anotaciones van de las nuevas a las antiguas. El botón Cargar más trae la siguiente página: el listado no termina en las primeras cincuenta anotaciones.

La tabla tiene cinco columnas:

• Hora — el momento de la acción.
• Actor — quién actuó. O bien el usuario de un administrador, o bien uno de los tipos de servicio: clave estática (entrada con las credenciales de emergencia de /etc/mcaster/secrets.env, comunes a todos y por eso sin 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, lo que resulta cómodo para buscar y filtrar.
• Recurso — sobre qué: tipo y nombre, por ejemplo stream/program-a.
• Resultado — éxito en una acción consumada y fallo en un inicio de sesión fallido.

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

Búsqueda en el diario¶

Sobre el listado hay cinco campos que funcionan en conjunto:

• 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.

Aplicar vuelve a leer el listado desde el principio. Un campo vacío significa «no filtrar».

Un incidente suele analizarse en dos consultas: primero por recurso — qué le pasó a este stream — y después por el actor de la anotación encontrada — qué más hizo esa misma persona ese día.

Conservación y protección¶

El diario vive en la misma base de datos que el resto del estado de la máquina y sobrevive al reinicio del proceso. No crea archivos en disco.

Las anotaciones solo se añaden: editar o borrar una anotación concreta 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/mcaster/, y desde el panel no se puede cambiar. Es deliberado: quien quiera esconder su acción no debe poder acortar la retención con el mismo acceso con el que la cometió. El valor cero significa «conservarlo todo», no «borrarlo todo».

Frente a quien tiene acceso a la propia base de datos el diario no ofrece protección ni la promete.

Exportación a un SIEM¶

Hacia fuera el diario se entrega de una sola manera: por lectura. Mcaster no abre archivos, ni sockets, ni conexiones salientes hacia un receptor.

Un recolector 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 sigue el diario por cursor: la respuesta trae el campo next, que se pasa como parámetro cursor en la petición siguiente. El orden es estable — de las nuevas a las antiguas — y cada evento tiene un identificador global derivado de la identidad de la instalación y del número de anotación. Por eso una página releída tras un corte devuelve los mismos identificadores y el receptor descarta los duplicados por sí solo; los eventos de dos instalaciones distintas nunca coinciden.

Los filtros son los del panel: resource_type, resource_name, actor, from, to, limit (hasta 1000 anotaciones por página).

El diario y la licencia¶

El registro de auditoría es una opción de licencia aparte. Mientras no está concedida no se graba nada, y la sección lo dice sin rodeos: el listado está vacío y sobre él hay un mensaje que indica que el diario no está incluido en la licencia. Un listado vacío sin explicación sería indistinguible de «no hay nada en el diario», y una supervisión rota parecería una supervisión que funciona.

La opción se lee en cada petición, así que en cuanto se concede el diario empieza a funcionar sin reiniciar: las nuevas acciones se graban y el listado se abre. Lo ocurrido mientras la opción no estaba concedida no aparecerá: esas anotaciones nunca se crearon.