使用 ABACAmazon KMS - Amazon Key Management Service
的 ABAC 条件键Amazon KMS标签还是别名？故障排除Amazon KMS
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 Amazon Web Services 服务入门。

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

使用 ABACAmazon KMS

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

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

Notes

使用 ABACAmazon KMS，请谨慎授予委托人管理标签和别名的权限。更改标签或别名可能允许或拒绝对 CMK 的权限。没有权限更改密钥策略或创建授权的密钥管理员可以控制对 CMK 的访问，如果他们有权管理标签或别名。

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

要根据 CMK 别名控制对其访问，必须使用条件键。您不能使用别名来表示 CMKResource元素。当别名显示在Resource元素时，策略语句将应用于别名，而不适用于关联的 CMK。

了解更多信息

的 ABAC 条件键Amazon KMS

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

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

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

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

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

  • IAM 策略kms:ResourceAliases，允许使用具有特定别名或别名模式的 CMK。这与依赖标签的策略略略有不同：尽管您可以在策略中使用别名模式，但每个别名必须在 Amazon Web Services 账户 以及区域。这允许您将策略应用于选定的 CMK 集，而无需在策略语句中列出 CMK 的键 ARN。要在集中添加或删除 CMK，请更改 CMK 的别名。

  • 带有的密钥策略aws:RequestAlias，允许委托人使用 CMKEncrypt操作，但仅当Encrypt请求使用该别名来标识 CMK。

  • IAM 策略aws:ResourceTag/tag-key，拒绝使用带有特定标签键和标签值的 CMK。这允许您将策略应用于选定的 CMK 集，而无需在策略语句中列出 CMK 的键 ARN。要在集合中添加或删除 CMK，请标记或取消标记 CMK。

  • IAM 策略aws:RequestTag/tag-key，允许委托人仅删除"Purpose"="Test"CMK 标签。

  • IAM 策略aws:TagKeys拒绝标记或取消标记 CMK 的权限Restricted标签键。

ABAC 使访问管理具有灵活性和可扩展性。例如，您可以使用aws:ResourceTag/tag-key条件键创建 IAM 策略，该策略允许委托人仅在 CMK 具有Purpose=Test标签。该策略适用于 Amazon Web Services 账户 。

当附加到用户或角色时，以下 IAM 策略允许委托人将所有现有 CMK 与Purpose=Test标记，用于指定操作。要提供对新 CMK 的此访问权限，您无需更改策略。您只需将Purpose=Test标签添加到 CMK。同样，要从带有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 的访问。没有权限更改密钥策略或创建授权的密钥管理员可以控制对 CMK 的访问，如果他们有权管理标签和别名。为了减轻这种风险，请考虑限制管理标签的权限和别名。例如，您可能只允许选择要管理Purpose=Test标签。有关详细信息，请参阅 使用别名控制对 CMK 的访问 和 使用标签控制对 CMK 的访问。

标签还是别名？

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

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

以下好处是普遍感兴趣的。

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

  • 相同的授权机制，适用于不同类型的Amazon资源的费用。

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

  • 授权访问一组 CMK。

    您可以使用标签管理对同一 Amazon Web Services 账户 以及区域。将相同的标签或标签键分配给您选择的 CMK。然后创建基于标签或标签键的简单、易于维护的策略声明。要在授权组中添加或删除 CMK，请添加或删除标记；您无需编辑策略。

基于别名的访问控制的优点

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

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

    • CMK 必须与该别名相关联。

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

    • 委托人必须拥有使用 CMK 的权限，但须遵守kms:RequestAlias条件。

    如果您的应用程序通常使用别名或别名 ARN 来引用 CMK，则此功能特别有用。

  • 提供非常有限的权限。

    别名在 Amazon Web Services 账户 以及区域。因此，授予委托人基于别名访问 CMK 的权限可能比基于标签授予他们访问权限要大得多。与别名不同，标签可以分配给相同账户和区域中的多个 CMK。如果选择，则可以使用别名模式，例如alias/test*，使委托人能够访问同一账户和区域中的一组 CMK。但是，允许或拒绝访问特定别名允许对 CMK 进行非常严格的控制。

故障排除Amazon KMS

根据 CMK 的标签和别名控制对 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 执行指定操作的权限。当委托人尝试读取或写入数据时，这可能会变得明显。Amazon使用客户托管 CMK 的服务。要跟踪标签更改，请查看您的 CloudTrail 日志TagResource或者UntagResource。

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

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

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

例如，以下 IAM 策略语句使用KMS: 资源别名条件键，以允许访问具有任何指定别名的账户不同区域的 CMK。 

{
  "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 的访问。

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

由于别名配额而拒绝访问

有权使用 CMK 的用户KMS: 资源别名条件将获得AccessDenied异常，如果 CMK 超过默认每个 CMK 的别名配额为该帐户和地区。

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

延迟的授权更改

您对标签和别名所做的更改最多可能需要五分钟才能影响 CMK 的授权。因此，标签或别名更改可能会在 API 操作影响授权之前反映在响应中。此延迟可能比影响大多数Amazon KMS操作。

例如，您可能拥有允许某些委托人使用任何 CMK 和"Purpose"="Test"标签。然后添加"Purpose"="Test"标签设置为 CMK。虽然TagResource操作完成并ListResourceTags响应确认标记已分配给 CMK，则承担者最多可能在五分钟内无法访问 CMK。

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

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

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

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

您可以通过查看CreateAlias、UpdateAlias, 和DeleteAlias日志条目。您也可以使用LastUpdatedDate字段中的ListAliases响应来检测更改。

例如，以下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，他们可能需要继续访问它。在这种情况下，您可能需要更新策略以确保委托人有权使用这两个 CMK。

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