ABAC para AWS KMS

El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos basados en atributos. AWS KMS admite ABAC al permitirle controlar el acceso a las claves administradas por el cliente en función de las etiquetas y alias asociados con las claves KMS. Las claves de condición de etiqueta y alias que habilitan ABAC en AWS KMS proporcionan una forma potente y flexible de autorizar a las principales entidades a utilizar claves KMS sin editar políticas ni administrar concesiones. Pero debe usar esta característica con cuidado para que a las principales entidades no se les permita o se les deniegue el acceso inadvertidamente.

Si utiliza ABAC, tenga en cuenta que el permiso para administrar etiquetas y alias es ahora un permiso de control de acceso. Asegúrese de conocer las etiquetas y alias existentes en todas las claves KMS antes de implementar una política que dependa de etiquetas o alias. Tome las precauciones razonables al agregar, eliminar y actualizar alias, y al etiquetar y desetiquetar claves. Otorgue permisos para administrar etiquetas y alias solo a las principales entidades que los necesiten y limite las etiquetas y alias que puedan administrar.

Notas

Cuando se utiliza ABAC para AWS KMS, tenga cuidado al dar permiso a las principales entidades para administrar etiquetas y alias. Cambiar una etiqueta o alias podría permitir o denegar el permiso a una clave KMS. Los administradores de claves que no tienen permiso para cambiar políticas de claves o crear concesiones pueden controlar el acceso a claves KMS si tienen permiso para administrar etiquetas o alias.

Puede que transcurran cinco minutos hasta que los cambios de etiqueta y alias afecten a la autorización de clave KMS. Los cambios recientes pueden ser visibles en las operaciones de API antes de que afecten a la autorización.

Para controlar el acceso a una clave KMS basándose en su alias, debe utilizar una clave de condición. No puede utilizar un alias para representar una clave KMS en el elemento Resource de una declaración de política. Cuando aparece un alias en el elemento Resource, la declaración de política se aplica al alias, no a la clave KMS asociada.

Más información

• Para conocer detalles sobre la compatibilidad de AWS KMS con ABAC, incluidos ejemplos, consulte Usar alias para controlar el acceso a las claves KMS y Uso de etiquetas para controlar el acceso a las claves KMS.

• Para obtener más información general acerca de cómo utilizar etiquetas para controlar el acceso a AWS, consulte ¿Qué es ABAC para AWS? y Control del acceso a recursos de AWS que utilizan etiquetas de recursos en la Guía del usuario de IAM.

Claves de condición de ABAC para AWS KMS

Para autorizar el acceso a claves KMS en función de sus etiquetas y alias, utilice las siguientes claves de condición en una política de claves o política de IAM.

Clave de condición de ABAC	Descripción	Tipo de política	Operaciones de AWS KMS
leyes: ResourceTag	La etiqueta (clave y valor) en la clave KMS coincide con la etiqueta (clave y valor) o el patrón de etiqueta en la política	Política de IAM únicamente	Operaciones de recursos clave KMS 2
aws:RequestTag/tag-key	La etiqueta (clave y valor) en la solicitud coincide con la etiqueta (clave y valor) o el patrón de etiqueta en la política	Políticas de claves y políticas de IAM1	TagResource, UntagResource
leyes: TagKeys	Las claves de etiqueta de la solicitud coinciden con las claves de etiqueta de la política.	Políticas de claves y políticas de IAM1	TagResource, UntagResource
km: ResourceAliases	Los alias asociados a la clave KMS coinciden con los alias o patrones de alias de la política	Política de IAM únicamente	Operaciones de recursos clave KMS 2
km: RequestAlias	El alias que representa la clave KMS en la solicitud coincide con los patrones de alias o alias de la política.	Políticas de clavessss y políticas de IAM1	Operaciones criptográficas, DescribeKeyGetPublicKey

¹Cualquier clave de condición que se pueda utilizar en una política de clave también se puede utilizar en una política de IAM, pero solo si la política de claves lo permite.

²Una operación de recursos de clave KMS es una operación autorizada para una clave KMS en particular. Para identificar las operaciones de recursos clave KMS, en la tabla de permisos AWS KMS, busque un valor de la clave KMS en la columna Resources para la operación.

Por ejemplo, puede utilizar estas claves de condición para crear las siguientes políticas.

• Una política de IAM con kms:ResourceAliases que habilita el permiso para usar claves KMS con un alias o patrón de alias en particular. Esto es un poco diferente de las políticas que se basan en etiquetas: aunque puede usar patrones de alias en una política, cada alias debe ser único en una Cuenta de AWS y región. Esto le permite aplicar una política a un conjunto seleccionado de claves KMS sin enumerar los ARN clave de las claves KMS en la declaración de política. Para agregar o quitar claves KMS del conjunto, cambie el alias de la clave KMS.

• Una política de claves con kms:RequestAlias que permite a las principales entidades usar una clave KMS en una operación Encrypt, pero solo cuando la solicitud Encrypt utiliza ese alias para identificar la clave KMS.

• Una política de IAM con aws:ResourceTag/tag-key que deniega permiso para utilizar claves KMS con una clave de etiqueta y un valor de etiqueta en concreto. Esto le permite aplicar una política a un conjunto seleccionado de claves KMS sin enumerar los ARN clave de las claves KMS en la declaración de política. Para agregar o quitar claves KMS del conjunto, etiqueta o desmarca de la clave KMS.

• Una política de IAM con aws:RequestTag/tag-key que permite a las principales entidades eliminar solo etiquetas de claves KMS de "Purpose"="Test"

• Una política de IAM con aws:TagKeys que deniega el permiso para etiquetar o desetiquetar una clave KMS con una clave de etiqueta Restricted.

ABAC hace que la administración de accesos sea flexible y escalable. Por ejemplo, puede utilizar la clave de condición aws:ResourceTag/tag-key para crear una política de IAM que permita a las principales entidades utilizar una clave KMS para operaciones especificadas solo cuando la clave KMS tenga una etiqueta Purpose=Test. La política se aplica a todas las claves KMS de todas las regiones de la Cuenta de AWS.

Cuando se adjunta a un usuario o rol, la siguiente política de IAM permite a las principales entidades utilizar todas las claves KMS existentes con una etiqueta Purpose=Test para las operaciones especificadas. Para proporcionar este acceso a claves KMS nuevas o existentes, no es necesario cambiar la política. Solo tiene que adjuntar la etiqueta Purpose=Test a las claves KMS. Del mismo modo, para eliminar este acceso de las claves KMS con una etiqueta Purpose=Test, edite o elimine la etiqueta.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Purpose": "Test"
        }
      }
    }
  ]
}

Sin embargo, si utiliza esta función, tenga cuidado al administrar etiquetas y alias. Agregar, cambiar o eliminar una etiqueta o alias puede permitir o denegar inadvertidamente el acceso a una clave KMS. Los administradores de claves que no tienen permiso para cambiar políticas de claves o crear concesiones pueden controlar el acceso a claves KMS si tienen permiso para administrar etiquetas y alias. Para mitigar este riesgo, considere limitar permisos para administrar etiquetas y alias. Por ejemplo, es posible que exija solo las principales entidades administren etiquetas Purpose=Test. Para más detalles, consulte Usar alias para controlar el acceso a las claves KMS y Uso de etiquetas para controlar el acceso a las claves KMS.

¿Etiquetas o alias?

AWS KMS admite ABAC con etiquetas y alias. Ambas opciones proporcionan una estrategia de control de acceso flexible y escalable, pero son ligeramente diferentes entre sí.

Es posible que decida usar etiquetas o alias en función de sus patrones de uso de AWS particulares. Por ejemplo, si ya ha otorgado permisos de etiquetado a la mayoría de los administradores, podría ser más fácil controlar una estrategia de autorización basada en alias. O bien, si está cerca de la cuota de alias por clave KMS, es posible que prefiera una estrategia de autorización basada en etiquetas.

Los siguientes beneficios son de interés general.

Beneficios del control de acceso basado en etiquetas

• Mismo mecanismo de autorización para diferentes tipos de recursos de AWS.

  Puede utilizar la misma etiqueta o clave de etiqueta para controlar el acceso a varios tipos de recursos, como un clúster de Amazon Relational Database Service (Amazon RDS), un volumen de Amazon Elastic Block Store (Amazon EBS) y una clave KMS. Esta función permite varios modelos de autorización diferentes que son más flexibles que el control de acceso basado en roles tradicional.

• Autorizar el acceso a un grupo de claves KMS.

  Puede utilizar etiquetas para administrar el acceso a un grupo de claves KMS en la misma región y Cuenta de AWS. Asigne la misma etiqueta o clave de etiqueta a las claves KMS que elija. A continuación, cree una declaración easy-to-maintain de política sencilla que se base en la etiqueta o la clave de la etiqueta. Para agregar o quitar una clave KMS de su grupo de autorización, agregue o elimine la etiqueta; no necesita editar la política.

Beneficios del control de acceso basado en alias

• Autorizar el acceso a operaciones criptográficas basadas en alias.

  La mayoría de las condiciones políticas de atributos basadas en solicitudes, incluida aws:RequestTag/tag-key, solo afectan a las operaciones que agregan, editan o eliminan el atributo. Sin embargo, la clave de RequestAlias condición kms: controla el acceso a las operaciones criptográficas en función del alias utilizado para identificar la clave KMS de la solicitud. Por ejemplo, puede concederle permiso a una entidad principal para usar una clave KMS en una operación Encrypt pero solo cuando el valor del parámetro KeyId sea alias/restricted-key-1. Para satisfacer esta condición se requiere todo lo siguiente:

  • La clave KMS debe estar asociada a ese alias.

  • La solicitud debe utilizar el alias para identificar la clave KMS.

  • La entidad principal debe tener permiso para utilizar la clave KMS en función de la condición kms:RequestAlias.

  Esto resulta especialmente útil si las aplicaciones utilizan comúnmente nombres de alias o ARN de alias para hacer referencia a claves KMS.

• Proporcione permisos muy limitados.

  Un alias debe ser único en una región y Cuenta de AWS. Como resultado, dar acceso a las principales entidades a una clave KMS basada en un alias puede ser mucho más restrictivo que darles acceso basado en una etiqueta. A diferencia de los alias, las etiquetas se pueden asignar a varias claves KMS de la misma cuenta y región. Si lo desea, puede usar un patrón de alias, como alias/test*, para dar acceso a las entidades principales a un grupo de claves KMS en la misma cuenta y Región. Sin embargo, permitir o denegar acceso a un alias en concreto permite un control muy estricto de claves KMS.

Solución de problemas de ABAC para AWS KMS

Controlar el acceso a las claves KMS en función de sus etiquetas y alias es conveniente y potente. Sin embargo, es propenso a algunos errores predecibles que querrá evitar.

Acceso cambiado debido al cambio de etiqueta

Si se elimina una etiqueta o se cambia su valor, se denegará el acceso a la clave KMS a las principales entidades que tengan acceso a una clave KMS basada únicamente en esa etiqueta. Esto también puede ocurrir cuando una etiqueta incluida en una declaración de política de denegación se agrega a una clave KMS. Agregar una etiqueta relacionada con la política a una clave KMS puede permitir el acceso a entidades principales a las que se debe denegar el acceso a una clave KMS.

Por ejemplo, supongamos que una entidad principal tiene acceso a una clave KMS basada en la etiqueta Project=Alpha, como el permiso proporcionado por la siguiente declaración de política de IAM de ejemplo.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IAMPolicyWithResourceTag",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "Alpha"
        }
      }
    }
  ]
}

Si se elimina la etiqueta de esa clave KMS o se cambia el valor de la etiqueta, la entidad principal ya no tiene permiso para usar la clave KMS para las operaciones especificadas. Esto puede resultar evidente cuando el director intenta leer o escribir datos en un AWS servicio que utiliza una clave gestionada por el cliente. Para rastrear el cambio de etiqueta, revise CloudTrail los registros TagResourceo UntagResource las entradas.

Para restaurar el acceso sin actualizar la política, cambie las etiquetas de la clave KMS. Esta acción tiene un impacto mínimo aparte de un breve período de tiempo mientras está surtiendo efecto a lo largo de AWS KMS. Para evitar un error como este, otorgue permisos de etiquetado y desetiquetado solo a las principales entidades que lo necesiten ylimite sus permisos de etiquetado a las etiquetas que necesitan administrar. Antes de cambiar una etiqueta, busque políticas para detectar el acceso que depende de la etiqueta y obtenga claves KMS en todas las regiones que tengan la etiqueta. Podrías considerar la posibilidad de crear una CloudWatch alarma de Amazon cuando cambies determinadas etiquetas.

Cambio de acceso debido al cambio de alias

Si se elimina un alias o se asocia a una clave KMS diferente, se denegará el acceso a la clave KMS a las principales entidades que tengan acceso a la clave KMS basándose únicamente en ese alias. Esto también puede ocurrir cuando se incluye un alias asociado con una clave KMS en una declaración de política de denegación. Agregar un alias relacionado con la política a una clave KMS también puede permitir el acceso a entidades principales a las que se debe denegar el acceso a una clave KMS.

Por ejemplo, la siguiente declaración de política de IAM utiliza la clave de ResourceAliases condición kms: para permitir el acceso a las claves de KMS en distintas regiones de la cuenta con cualquiera de los alias especificados.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:List*",
        "kms:Describe*",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "kms:ResourceAliases": [
            "alias/ProjectAlpha",
            "alias/ProjectAlpha_Test",
            "alias/ProjectAlpha_Dev"
          ]
        }
      }
    }
  ]
}

Para rastrear el cambio de alias, revise CloudTrail los registros y DeleteAliaslas CreateAliasUpdateAliasentradas.

Para restaurar el acceso sin actualizar la política, cambie el alias asociado con la clave KMS. Dado que cada alias se puede asociar a una sola clave KMS en una cuenta y región, administrar alias es un poco más difícil que administrar etiquetas. Restaurar el acceso a algunas entidades principales en una clave KMS puede denegar el acceso a la misma u otras entidades principales a una clave KMS diferente.

Para evitar este error, otorgue permisos de administración de alias solo a las principales entidades que lo necesiten y limite sus permisos de administración de alias a los alias que necesitan administrar. Antes de actualizar o eliminar un alias, busque políticas para detectar el acceso que depende del alias y busque claves KMS en todas las regiones asociadas al alias.

Acceso denegado debido a la cuota de alias

Los usuarios que estén autorizados a usar una clave de KMS con una ResourceAliases condición de kms: recibirán una AccessDenied excepción si la clave de KMS supera los alias predeterminados por cuota de claves de KMS para esa cuenta y región.

Para restaurar el acceso, elimine los alias asociados a la clave KMS para que cumpla con la cuota. O utilice un mecanismo alternativo para dar a los usuarios acceso a la clave KMS.

Cambio de autorización retrasado

Los cambios que realice en las etiquetas y alias pueden tardar hasta cinco minutos en afectar a la autorización de claves KMS. Como resultado, un cambio de etiqueta o alias podría reflejarse en las respuestas de las operaciones de API antes de que afecten a la autorización. Es probable que este retraso sea más largo que el breve retraso de consistencia final que afecta a la mayoría de las operaciones de AWS KMS.

Por ejemplo, puede que tenga una política de IAM que permita a ciertas entidades principales utilizar cualquier clave KMS con una etiqueta "Purpose"="Test". Luego, agrega la etiqueta "Purpose"="Test" de una clave KMS. Aunque la TagResourceoperación se complete y la ListResourceTagsrespuesta confirme que la etiqueta está asignada a la clave de KMS, es posible que las entidades principales no tengan acceso a la clave de KMS durante un máximo de cinco minutos.

Para evitar errores, construya este retraso esperado en su código.

Solicitudes fallidas debido a actualizaciones de alias

Cuando se actualiza un alias, se asocia un alias existente con una clave KMS diferente.

El descifrado y ReEncryptlas solicitudes que especifican el nombre del alias o el ARN del alias pueden fallar porque el alias ahora está asociado a una clave KMS que no cifró el texto cifrado. Esta situación normalmente devuelve un IncorrectKeyException o NotFoundException. O si la solicitud no tiene parámetro KeyId o DestinationKeyId, la operación puede fallar con la excepción AccessDenied dado que la persona que llama ya no tiene acceso a la clave KMS que cifró el texto cifrado.

Puede rastrear el cambio consultando los CloudTrail registros y las entradas de CreateAliasregistro. UpdateAliasDeleteAlias También puede usar el valor del LastUpdatedDate campo en la ListAliasesrespuesta para detectar un cambio.

Por ejemplo, en el siguiente ListAliasesejemplo de respuesta se muestra que se actualizó el ProjectAlpha_Test alias de la kms:ResourceAliases condición. Como resultado, las principales entidades que tienen acceso basado en el alias pierden el acceso a la clave KMS previamente asociada. En su lugar, tienen acceso a la clave KMS recién asociada.

$ aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]'

{
    "Aliases": [
        {
            "AliasName": "alias/ProjectAlpha_Test",
            "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test",
            "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321",
            "CreationDate": 1566518783.394,
            "LastUpdatedDate": 1605308931.903
        },
        {
            "AliasName": "alias/ProjectAlpha_Restricted",
            "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted",
            "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab",
            "CreationDate": 1553410800.010,
            "LastUpdatedDate": 1553410800.010
        }
    ]
}

La solución para este cambio no es simple. Puede actualizar el alias nuevamente para asociarlo a la clave KMS original. Sin embargo, antes de actuar, debe considerar el efecto de ese cambio en la clave KMS asociada actualmente. Si las principales entidades utilizan la última clave KMS en operaciones criptográficas, es posible que necesiten acceso continuo a ella. En este caso, es posible que desee actualizar la política para asegurarse de que las principales entidades tienen permiso para usar ambas claves KMS.

Puede evitar un error como el siguiente: antes de actualizar un alias, busque políticas para detectar el acceso que depende del alias. A continuación, obtenga claves KMS en todas las regiones asociadas con el alias. De permisos de administración de alias solo a las principales entidades que lo necesiten y limite sus permisos de administración de alias a los alias que necesitan administrar.