KMS a fondo

Casi todo el cifrado en reposo de tu cuenta AWS cuelga de AWS KMS: RDS, EBS, S3, Secrets Manager, los backups. Por eso la pregunta “¿quién puede usar esta llave?” es una de las más importantes que te vas a hacer, y su respuesta no está donde la mayoría la busca. No la decide (solo) IAM: la decide, en primer lugar, un documento pegado a la propia llave: la key policy. Entender esa diferencia es lo que separa un cifrado que protege de uno que da falsa sensación de seguridad.

Este nota asume que ya sabes qué es el envelope encryption y por qué KMS cifra data keys en vez de tus datos directamente. Si no, repásalo primero en Criptografía · Gestión de claves; aquí nos centramos en el control de acceso a las llaves.

La key policy: el documento que realmente decide#

Cada KMS key lleva exactamente una key policy, una política basada en recurso. A diferencia de un bucket o una cola —donde la política de recurso es opcional y suele ser secundaria frente a IAM— en KMS la key policy es el documento primario: sin una declaración que lo permita, ningún permiso IAM basta.

Cuando creas una llave desde la consola o con la API, AWS aplica una key policy por defecto cuyo corazón es esta declaración:

{
  "Sid": "EnableIAMUserPermissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Aquí está el detalle que confunde a todo el mundo: ese :root no es el usuario root. El principal de cuenta arn:aws:iam::111122223333:root representa a la cuenta entera y significa: “delega los permisos sobre esta llave en las políticas IAM de la cuenta”. Es decir, esa declaración es la que habilita que IAM tenga algo que decir sobre la llave. Si la quitas, IAM deja de poder conceder acceso y solo valen los principals nombrados explícitamente en la key policy.

KMS: la key policy decide quién usa la llave

Protección de datos · KMS

Paso 1 de 5La llave y dos peticiones

La KMS key cifra la base de datos de Citas. Dos principals piden Decrypt: el rol de la aplicación y un administrador IAM todopoderoso.

Key policy ↔ IAM: cómo se combinan#

Para que un principal dentro de la misma cuenta haga una operación como kms:Decrypt, tienen que cumplirse las dos condiciones a la vez:

La key policy permite el acceso: o bien nombra al principal directamente, o bien incluye la declaración EnableIAMUserPermissions que delega en IAM.
La política IAM del principal permite la acción (kms:Decrypt sobre esa llave).

Es un AND. Y de ese AND sale el resultado más contraintuitivo de KMS:

El mismo mecanismo, bien usado, es una defensa potente: una llave que cifra backups puede tener una key policy que solo permita a un rol de restauración y a nadie más, de forma que ni un administrador con credenciales comprometidas pueda leer esos backups.

Grants: delegación temporal y de grano fino#

Editar la key policy en cada operación no escala. Para delegación programática, temporal y revocable existen los grants. Un grant concede operaciones concretas (Decrypt, GenerateDataKey, ReEncrypt…) a un principal, opcionalmente restringidas por un encryption context, y se puede revocar después.

Así es como los servicios de AWS usan tus llaves sin que tengas que nombrarlos en la key policy: cuando creas un volumen EBS cifrado, EC2 crea un grant sobre tu llave para poder descifrarlo al arrancar. Por eso verás en muchas key policies una declaración que permite kms:CreateGrant solo cuando es para un recurso de AWS:

{
  "Sid": "AllowGrantsForAWSResources",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-citas" },
  "Action": ["kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant"],
  "Resource": "*",
  "Condition": {
    "Bool": { "kms:GrantIsForAWSResource": "true" }
  }
}

En resumen: hay tres vías para autorizar el uso de una llave —la key policy (nombrando al principal), IAM (si la key policy delega) y los grants— pero la key policy sigue siendo el marco que lo gobierna todo.

Rotación: automática vs manual#

Rotar una llave es generar material criptográfico nuevo. KMS ofrece tres modos:

Activas la rotación y KMS genera material nuevo cada 365 días por defecto. Desde 2024 puedes fijar un periodo personalizado con RotationPeriodInDays (mínimo 90 días). KMS conserva todo el material anterior: cuando descifras un texto viejo, elige automáticamente el material con el que se cifró, así que no hay que recifrar nada ni tocar la aplicación. Solo está disponible para llaves simétricas de cifrado con material generado por KMS (AWS_KMS).

aws kms enable-key-rotation \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --rotation-period-in-days 180

Si necesitas rotar ya (por ejemplo, tras una sospecha de compromiso), lanzas una rotación on-demand, tengas o no activada la automática. No altera el calendario de la automática.

aws kms rotate-key-on-demand \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

Para lo que KMS no rota solo —llaves asimétricas, HMAC, con material importado (EXTERNAL) o en un custom key store— rotas “a mano”: creas una llave nueva y apuntas tu alias a ella. El alias es la clave para que la aplicación no cambie de código.

aws kms update-alias \
  --alias-name alias/citas-rds \
  --target-key-id <nueva-key-id>

Llaves multi-región#

Una multi-Region key es un conjunto de llaves relacionadas —una primaria y sus réplicas en otras regiones— que comparten el mismo material criptográfico y el mismo Key ID (con distinto ARN por región). Su utilidad: un texto cifrado por la llave en eu-west-1 lo puede descifrar la réplica en us-east-1 sin llamadas entre regiones. Son imprescindibles para DR, backups entre regiones o firmas que deben verificarse en varias.

Ojo a las implicaciones de seguridad: cada réplica tiene su propia key policy, así que el acceso se gobierna región a región, pero el material es el mismo. La rotación es una propiedad compartida: la activas en la primaria y KMS copia el material nuevo (cifrado, nunca en claro) a todas las réplicas.

Cifrado entre cuentas#

Para que un principal de otra cuenta use tu llave hacen falta dos permisos, uno en cada cuenta:

En tu cuenta (la dueña de la llave): la key policy nombra a la otra cuenta o a su rol como principal permitido.
En la otra cuenta: una política IAM concede a ese rol la acción KMS sobre el ARN de tu llave.

{
  "Sid": "AllowLogArchiveAccount",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:role/replicador" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"],
  "Resource": "*"
}

Es el patrón de Citas para la replicación entre cuentas: el bucket citas-adjuntos en prod replica a la cuenta log-archive, y la llave de destino debe permitir al rol replicador. Como siempre, es un AND: si falta cualquiera de los dos lados, la operación falla.

Tu turno

Audita quién puede descifrar tus datos más sensibles

Elige una llave que cifre datos sensibles en tu trabajo o tu lab (una base de datos, un bucket, los backups).

Lee su key policy (aws kms get-key-policy). ¿Incluye EnableIAMUserPermissions? ¿Qué principals nombra directamente?
Lista los grants (aws kms list-grants). ¿Reconoces todos? ¿Alguno es de un recurso que ya no existe?
¿Está la rotación activada (aws kms get-key-rotation-status)? ¿Con qué periodo?
Pregúntate: si se filtra el rol X, ¿puede descifrar estos datos? ¿Y un admin IAM cualquiera?
Propón un endurecimiento: acotar un principal, añadir una condición kms:ViaService o separar en dos llaves.

Reto

Un usuario tiene kms:Decrypt en su política IAM sobre `*`. ¿Puede descifrar con cualquier llave de la cuenta?

▸Mostrar solución

No necesariamente. Solo podrá con las llaves cuya key policy delegue en IAM (la declaración EnableIAMUserPermissions) o lo nombren. Una llave con una key policy que no delegue en IAM le denegará el acceso aunque su política IAM diga kms:Decrypt sobre *. Key policy AND IAM.

Reto

¿La rotación automática de KMS te obliga a recifrar tus datos?