Tema: privacy-engineering
-
Tratar una solicitud de titular de datos como un proceso de ingeniería: exportar y eliminar
Tratar la solicitud de una persona de obtener una copia o la eliminación de sus datos como un trabajo: recepción verificada, un exportador por cada almacén del mapa de datos que produce un manifiesto, entrega mediante una descarga autenticada que caduca, eliminación a través del pipeline, exenciones enumeradas con códigos de motivo y una prueba con un sujeto sintético con una periodicidad fija; qué solicitudes deben atenderse y cuándo no se aborda aquí.
-
La privacidad diferencial en un párrafo, y dónde no encaja
La privacidad diferencial acota cuánto puede cambiar el registro de una sola persona la distribución de salida de un mecanismo de consulta, añadiendo ruido calibrado y cargando cada respuesta a un presupuesto; encaja en las publicaciones agregadas repetidas sobre poblaciones grandes y no encaja en datos a nivel de registro, grupos pequeños, operaciones exactas o análisis internos puntuales.
-
Lista de comprobación de revisión de privacidad para una funcionalidad
Diez preguntas que quien revisa responde antes de publicar una funcionalidad: inventario de los datos personales nuevos, decisiones de minimización, tarea de retención, acceso y registro de acceso, cobertura de exportación y eliminación, finalidades de preferencia, flujos con terceros, una pasada breve de LINDDUN, datos de prueba y un resultado registrado; solo propiedades de ingeniería, sin evaluación jurídica.
-
Datos de prueba sin datos personales de producción
Dar a desarrollo, CI y staging datos realistas generándolos: clasificar las columnas, escribir generadores con semilla que pasen los validadores de la aplicación, producir volumen con generate_series, copiar de producción solo las distribuciones, marcar los registros generados de forma reconocible, y eliminar el atajo de volcar producción.
-
Registros de consentimiento y preferencias como datos: qué se eligió, cuándo y a través de qué superficie
Modelar las elecciones de una persona como eventos de solo anexado (sujeto, propósito, elección, momento, fuente, versión del texto) con una vista de estado actual derivada que cada consumidor lee en el punto de uso; un booleano en la fila del usuario no puede responder qué se acordó en el momento de una acción dada, ni a qué usuarios afectó un error del banner.
-
Registros de acceso a datos personales: registrar quién leyó qué registro
Un registro de acceso para datos personales registra las lecturas, no solo las escrituras: actor, sujeto, objeto, motivo y momento, emitido en la ruta de lectura de la aplicación y conciliado con el registro de sentencias a nivel de base de datos para las rutas que lo eluden; debe responder preguntas centradas en el sujeto, como quién consultó el registro de esta persona en el último año.
-
Hacer visibles al equipo las lecturas de las tablas de datos personales reduce las consultas amplias sobre esas tablas
Hipótesis: una vez que se registra cada sentencia dirigida a las tablas que contienen datos personales (log_statement de PostgreSQL controla qué sentencias SQL se registran) y el registro se muestra al equipo en un resumen semanal, la proporción de lecturas amplias (sin predicado sobre un identificador de persona, o con una lista de columnas mediante comodín) disminuye, mientras que el número de lecturas legítimas y acotadas se mantiene igual; se propone una prueba de antes y después, sin afirmar ningún resultado.
-
La minimización de datos como disciplina de esquema y de registro
Almacenar solo los datos personales que una funcionalidad necesita, con la precisión más gruesa que la sirva, y mantener los identificadores fuera de los registros (logs) mediante listas de permitidos (allowlist) de campos; cada columna, campo de registro y almacén derivado que contenga datos personales es una decisión de diseño con un propósito, una persona responsable y una caducidad, no un valor por defecto.
-
Implementación de un calendario de retención como trabajos de eliminación
Un calendario de retención solo es real cuando cada clase de datos cuenta con un mecanismo que elimina a tiempo: eliminación de particiones para tablas particionadas por tiempo, reglas de ciclo de vida para el almacenamiento de objetos, trabajos DELETE idempotentes por lotes en el resto de los casos, cada uno con una métrica de la antigüedad del registro restante más antiguo y una alerta cuando esa antigüedad supera el período.
-
¿Cómo verifican los equipos que una eliminación borró todas las copias de los datos de una persona y qué encontró la verificación?
Pregunta abierta: que un trabajo de eliminación informe «hecho» no equivale a que los datos hayan desaparecido (versiones muertas de filas antes de VACUUM, versiones de objetos, cachés, índices, copias analíticas, copias de seguridad, logs, terceros). ¿Qué equipos verifican de extremo a extremo, con qué método y qué almacenes seguían conteniendo datos tras una eliminación completada?
-
Seudonimización frente a anonimización como técnicas de ingeniería
La seudonimización sustituye los identificadores directos por tokens y conserva una vía de retorno (una clave o una tabla de correspondencias), de modo que sigue habiendo un registro por persona; la anonimización busca eliminar para cualquiera la asociación entre registros y personas. Para los seudónimos conviene usar HMAC con clave por finalidad, y tratar una tabla seudonimizada como datos personales, ya que conserva cuasi-identificadores.
-
Modelado de amenazas de privacidad con LINDDUN: resumen del método
Recorra un diagrama de flujo de datos elemento por elemento con los siete tipos de amenaza de LINDDUN (vinculación, identificación, no repudio, detección, divulgación de datos, desconocimiento e imposibilidad de intervenir, incumplimiento), registre escenarios por elemento y elija mitigaciones de un menú breve; formato de una sola sesión basado en una sesión STRIDE.
-
Pipelines de eliminación de datos entre servicios, almacenes derivados y copias de seguridad
Modela la eliminación de los datos de una persona como un trabajo con un estado por cada almacén del mapa de datos: difunde un evento, exige que cada servicio responsable informe de su finalización con recuentos, trata de forma explícita el almacenamiento de objetos con versiones y los almacenes derivados, limita el tiempo de retención en las copias de seguridad o destruye claves por titular, y mantiene una lista de supresión para repetir la eliminación tras una restauración.
Legible por máquina: JSON