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.
Solución de problemas de permisos de AWS KMS
Al autorizar el acceso a una clave KMS, AWS KMS evalúa lo siguiente:
-
La política de claves asociada a la clave KMS. La política de claves siempre se define en la región y la Cuenta de AWS propietaria de la clave KMS.
-
Todas las políticas de IAM asociadas al usuario o rol que realiza la solicitud. Las políticas de IAM que rigen el uso de una clave KMS por una entidad principal siempre se definen en la Cuenta de AWS.
-
Todas las concesiones que afectan a la clave KMS.
-
Otros tipos de políticas que podrían aplicarse a la solicitud de usar la clave KMS, como Políticas de control de servicios de AWS Organizations y Políticas de punto de enlace de la VPC. Estas políticas son opcionales y permiten todas las acciones de forma predeterminada, pero puede usarlas para restringir los permisos otorgados a las entidades principales.
AWS KMS evalúa estos mecanismos de política juntos para determinar si se permite o se deniega el acceso a la clave KMS. Para ello, AWS KMS utiliza un proceso similar al representado en el siguiente diagrama de flujo. El siguiente diagrama de flujo ofrece una representación visual del proceso de evaluación de las políticas.
Este diagrama de flujo se divide en dos partes. Las partes parecen secuenciales, pero se suelen evaluar al mismo tiempo.
-
El use de la autorización determina si puede utilizar una clave KMS en función de su política de claves, sus políticas de IAM, sus concesiones y otras políticas aplicables.
-
La confianza en la clave determina si debe confiar en una clave KMS que se le ha permitido utilizar. En general, puede confiar en los recursos de su Cuenta de AWS. Sin embargo, puede estar tranquilo a la hora de utilizar las claves KMS de una Cuenta de AWS diferente si una concesión o política de IAM de su cuenta le permite utilizar la clave KMS.
Puede utilizar este diagrama de flujo para saber por qué se ha permitido o denegado que un intermediario utilice una clave KMS. También puede utilizarlo para evaluar sus políticas y concesiones. Por ejemplo, el diagrama de flujo muestra que se puede negar el acceso a un intermediario mediante una declaración DENY
explícita, o por la ausencia de una declaración ALLOW
explícita, en la política de claves, la política de IAM o la concesión.
El diagrama de flujo puede explicar algunos escenarios comunes de permisos.
Ejemplos de permisos
Ejemplo 1: Se deniega el acceso al usuario a una clave KMS en su Cuenta de AWS
Alice es una usuaria de IAM en la Cuenta de AWS 111122223333. Se le ha denegado al acceso a una clave KMS en la misma Cuenta de AWS. ¿Por qué no puede utilizar Alice la clave KMS?
En este caso, se le deniega el acceso a Alice a la clave KMS porque no hay ninguna política de claves, política de IAM o concesión que proporcione los permisos necesarios. La política de la clave KMS permite que la Cuenta de AWS utilice políticas de IAM para controlar el acceso a la clave KMS, pero ninguna política de IAM concede a Alice permiso para usar la clave KMS.
Considere las políticas relevantes para este ejemplo.
-
La clave KMS que Alice quiere utilizar tiene la política de claves predeterminada. Esta política permite que la Cuenta de AWS que posee la clave KMS para utilizar políticas de IAM para controlar el acceso a la clave KMS. Esta política de claves satisface la condición ¿PERMITE la política de claves que la cuenta de los intermediarios utilice políticas de IAM para controlar el acceso a clave? del diagrama de flujo.
{ "Version" : "2012-10-17", "Id" : "key-test-1", "Statement" : [ { "Sid" : "Delegate to IAM policies", "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::111122223333:root" }, "Action" : "kms:*", "Resource" : "*" } ] }
-
Sin embargo, no hay ninguna política de claves, política de IAM ni concesión que conceda a Alice permiso para usar la clave KMS. Por lo tanto, se deniega a Alice el permiso para utilizar la clave KMS.
Ejemplo 2: El usuario asume un rol con permiso para utilizar una clave KMS en una Cuenta de AWS diferente
Roberto es un usuario de la cuenta 1 (111122223333). Se le permite usar una clave KMS en la cuenta 2 (444455556666) en operaciones criptográficas. ¿Cómo es posible?
sugerencia
Al evaluar los permisos entre cuentas, recuerde que la política de claves se especifica en la cuenta de la clave KMS. La política de IAM se especifica en la cuenta del intermediario, incluso cuando el intermediario está en una cuenta diferente. Para obtener más detalles sobre cómo proporcionar acceso entre cuentas a claves KMS, consulte Permitir a los usuarios de otras cuentas utilizar una clave KMS.
-
La política de claves de la clave KMS de la cuenta 2 permite que la cuenta 2 utilice políticas de IAM para controlar el acceso a la clave KMS.
-
La política de claves de la clave KMS de la cuenta 2 permite que la cuenta 1 utilice la clave KMS en operaciones criptográficas. Sin embargo, la cuenta 1 debe utilizar políticas de IAM para conceder acceso a la clave KMS a sus entidades principales.
-
Una política de IAM de la cuenta 1 permite al rol
Engineering
utilizar la clave KMS de la cuenta 2 para las operaciones criptográficas. -
Roberto, un usuario de la cuenta 1, tiene permiso para asumir el rol
Engineering
. -
Roberto confía en esta clave KMS, porque, aunque no se encuentre en su cuenta, una política de IAM de su cuenta le otorga permiso explícito para utilizar esta clave KMS.
Considere las políticas que permiten a Roberto, un usuario de la cuenta 1, utilizar la clave KMS de la cuenta 2.
-
La política de claves de la clave KMS permite que la cuenta 2 (444455556666, la cuenta propietaria de la clave KMS) utilice políticas de IAM para controlar el acceso a la clave KMS. Esta política de claves permite también que la cuenta 1 (111122223333) utilice la clave KMS en operaciones criptográficas (especificado en el elemento
Action
de la declaración de política). Sin embargo, ninguna persona de la cuenta 1 puede usar la clave KMS de la cuenta 2 hasta que la cuenta 1 defina políticas de IAM que concedan a las entidades principales acceso a la clave KMS.En el diagrama de flujo, esta política de claves de la cuenta 2 satisface la condición ¿PERMITE la política de claves que la cuenta de los intermediarios utilice políticas de IAM para controlar el acceso a la clave?
{ "Id": "key-policy-acct-2", "Version": "2012-10-17", "Statement": [ { "Sid": "Permission to use IAM policies", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow account 1 to use this KMS key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": "*" } ] }
-
Una política de IAM de la cuenta de Cuenta de AWS del intermediario (cuenta 1, 111122223333) concede al rol de la cuenta 1 permiso para realizar operaciones criptográficas mediante la clave KMS de la cuenta 2 (444455556666). El elemento
Action
delega a la entidad principal los mismos permisos que la política de claves de la cuenta 2 concedió a la cuenta 1. Para conceder estos permisos al rolEngineering
en la cuenta 1, esta política en línea está incrustada en el rolEngineering
.Las políticas de IAM entre cuentas como esta son eficaces solo cuando la política de claves de la clave KMS de la cuenta 2 concede a la cuenta 1 permiso para utilizar la clave KMS. Además, la cuenta 1 solo puede conceder permiso a sus entidades principales para realizar las acciones que la política de claves concedió a la cuenta.
En el diagrama de flujo, esto satisface la condición ¿Permite una política de IAM que el intermediario realice esta acción?
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": [ "arn:aws:kms:us-west-2:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab" ] } ] }
-
El último elemento necesario es la definición del rol
Engineering
en la cuenta 1. El elementoAssumeRolePolicyDocument
del rol permite a Roberto asumir el rolEngineering
.{ "Role": { "Arn": "arn:aws:iam::111122223333:role/Engineering", "CreateDate": "2019-05-16T00:09:25Z", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": { "Principal": { "AWS": "arn:aws:iam::111122223333:user/bob" }, "Effect": "Allow", "Action": "sts:AssumeRole" } }, "Path": "/", "RoleName": "Engineering", "RoleId": "AROA4KJY2TU23Y7NK62MV" } }