将 ABAC 用于AWS KMS - AWS Key Management Service
的 ABAC 条件键AWS KMS标签或别名?ABAC for AWS KMS 问题排查
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 AWS 服务入门。

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

将 ABAC 用于AWS KMS

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

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

Notes

将 ABAC 用于 AWS KMS 时，请谨慎地向委托人授予管理标签和别名的权限。更改标签或别名可能会允许或拒绝对 CMK 的权限。无权更改密钥策略或创建授权的密钥管理员可以控制对 CMKs 的访问（如果他们有权管理标签或别名）。

标签和别名更改可能需要长达五分钟才能影响 CMK 授权。最近的更改在影响授权之前可能显示在 API 操作中。

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

了解更多

的 ABAC 条件键AWS KMS

要根据其标签和别名授予对 CMKs 的访问权限，请在密钥策略或 IAM 策略中使用以下条件键。

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

1 密钥策略中可以使用的任何条件键都可以在 IAM 策略中使用，但前提是密钥策略允许它。

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

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

  • 一个具有 IAM 的 aws:ResourceAliases 策略，该策略授予通过特定别名或别名模式使用 CMKs 的权限。这与依赖标签的策略略有不同：尽管您可以在策略中使用别名模式，但每个别名在 AWS 账户和区域中必须是唯一的。这样，您就可以将策略应用于一组选定的 CMKs，而无需在策略语句中列出 ARNs 的键 CMKs。要在集合中添加或删除 CMKs，请更改 CMK 的别名。

  • 一个具有 aws:RequestAlias 的密钥策略，允许委托人在 CMK 操作中使用 Encrypt，但前提是 Encrypt 请求使用该别名来标识 CMK。

  • 一个具有 IAM 的 aws:ResourceTag 策略，该策略拒绝将 CMKs 用于特定标签键和标签值的权限。这允许您将策略应用于一组选定的 CMKs，而无需在策略语句中列出 ARNs 的键 CMKs。要在集合中添加或删除 CMKs，请标记或取消标记 CMK。

  • 一个具有 IAM 的 aws:RequestTag 策略，仅允许委托人删除 "Purpose"="Test" CMK 标签。

  • 一个具有 IAM 的 aws:TagKeys 策略，该策略拒绝使用 CMK 标签键标记或取消标记 Restricted的权限。

ABAC 使访问管理变得灵活且可扩展。例如，您可以使用 aws:ResourceTag 条件键创建 IAM 策略，该策略允许委托人仅在 CMK 具有 CMK 标签时才对某些操作使用 Purpose=Test。该策略适用于 CMKs 账户的所有区域中的所有 AWS。

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

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

但是，如果您使用此功能，在管理标签和别名时要小心。添加、更改或删除标签或别名可能会无意中允许或拒绝访问 CMK。无权更改密钥策略或创建授权的密钥管理员可以控制对 CMKs 的访问（如果他们有权管理标签和别名）。要降低此风险，请考虑限制管理标签的权限和别名。例如，您可能希望仅允许选择委托人来管理 Purpose=Test 标签。有关详细信息，请参阅 使用别名控制对 CMKs 的访问 和 使用标签控制对 CMKs 的访问.

标签或别名?

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

您可能决定根据您的特定 AWS 使用模式使用标签或使用别名。例如，如果您已向大多数管理员授予标记权限，则基于别名控制授权策略可能会更容易。或者，如果您接近账户和区域中的别名配额或每个 CMK 的别名配额，则可能更喜欢基于标签的授权策略。

下列优点是通用的。

基于标签的访问控制的优势

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

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

  • 授予对一组 CMKs 的访问权限。

    您可以使用标签来管理对同一 CMKs 账户和区域中的一组 AWS 的访问。将相同的标签或标签键分配给您选择的 CMKs。然后，创建一个基于标签或标签键的易于维护的简单策略语句。要在授权组中添加或删除CMK，请添加或删除标签；您无需编辑策略。

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

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

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

    • 必须与该别名关联。CMK

    • 该请求必须使用别名来标识 CMK。

    • 委托人必须有权在 CMK 条件约束下使用 kms:RequestAlias。

    如果您的应用程序通常使用别名或别名 ARNs 来引用 CMKs，这将特别有用。

  • 提供非常有限的权限。

    别名在 AWS 账户和区域中必须是唯一的。因此，向委托人授予基于别名的 CMK 的访问权限可能比向委托人授予基于标签的访问权限限制要大得多。与别名不同，标签可分配给同一账户和区域中的多个CMKs。如果您选择这样做，则可以使用别名模式（如 alias/test*）向委托人授予对同一账户和区域中的 CMKs 组的访问权限。但是，允许或拒绝对特定别名的访问允许非常严格地控制 CMKs。

ABAC for AWS KMS 问题排查

根据标签和别名控制对 CMKs 的访问是方便而强大的。但是，您可能会容易遇到一些您希望防止的可预测的错误。

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

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

例如，假设委托人有权基于 CMK 标签访问 Project=Alpha，如以下示例 IAM 策略语句提供的权限。 

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

如果从该 CMK 中删除标签或更改了标签值，则委托人不再具有将 CMK 用于指定操作的权限。当委托人尝试在使用客户托管的 AWS 的 CMK 服务中读取或写入数据时，这很明显。要跟踪标签更改，请查看 CloudTrail 日志中的 TagResource 或 UntagResource 条目。

要在不更新策略的情况下恢复访问权限，请更改 CMK上的标签。除了在整个 AWS KMS 中生效的有效期之外，此操作的影响最小。为防止此类错误，仅为需要它的委托人授予标记和取消标记权限，并将标记权限限制为需要管理的标签。在更改标签之前，搜索策略以检测依赖该标签的访问权限，并在具有该标签的所有区域中获取 CMKs。在更改特定标签时，您可以考虑创建 Amazon CloudWatch 警报。

由于别名更改而进行的访问更改

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

例如，以下 IAM 策略语句使用 kms：ResourceAliases 条件键，以允许访问具有任一指定别名的账户的不同区域中的 CMKs。 

{
  "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 日志以查找 CreateAlias、UpdateAlias 和 DeleteAlias 条目。

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

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

由于别名配额而被拒绝访问

如果 CMK 超出某个账户和区域的默认每 ResourceAliases 配额，kms：AccessDeniedResourceAliasesCMK 条件授权使用的用户将会收到 CMK 异常。

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

延迟的授权更改

您对标签和别名所做的更改可能需要长达五分钟来影响 CMKs 的授权。因此，标签或别名更改可能会在影响授权的 API 操作的响应中反映。此延迟可能长于影响大多数 AWS KMS 操作的短暂最终一致性延迟。

例如，您可能有一个 IAM 策略，该策略允许特定委托人将任何 CMK 与 "Purpose"="Test" 标签结合使用。然后，将 "Purpose"="Test" 标签添加到 CMK。尽管 TagResource 操作完成并且 ListResourceTags 响应确认标签已分配给 CMK，但委托人可能在长达 5 分钟内无法访问 CMK。

要防止错误，请在代码中构建此预期延迟。

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

更新别名时，将现有别名与其他 CMK 关联。

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

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

例如，以下 ListAliases 示例响应显示更新了 ProjectAlpha_Test 条件中的 kms:ResourceAliases 别名。因此，根据别名具有访问权限的委托人将失去之前关联的 CMK 的访问权限。相反，他们有权访问新关联的 CMK。 

$ 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
        }
    ]
}

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

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