Concesiones en AWS KMS - AWS Key Management Service

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Concesiones en AWS KMS

Una concesión es un instrumento de política que permite que las principales entidades de AWS usen claves KMS en operaciones criptográficas. También puede permitirles ver una clave KMS (DescribeKey) y crear y administrar concesiones. Al autorizar el acceso a una clave KMS, se consideran concesiones junto con políticas de claves y políticas de IAM. Las concesiones se utilizan a menudo para permisos temporales, ya que puede crear uno, utilizar sus permisos y eliminarlo sin cambiar las políticas de claves o las políticas de IAM.

Las concesiones son comúnmente utilizadas por los servicios de AWS que se integran con AWS KMS para cifrar sus datos en reposo. El servicio crea una concesión en nombre de un usuario de la cuenta, utiliza sus permisos y retira la concesión tan pronto como finalice su tarea. Para obtener más detalles sobre los servicios de AWS, consulte Cómo los servicios de AWS usan AWS KMS o el tema Cifrado en reposo en la Guía del usuario o en la Guía para desarrolladores del servicio.

En Trabajar con concesiones puede consultar ejemplos de código que muestran cómo funcionan las concesiones en varios lenguajes de programación.

Acerca de las concesiones

Las concesiones son un mecanismo de control de acceso muy flexible y útil. Al crear una concesión para una clave de KMS, la concesión permite a las entidades principales beneficiarias llamar a las operaciones de concesión especificadas en la clave de KMS siempre que se cumplan todas las condiciones especificadas en la concesión.

  • Cada concesión permite el acceso a exactamente una clave KMS. Puede crear una concesión para una clave KMS en una Cuenta de AWS diferente.

  • Una concesión puede permitir el acceso a una clave KMS, pero no denegar el acceso.

  • Cada concesión tiene una entidad principal beneficiaria. La entidad principal beneficiaria puede representar una o más identidades en la misma Cuenta de AWS que la clave de KMS o en una cuenta diferente.

  • Una concesión solo puede permitir operaciones de concesión. Las operaciones de concesión deben estar respaldadas por la clave KMS de la concesión. Si especificas una operación no admitida, la CreateGrantsolicitud fallará con una ValidationError excepción.

  • La entidad principal beneficiaria puede utilizar los permisos que la concesión le otorga sin especificar la concesión, tal como lo haría si los permisos procedieran de una política de clave o de una política de IAM. Sin embargo, dado que la API de AWS KMS sigue un modelo de coherencia final, al crear, retirar o revocar una concesión, es posible que haya un breve retraso antes de que el cambio esté disponible a través de AWS KMS. Para utilizar los permisos de una concesión inmediatamente, use un token de concesión.

  • Un beneficiario principal autorizado puede eliminar la concesión (retirarla o revocarla). Al eliminar una concesión se eliminan todos los permisos permitidos por la concesión. No es necesario averiguar qué políticas se deben agregar o quitar para deshacer la concesión.

  • AWS KMS limita el número de concesiones en cada clave KMS. Para obtener más detalles, consulte Concesiones por clave KMS: 50 000.

Tenga cuidado al crear concesiones y al dar permiso a otros para crear concesiones. El permiso para crear subvenciones tiene implicaciones de seguridad, al igual que permitir el PutKeyPolicy permiso kms: para establecer políticas.

  • Los usuarios con permiso para crear concesiones para una clave KMS (kms:CreateGrant) puede usar una concesión para permitir a los usuarios y roles, incluyendo los servicios de AWS, para utilizar la clave KMS. Los principales beneficiarios pueden ser identidades en su propia Cuenta de AWS o identidades en una cuenta u organización diferente.

  • Las concesiones solo pueden permitir un subconjunto de operaciones de AWS KMS. Puede utilizar concesiones para permitir a los principales beneficiarios ver la clave KMS, utilizarla en operaciones criptográficas y crear y retirar concesiones. Para obtener más información, consulte Operaciones de concesión. También puede utilizar restricciones de la concesión para limitar los permisos de una concesión para una clave de cifrado simétrica.

  • Las entidades principales pueden obtener permiso para crear concesiones a partir de una política de claves o de una política de IAM. Las entidades principales que reciben el permiso kms:CreateGrant de una política puede crear concesiones para cualquier operación de concesión en la clave KMS. Estas entidades principales no necesitan tener el permiso que conceden en la clave. Cuando se permite permiso kms:CreateGrant en una política, puede usar condiciones de política para limitar este permiso.

  • Los principales beneficiarios también pueden obtener permiso para crear concesiones a partir de una concesión. Estas principales entidades solo pueden delegar los permisos que se les concedieron, incluso si tienen otros permisos de una política. Para obtener más detalles, consulte Concesión del permiso CreateGrant .

Para obtener ayuda con los conceptos relacionados con las concesiones, consulte Terminología de la concesión.

Conceptos de concesión

Para utilizar las concesiones de manera efectiva, deberá comprender los términos y conceptos que AWS KMS utiliza.

Restricción de concesiones

Condición que limita los permisos de la concesión. En la actualidad, AWS KMS admite restricciones de concesión basadas en el contexto de cifrado en la solicitud de una operación criptográfica. Para obtener más detalles, consulte Uso de restricciones de concesiones.

ID de concesión

El identificador único de una concesión de una clave KMS. Puedes usar un identificador de concesión, junto con un identificador clave, para identificar una concesión en una RevokeGrantsolicitud RetireGranto solicitud.

Operaciones de concesión

Las operaciones AWS KMS que puede permitir en una concesión. Si especificas otras operaciones, la CreateGrantsolicitud fallará con una ValidationError excepción. Estas son también las operaciones que aceptan un token de concesión. Para obtener información detallada sobre estos permisos, consulte la AWS KMS permisos.

Estas operaciones de concesión representan realmente permiso para usar la operación. Por lo tanto, para la operación ReEncrypt, puede especificar ReEncryptFrom, ReEncryptTo o ambos ReEncrypt*.

Las operaciones de concesión son:

Las operaciones de concesión que usted permita deben ser compatibles con la clave KMS de la concesión. Si especificas una operación no admitida, la CreateGrantsolicitud fallará con una ValidationError excepción. Por ejemplo, las concesiones para claves KMS de cifrado simétricas no pueden permitir las operaciones Sign (Firmar), Verify (Verificar), GenerateMac o VerifyMac. Las concesiones para claves CMK asimétricas no pueden permitir operaciones que generen claves de datos o pares de claves de datos.

Token de concesión

La API de AWS KMS sigue un modelo de coherencia final. Al crear una concesión, es posible que haya un breve retraso antes de que el cambio esté disponible a través de AWS KMS. Por lo general, el cambio tarda menos de unos segundos en propagarse por todo el sistema, pero en algunos casos puede tardar varios minutos. Si intenta utilizar una concesión antes de que se propague por completo por el sistema, es posible que obtenga un error de acceso denegado. Un token de concesión le permite hacer referencia a la concesión y utilizar los permisos de concesión inmediatamente.

Un token de concesión es una cadena única, no secreta, de longitud variable, codificada en base64 que representa una concesión. Puede usar el token de concesión para identificar la concesión en cualquier operación de concesión. Sin embargo, debido a que el valor del token es un resumen hash, no revela ningún detalle sobre la concesión.

Un token de concesión está diseñado para utilizarse solo hasta que la concesión se haya propagado por completo a través de AWS KMS. Después de eso, el principal beneficiario puede utilizar el permiso de la concesión sin proporcionar un token de concesión ni cualquier otra prueba de la concesión. Puede usar un token de concesión en cualquier momento, pero una vez que la concesión tenga una consistencia final, AWS KMS utiliza la concesión para determinar los permisos, no el token de concesión.

Por ejemplo, el siguiente comando llama a la GenerateDataKeyoperación. Utiliza un token de concesión para representar la concesión que da a la persona que llama (el principal beneficiario) permiso para llamar a GenerateDataKey en la clave KMS especificada.

$ aws kms generate-data-key \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --key-spec AES_256 \ --grant-token $token

También puede utilizar un token de concesión para identificar una concesión en operaciones que administran concesiones. Por ejemplo, el director que se retira puede usar un token de concesión en una llamada a la RetireGrantoperación.

$ aws kms retire-grant \ --grant-token $token

CreateGrant es la única operación que devuelve un token de concesión. No puede obtener un token de concesión de ninguna otra AWS KMS operación ni del evento de CloudTrail registro de la CreateGrant operación. Las ListRetirableGrantsoperaciones ListGrantsy devuelven el ID de concesión, pero no un token de concesión.

Para obtener más detalles, consulte Uso de un token de concesión.

Principal beneficiario

Las identidades que obtienen los permisos especificados en la concesión. Cada concesión tiene una entidad principal beneficiaria, pero la entidad principal beneficiaria puede representar varias identidades.

El principal del beneficiario puede ser cualquier entidad principal de AWS, incluida una Cuenta de AWS (raíz), un usuario de IAM, un rol de IAM, un rol o usuario federado o un usuario de rol asumido. El principal del beneficiario puede estar en la misma cuenta que la clave KMS o en una cuenta diferente. Sin embargo, el principal beneficiario no puede ser una entidad principal del servicio, un grupo de IAM o una organización de AWS.

nota

Las prácticas recomendadas de IAM desalientan el uso de usuarios de IAM con credenciales a largo plazo. Siempre que sea posible, utilice los roles de IAM, que proporcionan credenciales temporales. Para obtener más información, consulte la sección Prácticas recomendadas de seguridad de IAM en la Guía del usuario de IAM;.

Retiro (de una concesión)

Termina una concesión. Retire una concesión cuando termine de usar los permisos.

La revocación y el retiro de una concesión eliminan la concesión. Sin embargo, el retiro se realiza por medio de una entidad principal especificada en la concesión. La revocación suele realizarla un administrador de claves. Para obtener más detalles, consulte Retiro y revocación de concesiones.

Entidad principal que se va a dar de baja

Una entidad principal que puede retirar una concesión. Puede especificar una entidad principal que se va a dar de baja en una concesión, pero no es necesario. Esta entidad principal que se va a dar de baja puede ser cualquier entidad principal de AWS, incluyendo Cuentas de AWS, usuarios de IAM, roles de IAM, usuarios federados y usuarios de rol asumido. La entidad principal que se va a dar de baja puede estar en la misma cuenta de que la clave KMS o en una cuenta diferente.

nota

Las prácticas recomendadas de IAM desalientan el uso de usuarios de IAM con credenciales a largo plazo. Siempre que sea posible, utilice los roles de IAM, que proporcionan credenciales temporales. Para obtener más información, consulte la sección Prácticas recomendadas de seguridad de IAM en la Guía del usuario de IAM;.

Además de la principal entidad que se da de baja especificada en la concesión, la Cuenta de AWS también puede retirar la concesión en la que se creó. El principal beneficiario puede retirar la concesión, si la concesión admite la operación RetireGrant. Además, la Cuenta de AWS o una Cuenta de AWS que sea la principal entidad que se retira puede delegar el permiso para retirar una concesión a una entidad principal de IAM en la misma Cuenta de AWS. Para obtener más detalles, consulte Retiro y revocación de concesiones.

Revocación (de una concesión)

Termina una concesión. Puede revocar una concesión para denegar activamente los permisos que permite la concesión.

La revocación y el retiro de una concesión eliminan la concesión. Sin embargo, el retiro se realiza por medio de una entidad principal especificada en la concesión. La revocación suele realizarla un administrador de claves. Para obtener más detalles, consulte Retiro y revocación de concesiones.

Consistencia final (para las concesiones)

La API de AWS KMS sigue un modelo de coherencia final. Al crear, retirar o revocar una concesión, es posible que haya un breve retraso antes de que el cambio esté disponible a través de AWS KMS. Por lo general, el cambio tarda menos de unos segundos en propagarse por todo el sistema, pero en algunos casos puede tardar varios minutos.

Puede darse cuenta de este breve retraso si recibe errores inesperados. Por ejemplo, si intenta administrar una nueva concesión o utiliza los permisos en una nueva concesión antes de que se conozca la concesión en toda la AWS KMS, puede que obtenga un error de acceso denegado. Si retira o revoca una concesión, es posible que el principal beneficiario pueda seguir utilizando sus permisos durante un breve período hasta que la concesión se elimine por completo. La estrategia típica es volver a intentar la solicitud, y algunas AWS SDK incluyen el respaldo automático y la lógica de reintento.

AWS KMS tiene características para mitigar este breve retraso.

nota

Los tokens de concesión reemplazan la validez de la concesión hasta que todos los puntos de conexión del servicio se hayan actualizado con el nuevo estado de concesión. En la mayoría de los casos, la consistencia final se logrará en cinco minutos.

Para obtener más información, consulte Coherencia final de AWS KMS.

Prácticas recomendadas para concesiones de AWS KMS

AWS KMS recomienda las siguientes prácticas recomendadas a la hora de crear, usar y administrar concesiones.

  • Limite los permisos de la concesión a los que requiere el principal beneficiario. Utilice el principio de acceso menos privilegiado.

  • Utilice un principal beneficiario específico, como un rol de IAM, y otorgue permiso al principal beneficiario para usar solo las operaciones de API que requieran.

  • Use el contexto de cifrado de restricciones de concesión para asegurarse de que las personas que llaman utilizan la clave KMS para el propósito previsto. Para obtener más información sobre cómo utilizar el contexto de cifrado en una solicitud para proteger sus datos, consulte Cómo proteger la integridad de los datos cifrados mediante el uso AWS Key Management Service y EncryptionContext en el blog sobre AWS seguridad.

    sugerencia

    Utilice la restricción de EncryptionContextEqualconcesión siempre que sea posible. La restricción de EncryptionContextSubsetconcesión es más difícil de usar correctamente. Si necesita usarlo, lea detenidamente la documentación y pruebe la limitación de concesión para asegurarse de que funciona según lo previsto.

  • Suprima concesiones duplicadas. Las concesiones duplicadas tienen la misma clave ARN, acciones de API, principal beneficiario, contexto de cifrado y nombre. Si retira o revoca la concesión original pero deja los duplicados, las concesiones duplicadas sobrantes constituyen escaladas no intencionadas de privilegios. Para evitar duplicar concesiones al volver a intentar una solicitud CreateGrant, utilice el parámetro Name. Para detectar concesiones duplicadas, utilice la ListGrantsoperación. Si crea accidentalmente una concesión duplicada, retírela o revóquela lo antes posible.

    nota

    Las concesiones para las claves administradas por AWS podrían parecer duplicados, pero tienen diferentes beneficiarios principales.

    El campo GranteePrincipal de la respuesta ListGrants generalmente contiene el principal beneficiario de la concesión. Sin embargo, cuando el principal beneficiario de la concesión es un servicio de AWS, el campo GranteePrincipal contiene el servicio principal, que puede representar varios beneficiarios principales distintos.

  • Recuerde que las concesiones no caducan automáticamente. Retire o revoque la concesiones ni bien el permiso ya no sea necesario. Las concesiones que no se eliminan pueden crear un riesgo de seguridad para los recursos cifrados.