Qué datos tienes, y por qué los tienes

Cuando alguien dice «se filtraron datos», la primera pregunta profesional no es cuántos. Es cuáles.

Hay una escala, y conviene tenerla clara porque decide todo lo demás:

Datos públicos. El horario de la clínica, la dirección, los teléfonos de contacto. Filtrarlos no es un incidente.

Datos personales. Nombre, correo, teléfono, documento. Identifican a alguien. Su filtración habilita suplantación y fraude.

Datos sensibles. Salud, origen étnico, orientación, creencias, biometría, situación judicial. En la mayoría de las legislaciones tienen protección reforzada, y por una razón que no es burocrática: su filtración puede costarle a alguien el trabajo, la familia o la seguridad física.

Y ahora aplícalo a la agenda que abriste en la primera sala. Tenía nombre, documento parcial… y servicio.

Salud mental, 09:15.

Eso no es un dato personal. Es un dato de salud, de una persona identificada, con hora. Es lo más protegido que existe, y estaba a una dirección de distancia.

Aquí está la idea que cierra el módulo, y es de las pocas que no cuesta nada aplicar:

El dato que no tienes no se te puede filtrar.

Suena obvio y casi nadie lo aplica, porque el instinto por defecto es guardar todo por si acaso. Y «por si acaso» es una razón terrible para almacenar información de salud.

Para cada dato que un sistema guarda hay que poder contestar tres cosas:

¿Para qué lo necesito? Si la respuesta es «por si algún día hace falta», la respuesta real es que no lo necesitas.

¿Cuánto tiempo? Casi ningún dato hace falta para siempre. La agenda de hace tres años no sirve a nadie de la clínica y sigue siendo un riesgo idéntico si está en la base.

¿Completo? Fíjate en el detalle del escenario: los documentos aparecían truncados — ····5209. Eso es una decisión de alguien, y es buena. Para identificar una cita en pantalla bastan cuatro cifras; el número completo solo hace falta en un sitio y en un momento.

Ese es el principio de minimización, y es la única defensa que funciona incluso cuando todas las demás fallan. Si el atacante entra y hay poco que llevarse, se lleva poco.

Empezaste el módulo sabiendo que la agenda «salía de una base de datos». Terminas habiéndola consultado, habiéndola roto con una comilla, y sabiendo qué se guarda y qué no.

Cuatro cosas para quedarse:

Los datos viven en tablas y se piden con una consulta. La página no guarda nada: pide.

Si el dato del usuario se pega dentro de la orden, deja de ser un dato. Y la solución no es filtrar mejor: es separar los canales.

Una contraseña no se guarda, se reconoce. Resumen, con sal, con función lenta. Y nada de eso salva una contraseña mala.

Casi nada del código es tuyo, así que la versión de lo que incluyes es parte de tu seguridad.

Y por encima de las cuatro, la que aplica a cualquier sistema que construyas o revises: la mitad de la protección de un dato se decide el día que alguien elige guardarlo.

Lo que viene es el último módulo: juntar todo esto en un ataque y una defensa completos, y aprender a escribirlo para que alguien pueda arreglarlo.