Ya tenemos todas las piezas: AEAD versionado, KDFs, firmas, TLS, mTLS y, desde la lección anterior, un gestor de secretos con envelope encryption. Esta lección cambia de altitud: dejamos de mirar primitivas y adoptamos la visión de arquitecto. La pregunta ya no es "¿cómo funciona AES-GCM?" sino "¿qué datos de MediNube están cifrados, con qué capa, y contra qué atacante protege cada capa?". Vas a dibujar el mapa completo del dato — desde el navegador de Ana Pérez hasta la fila de PostgreSQL y la cinta de backup — y a descubrir que "está cifrado" es una frase que no significa nada hasta que respondes: ¿cifrado dónde y contra quién?

1. El mapa de datos de MediNube: estados y fronteras
2. En tránsito: TLS externo e interno (la BD también habla TLS)
3. En reposo: las cuatro capas y qué amenaza cubre cada una
4. Búsqueda sobre datos cifrados: el dilema y el índice ciego
5. Hashear, cifrar o dejar en claro: la tabla de decisión
6. El volcado robado: ejercicio mental guiado
7. Cifrado de extremo a extremo: el maximalismo y por qué MediNube no lo es

Todo dato está en uno de dos estados: en tránsito (viajando por una red) o en reposo (escrito en un disco). Cada estado tiene sus amenazas y sus herramientas. Este es el mapa de MediNube con lo que ya hemos construido:

Lección de arquitecto número uno: las flechas son tránsito (dominio de TLS, módulo 5) y los cilindros son reposo (dominio de los módulos 2 y 4). Lección número dos: el interior de la red "de confianza" también lleva candados — la época de "TLS solo en el perímetro" terminó cuando los atacantes aprendieron a moverse lateralmente por redes internas.

El tramo externo ya lo resolvimos en el módulo 5 y aquí solo lo reutilizamos: TLS 1.3 en portal.medinube.example y api.medinube.example, mTLS para las clínicas con su SAN clinica-sol.clientes.medinube.example, HSTS, certificados de vida corta con ACME. Nada nuevo.

Lo que sí es nuevo es mirar hacia dentro: la conexión app ↔ PostgreSQL también cruza una red, y en esa red puede haber un contenedor comprometido escuchando. PostgreSQL habla TLS de forma nativa, y el cliente decide cuánto exige con sslmode:

Aquí está la trampa que sorprende a casi todo el mundo: require cifra pero no verifica. Acepta cualquier certificado, incluido el autofirmado que MalloryClinic presente en un MITM dentro de la red. Es el verify=False de 05-02 disfrazado de opción razonable: canal cifrado con un desconocido. La configuración correcta usa la CA interna que creamos en 05-01:

Explicación: sslrootcert apunta a la raíz MediNube Lab Root CA desplegada en 05-01; verify-full obliga a que el certificado del servidor esté firmado por esa CA y que su SAN coincida con pg.interna.medinube.example. Es exactamente la validación de cadena+nombre del módulo 5, aplicada a la base de datos. La contraseña, por supuesto, sale del gestor de la lección anterior.

"La base de datos está cifrada" puede significar cuatro cosas muy distintas. La tabla que sigue es probablemente la más importante de la lección — cada capa protege contra un atacante concreto y es transparente para todos los demás:

Tres comentarios de profundidad:

• El cifrado de disco es necesario y casi nunca suficiente. Cuando el servidor está encendido (siempre, en un SaaS), LUKS es transparente: cualquier proceso con permisos lee los datos en claro. Su escenario real es el disco que sale del centro de datos. Actívalo siempre (en cloud suele venir de serie), pero no lo pongas en el informe de seguridad como "los historiales están cifrados".

• TDE y pgcrypto viven dentro de la BD. TDE (Transparent Data Encryption) cifra los ficheros del motor: mismo alcance que el disco, más granular. pgcrypto permite cifrar columnas desde SQL:

  -- pgcrypto: cifrado simétrico por columna, desde el propio SQL
  UPDATE pacientes
     SET telefono = pgp_sym_encrypt('612345678', 'clave-secreta')
   WHERE id = 4471;
  
  SELECT pgp_sym_decrypt(telefono::bytea, 'clave-secreta') FROM pacientes;
  

  Su límite salta a la vista: la clave viaja en la consulta SQL, con lo que acaba en los logs de la BD, en pg_stat_activity y en manos de cualquier atacante que ya esté dentro del motor... que es justo el atacante del que queríamos protegernos. Útil en escenarios acotados; no para los historiales de MediNube.

• El cifrado a nivel de aplicación es el más granular y el más fuerte. Es el que construimos en 02-03: el historial de Ana Pérez se cifra con AES-256-GCM (formato v1, AAD paciente=...;formato=v1) antes de salir de la app, y viaja ya cifrado hasta la fila de PostgreSQL. La BD solo ve bytes opacos: un volcado completo, una inyección SQL o un administrador curioso obtienen exactamente nada. La DEK llega por el envelope encryption de 06-01. El precio también es real, y le dedicamos la siguiente sección: la BD ya no puede indexar ni buscar sobre ese campo.

Las capas no compiten: se apilan. MediNube lleva disco cifrado (contra el robo físico), TLS interno (contra la red), cifrado de aplicación en los campos sensibles (contra la BD comprometida) y backups cifrados con el sobre híbrido de 04-05 cuando el destinatario es externo (la clínica que pide su copia: se cifra la DEK del backup con la pública de la clínica).

Aquí aparece el conflicto central del cifrado de aplicación. Un campo AEAD bien cifrado es indistinguible de bytes aleatorios y, además, cifrar dos veces el mismo valor produce blobs distintos (nonce aleatorio). Consecuencia directa:

No es un defecto: es la semántica de seguridad que queríamos. Pero recepción necesita buscar a Ana Pérez por DNI. El patrón práctico es el índice ciego (blind index): junto al campo cifrado se guarda un HMAC del valor normalizado, con una clave dedicada del gestor:

Por qué cada pieza es como es: la normalización garantiza que "12345678-Z" y "12345678z" produzcan el mismo índice (si no, la búsqueda falla por formato); el HMAC con clave (y no un simple sha256) impide que quien robe la tabla calcule el índice de todos los DNIs posibles por fuerza bruta —los DNIs tienen poquísima entropía, regla de oro 5—; y la clave dedicada limita el daño si se filtra.

Honestidad obligada sobre lo que el índice ciego filtra: es determinista, así que revela qué filas comparten valor (igualdad) y permite confirmar un DNI concreto a quien tenga la clave del índice. Solo sirve para igualdad exacta: nada de LIKE 'PER%', rangos ni ordenación. Existen esquemas más ambiciosos (cifrado que preserva orden, cifrado buscable), pero sus fugas son mucho peores de lo que parecen y su historia académica está llena de roturas: para MediNube, igualdad exacta con índice ciego y cualquier búsqueda más rica sobre campos no sensibles.

Con las capas y el índice ciego sobre la mesa, ya podemos decidir campo a campo. Esta es la tabla real de la tabla pacientes y compañía en MediNube — el criterio: ¿necesito recuperar el valor original? ¿necesito buscar por él? ¿qué pasa si se filtra?

La fila de la contraseña merece subrayado: cifrar una contraseña (recuperable) en lugar de hashearla es un error clásico de auditoría. Si el sistema puede recuperar tu contraseña, un atacante también.

Pongamos a prueba el diseño. MalloryClinic consigue un pg_dump completo de la BD de MediNube (una inyección SQL, un backup mal protegido, da igual el cómo). Recorramos qué obtiene según las capas presentes:

1. Sin ninguna capa (la MediNube del módulo 1): todo en claro. Historiales, DNIs, contraseñas. Brecha catastrófica, notificación a la AEPD, portada de prensa.
2. Solo disco cifrado: exactamente lo mismo que el punto 1. El volcado se hizo con el sistema arrancado; LUKS ni se enteró. Primera lección grabada a fuego: el cifrado de disco no protege contra volcados lógicos.
3. + TDE / cifrado de la BD: también casi lo mismo: el volcado lógico sale del motor, que descifra de forma transparente. TDE protegería el robo de los ficheros del motor, no del dump.
4. + cifrado de aplicación (la MediNube actual): los historiales y DNIs son blobs AEAD sin las DEKs (que están en el KMS, no en la BD); las contraseñas son Argon2id y además falta el pepper (que vive en el gestor); los índices ciegos no se invierten sin su clave. Mallory tiene ids, fechas y metadatos. Sigue siendo un incidente (los metadatos también cuentan para el RGPD y hay que notificarlo), pero el contenido clínico de Ana Pérez está a salvo.

Este ejercicio —"¿qué ve el atacante con este volcado?"— es la herramienta de diseño más barata que existe. Hazlo con cada tabla nueva antes de escribir la migración.

Queda una capa por encima de todas: el cifrado de extremo a extremo (E2E), donde ni siquiera el servidor puede leer los datos — solo los extremos tienen las claves. Signal, que ya mencionamos en el módulo 4, es el ejemplo canónico: el servidor de Signal transporta blobs que no puede abrir.

¿Podría MediNube ser E2E, con los historiales cifrados con claves que solo tienen las clínicas y los pacientes? Técnicamente sí (las piezas son las del módulo 4: X25519, sobres, firmas). Pero implicaría renunciar a funciones que hoy son el producto: el servidor no podría generar informes agregados, ni indexar para búsqueda, ni permitir que un médico de urgencias acceda a un historial si el paciente no está para "autorizar" criptográficamente; y la pérdida de la clave del paciente significaría la pérdida irrecuperable de su historial (o un sistema de recuperación... que reintroduce la confianza en el servidor). E2E es la elección correcta cuando el servidor es solo un transporte (mensajería); MediNube es un procesador de datos, y su compromiso honesto es otro: cifrado de aplicación con claves en KMS auditado, de modo que leer datos exija comprometer dos sistemas y deje rastro. Decir "somos E2E" sin serlo sería marketing, no criptografía — y las auditorías RGPD distinguen perfectamente ambas cosas.

• Error: sslmode=require y sensación de seguridad. Cifra, pero acepta cualquier certificado. Contra un MITM interno es inútil: verify-full + tu CA interna, siempre.
• Error: contar el cifrado de disco como cifrado de datos. Protege discos apagados. En el informe de seguridad, especifica capa por capa qué hay.
• Error: pasar la clave de pgcrypto en cada consulta y encontrársela después en los logs de PostgreSQL. Si necesitas protección contra la propia BD, cifra en la aplicación.
• Error: índice ciego con hash sin clave (sha256(dni)): con ~10⁸ DNIs posibles, se invierte por fuerza bruta en minutos. HMAC con clave del gestor, y normaliza antes.
• Consejo: apila capas según el atacante, no según la moda. La pregunta de diseño siempre es "¿contra quién?": robo físico → disco; red interna → TLS con verify-full; BD comprometida → aplicación; soporte externo → backups con sobre.
• Consejo: documenta la tabla de decisión de campos (claro/hash/cifrado/índice) en el repositorio. Es oro para el siguiente desarrollador y para el auditor.

1. Clasifica la tabla nueva: MediNube añade la tabla citas con columnas id, paciente_id, medico_id, fecha_hora, motivo_consulta (texto libre: "dolor torácico..."), telefono_contacto. Asigna tratamiento a cada columna (claro / AEAD / AEAD+índice ciego / hash) y justifica. Pista: recepción necesita buscar citas por teléfono de contacto.
2. El volcado, otra vez: con tu diseño del ejercicio 1, escribe qué obtiene exactamente MalloryClinic de un pg_dump de citas, y qué metadatos siguen filtrándose aunque todo lo sensible esté cifrado. ¿Es "cita del paciente X con el médico Y a las 9:00" un dato inocuo?
3. Cazando el require: escribe la cadena de conexión (o el bloque psycopg.connect) incorrecta con sslmode=require y su corrección con verify-full, y explica en dos frases el ataque concreto que la versión incorrecta permite dentro de la red de MediNube.

1. id, paciente_id, medico_id: claro (claves de JOIN; son referencias opacas). fecha_hora: claro (hay que consultar agendas por rango: WHERE fecha_hora BETWEEN..., imposible sobre AEAD y el índice ciego no cubre rangos). motivo_consulta: AEAD con AAD (p. ej. f"cita={id};formato=v2") — es contenido clínico, tan sensible como el historial. telefono_contacto: AEAD + índice ciego con normalización (quitar espacios, prefijo +34) porque hay que recuperarlo (llamar al paciente) y buscar por él.
2. Mallory ve el grafo de citas: qué paciente_id visita a qué medico_id y cuándo, sin motivos ni teléfonos. No es inocuo: si el médico Y es identificable como oncólogo, la mera existencia de citas frecuentes revela información de salud — por eso los metadatos también son datos personales bajo RGPD y el incidente igualmente se notifica. Mitigaciones posibles: pseudonimizar medico_id a nivel de aplicación o cifrar también esa relación aceptando el coste en consultas.
3. Incorrecta: psycopg.connect(..., sslmode="require"). Correcta: sslmode="verify-full", sslrootcert="/etc/medinube/pki/ca.crt". Ataque: un pod comprometido en la red interna hace ARP/DNS spoofing hacia pg.interna.medinube.example, presenta un certificado autofirmado y el cliente con require lo acepta sin rechistar: MalloryClinic termina el TLS, lee credenciales y consultas, y reenvía el tráfico a la BD real (MITM completo e invisible).

Ya no piensas en primitivas: piensas en capas. Sabes que "cifrado" sin apellidos no significa nada, que cada capa (disco, BD, aplicación, backup) tiene su atacante, que la app habla con PostgreSQL con verify-full contra la CA interna de 05-01, que buscar sobre datos cifrados se paga con índices ciegos y honestidad sobre sus fugas, y que el historial de Ana Pérez llega cifrado hasta la fila de la base de datos con DEKs que viven en el KMS de 06-01. El mapa de datos de MediNube está completo.

Queda un dato viajero que aún arrastra una vergüenza del módulo 1: el token de sesión del portal, aquel eyJ... que en 01-02 resultó ser Base64 sin firma — codificar no es cifrar... y tampoco es autenticar. En la próxima lección lo convertimos en lo que siempre debió ser: un token firmado. JWT, sus ataques clásicos y cómo usarlo bien. Nos vemos allí.