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.
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 Cuenta de AWS y propietaria de la clave de 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 en conjunto para determinar si se permite o deniega el acceso a la clave de KMS. Para ello, AWS KMS utiliza un proceso similar al que se muestra 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, usted confía en los recursos que tiene. Cuenta de AWS Sin embargo, también puede estar seguro de utilizar las claves de KMS de otra forma Cuenta de AWS si una política de concesión o de IAM de su cuenta le permite utilizar la clave de 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 al usuario el acceso a una clave KMS de su Cuenta de AWS
Alice es una usuaria de IAM en el 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 clave de la clave de KMS permite utilizar políticas de IAM Cuenta de AWS para controlar el acceso a la clave de KMS, pero ninguna política de IAM permite a Alice usar la clave de 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 el rol con permiso para usar una clave de KMS en otro Cuenta de AWS
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
Engineeringutilizar 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
Actionde 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 en la persona que llama Cuenta de AWS (cuenta 1, 111122223333) otorga al principal permiso para realizar operaciones criptográficas con la clave KMS en la cuenta 2 (444455556666). El elemento
Actiondelega 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 rolEngineeringen 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
Engineeringen la cuenta 1. El elementoAssumeRolePolicyDocumentdel 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" } }
