密钥访问故障排除 - Amazon Key Management Service
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

密钥访问故障排除

在授予对 KMS 密钥的访问权限时,Amazon KMS 将评估以下内容:

  • 附加到 KMS 密钥的密钥策略。密钥策略始终在拥有 KMS 密钥的 Amazon Web Services 账户 和区域中定义。

  • 附加到发出请求的 IAM 用户或角色的所有 IAM 策略。管理委托人对 KMS 密钥的使用的 IAM 策略始终在委托人的 Amazon Web Services 账户 中定义。

  • 应用于 KMS 密钥的所有授权

  • 可能应用于请求以使用 KMS 密钥的其他类型的策略,例如 Amazon Organizations 服务控制策略VPC 终端节点策略。这些策略是可选的,并且在默认情况下允许执行所有操作,但您可以使用它们限制授予委托人的权限。

Amazon KMS 同时评估这些策略机制,以确定是允许还是拒绝对 KMS 密钥的访问。为执行此操作,Amazon KMS 使用与以下流程图中所示流程相似的流程。以下流程图提供策略评估流程的可视化表示。


      描述策略评估流程的流程图

此流程图分为两个部分。这两个部分按顺序显示,但通常会同时对它们进行评估。

  • 使用授权根据其密钥策略、IAM 策略、授权和其他适用的策略来确定是否允许您使用 KMS 密钥。

  • 密钥信任确定您是否应信任允许您使用的 KMS 密钥。一般而言,您信任 Amazon Web Services 账户 中的资源。但是,如果您的账户中的授权或 IAM 策略允许您使用 KMS 密钥,您也可以自信地使用不同 Amazon Web Services 账户 中的 KMS 密钥。

您可以使用此流程图了解为什么允许或拒绝向发起人授予使用 KMS 密钥的权限。您还可以使用它评估您的策略和授权。例如,此流程图显示某个调用方可能被显式 DENY 语句拒绝访问,或者由于在密钥策略、IAM 策略或授权中没有显式 ALLOW 语句而被拒绝访问。

流程图可以解释一些常见的许可方案。

示例 1:用户被拒绝访问其 Amazon Web Services 账户 中的 KMS 密钥

Alice 是 111122223333 Amazon Web Services 账户 中的 IAM 用户。她被拒绝访问同一 Amazon Web Services 账户 中的 KMS 密钥。为什么 Alice 无法使用 KMS 密钥?

在这种情况下,Alice 被拒绝访问该 KMS 密钥,因为没有密钥策略、IAM 策略或为她授予所需权限的授权。KMS 密钥的密钥策略允许 Amazon Web Services 账户 使用 IAM 策略控制对 KMS 密钥的访问,但任何 IAM 策略均未向 Alice 授予使用 KMS 密钥的权限。


               描述策略评估流程的流程图

考虑用于此示例的相关策略。

  • Alice 想要使用的 KMS 密钥具有默认密钥策略。此政策允许拥有 KMS 密钥的 Amazon Web Services 账户 使用 IAM 策略控制对 KMS 密钥的访问。此密钥策略满足流程图中的密钥策略是否允许调用方账户使用 IAM 策略来控制对密钥的访问?条件。

    { "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" : "*" } ] }
  • 但是,没有任何密钥策略、IAM 策略或授权向 Alice 授予 KMS 密钥使用权限。因此,Alice 被拒绝使用 KMS 密钥的权限。

示例 2:用户代入的角色具有使用不同 Amazon Web Services 账户 中的 KMS 密钥的权限

Bob 是账户 1 (111122223333) 中的一个用户。他可以在加密操作中使用账户 2 (444455556666) 中的 KMS 密钥。如何才能实现?

提示

在评估跨账户权限时,请记住,密钥策略在 KMS 密钥的账户中指定。IAM 策略在调用方账户中指定,即使调用方使用的是不同的账户。有关提供对 KMS 密钥的跨账户访问的详细信息,请参阅 允许其他账户中的用户使用 KMS 密钥

  • 账户 2 中 KMS 密钥的密钥策略允许账户 2 使用 IAM 策略来控制对 KMS 密钥的访问。

  • 账户 2 中 KMS 密钥的密钥策略允许账户 1 在加密操作中使用 KMS 密钥。但是,账户 1 必须使用 IAM 策略授予其委托人对 KMS 密钥的访问权限。

  • 账户 1 中的 IAM 策略允许 Engineering 角色将账户 2 中的 KMS 密钥用于加密操作。

  • Bob 是账户 1 中的用户,有权限代入 Engineering 角色。

  • Bob 可以信任此 KMS 密钥,因为即使它不在他的账户中,他账户中的一个 IAM 策略也会向他授予使用此 KMS 密钥的显式权限。


               描述策略评估流程的流程图

考虑一下 Bob(账户 1 中的用户)使用账户 2 中 KMS 密钥的策略。

  • KMS 密钥的密钥策略允许账户 2(444455556666,拥有 KMS 密钥的账户)使用 IAM 策略来控制对 KMS 密钥的访问。此密钥策略还允许账户 1 (111122223333) 在加密操作中使用 KMS 密钥(在策略语句的 Action 元素中指定)。但是,账户 1 中的任何人都无法使用账户 2 中的 KMS 密钥,直到账户 1 定义授权委托人访问 KMS 密钥的 IAM 策略。

    在流程图中,账户 2 中的此密钥策略满足密钥策略是否允许调用方账户使用 IAM 策略来控制对密钥的访问?条件。

    { "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": "*" } ] }
  • 调用方的 Amazon Web Services 账户(账户 1,111122223333)中的 IAM 策略委托人授予使用账户 2 (444455556666) 中的 KMS 密钥执行加密操作的权限。Action 元素向该委托人委派的权限与账户 2 中的密钥策略向账户 1 授予的权限相同。要将这些权限授予账户 1 中的 Engineering 角色,将此内联策略嵌入Engineering 角色中。

    仅当账户 2 中的 KMS 密钥的密钥策略向账户 1 授予使用此 KMS 密钥的权限时,类似于此策略的跨账户 IAM 策略才有效。此外,账户 1 只能向其委托人授予执行此密钥策略已授予该账户的操作的权限。

    在流程图中,这满足 IAM 策略是否允许调用方执行此操作?条件。

    { "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" ] } ] }
  • 最后一个必需元素是账户 1 中 Engineering 角色的定义。此角色中的 AssumeRolePolicyDocument 允许 Bob 代入 Engineering 角色。

    { "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" } }