AWS Key Management Service
开发人员指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

密钥访问故障排除

当授予对客户主密钥 (CMK) 的访问权限时,AWS KMS 评估以下内容:

  • 附加到 CMK 的密钥策略。密钥策略始终在拥有 CMK 的 AWS 账户中定义。

  • 附加到发出请求的 IAM 用户或角色的所有 IAM 策略。IAM 控制委托人使用 CMK 的策略始终在委托人的 AWS 账户中定义。

  • 应用于 CMK 的所有授权。

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


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

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

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

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

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

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

示例 1:用户被拒绝访问其 AWS 账户中的 CMK

Alice 是 111122223333 AWS 账户中的 IAM 用户。她被拒绝访问同一 AWS 账户中的 CMK。为什么 Alice 使用无法 CMK?

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


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

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

  • Alice 想要使用的 CMK 具有默认密钥策略。此策略允许拥有该 CMK 的 AWS 账户使用 IAM 策略来控制对 CMK 的访问。此密钥策略满足流程图中的密钥策略是否允许调用方账户使用 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 授予 CMK 使用权限。因此,Alice 被拒绝使用 CMK 的权限。

示例 2:用户代入的角色具有使用不同 AWS 账户中的 CMK 的权限

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

提示

在评估跨账户权限时,请记住,密钥策略在 CMK 账户中指定。IAM 策略在调用方账户中指定,即使调用方使用的是不同的账户。

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

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

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

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

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


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

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

  • CMK 的密钥策略允许账户 2(444455556666,拥有 CMK 的账户) 使用 IAM 策略来控制对 CMK 的访问。此密钥策略还允许账户 1 (111122223333) 在加密操作中使用 CMK(在策略语句的 Action 元素中指定)。但是,账户 1 中的任何人都无法使用账户 2 中的 CMK,直到账户 1 定义授权委托人访问 CMK 的 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 CMK", "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": "*" } ] }
  • 调用方的 AWS 账户(账户 1,111122223333)中的 IAM 策略向账户 1 中的 ExampleRole 角色授予权限,让其使用账户 2 (444455556666) 中的 CMK 执行加密操作。Action 元素向该角色授予的权限与账户 2 中的密钥策略向账户 1 授予的权限相同。

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

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

    { "Version": "2012-10-17", "Statement": [ { "Principal": { "arn:aws:iam::111122223333:role/ExampleRole" } "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 中 ExampleRole 角色的定义。此角色中的 AssumeRolePolicyDocument 允许 Bob 代入 ExampleRole 角色。

    { "Role": { "Arn": "arn:aws:iam::111122223333:role/ExampleRole", "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": "ExampleRole", "RoleId": "AROA4KJY2TU23Y7NK62MV" } }