排除 AWS KMS 权限故障 - AWS Key Management Service

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

排除 AWS KMS 权限故障

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    { "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 policy 或授权向 Alice 授予 KMS 密钥使用权限。因此,Alice 被拒绝使用 KMS 密钥的权限。

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

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

提示

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

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

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

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

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

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

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

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

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

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

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

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

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

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