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 账户中的资源。但是,如果您账户中的授权或 IAM 策略允许您使用 CMK,您也可以自信地使用不同 AWS 账户中的 CMK。

您可以使用此流程图了解为什么允许或拒绝向发起人授予使用 CMK 的权限。您还可以使用它评估您的策略和授权。例如,流程图显示:可以通过显式 DENY 语句或通过在密钥策略、IAM 策略或授权中省略显式 ALLOW 语句来拒绝授予某个发起人访问权限。

让我们使用流程图来说明一些常见权限场景。

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

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

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


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

让我们检查此示例的相关策略。

  • 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" : "*" } ] }
  • 但是,不存在向 Alice 授予 CMK 使用权限的密钥策略、IAM 策略或授权。因此,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" } }