将 ABAC 用于 AWS KMS - AWS Key Management Service

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

将 ABAC 用于 AWS KMS

基于属性的访问控制 (ABAC) 是一种授权策略,它根据属性定义权限。 通过允许您根据与 关联的标签和别名控制对客户主密钥 (AWS KMS) 的访问来支持 CMKs CMKsABAC。在 中启用 ABAC 的标签和别名条件键AWS KMS提供了一种强大而灵活的方法来授权委托人使用 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 TagResourceUntagResource
aws:TagKeys 请求中的标签键与策略中的标签键匹配 密钥策略和 IAM 策略1 TagResourceUntagResource
kms:ResourceAliasess 与 关联的别名与策略中的别名或别名模式CMK匹配 IAM 仅 策略 CMK 资源操作 2
kms:RequestAlias 表示请求CMK中的 的别名与策略中的别名或别名模式匹配。 密钥策略和 IAM 策略1 加密操作DescribeKeyGetPublicKey

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

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

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

  • 具有 IAM 的 策略,该aws:ResourceAliases策略允许将 CMKs 与特定别名或别名模式结合使用的权限。这与依赖于标签的策略稍有不同:虽然您可以在策略中使用别名模式,但每个别名在AWS账户和区域中必须是唯一的。这允许您将策略应用于一组选定的策略CMKs,而无需在策略语句CMKs中列出 的密钥 ARNs。要在集中添加或删除 CMKs ,请更改 的别名CMK。

  • 具有 aws:RequestAlias 的密钥策略,允许委托人CMK在 Encrypt 操作中使用 ,但仅当Encrypt请求使用该别名标识 时CMK。

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

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

  • 具有 IAM 的 aws:TagKeys 策略拒绝使用标签CMKRestricted键标记或取消标记 的权限。

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 故障排除 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。要跟踪标签更改,请检查 CloudTrailTagResourceUntagResource 条目日志。

要在不更新策略的情况下恢复访问权限,请更改 上的标签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" ] } } ] }

要跟踪别名更改,请查看 CloudTrailCreateAliasUpdateAliasDeleteAlias 条目的日志。

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

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

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

如果 CMK 超过该账户和区域的每个kms:ResourceAliasess配额的默认AccessDenied别名,由 CMKkms:ResourceAliases CMK 条件授权使用的用户将会收到 异常。

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

延迟的授权更改

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

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

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

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

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

解密ReEncrypt指定别名别名 ARN 的请求可能会失败,因为别名现在与未加密密文CMK的 关联。这种情况通常返回 IncorrectKeyExceptionNotFoundException。或者,如果请求没有 KeyIdDestinationKeyId 参数,则操作可能会失败并出现AccessDenied异常,因为调用方不再有权访问加密密文CMK的 。

您可以通过查看 CloudTrailCreateAliasUpdateAliasDeleteAlias 日志条目的日志来跟踪更改。您还可以使用 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,在与别名关联的所有区域中获取 。仅向需要别名管理权限的委托人授予该权限,并将其别名管理权限限制别名权限限制为需要管理的别名。