Quién administra la clave y quién la usa

A diferencia de otros recursos de AWS, una clave de KMS no concede permisos a nadie por defecto, ni siquiera a la cuenta que la creó. La política por defecto de la clave incluye una declaración que da a la cuenta, a través de su principal raíz, el derecho de usar políticas de IAM para repartir acceso a la clave. Sin ella, las políticas de IAM no sirven para dar acceso, y si se borra el único usuario con permiso la clave puede quedar sin administrador.

Esa declaración no es un agujero: es la que permite gobernar la clave desde IAM sin dejarla huérfana.

En la política que crea la consola de AWS hay dos grupos: administradores de la clave, que pueden cambiar su política, rotarla o programar su borrado pero no cifran ni descifran, y usuarios de la clave, que cifran y descifran pero no la administran. La separación se rompe con facilidad: como un administrador puede editar la política, puede darse a sí mismo el permiso de uso. La defensa es doble: no poner a la misma identidad en los dos grupos y vigilar en el registro los cambios de política.

La separación de funciones no se cumple solo en el papel: se comprueba mirando quién aparece en ambos grupos.

Abre el laboratorio y lee la política de la clave de contratos. Cruza la lista de principales de la declaración de administradores con la de la declaración de uso, y busca el que está en las dos.

Una clave puede aceptar un principal comodín cuando una condición lo limita: por ejemplo, solo la propia cuenta y solo a través de un servicio concreto. Sin condición, el comodín deja el descifrado abierto a cualquier identidad. En la política de la clave de pedidos hay dos declaraciones con comodín: una lleva condiciones y la otra no. Anota el identificador de la que no las lleva.

En Key Vault, administrar el vault (plano de control) y leer sus datos (plano de datos) son permisos distintos. Pero si el vault usa el modelo de política de acceso, quien tiene el rol Contributor en el plano de control puede modificar esa política y concederse acceso a los datos. El criterio de Quebrada Alta pide permisos de datos con roles de datos y no con Contributor. Revisa qué grupo está en esa situación sobre el vault que usa política de acceso.