Seudonimizar y enmascarar en registros y pruebas

Enmascarar es ocultar parte de un dato al mostrarlo o al escribirlo (los primeros caracteres y asteriscos, los últimos cuatro dígitos). Seudonimizar es sustituir el identificador por otro valor de forma que, sin una información adicional guardada aparte, no se pueda saber a quién corresponde. Anonimizar es lograr que ya no se pueda volver a identificar a la persona por ningún medio razonable.

La diferencia importa porque un dato seudonimizado sigue siendo un dato personal: alguien con la información adicional (la tabla de correspondencias, la clave, o la posibilidad de recalcular el seudónimo) puede volver a la persona. Solo lo que de verdad se anonimizó sale del alcance de la ley. En revisión, la pregunta útil es siempre: ¿quién puede revertir esto y con qué?

El enmascarado de registros suele funcionar con una lista de nombres de campo: si la clave del evento coincide, se enmascara. El fallo típico es que la lista se escribió una vez y el código siguió creciendo: un evento nuevo usa una clave que nadie añadió, y el dato sale entero. Además, la lista protege datos del socio, pero a veces el registro contiene datos de otra persona que ni siquiera es usuaria de la aplicación.

Compara las claves que aparecen en app.log con la lista de enmascarar.

Usar una copia de producción para pruebas es cómodo y frecuente, y por eso se prepara con un guion que reemplaza los datos reales por valores ficticios. Ese guion es un control de privacidad: hay que leerlo columna por columna, porque basta una excepción «porque las pruebas la necesitan real» para que el entorno menos vigilado guarde datos de todos los socios.

Recorre el guion contra la lista de columnas de la tabla de socios, una por una.

El guion sustituye el número de documento por su resumen criptográfico sin ninguna clave. Parece irreversible, y para un valor aleatorio largo lo sería. Pero los números de documento son pocos y predecibles: cualquiera que tenga la copia puede calcular el resumen de todos los números posibles y encontrar a qué persona corresponde cada fila.

La corrección conserva la utilidad para las pruebas (un valor estable por socio) sin permitir el recálculo: un valor aleatorio con una tabla de correspondencias que no sale de producción, o una función con clave secreta que se guarda fuera del entorno de pruebas.

Lo que va en la URL de una petición no se queda en la aplicación: lo escriben los registros de acceso del servidor web, el balanceador, los proxies y, a veces, el historial del navegador. Esos registros rara vez pasan por la lista de enmascarado de la aplicación. Por eso un identificador personal nunca debería ir en la cadena de consulta: va en el cuerpo de una petición, o se sustituye por un identificador interno.

Busca en el registro de acceso un dato personal dentro de la URL.