本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 对 ABAC 进行故障排除 AWS KMS
基于 KMS 密钥的标签和别名控制对 KMS 密钥的访问非常方便，且功能强大。但是，它容易出现一些您希望防止的可预测错误。
## 由于标签更改而更改访问权限
如果某个标签被删除或其值被更改，则仅能基于该标签访问 KMS 密钥的委托人将被拒绝访问 KMS 密钥。当拒绝策略语句中包含的标签添加到 KMS 密钥时，也会发生这种情况。向 KMS 密钥添加与策略相关的标签可以允许访问应被拒绝访问 KMS 密钥的委托人。
例如，假设委托人可以基于 `Project=Alpha` 标签访问 KMS 密钥，例如以下示例 IAM policy 语句提供的权限。
------
#### [ JSON ]
****
```
{
"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](ct-tagresource.md)或[UntagResource 条目](ct-untagresource.md)。
要在不更新策略的情况下恢复访问，请更改 KMS 密钥上的标签。这一措施除了短时间在整个 AWS KMS中生效之后，产生的影响极小。为了防止这样的错误，请仅向需要它的委托人授予标记和取消标记权限，并[将其标记权限限制](tag-permissions.md#tag-permissions-conditions)到他们需要管理的标签。更改标签之前，请搜索策略以检测依赖于标签的访问权限，并在具有该标签的所有区域中获取 KMS 密钥。您可以考虑在更改特定标签时创建 Amazon CloudWatch 警报。
## 由于别名更改而导致的访问权限更改
如果别名被删除或与其他 KMS 密钥关联，则仅能基于该别名访问 KMS 密钥的委托人将被拒绝访问 KMS 密钥。当拒绝策略语句中包含与 KMS 密钥关联的别名时，也会发生这种情况。向 KMS 密钥添加与策略相关的别名也可以允许访问应被拒绝访问 KMS 密钥的委托人。
例如，以下 IAM 策略声明使用 k [ms: ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 条件密钥允许使用任意指定别名访问账户中不同区域的 KMS 密钥。
------
#### [ JSON ]
****
```
{
"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](ct-updatealias.md)](ct-createalias.md)、和[DeleteAlias](ct-deletealias.md)条目。
要在不更新策略的情况下恢复访问，请更改与 KMS 密钥关联的别名。由于每个别名只能与账户和区域中的一个 KMS 密钥相关联，因此管理别名比管理标签要困难一些。恢复一些委托人对一个 KMS 密钥的访问权限可能会拒绝相同或其他委托人对其他 KMS 密钥的访问。
为了防止出现此错误，请仅向需要它的委托人授予别名管理权限，并[将其别名管理权限限制](alias-access.md#alias-access-limiting)到他们需要管理的别名。在更新或删除别名之前，请搜索策略以检测依赖于别名的访问权限，并在与别名关联的所有区域中查找 KMS 密钥。
## 由于别名配额而拒绝访问
如果 KMS 密钥超过该账户和地区[每个 [KMS 密钥配额的默认别名，则获得 kms: ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 条件授权使用 KMS 密钥](resource-limits.md#aliases-per-key)的用户将获得`AccessDenied`例外。
要恢复访问，请删除与 KMS 密钥关联的别名，使其符合配额。或者使用备用机制授予用户访问 KMS 密钥的权限。
## 延迟的授权更改
您对标签和别名的更改最多可能需要 5 分钟的时间才能影响 KMS 密钥授权。因此，标签或别名更改可能会在 API 操作影响授权之前反映在响应中。这种延迟可能比影响大多数 AWS KMS 操作的短暂的最终一致性延迟要长。
例如，您可能拥有一个 IAM policy，允许某些委托人使用带有 `"Purpose"="Test"` 标签的任何 KMS 密钥。然后，您将 `"Purpose"="Test"` 标签添加到 KMS 密钥。尽管[TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)操作已完成且[ListResourceTags](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListResourceTags.html)响应确认标签已分配给 KMS 密钥，但委托人可能在长达五分钟内无法访问 KMS 密钥。
为了防止出现错误，请将此预期延迟构建到您的代码中。
## 由于别名更新而失败的请求
当您更新别名时，您将现有别名与另一个 KMS 密钥关联。
[解密](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)和指定别名或[别名](concepts.md#key-id-alias-name) [ARN](concepts.md#key-id-alias-ARN) 的[ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)请求可能会失败，因为该别名现在与未加密密文的 KMS 密钥相关联。这种情况通常会返回 `IncorrectKeyException` 或者 `NotFoundException`。或者如果请求中没有 `KeyId` 或 `DestinationKeyId` 参数，则操作可能会失败，并出现 `AccessDenied` 异常，因为调用方不再具有对加密密文的 KMS 密钥的访问权限。
您可以通过查看[CreateAlias[UpdateAlias](ct-updatealias.md)](ct-createalias.md)、和 CloudTrail 日志条目的[DeleteAlias](ct-deletealias.md)日志来跟踪更改。您还可以在[ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)响应中使用该`LastUpdatedDate`字段的值来检测更改。
例如，以下[ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)示例响应显示`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 密钥。请仅向需要它的委托人授予别名管理权限，并[将其别名管理权限限制](alias-access.md#alias-access-limiting)到他们需要管理的别名。