Capítulo 14 — Fundamentos de privacidad

Mapa de la lección

Lección 14 publicada. Mapa, ejemplo, EX027.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["14.1 La seguridad no es privacidad"]
  N2["14.2 Principios"]
  N3["14.3 Datos personales en lugares inesperados"]
  N4["14.4 La privacidad en las operaciones de seguridad"]
  N5["14.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX027"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["14.1 La seguridad no es privacidad"]
  N2["14.2 Principios"]
  N3["14.3 Datos personales en lugares inesperados"]
  N4["14.4 La privacidad en las operaciones de seguridad"]
  N5["14.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX027"]

[Resultados de aprendizaje y conexión]
    |
    v
[14.1 La seguridad no es privacidad]
    |
    v
[14.2 Principios]
    |
    v
[14.3 Datos personales en lugares inesperados]
    |
    v
[14.4 La privacidad en las operaciones de seguridad]
    |
    v
[14.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX027]

Resultados de aprendizaje y conexión

Después de este capítulo usted podrá (1) explicar la diferencia entre seguridad y privacidad; (2) aplicar principios de protección de datos como la licitud, la limitación de la finalidad, la minimización y la limitación del plazo de conservación; (3) identificar datos personales en los sistemas de los servicios críticos, incluidos los datos que se vuelven personales al combinarse; y (4) recomendar diseños que protejan la privacidad para la supervisión y los datos de incidentes. Se apoya en el capítulo 9 (datos) y el capítulo 10 (ética) y prepara el capítulo 29 (operaciones) y los requisitos éticos del proyecto final.

14.1 La seguridad no es privacidad

La seguridad protege los sistemas y la información frente al acceso, la modificación y la pérdida no autorizados. La privacidad se ocupa de si el tratamiento de información sobre las personas, incluso el tratamiento autorizado, es apropiado, proporcionado y justo. Una base de datos hospitalaria perfectamente segura puede vulnerar igualmente la privacidad si se usa para una finalidad de la que nunca se informó a los pacientes. El NIST Privacy Framework trata el riesgo para la privacidad como algo que surge del propio tratamiento de datos, solapado con el riesgo de ciberseguridad pero distinto de él.

La detección de clones de CT es el ejemplo: almacenar de forma segura dos años de validaciones seguiría siendo un problema de privacidad.

14.2 Principios

El Reglamento General de Protección de Datos de la UE establece principios que se reproducen ampliamente en otros lugares: licitud, lealtad y transparencia; limitación de la finalidad; minimización de datos; exactitud; limitación del plazo de conservación; integridad y confidencialidad; y responsabilidad proactiva (Regulation (EU) 2016/679, Article 5). Los datos de salud son una categoría especial que exige condiciones adicionales. Nota para el lector hispanohablante: en España, el RGPD se complementa con la Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales; en América Latina rige la ley de cada país, por ejemplo la Ley 25.326 en Argentina o la Ley 1581 de 2012 en Colombia. No hace falta que se convierta en jurista, pero debe reconocer cuándo una cuestión de diseño es también una cuestión de protección de datos e implicar al delegado de protección de datos de la organización, y nunca debe presentar el resumen de este libro como asesoramiento jurídico para un caso concreto.

14.3 Datos personales en lugares inesperados

Los servicios críticos tienen datos personales evidentes (historias clínicas, cuentas bancarias, llamadas de emergencia) y otros menos evidentes. Las lecturas de un contador inteligente a intervalos cortos pueden revelar cuándo hay alguien en casa. Los datos de validación de una tarjeta de transporte trazan los desplazamientos de una persona. Los registros de seguridad anotan quién inició sesión, desde dónde y cuándo: datos personales sobre el personal. La combinación importa: ni un código postal ni una fecha de nacimiento suelen identificar a alguien por sí solos, pero junto con el sexo a menudo sí. La seudonimización (sustituir los nombres por códigos) reduce el riesgo, pero no es anonimización si la clave existe o si la reidentificación es posible.

14.4 La privacidad en las operaciones de seguridad

La supervisión de seguridad recoge, por diseño, datos sobre las personas. Una práctica que protege la privacidad: recoger lo que necesita la finalidad de detección, no todo lo disponible; restringir el acceso a los registros en bruto; fijar plazos de conservación; seudonimizar donde el análisis no necesita nombres; documentar la finalidad y la base jurídica; y, en un incidente, compartir indicadores (direcciones, hashes de archivos) en lugar de datos personales siempre que sea posible. Durante una brecha que afecte a datos personales pueden aplicarse obligaciones de notificación en plazos cortos, por lo que los planes de incidentes incluyen al delegado de protección de datos desde el principio.

El diseño revisado de CT aplica cuatro de estas prácticas: detalle durante 30 días, seudónimos con clave, dos analistas con nombre y una finalidad declarada.

14.5 Ejemplo resuelto: analítica de validaciones de CT (sintético)

Este caso es sintético. El equipo de seguridad de Calder Transit quiere detectar tarjetas de transporte clonadas buscando la misma tarjeta usada en dos estaciones demasiado alejadas en un tiempo demasiado corto. El diseño propuesto copia todas las validaciones de tarjeta (ID de la tarjeta, estación, hora) durante dos años en la plataforma de analítica de seguridad. Una revisión de privacidad pregunta: ¿hacen falta dos años? (La detección de clones necesita de minutos a días; conservar el detalle completo durante 30 días y después agregar). ¿Hace falta el ID de la tarjeta en claro? (Un seudónimo con clave basta para emparejar; solo los casos confirmados se reidentifican, por parte del equipo de fraude). ¿Quién puede consultarlo? (Dos analistas con nombre, con registro). ¿Se está creando como efecto secundario un historial de viajes de los pasajeros? (Sí, y por eso el diseño limita la conservación y el acceso). El diseño revisado cumple la finalidad de detección con una fracción del riesgo para la privacidad.

14.6 Actividad práctica

Elija un servicio que use (una tarjeta de transporte, un contador inteligente, una aplicación de un hospital). A partir de su aviso de privacidad público, enumere los datos personales recogidos, las finalidades declaradas y la conservación. Identifique un dato cuya finalidad no esté clara y redacte una pregunta que podría enviar al proveedor. Fíjese en si el aviso indica la conservación en días o años, o solo «durante el tiempo necesario»; esto último es algo que merece la pena preguntar. Anote si la supervisión de seguridad figura siquiera como finalidad. Redacte su pregunta con cortesía y precisión, por ejemplo preguntando cuánto tiempo se conservan los datos de cada viaje antes de agregarlos y quién puede acceder a ellos.

14.7 Errores comunes y límites

• «Somos seguros, por lo tanto cumplimos».
• Recogerlo todo «por si resulta útil».
• Llamar anónimos a los datos seudonimizados.
• Olvidar los datos del personal en los registros.
• Dar conclusiones jurídicas sin los asesores jurídicos y de protección de datos de la organización.

Cada uno aparece en los ejemplos de este capítulo. La copia original de dos años de validaciones de CT era segura y aun así desproporcionada. «Por si resulta útil» es la forma en que el ID completo de la tarjeta acabó en la plataforma de analítica. Los seudónimos con clave son reversibles por el equipo de fraude, así que no son anónimos. La propuesta de supervisión de accesos del CVH en el EX027 registra nombres del personal, que son datos personales del personal. Y ninguno de estos diseños debería calificarse de lícito sin el delegado de protección de datos.

Ejercicios — capítulo 14

EX027 — Minimizar un registro. Objetivo: aplicar la minimización a la supervisión de seguridad. Entradas: una propuesta del CVH para registrar cada acceso del personal a las historias clínicas con el nombre completo del paciente, el diagnóstico, el nombre del miembro del personal, la estación de trabajo y la hora, conservados indefinidamente, para detectar accesos inapropiados. Pasos: proponga un diseño minimizado que cumpla la misma finalidad. Evidencia esperada: lista de campos, conservación, acceso y una frase sobre la finalidad. Rúbrica: 3 = identificador de la historia en lugar del diagnóstico, conservación definida, acceso restringido, finalidad declarada, personal informado; 2 = parcial; 1 = «registrar menos» sin diseño; 0 = nada.

EX028 — Riesgo de combinación. Objetivo: reconocer la reidentificación. Entradas: CW publica el consumo horario «anonimizado» de cada contador con el código postal y el tipo de inmueble. Pasos: explique dos riesgos de reidentificación y dos mitigaciones. Evidencia esperada: explicación. Rúbrica: 3 = los códigos postales pequeños con tipos de inmueble únicos identifican hogares, la ocupación puede inferirse de los patrones horarios; mitigaciones: umbrales de agregación, tiempo o ubicación menos detallados, acuerdos de acceso; 2 = uno de cada; 1 = vago; 0 = nada.

Síntesis del capítulo

La privacidad pregunta si el tratamiento de datos sobre las personas es apropiado, no solo si es seguro. Aplique la limitación de la finalidad, la minimización y la limitación del plazo de conservación (especialmente a la propia supervisión de seguridad), reconozca que las combinaciones reidentifican e implique a especialistas en protección de datos en lugar de ofrecer conclusiones jurídicas.