Gestión de Claves, Acceso entre Cuentas y Diseño de CMK con KMS y Envelope Encryption en AWS
_Category: Data Protection_
Cifrar los datos no sirve de nada si las claves de cifrado no están protegidas. AWS KMS (Key Management Service) existe precisamente para resolver ese problema. En el examen SCS-C03, KMS aparece entrelazado con S3, EBS, RDS y Secrets Manager en escenarios complejos que exigen entender los tipos de clave, el modelo de permisos y el flujo de Envelope Encryption. Una vez que interiorices estos patrones, la mayoría de las preguntas sobre KMS se resolverán casi de forma automática.
---
El problema que resuelve KMS: el riesgo de gestionar claves manualmente
¿Qué significa gestionar claves de cifrado por tu cuenta? Imagina que guardas objetos valiosos en una caja fuerte, pero dejas la llave pegada con cinta adhesiva en el cajón del escritorio. En el mundo del software, los antipatrones equivalentes son: incrustar una clave AES-256 directamente en el código fuente, almacenarla en texto plano como variable de entorno, o guardarla en el disco local del servidor.
AWS KMS resuelve estos problemas de tres maneras. Primero, el material de clave (key material) vive dentro de un HSM (Hardware Security Module): ni AWS ni el cliente pueden extraer la clave maestra en texto plano. Segundo, toda operación de cifrado y descifrado pasa por la API de KMS, lo que deja un registro de auditoría completo en CloudTrail. Tercero, ofrece un control de acceso granular integrado con IAM, aplicable clave por clave.
En el examen, cuando veas las palabras clave «registro de auditoría», «rastreo de acceso a claves» o «gestión centralizada de claves», la respuesta apunta a KMS. Si el enunciado exige «control físico directo del hardware HSM», entonces el camino lleva a CloudHSM.
---
Tipos de clave: Customer Managed Key, AWS Managed Key y AWS Owned Key
KMS ofrece tres tipos de claves. La diferencia es similar a comprar tu propio vehículo, alquilar un coche de alquiler o tomar un taxi: el nivel de control cambia radicalmente en cada caso.
| Aspecto | Customer Managed Key (CMK) | AWS Managed Key | AWS Owned Key | |---------|---------------------------|-----------------|---------------| | Quién la crea | El cliente | AWS (por servicio, automática) | AWS | | Edición de Key Policy | Sí | No | No | | Rotación | Manual o automática (anual) | Automática (anual) | Gestionada por AWS | | Logs en CloudTrail | Registros detallados | Registrados | No expuestos | | Coste | 1 USD/mes por clave + llamadas API | Gratuita | Gratuita | | Ejemplo de uso | CMK propia para cifrar S3 o EBS | Clave predeterminada de S3 SSE-KMS, cifrado básico de RDS | Clave interna de S3 SSE-S3 | | Compartir entre cuentas | Sí (controlado por Key Policy) | No | No |
Cuando el enunciado diga «quiero controlar directamente la política de claves», «necesito usar la clave desde otra cuenta» o «debo desactivar el acceso de inmediato», la respuesta correcta es siempre Customer Managed Key (CMK). AWS Managed Key es cómoda, pero el cliente no puede editar su Key Policy.
Hay una trampa frecuente relacionada con la rotación: las CMK creadas con Imported Key Material no admiten rotación automática. En ese caso, la práctica recomendada oficial es crear una nueva CMK y reasignar el KMS Alias, sin tocar el código de la aplicación.
!3 tipos de claves de KMS
Cómo funciona Envelope Encryption
Envelope Encryption es el concepto central de KMS. Visualízalo como un sobre sellado: dentro del sobre hay una contraseña escrita en papel, y el sobre en sí está bloqueado con la llave de una caja fuerte. En la práctica, los datos no se cifran directamente con KMS; en su lugar se genera una Data Key (DEK) temporal para cifrar los datos, y esa DEK se cifra a su vez con la clave maestra (CMK) en KMS. Es un proceso de dos etapas.
Flujo de cifrado: llamada a la API GenerateDataKey → KMS devuelve la DEK en texto plano y la DEK cifrada → se cifran los datos localmente con la DEK en texto plano → se borra la DEK en texto plano de la memoria de inmediato → se almacenan juntos los datos cifrados y la DEK cifrada.
Flujo de descifrado: se envía la DEK cifrada a la API Decrypt de KMS → KMS devuelve la DEK en texto plano → se descifran los datos → se borra la DEK en texto plano de inmediato.
Esta arquitectura tiene dos ventajas clave. Los datos de gran volumen se procesan localmente con rapidez (KMS solo maneja directamente bloques de hasta 4 KB), y basta con desactivar la CMK para que todas las DEK queden inutilizables, bloqueando el acceso a los datos de forma instantánea.
Trampa de examen: para el cifrado en el lado del cliente (CSE), no basta con kms:Encrypt y kms:Decrypt. Hace falta añadir kms:GenerateDataKey para generar la DEK. En las cargas multiparte de S3, los archivos pequeños solo requieren kms:GenerateDataKey, pero la fase CompleteMultipartUpload de archivos grandes también necesita kms:Decrypt.
---
Modelo de permisos: las tres capas de Key Policy, IAM Policy y Grant
Los permisos de KMS funcionan con tres capas superpuestas. Imagina el sistema de acceso a un edificio corporativo para entender cómo encajan.
| Capa | Analogía | Característica | Momento de aplicación | |------|----------|----------------|-----------------------| | Key Policy | Política maestra del edificio | Política basada en recurso adjunta directamente a la clave. IAM Policy solo es efectiva si Key Policy lo permite primero | Siempre activa | | IAM Policy | Credencial del empleado | Política basada en identidad (adjunta a rol o usuario). Solo válida si Key Policy delega en la raíz de la cuenta | Siempre activa | | Grant | Autorización temporal | Delega operaciones concretas en un Principal específico de forma temporal. Uso habitual interno de servicios AWS (EBS, ECS, etc.) con CMK del cliente | Efectiva de inmediato; puede expirar o revocarse |
El principio más importante: si en Key Policy no aparece el Principal raíz de la cuenta (), ninguna IAM Policy de esa cuenta podrá acceder a la clave, por muy permisiva que sea. Si falta esa delegación a la raíz, la clave se vuelve irrecuperable. Al crear claves desde la consola de KMS se incluye automáticamente, pero al hacerlo con la API o IaC hay que añadirlo de forma explícita.
La condición kms:ViaService permite el uso de la clave solo cuando la solicitud proviene de un servicio AWS concreto. Es como una credencial válida únicamente si entras por la puerta principal. Añadir en Key Policy permite que solo S3 en esa región use la clave; las llamadas directas a la API de KMS quedan bloqueadas.
La condición kms:EncryptionContext verifica el contexto de cifrado. Los datos cifrados con no pueden descifrarse sin ese mismo contexto. Es un enlace criptográfico que previene el descifrado accidental de datos de producción en entornos de desarrollo o pruebas.
Grant es la herramienta adecuada cuando necesitas delegar permisos temporalmente sin modificar Key Policy. AWS lo usa internamente cuando conecta un volumen EBS a una instancia EC2. Para control de acceso a largo plazo, lo recomendable es Key Policy o IAM Policy.
---
Acceso entre cuentas y patrones con Multi-Region Key
La clave del acceso entre cuentas (Cross-Account) a claves KMS es que ambos lados deben permitirlo explícitamente. Key Policy de la cuenta A debe autorizar al Principal de la cuenta B, y IAM Policy de la cuenta B debe conceder los permisos correspondientes (por ejemplo, kms:Decrypt) al rol que los necesite. Aunque Key Policy permita a la cuenta B, si IAM Policy de esa cuenta no está configurada, el acceso será denegado.
Al copiar snapshots de EBS entre cuentas, para eliminar la dependencia de la CMK de la cuenta origen conviene re-cifrar durante la copia con la CMK de la cuenta de destino. Así, aunque la cuenta origen se vea comprometida, los snapshots de respaldo permanecen bajo el control independiente de la CMK de la cuenta de destino.
La condición aws:PrincipalOrgID permite con un solo identificador de organización que todas las cuentas miembro accedan, de modo que las cuentas nuevas queden cubiertas automáticamente sin necesidad de actualizar Key Policy.
Multi-Region Key replica una clave principal (primary key) en varias regiones. Las claves replicadas comparten el mismo identificador y el mismo material de clave, por lo que los datos cifrados en la región A pueden descifrarse con la misma clave en la región B. Combinado con la replicación multirregión de Secrets Manager, desaparece la carga de gestionar claves independientes por región.
Imported Key Material permite traer a KMS el material de clave generado en un HSM externo u otro sistema. Al no soportar rotación automática, para cumplir con políticas de rotación anual hay que crear una nueva CMK y reasignar el Alias de forma manual. Eliminar el Imported Key Material de inmediato hace que todos los datos cifrados con esa clave queden irrecuperables al instante, lo que satisface requisitos del tipo «bloqueo en menos de 24 horas».
---
Servicios clave que se integran con KMS
KMS se integra con prácticamente todos los servicios de almacenamiento, bases de datos y cómputo de AWS. El cifrado en servidor de S3 (SSE) tiene tres modalidades. SSE-S3 delega la generación y gestión de claves completamente en S3, usando una clave AES-256 única por objeto. SSE-KMS usa la CMK que especifique el cliente y deja registro en CloudTrail para trazabilidad de auditoría. SSE-C requiere que el cliente proporcione la clave en cada solicitud; AWS la usa para cifrar, pero no la almacena.
Al crear un volumen EBS con cifrado activado, la encriptación es transparente usando la CMK de KMS. Los volúmenes ya existentes no pueden cifrarse en caliente: hay que crear un snapshot y aplicar la opción de cifrado al copiarlo. RDS solo permite activar el cifrado en el momento de crear la instancia; para cifrar una instancia existente hay que restaurarla desde un snapshot cifrado.
Secrets Manager cifra los secretos con una CMK de