Por qué la retención de logs no es un problema de IT sino de negocio
La mayoría de empresas descubre que necesitaba sus logs el día que recibe una demanda, una inspección regulatoria o una reclamación de un exempleado. Para entonces, los registros ya han sido rotados, sobrescritos o simplemente nunca se configuraron para conservarse. El departamento de IT asume que la retención de logs es un asunto técnico —espacio en disco, configuración de logrotate— pero en realidad es una decisión de negocio con consecuencias jurídicas directas.
Pensemos en un escenario común: un empleado filtra datos de clientes a la competencia. La empresa lo descubre seis meses después, cuando el competidor lanza un producto sospechosamente similar. El abogado solicita los logs de acceso a la base de datos de clientes para demostrar la exfiltración. Pero el servidor de base de datos tenía configurada una rotación de 30 días. Los logs desaparecieron hace cinco meses. Sin ellos, no hay forma de probar quién accedió a qué datos, cuándo ni desde dónde. El caso se desmorona antes de empezar.
El coste de retener logs es ridículo comparado con el coste de no tenerlos. Un año de logs de autenticación de una empresa mediana puede ocupar unos pocos gigabytes comprimidos. El almacenamiento en disco o en cloud de esos gigabytes cuesta céntimos al día. Un litigio perdido por falta de evidencia puede costar decenas o cientos de miles de euros, además del daño reputacional. La aritmética es clara: retener logs es el seguro más barato que puede contratar una empresa.
La decisión de cuánto tiempo conservar logs, qué sistemas monitorizar y dónde almacenar los registros no debería tomarla un administrador de sistemas en solitario. Es una decisión que implica a dirección, al departamento legal y al responsable de seguridad. Si tu empresa no tiene una política de retención de logs documentada y aprobada por dirección, tienes un riesgo no gestionado que puede materializarse en cualquier momento.
Marco legal: qué obliga la normativa española a conservar
En España no existe una ley única que diga «conserve sus logs X años». La obligación de retención se deriva de varias normativas que convergen, y la tensión entre ellas es lo que hace complejo el diseño de una política adecuada.
La LSSI (Ley 34/2002), en su artículo 12, obliga a los prestadores de servicios de la sociedad de la información a retener los datos de conexión y tráfico generados por las comunicaciones durante un período máximo de 12 meses. Esto aplica a cualquier empresa que ofrezca servicios online: desde un e-commerce hasta una plataforma SaaS. Los «datos de conexión» incluyen IPs de origen, timestamps de acceso y datos de sesión, que son precisamente los logs de servidor web y de autenticación.
El RGPD introduce el principio de minimización de datos (artículo 5.1.c): no conservar datos personales más tiempo del necesario para su finalidad. Pero el propio RGPD, en su artículo 17.3, reconoce excepciones a la supresión cuando el tratamiento es necesario para la formulación, el ejercicio o la defensa de reclamaciones. Aquí reside la tensión: minimización obliga a borrar, pero interés legítimo y defensa de reclamaciones justifica conservar. La clave está en documentar la justificación y aplicar medidas de seguridad proporcionales.
El Código de Comercio (artículo 30) obliga a conservar la documentación contable y empresarial durante 6 años desde el último asiento. Los registros de transacciones digitales, incluyendo logs de sistemas ERP y de facturación, entran en esta categoría cuando documentan operaciones mercantiles.
A esto se suman las normativas sectoriales: el sector financiero (directivas de la EBA, normativa del Banco de España) exige conservación de registros de operaciones entre 5 y 10 años. El sector sanitario tiene requisitos específicos para historiales clínicos electrónicos (mínimo 5 años tras el alta). Las empresas que operan en sectores regulados deben verificar sus obligaciones específicas, porque los plazos genéricos pueden ser insuficientes. Un perito informático judicial puede ayudar a identificar qué registros son exigibles en cada contexto.
Qué logs conservar: el mínimo viable por tipo de sistema
No todos los logs tienen el mismo valor probatorio. El objetivo no es conservar todo (inviable y contraproducente por el RGPD), sino identificar el mínimo conjunto de registros que permita reconstruir «quién hizo qué, cuándo y desde dónde» en caso de incidente o litigio. Este es el mínimo viable por tipo de sistema:
Autenticación (AD/LDAP/SSO)
Logins exitosos y fallidos, cambios de contraseña, bloqueos de cuenta, asignación y revocación de privilegios. Son la base para atribuir acciones a usuarios concretos.
Retención mínima: 24 meses
Acceso web y API
IP de origen, URL solicitada, método HTTP, código de respuesta, user-agent, timestamp. Imprescindibles para demostrar accesos indebidos, scraping o ataques de fuerza bruta.
Retención mínima: 12 meses
Auditoría de base de datos
Consultas ejecutadas (especialmente SELECT masivos, DELETE, DROP), usuario que las ejecutó, tablas afectadas. Cruciales en casos de robo de datos o manipulación de registros.
Retención mínima: 24 meses
Servidor de correo
Remitente, destinatario, timestamp, tamaño del mensaje, resultado de entrega. No el contenido del email, sino los metadatos de envío que prueban que una comunicación existió.
Retención mínima: 12 meses
Firewall e IDS/IPS
Conexiones permitidas y denegadas, alertas de intrusión, IPs de origen y destino, puertos, protocolos. Son la primera línea para detectar intrusiones y documentar ataques externos.
Retención mínima: 12 meses
VPN y acceso remoto
Conexiones entrantes, usuario autenticado, IP de origen, duración de la sesión, volumen de datos transferidos. Esenciales para demostrar accesos desde fuera de la red corporativa.
Retención mínima: 24 meses
Cloud provider (CloudTrail, Activity Log, Audit Logs)
Operaciones a nivel de infraestructura: creación/destrucción de recursos, cambios de permisos IAM, accesos a buckets de almacenamiento, modificaciones de configuración de red. Complementan pero no sustituyen los logs de aplicación.
Retención mínima: 12 meses (exportar a almacenamiento propio, no depender del periodo por defecto del proveedor)
Para una guía detallada sobre cómo analizar estos logs cuando llegan a un procedimiento judicial, consulta nuestra guía de análisis de logs de servidor para juicio.
Arquitectura de retención: centralizar, proteger e indexar
Tener los logs en el mismo servidor que los genera es como guardar el contrato en el edificio que está ardiendo. La primera regla de una arquitectura de retención seria es la separación: los logs deben copiarse a un sistema independiente donde el administrador del servidor de origen no tenga permisos de escritura ni borrado. Si el atacante (o el empleado desleal) compromete el servidor de producción, los logs ya están a salvo en otro sitio.
La solución más robusta es un SIEM (Security Information and Event Management), como Splunk, Elastic SIEM, QRadar o Wazuh. Un SIEM no solo almacena logs: los normaliza (convierte formatos diversos a un esquema común), los indexa (permite búsquedas rápidas sobre millones de registros) y los correlaciona (detecta patrones que un log individual no revela). Para empresas medianas y grandes, un SIEM es la inversión más rentable en capacidad forense preventiva.
Para empresas más pequeñas que no pueden justificar un SIEM, un stack ELK (Elasticsearch, Logstash, Kibana) o incluso un servidor dedicado con rsyslog y almacenamiento en disco protegido puede cumplir el mínimo viable. Lo esencial es que los logs se envíen en tiempo real al sistema centralizado (no mediante copias periódicas, que dejan ventanas sin cobertura) y que el almacenamiento sea de tipo WORM (Write Once Read Many) o equivalente: se pueden añadir registros pero no modificar ni borrar los existentes.
La verificación de integridad es el tercer pilar. Calcular hashes periódicos (por ejemplo, un hash SHA-256 diario del bloque de logs) y almacenar esos hashes en un sistema independiente (o incluso en un servicio de timestamping blockchain) permite demostrar a posteriori que los logs no han sido alterados. Cuando un perito tiene que defender la autenticidad de unos logs en juicio, la existencia de hashes verificables y una cadena de custodia documentada son lo que marca la diferencia entre una prueba sólida y una que se impugna con éxito.
Finalmente, hay que distinguir entre rotación de producción y retención. Que un servidor web rote sus access.log cada 7 días es correcto para no llenar el disco de producción. Pero esa rotación debe ir acompañada de un envío previo al sistema centralizado de retención. Si la rotación elimina logs sin que se hayan copiado, no hay retención: hay destrucción programada de evidencia potencial.
Errores que destruyen la capacidad de litigar
En mi experiencia como perito en análisis forense, estos son los errores más frecuentes que encuentro cuando una empresa necesita sus logs y descubre que no los tiene —o que los tiene de forma inútil:
Rotación por defecto sin backup
El sistema operativo o el servidor web viene configurado con una rotación de 7-30 días. Nadie la modifica. Nadie envía los logs a un sistema externo. Cuando los necesitan, solo quedan los últimos días. Es el error más común y el más fácil de evitar: basta con configurar el reenvío a un syslog centralizado.
Logs almacenados en el sistema investigado
Si los logs de un servidor están únicamente en ese servidor, cualquier persona con acceso root puede borrarlos o modificarlos. En un caso de acceso indebido, el primer acto del intruso suele ser limpiar los logs locales. Si no hay copia externa, la evidencia desaparece con un solo comando.
Sin normalización de zona horaria
Un servidor registra en UTC, otro en CET, el firewall en epoch Unix y la aplicación en hora local sin indicador de zona. Cuando hay que correlacionar eventos entre sistemas, los desfases horarios generan una cronología incoherente que un contra-peritaje explotará para sembrar dudas. La normalización debe configurarse en el momento de la ingesta, no cuando ya se necesita analizar.
Sobrescritura con nuevos despliegues
En entornos containerizados (Docker, Kubernetes), cada despliegue destruye el contenedor anterior junto con sus logs si no están externalizados. Un pipeline de CI/CD que hace deploy cada hora puede destruir 24 conjuntos de logs al día. Los logs de los contenedores deben redirigirse a un sistema externo antes de que el contenedor sea efímero.
No registrar nada (el peor de todos)
Aplicaciones que no generan logs de auditoría porque «nadie lo pidió en los requisitos». Bases de datos sin query log activado. Servidores sin audit policy configurada. Es el escenario más devastador: no se trata de que se perdieran los logs, es que nunca existieron. Cuando llega el litigio, no hay absolutamente nada que analizar.
Cómo implementar una política de retención en 5 pasos
Implementar una política de retención de logs no requiere un presupuesto millonario ni un equipo de seguridad dedicado. Requiere método y decisión. Estos cinco pasos son aplicables tanto a una PYME con un servidor como a una empresa con cientos de sistemas:
Paso 1: Inventario de fuentes de logs
Haz una lista completa de todos los sistemas que generan logs: servidores web, servidores de aplicación, bases de datos, directorio activo, firewall, VPN, proveedor cloud, correo electrónico, aplicaciones de negocio. Por cada sistema, documenta qué tipo de logs genera, en qué formato, dónde se almacenan y cuál es la rotación actual. Este inventario es la base de todo lo demás. Sin él, estás tomando decisiones a ciegas.
Paso 2: Clasificar por requisito legal y de negocio
No todos los logs necesitan el mismo periodo de retención. Clasifica cada fuente según la obligación legal que aplica (LSSI, RGPD, Código de Comercio, normativa sectorial) y el valor probatorio para el negocio (¿qué litigios son realistas para esta empresa?). Un e-commerce necesita priorizar logs de transacciones y acceso a datos de clientes. Una consultora, logs de acceso a propiedad intelectual y correo electrónico.
Paso 3: Definir periodos de retención
Para cada categoría de log, establece un periodo concreto de retención: 12 meses, 24 meses, 6 años. El periodo debe ser el máximo entre la obligación legal y la necesidad de negocio, pero no más (por minimización del RGPD). Documenta la justificación de cada periodo. Si mañana la AEPD pregunta por qué conservas IPs 24 meses, necesitas una respuesta razonada y documentada, no una improvisación.
Paso 4: Implementar almacenamiento centralizado
Configura el envío de logs en tiempo real desde cada fuente al sistema centralizado. Verifica que los logs llegan correctamente (monitoriza la ingesta). Protege el almacenamiento con control de acceso restrictivo, cifrado y, si es posible, almacenamiento WORM. Implementa hashing periódico de bloques de logs para verificación de integridad. Prueba que la búsqueda y recuperación funcionan: un almacenamiento donde no puedes encontrar lo que buscas es solo un disco lleno.
Paso 5: Probar recuperación y usabilidad forense
Al menos una vez al año, simula un escenario de necesidad: «Necesito los logs de acceso del usuario X entre el 1 y el 15 de marzo del año pasado.» Verifica que puedes recuperarlos, que son legibles, que los timestamps son coherentes y que contienen la información esperada. Si un perito informático no pudiera trabajar con esos logs en un caso real, la política de retención no está cumpliendo su función.
¿Necesitas diseñar una política de retención de logs?
Te ayudo a identificar qué logs necesita conservar tu empresa, durante cuánto tiempo y con qué arquitectura, para que el día que los necesites estén ahí.
Preguntas frecuentes
Depende del tipo de log y del sector. Como mínimo, la LSSI obliga a conservar datos de tráfico 12 meses si eres prestador de servicios de la sociedad de la información. El Código de Comercio exige conservar documentación contable 6 años. Para logs de autenticación y acceso, la recomendación práctica es un mínimo de 12-24 meses, ya que es el plazo en el que la mayoría de litigios tecnológicos se inician tras el descubrimiento de los hechos.
El RGPD establece el principio de minimización, pero también reconoce el interés legítimo como base legal para el tratamiento. Conservar logs con datos personales (IPs, identificadores de usuario) está justificado si es necesario para la seguridad del sistema, el cumplimiento legal o la defensa de reclamaciones. Lo que exige el RGPD es que documentes esa justificación en tu registro de actividades de tratamiento y apliques medidas de seguridad adecuadas.
La ausencia de logs debilita gravemente tu posición procesal. Si no puedes demostrar qué ocurrió en tus sistemas, no podrás acreditar hechos a tu favor ni refutar las alegaciones de la parte contraria. En algunos casos, la destrucción u omisión de registros puede generar presunciones desfavorables. El juez puede interpretar que la falta de evidencia perjudica a quien tenía la obligación o la capacidad de conservarla.
No. Un SIEM (Security Information and Event Management) es la solución más completa, pero no la única ni la obligatoria. Para empresas pequeñas, un sistema de reenvío de logs a un servidor centralizado con almacenamiento protegido puede ser suficiente. Lo esencial es que los logs se almacenen fuera del sistema que los genera, estén protegidos contra manipulación y sean recuperables cuando se necesiten.
No completamente. Los logs del proveedor cloud (CloudTrail, Activity Log) registran las operaciones a nivel de infraestructura, pero no capturan lo que ocurre dentro de tus aplicaciones ni a nivel de sistema operativo de tus instancias. Además, dependes de las políticas de retención del proveedor, que pueden ser más cortas que tus necesidades. Lo ideal es complementar los logs del cloud con tus propios logs de aplicación y exportar ambos a un almacenamiento que controles.
La integridad de los logs se demuestra mediante varias técnicas: almacenamiento WORM (Write Once Read Many), firma digital de cada entrada o bloque de logs, hashing periódico con timestamps verificables, y segregación de accesos para que los administradores del sistema no puedan modificar el almacenamiento de logs. Cuantas más capas de protección documentes, más difícil será que alguien cuestione su autenticidad en juicio.
Para una PYME, el coste de almacenamiento de logs es sorprendentemente bajo: los logs son texto comprimible y unos pocos GB cubren meses de actividad. Un stack open-source (rsyslog + almacenamiento en disco dedicado) puede costar menos de 50 €/mes. Soluciones SIEM cloud como Elastic o Datadog escalan desde unos cientos de euros mensuales. El coste de no tener logs cuando los necesitas (un litigio perdido, una sanción regulatoria) es órdenes de magnitud superior.
Depende de cómo se hizo la rotación. Si los logs se comprimieron y archivaron (la configuración habitual de logrotate), pueden recuperarse descomprimiéndolos. Si se eliminaron y el espacio fue sobrescrito, la recuperación es difícil o imposible. En entornos cloud, los logs purgados del servicio solo se recuperan si existían copias en backups, un SIEM o un bucket de almacenamiento secundario. Actuar rápido es clave.