Cifrado, gestión de claves y secretos

Qué protege el cifrado y qué no

El cifrado se trata a menudo como una casilla que marcar: "los datos están cifrados en tránsito y en reposo". La frase esconde la pregunta que importa, que es frente a quién. Cada capa de cifrado protege los datos frente a unos actores y no frente a otros, y en todos los casos la protección es exactamente tan fuerte como el control sobre quién puede usar la clave. El cifrado no elimina el problema del control de acceso; lo traslada de los datos a las claves, donde normalmente es más fácil gestionarlo, auditarlo y revocarlo.

El cifrado en tránsito protege los datos que se mueven por una red para que no se lean ni se alteren por el camino. En la web eso significa TLS, presentado en el Capítulo 0; entre servicios significa TLS o TLS mutuo, que se tratan junto con zero trust. El cifrado en reposo protege los datos almacenados, pero "en reposo" no es una sola cosa: la tabla muestra las capas habituales en la plataforma de reparto de comida.

Al leer la tabla de arriba abajo, cada capa protege frente a más actores y cuesta más funcionalidad. Un buen diseño usa las capas baratas y transparentes en todas partes (hoy TLS y el cifrado del almacenamiento son casi gratuitos) y las caras de forma selectiva, para los datos cuya exposición haría más daño. Decidir qué datos son esos es tarea de la clasificación de datos, que se trata más adelante en esta sección junto con la tokenización y un ejemplo práctico.

Criptografía simétrica y asimétrica

El cifrado simétrico usa una única clave secreta para cifrar y descifrar. Es lo bastante rápido para grandes volúmenes de datos, y el algoritmo estándar es AES (FIPS 197, 2001) con claves de 128 o 256 bits. Los diseños modernos usan cifrado autenticado, que detecta la manipulación además de ocultar el contenido: AES en modo Galois/Counter (AES-GCM) o ChaCha20-Poly1305 (RFC 8439). Los modos autenticados necesitan un nonce único para cada mensaje cifrado con la misma clave; reutilizar un nonce con AES-GCM puede revelar el texto en claro y permitir falsificaciones, que es una de las muchas razones para usar bibliotecas bien probadas en lugar de ensamblar las primitivas por tu cuenta.

La criptografía asimétrica usa un par de claves: una clave pública que cualquiera puede tener y una clave privada que se mantiene en secreto. Permite dos cosas que la criptografía simétrica no puede hacer. El acuerdo de claves permite que dos partes que nunca se han visto establezcan una clave simétrica compartida a través de una red abierta (Diffie-Hellman de curva elíptica en TLS 1.3). Las firmas digitales (RSA, ECDSA, Ed25519) permiten que cualquiera que tenga la clave pública verifique que los datos proceden del titular de la clave privada y no se han modificado, lo que proporciona integridad, autenticidad y una base para el no repudio. Las operaciones asimétricas son lentas, así que los protocolos reales son híbridos: TLS usa la criptografía asimétrica para autenticar al servidor y acordar las claves, y después el cifrado simétrico para los datos.

Una computadora cuántica grande rompería los algoritmos RSA y de curva elíptica actuales, aunque no AES con claves suficientemente largas. En agosto de 2024, el NIST publicó sus primeros estándares poscuánticos: FIPS 203 (ML-KEM, para el establecimiento de claves), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA), ambos para firmas. Los datos que deben seguir siendo confidenciales durante muchos años ya están en riesgo hoy por los atacantes que graban ahora el tráfico cifrado para descifrarlo más adelante, así que la respuesta arquitectónica es la agilidad criptográfica (crypto agility): mantener un inventario de dónde se usa cada algoritmo, evitar codificarlos de forma fija y preferir bibliotecas, protocolos y proveedores que puedan cambiar de algoritmo, como han empezado a hacer los principales navegadores y bibliotecas TLS con el intercambio de claves poscuántico híbrido.

El hash, los MAC, las firmas y el cifrado son herramientas distintas

Confundir estas primitivas es una fuente habitual de defectos de diseño, como "cifrar" las contraseñas para poder descifrarlas, o confiar en un hash simple para demostrar que un webhook procede de un proveedor de pagos. La tabla las pone una al lado de otra.

Almacenamiento de contraseñas

Un hash de uso general como SHA-256 está diseñado para ser rápido, que es justo lo contrario de lo que necesitan las contraseñas: los procesadores gráficos pueden probar miles de millones de intentos por segundo contra una tabla robada de hashes rápidos. El hash de contraseñas usa funciones deliberadamente lentas y, idealmente, exigentes en memoria (memory-hard), para que cada intento le cueste al atacante tiempo y memoria reales, con una sal (salt) aleatoria y única por contraseña, para que contraseñas idénticas produzcan hashes distintos y las tablas precalculadas no sirvan de nada.

La OWASP Password Storage Cheat Sheet da las recomendaciones actuales por orden de preferencia. Argon2id (una variante de Argon2, ganador de la Password Hashing Competition de 2015), con un mínimo de 19 MiB de memoria, dos iteraciones y un grado de paralelismo (o un compromiso equivalente, como 46 MiB con una iteración). scrypt donde Argon2id no esté disponible, con un parámetro de costo de 2¹⁷ (128 MiB), un tamaño de bloque de 8 y un paralelismo de 1. bcrypt solo para sistemas heredados, con un factor de trabajo de al menos 10, recordando que la mayoría de las implementaciones ignoran la entrada que supera los 72 bytes. Donde se exija el cumplimiento de FIPS 140, PBKDF2 con HMAC-SHA-256 y 600 000 iteraciones. Estas cifras suben a medida que mejora el hardware, así que consulta la cheat sheet vigente en lugar de copiar números en un documento de diseño.

De aquí se derivan tres puntos de diseño. Guarda el algoritmo y los parámetros con cada hash (los formatos codificados estándar lo hacen), para poder aumentar los parámetros más adelante: cuando un usuario inicia sesión correctamente, verifica con el hash antiguo y vuelve a calcular el hash de inmediato con los parámetros nuevos. Considera una pimienta (pepper), un secreto que se añade a cada contraseña antes de calcular el hash y que se guarda en una bóveda o un HSM en lugar de en la base de datos, lo que frustra a un atacante que solo robe la base de datos. Y lo más importante: pregúntate si deberías guardar contraseñas en absoluto: delegar la autenticación en un proveedor de identidad y ofrecer passkeys elimina de la mayoría de tus servicios el secreto más atacado.

Gestión de claves y cifrado de sobre

Las claves tienen un ciclo de vida, descrito en NIST SP 800-57 Part 1: generación (a partir de una fuente aleatoria adecuada), almacenamiento, distribución, uso, rotación al final de un criptoperiodo definido, revocación si se comprometen y destrucción. Hacer todo eso de forma segura a mano no es práctico, y por eso las arquitecturas se apoyan en un servicio de gestión de claves (KMS) como AWS KMS, Azure Key Vault o Google Cloud KMS, o en un sistema autogestionado como HashiCorp Vault. Un KMS guarda las claves maestras dentro de módulos de seguridad de hardware (HSM), dispositivos resistentes a la manipulación validados según FIPS 140, y realiza operaciones con esas claves cuando se le solicitan, sujetas a una política de acceso, de modo que las aplicaciones nunca ven las claves maestras y cada uso queda registrado.

Enviar cada registro al KMS para cifrarlo sería lento y caro, y las API de KMS limitan el tamaño de las solicitudes. El cifrado de sobre resuelve esto. La aplicación le pide al KMS una clave de cifrado de datos (DEK) nueva; el KMS la devuelve dos veces, en texto en claro y envuelta (cifrada) con una clave de cifrado de claves (KEK) que nunca sale del HSM. La aplicación cifra los datos localmente con la DEK en claro, borra la DEK de la memoria y guarda el texto cifrado junto con la DEK envuelta. Para descifrar, envía solo la pequeña DEK envuelta al KMS, que comprueba el permiso de quien llama, registra la solicitud y devuelve la DEK.

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt_field(plaintext: bytes, kms, kek_id: str, context: bytes) -> dict:
    dek = AESGCM.generate_key(bit_length=256)            # fresh data key
    nonce = os.urandom(12)                               # never reuse with this key
    ct = AESGCM(dek).encrypt(nonce, plaintext, context)  # context binds it to its row
    wrapped = kms.encrypt(key_id=kek_id, plaintext=dek)  # KEK stays inside the KMS
    return {"ct": ct, "nonce": nonce, "wrapped_dek": wrapped, "kek": kek_id}

def decrypt_field(rec: dict, kms, context: bytes) -> bytes:
    dek = kms.decrypt(key_id=rec["kek"], ciphertext=rec["wrapped_dek"])  # checked, logged
    return AESGCM(dek).decrypt(rec["nonce"], rec["ct"], context)

El cifrado de sobre tiene varias ventajas arquitectónicas. La rotación es barata: rotar una KEK crea una nueva versión de la clave para las nuevas operaciones de envoltura, mientras que las versiones antiguas siguen disponibles para descifrar; las DEK existentes pueden volver a envolverse sin tocar los datos, y solo hace falta volver a cifrarlo todo si una DEK puede haber quedado expuesta. El radio de impacto es limitado: con una DEK por registro, archivo o partición, una DEK filtrada expone poco. La separación de funciones se vuelve posible: el servicio de pedidos puede usar su KEK para desenvolver, pero no cambiar su política ni borrarla, mientras que los administradores de seguridad pueden gestionar las claves, pero no descifrar los datos. Las jerarquías de claves se corresponden con la organización: una KEK por servicio y clase de datos, o por cliente (tenant), de modo que una gran cadena de restaurantes podría incluso aportar y controlar su propia clave. Y destruir una clave es una herramienta poderosa: el crypto-shredding hace ilegible cada copia de los datos cifrados con ella, incluidas las copias de seguridad y los logs de eventos inmutables, lo que importa para el supresión según el RGPD (GDPR) y para los sistemas basados en event sourcing.

El precio es una nueva dependencia crítica. Si el KMS no está disponible, los datos cifrados no pueden leerse; si una clave se borra por error, los datos se pierden para siempre. Por eso los KMS en la nube imponen un periodo de espera antes del borrado, y los arquitectos deberían tratar el borrado de claves y los cambios en las políticas de claves como operaciones privilegiadas, registradas y de dos personas, guardar en caché brevemente las DEK desenvueltas donde importe la latencia de las llamadas al KMS e incluir el KMS en los planes de recuperación ante desastres.

Gestión de secretos

Un secreto es cualquier credencial que da acceso: contraseñas de bases de datos, claves de API del proveedor de pagos, claves privadas, claves de firma, secretos de cliente de OAuth, secretos de webhooks. La gestión de secretos parte de una regla: los secretos nunca viven en el código fuente, ni en imágenes de contenedor, ni en archivos de configuración confirmados en repositorios, porque estos se copian, se guardan en caché, se bifurcan y los leen muchas más personas y sistemas de los que deberían acceder al secreto. Una vez que está en el historial de un repositorio, un secreto permanece ahí aunque se borre la línea.

Los secretos deben estar en una bóveda (vault) (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager) que los guarde cifrados, los entregue solo a cargas de trabajo autenticadas según la política, registre cada acceso y admita la rotación. Mejor que rotar secretos de larga duración es no tenerlos: una bóveda puede emitir secretos dinámicos, como una cuenta de base de datos creada para una instancia de servicio con una vigencia (lease) de una hora, y la identidad de carga de trabajo permite que los servicios se autentiquen ante las API de la nube y entre sí sin ningún secreto almacenado. Los secretos inyectados en tiempo de ejecución deberían leerse de archivos o de la API de la bóveda en lugar de variables de entorno visibles para todo el mundo, que tienden a acabar en volcados de memoria por fallos y en logs de depuración.

La prevención necesita automatización, porque las personas se equivocan. Los hooks de pre-commit y los escáneres del pipeline (como gitleaks y detect-secrets) detectan los secretos antes de que se suban; los servicios de alojamiento de repositorios buscan formatos de secretos conocidos, y la protección de push (push protection) de GitHub bloquea los push que los contienen. Los atacantes escanean los repositorios públicos a los pocos minutos de cada push. Las consecuencias están bien documentadas: en 2016, unos atacantes que lograron acceder a un repositorio privado de GitHub usado por ingenieros de Uber encontraron allí una clave de acceso al almacenamiento en la nube de Uber y descargaron datos personales de unos 57 millones de pasajeros y conductores.

Tokenización y reducción del alcance de PCI DSS

La tokenización sustituye un valor sensible por un token que no tiene ninguna relación matemática con él; el valor real se guarda en una bóveda aparte, muy protegida, y solo la bóveda puede volver a asociar el token con su valor. A diferencia del cifrado, un token robado no puede revertirse con una clave, porque no hay clave, solo una consulta en un sistema que el atacante no controla.

Su uso más importante son los pagos con tarjeta. El Payment Card Industry Data Security Standard (PCI DSS, actualmente en la versión 4.0.1, publicada en junio de 2024) se aplica a todo componente del sistema que almacene, procese o transmita datos del titular de la tarjeta, o que esté conectado a esos componentes o pueda afectar a su seguridad. Una plataforma que deja pasar los números de tarjeta por sus servidores mete en el alcance su API gateway, sus servicios, sus logs, sus redes y sus administradores, con cientos de requisitos y una evaluación anual. Una plataforma que usa los campos de pago alojados o la redirección del proveedor de pagos, de modo que los números de tarjeta van directamente del dispositivo del cliente al proveedor, solo recibe un token y quizá los cuatro últimos dígitos, y su alcance de PCI DSS se reduce drásticamente: un comercio más pequeño puede optar al cuestionario de autoevaluación más breve, e incluso los comercios más grandes, que siguen necesitando una evaluación anual por parte de un evaluador cualificado, tienen muchos menos sistemas que evaluar. Este es el diseño del modelo de amenazas del proceso de pago: los datos de tarjeta más baratos de proteger son los que nunca guardas. Cifrar tú mismo los números de tarjeta no consigue la misma reducción, porque quien pueda descifrarlos sigue dentro del alcance.

La misma idea sirve para otros identificadores sensibles. Un servicio interno de tokenización puede sustituir los números de la seguridad social o los números de pasaporte por tokens en toda la plataforma, de modo que solo un servicio pequeño y muy protegido vea alguna vez los valores reales.

Clasificación de datos

Las decisiones sobre cifrado, tokenización, logging, conservación y acceso dependen de saber qué datos son sensibles y en qué medida. Un esquema de clasificación de datos establece unos pocos niveles con reglas de tratamiento asociadas, para que los equipos no decidan cada caso desde cero. Lo habitual son cuatro niveles; lo que importa es que cada conjunto de datos del catálogo de datos o del esquema de la plataforma lleve un nivel, y que las reglas se apliquen mediante plantillas y comprobaciones, no de memoria.

Cifrado a nivel de campo

El cifrado a nivel de campo, la capa a nivel de aplicación de la primera tabla, cifra campos individuales antes de escribirlos, normalmente con cifrado de sobre y una KEK por clase de datos. Su fortaleza es que todo lo que hay después de la aplicación solo contiene texto cifrado: los administradores de bases de datos, las réplicas de lectura, las copias de seguridad y el almacén de datos (data warehouse) alimentado por captura de datos de cambios. Una brecha en cualquiera de ellos no expone nada legible, y el acceso al texto en claro se reduce a los servicios que pueden llamar al KMS con esa clave, y cada llamada queda registrada.

Sus costos son reales. La base de datos ya no puede indexar, buscar, ordenar ni hacer joins por el campo cifrado. Las búsquedas por igualdad pueden recuperarse con un índice ciego (blind index), una columna aparte que guarda un hash con clave (HMAC) del valor normalizado, a cambio de revelar qué filas comparten un valor. El cifrado determinista tiene la misma fuga, mientras que las consultas por rango necesitan esquemas especializados o, simplemente, no deberían hacerse sobre esos campos. Algunas bases de datos ofrecen cifrado a nivel de campo del lado del cliente o cifrado consultable, que empaquetan estas técnicas. Por estos costos, el cifrado a nivel de campo debería reservarse para los datos restringidos, cuyos campos rara vez se consultan de todos modos.