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 en el formato de log común de los servidores web y en campos como client_ip o x-forwarded-for de un log estructurado. En la sentencia Breyer, dictada sobre la Directiva 95/46, anterior al RGPD, el Tribunal de Justicia de la Unión Europea consideró que una IP dinámica puede ser un dato personal para quien tiene medios legales de asociarla a alguien con la información adicional que guarda el proveedor de acceso a Internet de esa persona, y por eso en esta guía tapamos todas las IP.

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 muchas trazas de error. Están además los identificadores internos de usuario o de cliente, como un user_id o un número de pedido, que no dicen el nombre, pero quien tenga la base de datos llega con ellos a la persona. En un log en JSON, los nombres de las claves delatan también 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 puede pasar por varias personas. Una incidencia en un repositorio público puede acabar indexada en los buscadores y seguir visible 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 qué guarda una IA de los documentos que le subes.

La pregunta útil en los tres casos es qué necesita ver quien lo recibe para ayudarte. No suelen ser 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 oculta igual los valores y además no deja ver qué líneas son del mismo cliente, lo que protege algo más, pero le quita esa pista a quien te ayuda. 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. Un reemplazo fijo con sed, como cambiar cada IP por [IP], sirve para tapar, pero no numera, porque no distingue un valor de otro. Trabaja sobre un duplicado, ya que con la opción -i y sin sufijo sed sobrescribe el original sin dejar respaldo, y antes de enviar el log busca lo que se haya escapado, por ejemplo con grep -E y un patrón de IP o de correo.