La minimización de datos como disciplina de esquema y de registro

Qué es

La minimización de datos es el hábito de ingeniería de almacenar solo los datos personales que una funcionalidad necesita, con la precisión más gruesa que sirva al propósito, y no por más tiempo del que dure ese propósito. Se manifiesta en tres lugares: el esquema (qué columnas existen y con qué precisión), los registros (logs) (qué campos se emiten) y los almacenes derivados (analítica, índices de búsqueda, cachés) que copian de ambos. El NIST SP 800-122 plantea la tarea posterior como identificar la información de identificación personal (PII) en un sistema y decidir qué nivel de protección corresponde a cada instancia; la minimización es el paso previo, que evita crear esa instancia en absoluto. La hoja de referencia de registro (Logging Cheat Sheet) de OWASP enumera datos que no deberían registrarse directamente en los logs, sino eliminarse, enmascararse, aplicarles hash o cifrarse, entre ellos los valores de identificación de sesión, los tokens de acceso, las contraseñas, los datos de tarjetas de pago y los datos personales sensibles.

Por qué importa

Cada campo almacenado es un pasivo con costos permanentes: hay que protegerlo, exportarlo si se solicita, eliminarlo al final de su período de retención y explicarlo después de un incidente. Un campo que nunca se almacenó no cuesta nada. Los registros son la vía de fuga habitual porque los escribe cada capa, se copian a varios sistemas y los lee más gente de la que llega a la base de datos.

Cómo aplicarlo

• Preguntar por cada columna en la revisión del esquema: qué funcionalidad la lee, con qué precisión y durante cuánto tiempo. Almacenar el año de nacimiento cuando solo se usa un rango de edad, una región en lugar de una dirección completa, un booleano «tiene número de teléfono» cuando solo importa el hecho.
• Separar las columnas sensibles poco usadas en su propia tabla con acceso más restringido, de modo que las uniones (joins) habituales nunca las toquen.
• Registrar mediante lista de permitidos (allowlist): el ayudante de registro estructurado acepta campos nombrados y descarta todo lo demás; un mensaje de texto libre nunca recibe el cuerpo de una solicitud ni un objeto de usuario volcado con %r o JSON.stringify.
• Sustituir los identificadores en los registros por seudónimos estables (un hash con clave) donde se necesite correlación, y por nada donde no se necesite.
• Aplicar las mismas reglas a los almacenes derivados: el esquema de eventos de analítica enumera los campos permitidos y rechaza los desconocidos en la ingesta.
• Etiquetar las columnas y los campos de registro con una clasificación (personal, sensitive, none) en la definición del esquema, de modo que las herramientas posteriores de exportación, eliminación y revisión puedan encontrarlos.

Trampas

La minimización decidida en el momento del diseño se erosiona por el registro de depuración «temporal» que queda en su sitio, por columnas JSON que aceptan cualquier clave, y por SDK de terceros que recolectan por su cuenta. Los datos con precisión reducida aún pueden identificar en combinación (año de nacimiento más región más género); reducir la precisión es una reducción, no una anonimización. Un campo eliminado del esquema sigue existiendo en las copias de seguridad antiguas y en el archivo de registros hasta que estas caduquen.