Cómo compartir un log sin filtrar datos personales

Qué viaja dentro de un log

Lo más repetido es la dirección IP de cada cliente, que va al principio de cada línea de un servidor web y en campos como client_ip o x-forwarded-for de un log estructurado. El Tribunal de Justicia de la Unión Europea consideró en la sentencia Breyer que una IP dinámica puede ser un dato personal para quien tiene medios legales de asociarla a una persona, así que lo prudente es tratarlas todas como tal.

Detrás vienen los correos y teléfonos que viajan en los parámetros de una URL o en el cuerpo de una petición, las cookies y los identificadores de sesión, los tokens de las cabeceras Authorization y de parámetros como token= o sid=, y las rutas con el nombre de usuario del equipo, como /home/ana o C:\Users\ana, que aparecen en cualquier traza de error. En un log en JSON, además, los nombres de las claves delatan qué hay en cada valor, con campos como email, phone, password o ip. Un identificador de sesión sin caducar vale tanto como una contraseña, porque basta para entrar en la cuenta mientras la sesión siga abierta.

Soporte, un foro o una IA: quién lo va a leer

El destino cambia cuánto dura el texto y cuánta gente lo ve. Un ticket de soporte queda en el sistema del proveedor y pasa por varias personas. Una incidencia en un repositorio público la indexan los buscadores y sigue ahí años después, aunque cierres el problema. Y lo que pegas en un asistente de IA sale a los servidores de otra empresa, con el plazo de conservación que diga su política, como contamos en la guía sobre subir documentos con datos a ChatGPT.

La pregunta útil en los tres casos es qué necesita ver quien lo recibe para ayudarte. Casi nunca son los valores. Necesita el orden de los hechos, las fechas, los códigos de estado, las rutas de la aplicación y los mensajes de error, y le basta con saber que dos líneas corresponden al mismo cliente, sin saber quién es.

Tapar sin que el log deje de servir

La técnica que conserva la utilidad es la seudonimización, que cambia cada valor por un marcador y da siempre el mismo marcador al mismo valor. Si la IP 203.0.113.24 aparece en cuarenta líneas, en todas pasa a ser [IP_1], y quien lee el log sigue viendo que es el mismo cliente el que repite la petición que falla. Tapar con bloques o con una palabra fija protege igual, pero borra esa relación. La diferencia entre las dos técnicas, y por qué la primera no convierte el log en anónimo, la explicamos en la guía sobre anonimización y seudonimización.

Hay que respetar además el formato. Si el log es JSON y quien lo recibe lo va a procesar con un programa, el resultado tiene que seguir siendo JSON válido, con el marcador dentro de las comillas del valor y sin tocar llaves ni comas. Un número tapado pasa a ser una cadena, y conviene saberlo si algún campo numérico se sustituye.

A mano se puede hacer con la búsqueda y sustitución de cualquier editor, con sed en la terminal o con jq para reescribir un campo concreto de cada objeto de un JSON. El riesgo está en lo que no se ve a la primera, como la IP repetida en un campo que no habías mirado o el token pegado al final de una URL.