本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 對適用於 的 ABAC 進行故障診斷 AWS KMS
根據 KMS 金鑰的標籤和別名來控制對 KMS 金鑰的存取非常方便且功能強大。但是，很容易出現一些您想要防止的可預測錯誤。
## 存取因標籤變更而變更
如果刪除標籤或變更其值，則只能根據該標籤存取 KMS 金鑰的委託人將被拒絕存取 KMS 金鑰。當拒絕政策陳述式中包含的標籤新增至 KMS 金鑰時，也可能會發生這種情況。將政策相關標籤新增至 KMS 金鑰可以允許存取應被拒絕存取 KMS 金鑰的委託人。
例如，假設委託人可以根據 `Project=Alpha` 標籤存取 KMS 金鑰，例如下列範例 IAM 政策陳述式所提供的許可。
------
#### [ 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 服務中讀取或寫入資料時，這可能會變得很明顯。若要追蹤標籤變更，請檢閱 [TagResource](ct-tagresource.md) 或 [UntagResource 項目](ct-untagresource.md)的 CloudTrail 日誌。
若要在不更新政策的情況下還原存取權，請變更 KMS 金鑰上的標籤。這個動作的影響最小，除了很短的一段時間，該動作會在整個 AWS KMS中有效。為了防止類似錯誤，請僅將標記和取消標記許可提供給需要的委託人，並將[其標記許可限制](tag-permissions.md#tag-permissions-conditions)為他們需要管理的標籤。變更標籤之前，搜尋政策可偵測依存於標籤的存取權，並在具有該標籤的所有區域中取得 KMS 金鑰。當特定標籤變更時，您可能會考慮建立 Amazon CloudWatch 警示。
## 存取因別名變更而變更
如果別名遭到刪除或與不同的 KMS 金鑰相關聯，則只能以該別名為基礎存取 KMS 金鑰的委託人將會被拒絕存取 KMS 金鑰。當與 KMS 金鑰相關聯的別名包含在拒絕政策陳述式中時，也可能會發生這種情況。將政策相關別名新增至 KMS 金鑰也可以允許存取應被拒絕存取 KMS 金鑰的委託人。
例如，下列 IAM 政策陳述式使用 [kms: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](ct-createalias.md)、[UpdateAlias](ct-updatealias.md) 和 [DeleteAlias](ct-deletealias.md) 項目。
若要在不更新政策的情況下還原存取權，請變更與 KMS 金鑰相關聯的別名。由於每個別名只能與帳戶和區域中的一個 KMS 金鑰相關聯，因此管理別名會比管理標籤困難。還原某個 KMS 金鑰上的某些委託人的存取，可以拒絕相同或其他委託人存取不同的 KMS 金鑰。
若要避免發生此錯誤，請僅將別名管理許可提供給需要的委託人，並將[其別名管理許可](alias-access.md#alias-access-limiting)限制為需要管理的別名。在更新或刪除別名之前，搜尋政策以偵測取決於別名的存取權，並在與別名相關聯的所有區域中尋找 KMS 金鑰。
## 因別名配額而拒絕存取
如果 KMS 金鑰超過該帳戶和區域中[每個 KMS 金鑰別名](resource-limits.md#aliases-per-key)的預設配額，則已授權透過 [kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 條件使用 KMS 金鑰的使用者會遇到 `AccessDenied` 例外狀況。
若要還原存取權，請刪除與 KMS 金鑰相關聯的別名，使其符合配額。或者使用替代機制，讓使用者存取 KMS 金鑰。
## 延遲的授權變更
您對標籤和別名所做的變更可能需要最長五分鐘才會體現在 KMS 金鑰授權上。因此，標籤或別名變更可能會反映在 API 操作的回應中，然後才會影響授權。此延遲可能比影響大多數 AWS KMS 操作的短暫最終一致性延遲更長。
例如，您可能擁有 IAM 政策，允許特定委託人將任何 KMS 金鑰與 `"Purpose"="Test"` 標籤搭配使用。然後，您將 `"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 金鑰。
指定[別名名稱](concepts.md#key-id-alias-name)或[別名 ARN](concepts.md#key-id-alias-ARN) [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) 和 [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html) 請求可能會失敗，因為別名現在與未加密文字的 KMS 金鑰相關聯。這種情況通常會傳回 `IncorrectKeyException` 或 `NotFoundException`。或者，如果請求沒有 `KeyId` 或 `DestinationKeyId` 參數，則操作可能會失敗，並顯示 `AccessDenied` 例外狀況，因為呼叫者不再具有加密文字之 KMS 金鑰的存取權。
您可以透過查看 CloudTrail 日誌來取得 [CreateAlias](ct-createalias.md)、[UpdateAlias](ct-updatealias.md) 和 [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)限制為需要管理的別名。