DEV Community

Cover image for KMS - Automatic key rotation
Luis Eduardo Lunar Guevara
Luis Eduardo Lunar Guevara

Posted on

KMS - Automatic key rotation

#aws #cloudskills #tutorial #kms

Estoy haciendo algunos cambios al newsletter con el objeto de lograr de forma más eficiente el objetivo. ¿Cuál es? No quedarnos solo con una respuesta memorizada para un examen, sino lograr materializar esa respuesta de forma operativa, pues definitivamente haciendo se aprende más que solo leyendo y memorizando.

Vayamos con la pregunta de hoy:

Digital Café Luna is implementing a new application that will use AWS KMS customer managed keys to encrypt sensitive business data. The team will create the KMS keys directly in AWS KMS and will not import any external key material. The security requirement says that the encryption keys must rotate every 12 months with the least operational overhead.

Which solution will meet these requirements?

A. Change the customer managed KMS key policy to enable automatic key rotation.

B. Use AWS managed KMS keys instead so AWS rotates the keys automatically.

C. Schedule an AWS Lambda function to rotate the backing key of each KMS key.

D. Enable automatic key rotation on each customer managed KMS key.

✅ Correct answer: D

La pregunta nos entrega tres cosas clave:

  1. Son customer managed KMS keys.
  2. El key material lo genera AWS KMS.
  3. La rotación debe ocurrir cada 12 meses con least operational overhead.

En este caso, no hay que inventar nada con Lambda y mucho menos cambiarse a AWS managed keys. AWS KMS permite habilitar automatic key rotation en KMS keys simétricas administradas por el cliente cuando el key material ha sido generado por KMS.

¿Por qué las otras son incorrectas?

A: La rotación automática no se activa modificando la key policy. La key policy controla permisos sobre la key y la rotación se habilita como configuración de la KMS key, por consola, API o CLI.
B: AWS managed keys sí rotan automáticamente cada año, pero la pregunta dice que Digital Café Luna va a crear customer managed KMS keys.
C: No aplica para nada, el backing key lo maneja KMS internamente. Además, la pregunta pide least operational overhead; construir algo manual, como una Lambda va contra el caso de uso.

Ahora llevemos esto a la práctica y validemos desde CLI.

Nos ubicamos en la región us-east-1 (N. Virginia). Este tipo de pregunta normalmente cae dentro del dominio de Data Protection de la certificación AWS Certified Security – Specialty (SCS-C03), y lo que se espera es que entendamos cuándo aplica la rotación automática en AWS KMS y cómo habilitarla sin complicar el diseño.
Como es una certificación de especialización, lo haremos en lo posible vía CLI (más directo, más verificable y más cercano a una operación real).

Paso 1 — Creamos nuestra customer managed KMS key

Vamos a crearla simétrica y el material criptográfico lo genera AWS KMS, tal como dice la pregunta.

REGION="us-east-1"
LAB_ID="scs-kms-rotation"
KMS_ALIAS="alias/${LAB_ID}"
Enter fullscreen mode Exit fullscreen mode 
KEY_ID=$(aws kms create-key \
  --region "$REGION" \
  --description "Lab - KMS rotación automática de la key" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS \
  --query "KeyMetadata.KeyId" \
  --output text)
Enter fullscreen mode Exit fullscreen mode 
aws kms create-alias \
  --region "$REGION" \
  --alias-name "$KMS_ALIAS" \
  --target-key-id "$KEY_ID"

echo "KEY_ID=$KEY_ID"
echo "KMS_ALIAS=$KMS_ALIAS"
Enter fullscreen mode Exit fullscreen mode

Si todo salió bien, ya tenemos una customer managed KMS key creada directamente en KMS, podemos comprobarlo de esta forma:

aws kms describe-key \
  --region "$REGION" \
  --key-id "$KEY_ID" \
  --query "KeyMetadata.{KeyId:KeyId,Origin:Origin,KeyUsage:KeyUsage,State:KeyState}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

Comprobación de creación de KMS key

Validación de metadata de la KMS key

Paso 2 — Validemos el estado de la rotación

Validemos cómo está el estado de la rotación, así tenemos un antes y un después que nos permitirá comprobar que el cambio realmente ocurrió.

aws kms get-key-rotation-status \
  --region "$REGION" \
  --key-id "$KEY_ID"
Enter fullscreen mode Exit fullscreen mode

Deberíamos tener como respuesta algo así.

{
  "KeyRotationEnabled": false,
  "KeyId": "arn:aws:kms:us-east-1:ACCOUNT_ID:key/KEY_ID"
}
Enter fullscreen mode Exit fullscreen mode

Si todo está ok, entonces la key no solo existe, sino que la rotación automática no se ha habilitado.

Paso 3 — Habilitamos la rotación automática y validamos

Ahora vamos con lo que pide la pregunta, habilitar la rotación automática directamente sobre la customer managed KMS key.

aws kms enable-key-rotation \
  --region "$REGION" \
  --key-id "$KEY_ID"
Enter fullscreen mode Exit fullscreen mode

Este comando no muestra salida, en AWS CLI debemos tomar una buena “mala costumbre”, ejecutar un comando y luego validarlo enseguida, no demos nada por hecho, nos puede salir caro!!!

Ahora ejecutamos nuevamente la validación del estado de rotación que hicimos en el paso 2.

aws kms get-key-rotation-status \
  --region "$REGION" \
  --key-id "$KEY_ID"
Enter fullscreen mode Exit fullscreen mode

Ahora deberíamos tener algo diferente, el parámetro KeyRotationEnabled debería cambiar a true.

{
  "KeyRotationEnabled": true,
  "KeyId": "arn:aws:kms:us-east-1:ACCOUNT_ID:key/KEY_ID"
}
Enter fullscreen mode Exit fullscreen mode

Con esto ya tenemos validada la respuesta, la rotación automática se habilitó como configuración de la KMS key, no tocamos la key policy, no usamos Lambda y tampoco cambiamos a AWS managed keys.

Clean up

Ahora hagamos el clean up para evitar costos no deseados.

Recordemos que las keys en AWS KMS no se eliminan enseguida, debemos programar la eliminación y esperar.

Primero eliminamos el alias:

aws kms delete-alias \
  --region "$REGION" \
  --alias-name "$KMS_ALIAS"
Enter fullscreen mode Exit fullscreen mode

Luego programamos la eliminación de la KMS key:

aws kms schedule-key-deletion \
  --region "$REGION" \
  --key-id "$KEY_ID" \
  --pending-window-in-days 7
Enter fullscreen mode Exit fullscreen mode

Y validamos el estado final:

aws kms describe-key \
  --region "$REGION" \
  --key-id "$KEY_ID" \
  --query "KeyMetadata.{KeyState:KeyState,DeletionDate:DeletionDate}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

La key debería quedar en estado PendingDeletion.

Cierre

Antes de terminar, gracias por acompañarme y por compartir estos labs si consideras que pueden ayudar a alguien más.

Esta será la nueva dinámica del newsletter: tomar una pregunta tipo examen, entender por qué una respuesta es correcta, revisar por qué las otras no aplican y luego llevarlo a una validación práctica.

La idea es que sea más fácil de seguir y, sobre todo, más útil para quienes estamos aprendiendo haciendo.

Antes de cerrar por hoy, podemos revisar el tema en estas fuentes:

Hasta la próxima.

Top comments (0)