AWS KMS 中的 ABAC - AWS Key Management Service
AWS KMS 的 ABAC 条件键标签还是别名？适用于 AWS KMS 的 ABAC 的故障排除

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

AWS KMS 中的 ABAC

基于属性的访问控制 (ABAC) 是一种授权策略，它基于属性来定义权限。AWS KMS 通过允许您根据与 KMS 密钥关联的标签和别名控制对客户托管密钥的访问来支持 ABAC。在 AWS KMS 中启用 ABAC 的标签和别名条件键提供了一种功能强大且灵活的方式来授权委托人使用 KMS 密钥，而无需编辑策略或管理授权。但是，您应该小心使用这些功能，以免委托人无意中允许或拒绝访问。

如果您使用 ABAC，请注意管理标签和别名的权限现在是访问控制权限。在部署依赖于标签或别名的策略之前，请确保您知道所有 KMS 密钥上的现有标签和别名。添加、删除和更新别名，以及标记和取消标记密钥时，采取合理的预防措施。仅授予需要管理标签和别名权限的委托人该权限，并限制他们可以管理的标签和别名。

注意事项

将 ABAC 用于 AWS KMS 时，请谨慎授予委托人管理标签和别名的权限。更改标签或别名可以允许或拒绝对 KMS 密钥的权限。不具有更改密钥策略或创建授权权限的密钥管理员可以控制对 KMS 密钥的访问，前提是他们有权管理标签或别名。

标签和别名的更改最多可能需要 5 分钟的时间才能影响 KMS 密钥授权。最近的更改可能会在 API 操作中显示，然后才会影响授权。

要根据 KMS 密钥别名控制对它的访问权限，必须使用条件键。您不能使用别名来表示策略语句的 Resource 元素中的 KMS 密钥元素。当别名出现在 Resource 元素时，策略语句将应用于别名，而不是关联的 KMS 密钥。

了解更多

AWS KMS 的 ABAC 条件键

要根据 KMS 密钥的标签和别名授权访问 KMS 密钥，请在密钥政策或 IAM policy 中使用以下条件键。

ABAC 条件键 描述 策略类型 AWS KMS 操作
aws：ResourceTag KMS 密钥上的标签（键和值）与策略中的标签（键和值）或标签模式匹配 仅限 IAM policy KMS 密钥资源操作 2
aws:RequestTag/tag-key 请求中的标签（键和值）与策略中的标签（键和值）或标签模式匹配 密钥政策和 IAM policy 1 TagResource, UntagResource
aws：TagKeys 请求中的标签键与策略中的标签键匹配 密钥政策和 IAM policy 1 TagResource, UntagResource
kms: ResourceAliases 与 KMS 密钥关联的别名与策略中的别名或别名模式匹配 仅限 IAM policy KMS 密钥资源操作 2
kms: RequestAlias 表示请求中的 KMS 密钥的别名与策略中的别名或别名模式匹配。 密钥政策和 IAM policy 1 加密操作，，DescribeKeyGetPublicKey

1 任何可在密钥政策中使用的条件键也可以在 IAM policy 中使用，但只有在密钥政策允许它时。

2 KMS 密钥资源操作是特定 KMS 密钥授权的操作。若要标识 KMS 密钥资源操作，请在 AWS KMS 权限表中，在操作的 Resources 列中查找的 KMS 密钥的值。

例如，您可以使用这些条件键创建以下策略。

  • 具有 kms:ResourceAliases 的 IAM policy，可授予将 KMS 密钥与特定别名或别名模式结合使用的权限。这与依赖于标签的策略略有不同：尽管您可以在策略中使用别名模式，但每个别名在 AWS 账户 和区域中必须是唯一的。这使您能够将策略应用于选定的 KMS 密钥集，而无需在策略语句中列出 KMS 密钥的密钥 ARN。要从集中添加或删除 KMS 密钥，请更改 KMS 密钥的别名。

  • 带有 kms:RequestAlias 的密钥策略，可允许委托人在 Encrypt 操作中使用 KMS 密钥，但前提是仅当 Encrypt 请求使用该别名标识 KMS 密钥时。

  • 带有 aws:ResourceTag/tag-key 的 IAM policy，可拒绝将 KMS 密钥与特定标签键和标签值结合使用的权限。这让您能够将策略应用于选定的 KMS 密钥集，而无需在策略语句中列出 KMS 密钥的密钥 ARN。要在集中添加或删除 KMS 密钥，请标记或取消标记 KMS 密钥。

  • 带有 aws:RequestTag/tag-key 的 IAM policy，可允许委托人仅删除 "Purpose"="Test" KMS 密钥标签。

  • 带有 aws:TagKeys 的 IAM policy，可拒绝使用 Restricted 标签键标记或取消标记 KMS 密钥的权限。

ABAC 使访问管理具有灵活性和可扩展性。例如，您可以使用 aws:ResourceTag/tag-key 条件键创建 IAM policy，该策略允许委托人仅在 KMS 密钥具有 Purpose=Test 标签时将 KMS 密钥用于特定操作。该策略适用于 AWS 账户 的所有区域中的所有 KMS 密钥。

当附加到用户或角色时，以下 IAM policy 允许委托人将带有 Purpose=Test 标签的所有现有 KMS 密钥用于指定操作。要提供对新的或现有 KMS 密钥的访问权限，您不需要更改策略。只需将 Purpose=Test 标签附加到 KMS 密钥。同样，要从具有 Purpose=Test 标签的 KMS 密钥中删除此访问权限，请编辑或删除标签。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Purpose": "Test"
        }
      }
    }
  ]
}

但是，如果您使用此功能，在管理标记和别名时要加小心。添加、更改或删除标签或别名可能会无意中允许或拒绝对 KMS 密钥的访问。不具有更改密钥策略或创建授权权限的密钥管理员可以控制对 KMS 密钥的访问，前提是他们有权管理标签和别名。为了减轻这种风险，请考虑限制管理标签的权限和别名。例如，您可能想要仅允许特色级委托人管理 Purpose=Test 标签。有关详细信息，请参阅 使用别名控制对 KMS 密钥的访问 和 使用标签控制对 KMS 密钥的访问。

标签还是别名？

AWS KMS 支持带有标签和别名的 ABAC。这两种选项都提供了灵活、可扩展的访问控制策略，但它们彼此略有不同。

您可能会根据您的特定 AWS 使用模式决定是使用标签还是使用别名。例如，如果您已经向大多数管理员授予了标记权限，则基于别名控制授权策略可能会更容易。或者，如果您接近每个 KMS 密钥的别名数量配额，您可能更喜欢基于标签的授权策略。

以下益处是大家都感兴趣的。

基于标签的访问控制的益处

  • 不同类型的 AWS 资源的授权机制相同。

    您可以使用相同的标签或标签键来控制对多种资源类型的访问，例如 Amazon Relational Database Service（Amazon RDS）集群、Amazon Elastic Block Store（Amazon EBS）卷和 KMS 密钥。此功能支持多种不同的授权模型，这些模型比传统的基于角色的访问控制更加灵活。

  • 授权访问一组 KMS 密钥。

    您可以使用标签来管理对同一 AWS 账户 和区域中的一组 KMS 密钥的访问权限。将相同的标签或标签键分配给您选择的 KMS 密钥。然后创建一个基于标签或标签密钥的简单 easy-to-maintain 策略声明。要在授权组中添加或删除 KMS 密钥，请添加或删除标签；您无需编辑策略。

基于别名的访问控制的益处

  • 根据别名授权对加密操作的访问。

    大多数基于请求的属性策略条件，包括 a ws:RequestTag/tag-key，仅影响添加、编辑或删除属性的操作。但是 k ms: RequestAlias 条件密钥根据用于在请求中识别 KMS 密钥的别名来控制对加密操作的访问。例如，您可以授予委托人在 Encrypt 操作中使用 KMS 密钥的权限，但只有当 KeyId 参数的值为 alias/restricted-key-1 时。要满足此条件，需要以下所有条件：

    • KMS 密钥必须与该别名相关联。

    • 请求必须使用别名来标识 KMS 密钥。

    • 委托人必须拥有使用受 kms:RequestAlias 条件约束的 KMS 密钥的权限。

    如果您的应用程序通常使用别名名称或别名 ARN 来引用 KMS 密钥，这将特别有用。

  • 提供非常有限的权限。

    别名在 AWS 账户 和区域中必须是唯一的。因此，基于别名授予委托人访问 KMS 密钥的权限可能比基于标签授予他们访问权限更严格。与别名不同，标签可分配给同一账户和区域中的多个 KMS 密钥。如果选择，则可以使用别名模式（例如 alias/test*）为委托人授予对同一账户和区域中一组 KMS 密钥的访问权限。但是，允许或拒绝访问特定别名允许对 KMS 密钥进行非常严格的控制。

适用于 AWS KMS 的 ABAC 的故障排除

基于 KMS 密钥的标签和别名控制对 KMS 密钥的访问非常方便，且功能强大。但是，它容易出现一些您希望防止的可预测错误。

由于标签更改而更改访问权限

如果某个标签被删除或其值被更改，则仅能基于该标签访问 KMS 密钥的委托人将被拒绝访问 KMS 密钥。当拒绝策略语句中包含的标签添加到 KMS 密钥时，也会发生这种情况。向 KMS 密钥添加与策略相关的标签可以允许访问应被拒绝访问 KMS 密钥的委托人。

例如，假设委托人可以基于 Project=Alpha 标签访问 KMS 密钥，例如以下示例 IAM policy 语句提供的权限。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IAMPolicyWithResourceTag",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "Alpha"
        }
      }
    }
  ]
}

如果该标签已从该 KMS 密钥中删除或标签值发生更改，则委托人不再具有将 KMS 密钥用于指定操作的权限。当委托人尝试在使用客户托管密钥的AWS服务中读取或写入数据时，这一点可能会变得显而易见。要跟踪标签的更改，请查看您的 CloudTrail日志TagResource或UntagResource 条目。

要在不更新策略的情况下恢复访问，请更改 KMS 密钥上的标签。这一措施除了短时间在整个 AWS KMS 中生效之后，产生的影响极小。为了防止这样的错误，请仅向需要它的委托人授予标记和取消标记权限，并将其标记权限限制到他们需要管理的标签。更改标签之前，请搜索策略以检测依赖于标签的访问权限，并在具有该标签的所有区域中获取 KMS 密钥。您可以考虑在更改特定标签时创建 Amazon CloudWatch 警报。

由于别名更改而导致的访问权限更改

如果别名被删除或与其他 KMS 密钥关联，则仅能基于该别名访问 KMS 密钥的委托人将被拒绝访问 KMS 密钥。当拒绝策略语句中包含与 KMS 密钥关联的别名时，也会发生这种情况。向 KMS 密钥添加与策略相关的别名也可以允许访问应被拒绝访问 KMS 密钥的委托人。

例如，以下 IAM 策略声明使用 k ms: ResourceAliases 条件密钥允许使用任意指定别名访问账户中不同区域的 KMS 密钥。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AliasBasedIAMPolicy",
      "Effect": "Allow",
      "Action": [
        "kms:List*",
        "kms:Describe*",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:*:111122223333:key/*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "kms:ResourceAliases": [
            "alias/ProjectAlpha",
            "alias/ProjectAlpha_Test",
            "alias/ProjectAlpha_Dev"
          ]
        }
      }
    }
  ]
}

要跟踪别名更改，请查看 CloudTrail 日志中是否有CreateAliasUpdateAlias、和DeleteAlias条目。

要在不更新策略的情况下恢复访问，请更改与 KMS 密钥关联的别名。由于每个别名只能与账户和区域中的一个 KMS 密钥相关联，因此管理别名比管理标签要困难一些。恢复一些委托人对一个 KMS 密钥的访问权限可能会拒绝相同或其他委托人对其他 KMS 密钥的访问。

为了防止出现此错误，请仅向需要它的委托人授予别名管理权限，并将其别名管理权限限制到他们需要管理的别名。在更新或删除别名之前，请搜索策略以检测依赖于别名的访问权限，并在与别名关联的所有区域中查找 KMS 密钥。

由于别名配额而拒绝访问

如果 KMS 密钥超过该账户和地区每个 KMS 密钥配额的默认别名，则获得 kms: ResourceAliases 条件授权使用 KMS 密钥的用户将获得AccessDenied例外。

要恢复访问，请删除与 KMS 密钥关联的别名，使其符合配额。或者使用备用机制授予用户访问 KMS 密钥的权限。

延迟的授权更改

您对标签和别名的更改最多可能需要 5 分钟的时间才能影响 KMS 密钥授权。因此，标签或别名更改可能会在 API 操作影响授权之前反映在响应中。此延迟可能会比影响大多数 AWS KMS 操作的短暂最终一致性延迟长。

例如，您可能拥有一个 IAM policy，允许某些委托人使用带有 "Purpose"="Test" 标签的任何 KMS 密钥。然后，您将 "Purpose"="Test" 标签添加到 KMS 密钥。尽管TagResource操作已完成且ListResourceTags响应确认标签已分配给 KMS 密钥，但委托人可能在长达五分钟内无法访问 KMS 密钥。

为了防止出现错误，请将此预期延迟构建到您的代码中。

由于别名更新而失败的请求

当您更新别名时，您将现有别名与另一个 KMS 密钥关联。

解密和指定别名或别名 ARN 的ReEncrypt请求可能会失败，因为该别名现在与未加密密文的 KMS 密钥相关联。这种情况通常会返回 IncorrectKeyException 或者 NotFoundException。或者如果请求中没有 KeyId 或 DestinationKeyId 参数，则操作可能会失败，并出现 AccessDenied 异常，因为调用方不再具有对加密密文的 KMS 密钥的访问权限。

您可以通过查看CreateAliasUpdateAlias、和 CloudTrail 日志条目的DeleteAlias日志来跟踪更改。您还可以在ListAliases响应中使用该LastUpdatedDate字段的值来检测更改。

例如，以下ListAliases示例响应显示kms:ResourceAliases条件中的ProjectAlpha_Test别名已更新。因此，基于别名具有访问权限的委托人将失去对先前关联的 KMS 密钥的访问权限。相反，他们可以访问新关联的 KMS 密钥。

$ aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]'

{
    "Aliases": [
        {
            "AliasName": "alias/ProjectAlpha_Test",
            "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test",
            "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321",
            "CreationDate": 1566518783.394,
            "LastUpdatedDate": 1605308931.903
        },
        {
            "AliasName": "alias/ProjectAlpha_Restricted",
            "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted",
            "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab",
            "CreationDate": 1553410800.010,
            "LastUpdatedDate": 1553410800.010
        }
    ]
}

这种变化的补救办法并不简单。您可以再次更新别名以将其与原始 KMS 密钥关联。但是，在执行操作之前，您需要考虑该更改对当前关联的 KMS 密钥的影响。如果委托人在加密操作中使用后一个 KMS 密钥，他们可能需要继续访问该密钥。在这种情况下，您可能需要更新策略以确保委托人有权使用这两个 KMS 密钥。

您可以防止出现这样的错误：在更新别名之前，搜索策略以检测依赖于别名的访问。然后，在与别名关联的所有区域中获取 KMS 密钥。请仅向需要它的委托人授予别名管理权限，并将其别名管理权限限制到他们需要管理的别名。