El riesgo silencioso del RGPD en tu stack de logs
Actualizado para 2026
La mayoría de los equipos auditan su base de datos en busca de datos personales. Pocos aplican el mismo rigor a su sistema de logs.
El artículo 5, apartado 1, letra e) del RGPD limita el tiempo que puedes conservar datos personales. Para bases de datos, los equipos establecen políticas de retención y tareas de eliminación. Para archivos de log, la regla es más simple: conservar todo 90 días para depuración.
¿El problema? Esas entradas contienen datos personales. Las entradas de peticiones contienen emails de usuarios. Las capturas de errores contienen valores de entrada en bruto. Las entradas de acceso contienen direcciones IP. Cada uno de estos datos es información personal bajo el RGPD. Tu equipo necesita una base jurídica y un plan de retención para cada caso.
Qué termina en tus archivos de log
El logging estándar de aplicaciones web acumula una amplia gama de PII de distintas fuentes.
Entradas de acceso (nginx/Apache):
- Direcciones IP — datos personales según las directrices del CEPD
- Cadenas user-agent — pueden permitir la identificación de dispositivos
- Tokens de sesión — si se incluyen en la salida
Entradas de aplicación (JSON estructurado):
- IDs de usuario y direcciones de email
- Errores de validación — suelen incluir el valor inválido en bruto, que puede ser un dato real del usuario
- Eventos de negocio — IDs de pedidos vinculados a cuentas de cliente
- Consultas de búsqueda — pueden contener nombres o direcciones
Entradas de API gateway:
- Cabeceras de autorización — capturadas parcialmente en algunas configuraciones
- Parámetros de consulta — pueden llevar IDs de usuario, nombres o emails
- Cuerpos de petición y respuesta — presentes en configuraciones de nivel depuración
Entradas de auditoría de base de datos:
- Consultas SQL con cláusulas WHERE como
email = 'user@example.com' - Valores personales literales en parámetros de consulta
Esta acumulación no es intencional. Es un efecto secundario de prácticas de logging diseñadas para depuración, no para el RGPD.
Posición del CEPD sobre las direcciones IP
El Comité Europeo de Protección de Datos (CEPD) considera que las direcciones IP son datos personales. Los proveedores de acceso pueden vincularlas a sus suscriptores. Dentro de una organización, pueden identificar a usuarios concretos.
La implicación es directa. Las entradas de acceso con IPs son registros personales. Conservar la salida de nginx 12 meses significa conservar datos personales 12 meses. Eso requiere una base jurídica bajo el artículo 6. También requiere que el período de retención coincida con el propósito declarado.
La mayoría de los equipos omiten este análisis. "Guardamos entradas 90 días porque lo dice el equipo de seguridad" es una regla operativa. No es un análisis bajo el artículo 5, apartado 1, letra e). Consulta nuestra visión general de conformidad legal para el contexto completo.
El camino hacia el cumplimiento
La ruta práctica para la mayoría de los equipos no es reducir las ventanas de retención. Las justificaciones operativas y de seguridad para períodos más largos son reales. El mejor camino es enmascarar las entradas antes del almacenamiento a largo plazo.
Un modelo por niveles funciona bien.
0–7 días: Registros brutos completos para depuración activa. Siete días es suficientemente corto para la mayoría de los equipos.
7–90 días: Registros enmascarados para análisis de tendencias y monitorización de seguridad. Las IPs se reemplazan. Los emails de usuario se convierten en tokens estables. Los números de cuenta se enmascaran. Los campos técnicos — marcas de tiempo, códigos de error, latencia, endpoints — se conservan intactos.
90+ días (si es necesario): Solo salida agregada. Conteos de eventos, tasas de error, rangos de latencia. No quedan registros a nivel individual.
La retención de datos personales se detiene en siete días. La salida agregada puede conservarse sin exponer a nadie. Consulta Seguridad y Cumplimiento para más detalles.
Preservar la estructura JSON para la monitorización
Un buen enmascaramiento mantiene la estructura JSON intacta. Solo reemplaza el contenido. Esto mantiene la salida útil para depuración y alertas.
Conservado:
- Estructura JSON y nombres de claves
- Marcas de tiempo y secuencias temporales
- Tipos de errores y códigos de estado HTTP
- Métodos HTTP, rutas y valores de latencia
- Tipos de eventos de negocio
Reemplazado:
- Direcciones de email → token estable por original (p. ej.
user1@example.com) - Direcciones IP → rangos RFC 5737 (
192.0.2.x) - Números de cuenta →
ACCT_XXXXX - Números de teléfono →
+XX XXX XXX XXXX - Nombres en texto de error →
[PERSON]
Los tokens estables mantienen los traces útiles. Un trace para user1@example.com a lo largo de 40 entradas funciona igual que el original. Las métricas agregadas — tasas de error, latencia, throughput — no necesitan ningún dato personal. Consulta el Glosario para los términos seudonimización y anonimización.
Tres opciones de integración
Tres patrones cubren a la mayoría de los equipos de ingeniería.
Opción 1 — Enmascaramiento en el pipeline: Fluentd o Logstash intercepta cada línea antes de reenviarla. Un paso de enmascaramiento se ejecuta en línea. Elastic o Datadog recibe solo registros limpios. No se necesitan cambios en el código de la aplicación.
Opción 2 — Procesamiento por lotes nocturno: Los registros brutos se almacenan localmente. Un trabajo nocturno enmascara la salida del día anterior y elimina la versión bruta. Los registros enmascarados van al almacenamiento a largo plazo. La salida bruta se conserva solo siete días.
Opción 3 — Enmascaramiento previo al intercambio: Los registros brutos permanecen internos con controles de acceso estrictos. Antes de compartir con pen testers o contratistas externos, ejecuta un pase de enmascaramiento. Los terceros siempre reciben versiones limpias.
Para la documentación RGPD, el enmascaramiento es una "medida técnica" bajo el artículo 32. Registra la herramienta, su configuración y tu política de retención en el Registro de Actividades de Tratamiento (RAT) según el artículo 30. Consulta nuestro FAQ para preguntas frecuentes sobre el RAT.
¿Quieres ver un ejemplo real? Consulta los estudios de caso. También puedes revisar los precios para saber qué plan incluye pipelines de enmascaramiento integrados.
Fuentes
- RGPD Artículo 5: Principios relativos al tratamiento — VERIFIED-EXTERNAL
- Dictamen CEPD 5/2019 sobre la directiva ePrivacy y el RGPD — VERIFIED-EXTERNAL
- Sonra.io: Enmascaramiento PII en datos JSON y XML — VERIFIED-EXTERNAL