Logging, evidencia y entrega a SIEM

​

Resumen

Zylon registra eventos estructurados de auditoria, seguridad, aplicacion y ciclo de vida de chats de IA cuando el almacenamiento o la entrega de logs estan habilitados. Los operadores pueden usar estos logs para investigar que ocurrio, quien lo inicio, que se solicito, que se respondio y que herramientas o rutas de datos observables se usaron. Zylon puede:

• Almacenar logs estructurados internamente cuando logging.storage.enabled esta habilitado.
• Enviar logs a SIEMs y colectores mediante syslog, incluidos RFC 5424 JSON y CEF.
• Enviar logs JSON estructurados a destinos HTTP.
• Permitir que usuarios autorizados de Backoffice recuperen logs almacenados manualmente.

El comportamiento predeterminado de almacenamiento de logs conserva los logs almacenados dentro del despliegue Zylon del cliente salvo que se configure entrega externa de logs. Los operadores deben confirmar por separado la configuracion especifica del despliegue para observabilidad, telemetria y crash reporting. La configuracion de entrega externa esta documentada en Configuracion: Entrega y almacenamiento de logs.

​

Antes de configurar la entrega

• Confirme que logs deben almacenarse en Zylon y que logs deben entregarse a sistemas controlados por el cliente.
• Confirme el host y puerto del colector syslog, o la URL del colector HTTP, desde la red del despliegue Zylon.
• Seleccione syslog rfc5424_json, syslog cef o HTTP canonical_json segun el input del colector.
• Decida si se requiere verificacion de certificados TLS y prepare una ruta CA confiable si hace falta.
• Decida la retencion en el almacenamiento interno de Zylon y en sistemas externos.
• Revise filtros de accion y organizacion para no excluir eventos de auditoria requeridos.
• Confirme que los nodos de Zylon usan una fuente horaria confiable como NTP. La correlacion forense depende de relojes sincronizados y revision en UTC.

​

Que registra Zylon

Zylon almacena un sobre de log compartido y datos estructurados especificos del evento. Los campos exactos dependen de la familia de evento y de los ajustes de logging habilitados.

Claves de request enmascaradas

Zylon enmascara estos nombres exactos de clave de request antes de almacenar: password, new_password, current_password, secret, api_key, apikey, private_key, privatekey, token, id_token, access_token, refresh_token, session_token, bearer_token, client_secret, secret_key, credentials, connection_string, cookie, set_cookie y authorization.Zylon tambien enmascara claves que terminan en _token, _password, _secret, _credential, _credentials, _connection_string o _cookie.

​

Confianza e integridad

Los logs almacenados deben tratarse como registros operativos con una superficie de recuperacion Backoffice de solo lectura:

• El acceso documentado a logs de Backoffice es solo para recuperacion.
• La recuperacion de logs mediante Backoffice tambien queda registrada, para que los operadores puedan revisar quien accedio a registros de plataforma o gateway.
• No hay flujo documentado de UI o API de Backoffice para que un operador modifique o borre un registro individual.
• La ruta documentada de borrado de logs almacenados es la limpieza de retencion configurada.
• La limpieza esta deshabilitada por defecto. Cuando se habilita, el umbral predeterminado es 180 dias.

Zylon no documenta una cadena criptografica de hashes, una cadena de firmas o un almacenamiento interno de logs con evidencia anti-manipulacion. Para mayor evidencia anti-manipulacion, entregue logs a un SIEM o archivo append-only controlado por el cliente, restrinja acceso de administradores de base de datos, conserve backups y monitorice auditoria de Kubernetes/base de datos. El acceso directo a base de datos por administradores de infraestructura queda fuera del modelo de permisos de Backoffice.

​

Administracion del sistema de logging

El almacenamiento, retencion y entrega de logs son configuracion del despliegue. Cambios como deshabilitar almacenamiento, reducir retencion o cambiar destinos de entrega deben capturarse en change management, historial GitOps, auditoria Kubernetes o logs de infraestructura del cliente.

​

Auditabilidad de IA

Zylon proporciona auditabilidad del ciclo de vida observable del chat y de acciones visibles para el agente. Los logs pueden ayudar a reconstruir:

• quien inicio un chat;
• que organizacion, gateway o proyecto participo;
• que metadatos de request se almacenaron;
• que respuesta se almaceno cuando auditoria la capturo;
• que herramientas fueron visibles en el payload de respuesta;
• que acciones, integraciones, archivos, chats y proyectos se usaron.

​

Logging y trazabilidad para EU AI Act

El logging de Zylon puede apoyar flujos de trazabilidad y record-keeping para EU AI Act, segun la configuracion y el despliegue. Debe tratarse como una fuente tecnica de evidencia dentro de un programa mas amplio de gobierno, monitoreo y retencion.

​

Mapeo de evidencia de control

Esta tabla ayuda en procurement y mapeo de evidencia de control; no es una declaracion de certificacion ni una afirmacion de cumplimiento. La aplicabilidad final depende del despliegue, politicas, procedimientos, monitoreo, retencion y caso de uso del cliente.

​

Almacenamiento y retencion de logs

Cuando el almacenamiento esta habilitado, Zylon persiste logs estructurados internamente. Cuando esta deshabilitado, los logs nuevos no se persisten internamente. Zylon puede limpiar logs almacenados tras una ventana configurada. La limpieza de logs almacenados esta deshabilitada por defecto. El valor predeterminado de retencion es 180 dias cuando la limpieza de logs esta habilitada. Los colectores externos mantienen sus propias politicas de retencion fuera de Zylon.

​

Derecho de supresion y retencion

Los logs de auditoria y seguridad pueden contener identificadores de usuario, cuenta, organizacion, IP, prompts, respuestas u otro contexto que puede ser dato personal segun el despliegue. Una solicitud de borrado de usuario no implica necesariamente borrado inmediato de todo registro historico de auditoria; muchos entornos regulados retienen logs de seguridad durante un periodo definido para preservar evidencia de fraude, abuso e incidentes. Configure retencion, filtros de entrega externa y retencion downstream segun base legal y politica de minimizacion. Si su politica exige pseudonimizacion o borrado anticipado de campos vinculados a usuarios, implemente esa obligacion en el colector/SIEM controlado por el cliente o valide el comportamiento de producto de la version desplegada.

​

Tiempo y marcadores de esquema

Los registros exponen timestamps ISO como start_timestamp y end_timestamp. Use UTC para investigaciones entre sistemas y mantenga todos los nodos de Zylon sincronizados con NTP o fuente horaria equivalente. Los payloads entregados incluyen marcadores de esquema como zylon.rfc5424_json.v1 y zylon.canonical_json.v1. Estos marcadores permiten que los parsers SIEM enruten e identifiquen formas de payload. No imponen por si mismos una politica de deprecacion o migracion; valide la compatibilidad de parsers al actualizar.

​

Formas de consumir logs

​

Recomendaciones operativas

• Mantenga el almacenamiento interno habilitado salvo aprobacion de seguridad, legal y operaciones.
• Entregue logs a un SIEM o colector controlado por el cliente cuando se requiera monitoreo o retencion independiente.
• Prefiera TLS para syslog cuando el colector lo soporte.
• Habilite verificacion de certificados en produccion cuando exista una ruta de confianza.
• Use filtros con cuidado para no excluir eventos necesarios para investigacion.
• Confirme retencion downstream por separado de la retencion interna de Zylon.
• Pruebe recuperacion y entrega despues de cambiar configuracion de logging.