Registro de Auditoría
Registro de Auditoría
Chinaski conserva varios trails uno junto al otro: un audit trail de quién cambió qué, un event log operativo, un log de autenticación, más build logs e historial de settings. Solo de admin en todos los casos, así que todo aquí es para los administradores del site.
El audit trail
Cada mutación de contenido (crear, actualizar o borrar páginas, posts, blocks, documentos, categorías, media, themes, usuarios, settings, forms, nav items y más) se registra con el actor (el usuario logueado), la acción, el tipo de entidad y ID, una breve línea de detalle y un timestamp. Las operaciones de backup (restore, push, errores) también aparecen allí.
Puedes navegarlo bajo la entrada de auditoría en el área de admin. Las entradas se paginan de cincuenta en cincuenta, y puedes hacer búsqueda de texto libre a través de detalles y nombres, o filtrar por actor, acción, tipo de entidad, ID de entidad o cualquier combinación. La página también muestra la antigüedad de la entrada más vieja, es decir, cuánto historial realmente tienes. Una exportación CSV descarga el conjunto filtrado actualmente.
Límites honestos: el audit trail registra qué pasó pero no es un vault a prueba de manipulación; es una tabla simple en la base de datos. El texto de detalle de más de 4000 caracteres se trunca.
El event log
Los mensajes operativos (advertencias, errores, notices) aterrizan en el event log. Se muestra en la página de Health en el área de admin, paginado de cincuenta en cincuenta con un filtro de nivel: advertencias más errores, o solo errores.
Siéntete libre de limpiarlo cuando se vuelva ruidoso: un control en la página de Health borra las entradas de más de 30 días por defecto, o todo si eliges. Limpiar el log se registra en sí mismo en el audit trail, así que la limpieza no es invisible.
Log de autenticación
El resultado de cada intento de login (éxito, fallo o bloqueado por cuenta suspendida o bloqueo de IP) se registra con el usuario, dirección IP y timestamp.
- Una vista por usuario (la login history de cualquier cuenta) vive en la página de cada usuario en el área de admin.
- La página de Health muestra las últimas 100 entradas de autenticación.
- Los fallos repetidos desde una IP disparan bloqueos escalonados: 60 segundos tras 5 fallos consecutivos, 5 minutos tras 10, y 30 minutos tras 20. Las tasas de fallo sostenidas levantan una alerta en el event log.
Retención
Las entradas viejas se podan automáticamente de forma continua, aproximadamente cada 15 minutos:
| Trail | Se conserva |
|---|---|
| Audit trail | las 50,000 entradas más nuevas |
| Log de autenticación | las 10,000 entradas más nuevas |
| Event log | las 5,000 entradas más nuevas |
| Settings revisions | los 50 snapshots más nuevos |
| Build log | los ~100 builds completados más nuevos |
Los tokens de reset de contraseña expiran después de 7 días, y las sesiones de usuario expiradas se limpian. Si necesitas que los registros sobrevivan a esa retención, usa la exportación CSV o un security log externo (abajo) antes de que las entradas rueden.
Historial de settings
Cada guardado en settings hace un snapshot de todas las settings no secretas a un historial de revisions antes de la escritura. Puedes revisar y restaurar desde los últimos snapshots en la pestaña Settings → History. Los valores secretos (contraseña SMTP, webhook secrets, SSO client secret, Turnstile key, Spaces secret) se excluyen de los snapshots: siempre se almacenan cifrados y nunca aparecen en el historial en texto plano.
Security log estructurado
Para fines forenses Chinaski también emite líneas JSON estructuradas para los eventos de seguridad de alta señal: login con éxito, fallo de login, bloqueo y suspensión de login, login SSO, limpiezas de sesiones obsoletas, rate-limiting de registro y hits de honeypot. Estos van a tu system journal (journald en una instalación systemd estándar, journalctl -u chinaski@1 para leerlos).
Si estableces el destino del security log (Settings → Security) a un path de archivo, esos eventos se agregan adicionalmente allí: JSON separado por saltos de línea, modo de archivo 0600, así que un registro sobrevive incluso si la base de datos misma se compromete. Apúntalo a una ubicación excluida de cualquier limpieza automatizada del directorio de la instancia si esa durabilidad te importa.