Cuando una aplicación web muestra una página en blanco o un servidor rechaza una conexión, lo primero que hace un administrador es abrir un archivo. Este archivo es un log. Contiene el rastro con fecha y hora de cada evento ocurrido en el sistema: una solicitud recibida, un error desencadenado, un usuario autenticado. Entender los logs en informática es tener un hilo conductor para rastrear el origen de un problema, verificar que un servicio funciona o detectar un comportamiento anormal.
Lo que realmente contiene un log y por qué el formato lo cambia todo
Un log es un registro de eventos. Cada línea asocia, como mínimo, una fecha, una fuente y un mensaje. En un servidor web, por ejemplo, cada visita genera una línea que especifica la dirección IP del visitante, la página solicitada, el código de respuesta HTTP y el tiempo de procesamiento.
¿Alguna vez has abierto un archivo de texto lleno de líneas incomprensibles? A menudo es un log no estructurado. El mensaje está redactado en texto libre, sin un formato fijo. Cada aplicación escribe a su manera, lo que hace que la búsqueda sea penosa en cuanto varios servicios coexisten.
En cambio, un log estructurado en JSON organiza cada campo de manera legible por una máquina. La fecha, el nivel de severidad, el servicio involucrado y el mensaje ocupan cada uno un campo dedicado. La ganancia es directa: una herramienta de análisis puede filtrar, clasificar y cruzar miles de eventos en pocos segundos en lugar de buscar un patrón en texto plano.
Para saber todo sobre los logs en informática, la distinción entre formato estructurado y no estructurado es el primer concepto a dominar, porque condiciona lo que sigue: recolección, almacenamiento, análisis.
Niveles de severidad de los logs: leer la señal correcta en el momento adecuado
No todos los eventos registrados tienen la misma gravedad. Los frameworks de registro utilizan una escala de severidad que permite filtrar lo que merece atención inmediata.
- DEBUG: detalles finos utilizados durante el desarrollo, desactivados en producción para evitar un volumen excesivo.
- INFO: eventos normales que confirman el buen funcionamiento (inicio de un servicio, conexión exitosa).
- WARN: situación inusual que no impide el funcionamiento pero señala un riesgo (espacio en disco bajo, alta latencia).
- ERROR: un procesamiento ha fallado, una acción del usuario no ha tenido éxito. A menudo se requiere intervención.
- FATAL: el servicio se detiene. Toda la aplicación o el servidor está fuera de línea.
La tentación frecuente es pasar todo a DEBUG para “no perderse nada”. El resultado: archivos que crecen varios gigabytes por día, un costo de almacenamiento que explota y un ruido permanente que ahoga las verdaderas alertas. Elegir el nivel de severidad correcto reduce el volumen sin perder información útil.
Datos sensibles en los logs: lo que nunca se debe registrar
Un log puede capturar casi todo lo que transita en una aplicación. Ese es precisamente el problema. OWASP recomienda excluir de los registros las contraseñas, los tokens de acceso, los identificadores de sesión, las claves de cifrado y los datos personales sensibles.
¿Por qué esta precaución? Porque los logs mismos pueden convertirse en una fuente de fuga de datos. Un archivo log almacenado sin restricciones de acceso expone información que puede ser explotada por un atacante. Cuando es necesario un seguimiento, la buena práctica es enmascarar o seudonimizar los valores sensibles antes de escribir en el registro.
La CNIL proporciona una referencia para los rastros de acceso y acciones de los usuarios: una conservación de seis meses a un año según la finalidad. Más allá, el contenido recolectado debe seguir siendo proporcional a la necesidad real. Conservar solicitudes completas durante varios años sin una justificación definida expone a un riesgo jurídico tanto como técnico.
Proteger la integridad de los registros
Un log modificado o eliminado pierde toda su valor probatorio. OWASP recomienda controles de integridad, acceso restringido y monitoreado, así como proteger los datos de log. Un registro útil para una investigación también debe ser confiable. Un atacante que accede a un servidor a menudo intentará borrar sus huellas en los logs antes de cualquier otra acción.
Regulación europea y registro: obligaciones concretas
La registro ya no es solo una buena práctica técnica. La Ley de Ciberresiliencia europea incluye el registro de eventos de seguridad entre los requisitos aplicables a los productos digitales. La directiva NIS 2, por su parte, impone a las entidades correspondientes establecer capacidades de detección y respuesta a incidentes, lo que supone un sistema de logs funcional y utilizable.
Sin un registro confiable, la conformidad con NIS 2 o CRA se vuelve imposible de demostrar. Estos textos no detallan qué herramienta utilizar, pero exigen la capacidad de rastrear, detectar y responder. Los logs son la base técnica de esta capacidad.
Buenas prácticas de gestión de logs en el día a día
Implementar logs no es suficiente. Su utilidad depende de cómo se recojan, centralicen y utilicen.
- Centralizar los registros de todos los servicios en una plataforma única evita buscar manualmente en cada servidor. Un recolector recupera los eventos y los envía a un punto de análisis común.
- Definir una política de retención adecuada para cada tipo de log. Los rastros de acceso de usuario no tienen la misma duración de conservación útil que los logs de diagnóstico de aplicaciones.
- Establecer alertas sobre los niveles ERROR y FATAL para reaccionar antes de que los usuarios informen del problema.
- Revisar regularmente lo que se registra. Un campo agregado durante un desarrollo rápido puede contener datos personales sin que nadie lo haya previsto.
El valor de un sistema de logs se mide por la velocidad de resolución de un incidente. Un registro bien estructurado, centralizado y depurado según reglas claras transforma una falla de varias horas en un diagnóstico de unos minutos. Eso es lo que separa a un equipo que sufre los incidentes de un equipo que los anticipa.
