Gestión de claves
Ciclo de vida y rotación de claves, HSM, envelope encryption paso a paso y cómo KMS controla el acceso con key policies, grants y claves multi-región.
Un sistema criptográfico es tan fuerte como la gestión de sus claves. Puedes usar AES-256 y TLS 1.3 impecables, pero si la clave acaba en un repositorio, nunca rota o se borra sin querer, todo se viene abajo. La gestión de claves es la parte menos vistosa y más decisiva de la criptografía aplicada, y en AWS gira alrededor de KMSAWS KMSServicio gestionado de AWS que crea y controla claves de cifrado; las claves nunca salen en claro y cada una lleva su propia key policy.. Esta nota recorre el ciclo de vida de una clave, el patrón de envelope encryptionEnvelope encryptionCifrar los datos con una data key, y cifrar esa data key con otra clave (una KEK); solo viaja y se almacena la data key cifrada. y, sobre todo, cómo se controla quién puede usar una llave.
El ciclo de vida de una clave#
Una clave no es un secreto estático: pasa por fases y cada una tiene sus riesgos.
- Generación: con aleatoriedad fuerte, idealmente dentro de un HSM (Hardware Security Module), un dispositivo que crea y guarda claves sin que salgan nunca en claro. KMS respalda sus claves en HSMs validados FIPS 140.
- Distribución / uso: la clave se usa para cifrar, pero nunca debería viajar ni almacenarse en claro. Aquí entra envelope encryption.
- Rotación: sustituir la clave cada cierto tiempo limita cuántos datos protege una sola clave y acota el daño si se compromete. KMS ofrece rotación automática del material criptográfico.
- Revocación / deshabilitación: si sospechas un compromiso, deshabilitas la clave para cortar su uso al instante.
- Destrucción: borrar una clave hace ilegibles los datos cifrados con ella. Por eso KMS impone una espera obligatoria de 7 a 30 días antes de eliminarla: un borrado accidental es irreversible.
Envelope encryption paso a paso#
KMS no cifra tus terabytes directamente: sería lento y expondría la clave maestra en cada llamada. En su lugar usa envelope encryption, una clave que cifra otra clave.
Paso 1 de 6Generar data key
La app pide a KMS una data key con GenerateDataKey. La KEK (la KMS key, que nunca sale de KMS) devuelve dos versiones: una en claro y una copia cifrada.
La clave maestra de KMS actúa como KEK (Key Encryption Key) y nunca sale del servicio. El flujo es:
- La app llama a
GenerateDataKey. KMS devuelve una data key en dos formas: una en claro y una copia cifrada con la KEK. - La app cifra el objeto (la PII) con la data key en claro, localmente y con AES-GCM.
- En cuanto termina, borra la data key en claro de memoria. Ya no queda ninguna copia utilizable fuera de KMS.
- Guarda el objeto cifrado junto a la data key cifrada. Quien robe el bucket se lleva ambos cifrados y ninguno sirve sin la KEK.
- Para leer, envía la data key cifrada a
Decrypt; KMS la descifra con la KEK y devuelve la data key en claro, solo en memoria, para descifrar el objeto.
Así ciframos cualquier volumen sin llamar a KMS por cada byte, limitamos la exposición de la clave maestra a operaciones pequeñas y centralizamos el control de acceso y la auditoría (cada Decrypt queda en CloudTrail) en una sola llave. Es exactamente lo que hacen por debajo el cifrado de S3, EBS y RDS.
Quién puede usar la llave: key policies vs grants#
Aquí está la parte que más sorprende de KMS. Cada clave tiene una key policy: una política basada en recurso, pegada a la propia llave, que es el control de acceso principal. A diferencia del resto de AWS, con KMS los permisos IAM por sí solos no bastan: la key policy tiene que habilitarlos.
Vulnerable
Seguro
// La política IAM del usuario dice kms:* sobre todo...{ "Effect": "Allow", "Action": "kms:*", "Resource": "*" }
// ...pero la key policy de la llave NO incluye la// declaración que delega en IAM. Resultado: ese// administrador NO puede usar ni gestionar la clave.// La llave queda "aislada" de IAM.{ "Sid": "EnableIAMUserPermissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "kms:*", "Resource": "*"}// Este "root" NO es el usuario root: representa la// cuenta. Permite que las políticas IAM deleguen// permisos sobre la llave, y evita el bloqueo total.Por eso un administrador IAM puede quedarse sin acceso a una llave: si la key policy no lo incluye y tampoco está la declaración que delega en IAM, no hay forma de usarla. Es una propiedad buscada —permite llaves que ni el equipo de plataforma puede abrir— pero también la causa de bloqueos accidentales.
- Key policy: control base, siempre presente. Define quién administra y quién usa la llave.
- IAM: solo surte efecto si la key policy delega en la cuenta (la declaración de arriba).
- Grants: delegación temporal y granular, pensada para que un servicio o una sesión use la llave para una operación concreta durante un tiempo, sin reescribir la política. Se crean y revocan por API (
CreateGrant,RevokeGrant).
Claves multi-región y cifrado entre cuentas#
Dos necesidades habituales en una organización como la de Citas (cuentas prod / staging / log-archive):
- Claves multi-región: KMS permite crear réplicas de una clave en varias regiones con el mismo material y el mismo ID (prefijo
mrk-). Sirven para escenarios donde cifras en una región y necesitas descifrar en otra (recuperación ante desastres, datos replicados) sin volver a cifrar. - Cifrado entre cuentas: una llave en una cuenta puede autorizar, vía su key policy (y grants), a principales de otra cuenta a cifrar o descifrar. Así el worker de la cuenta de prod puede descifrar objetos escritos por otra cuenta, o la cuenta de log-archive mantiene control exclusivo sobre la clave que cifra los logs, aunque los produzcan otras cuentas.
Tu turno
Modela la gestión de claves de un dato sensible
Elige un dato cifrado en un sistema que manejes (un bucket, un volumen, una base de datos) y responde:
- ¿Qué llave lo cifra y quién puede llamar a
Decrypt? ¿Lo sabes con certeza o lo das por hecho? - ¿Está activada la rotación? ¿Y la protección contra borrado?
- Si tuvieras que revocar el acceso ya ante un incidente, ¿qué tocarías: la key policy, una grant, una política IAM? ¿Cuánto tardaría en surtir efecto?
- ¿Hay alguna llave de la que el equipo que administra IAM no debería poder descifrar? ¿Lo refleja hoy la key policy?
Si no puedes responder a la primera pregunta con certeza, ese es tu primer trabajo.
Reto
¿Por qué KMS obliga a esperar entre 7 y 30 días para borrar una clave, en vez de eliminarla al instante?
▸Mostrar solución
Porque borrar la llave hace ilegibles para siempre todos los datos cifrados con ella: no hay recuperación. La espera es una red de seguridad contra borrados accidentales o maliciosos: durante ese plazo puedes cancelar la eliminación. Mientras tanto la clave queda deshabilitada, así que detectas rápido si algo dependía de ella.
Reto
Guardas la data key cifrada en el mismo bucket que el objeto cifrado. ¿No es eso dejar la llave bajo el felpudo?
▸Mostrar solución
No, porque la data key está cifrada con la KEK de KMS, que nunca sale del servicio. Quien robe
el bucket se lleva el objeto cifrado y la data key cifrada, y ninguno sirve sin poder llamar a
Decrypt sobre esa KEK, lo cual exige permisos que controla la key policy. El control de acceso a
la KEK, no el esconder la data key, es lo que protege los datos.
En resumen#
- La seguridad real depende de la gestión de claves: generación en HSM, rotación, deshabilitación y una destrucción con red de seguridad (espera de 7–30 días en KMS).
- Envelope encryption: la KEK de KMS cifra una data key que cifra los datos; la data key en claro se borra y la cifrada se guarda al lado. Escala sin exponer la clave maestra.
- Rotar no re-cifra lo antiguo; para eso hay que re-cifrar explícitamente.
- En KMS manda la key policy: IAM solo funciona si la política lo delega, y por eso un admin IAM puede quedarse sin acceso a una llave. Usa grants para delegación temporal.
- Multi-región y entre cuentas permiten descifrar en otra región o autorizar a otra cuenta; úsalos con key policies de mínimo privilegio.