本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 適用於 的 ABAC AWS KMS 屬性型存取控制 (ABAC) 是一種授權策略，可根據屬性定義許可。 AWS KMS 支援 ABAC，可讓您根據與 KMS 金鑰相關聯的標籤和別名來控制對客戶受管金鑰的存取。在 中啟用 ABAC 的標籤和別名條件金鑰 AWS KMS 提供強大且靈活的方式，以授權主體使用 KMS 金鑰，而無需編輯政策或管理授予。但是，您應該謹慎使用這些功能，避免委託人意外被允許或拒絕存取。 如果您使用 ABAC，請注意管理標籤和別名的許可現在是存取控制許可。部署依存於標籤或別名的政策之前，請務必先知曉所有 KMS 金鑰上的現有標籤和別名。新增、刪除和更新別名，以及標記和取消標記金鑰時，請採取合理的預防措施。只將管理標籤和別名的許可授予需要的委託人，並限制他們可以管理的標籤和別名。 **備註** 使用 ABAC for 時 AWS KMS，請謹慎授予主體管理標籤和別名的許可。變更標籤或別名可能會允許或拒絕 KMS 金鑰的許可。沒有變更主要政策或建立授權之許可的重要管理員可以控制 KMS 金鑰的存取，如果他們擁有管理標籤或別名的許可。 可能最多需要五分鐘才能將標籤和別名變更體現在 KMS 金鑰授權上。最近的變更可能會在 API 操作中可見，然後才會影響授權。 若要根據 KMS 金鑰的別名來控制對 KMS 金鑰的存取，您必須使用條件索引鍵。您不能使用別名來代表政策陳述式 `Resource` 元素中的 KMS 金鑰。當別名出現在 `Resource` 元素時，政策陳述式會套用至別名，而不是相關聯的 KMS 金鑰。 **進一步了解** + 如需 ABAC AWS KMS 支援的詳細資訊，包括範例，請參閱 [使用別名來控制對 KMS 金鑰的存取](alias-authorization.md)和 [使用標籤來控制對 KMS 金鑰的存取](tag-authorization.md)。 + 如需使用標籤控制資源 AWS 存取的一般資訊，請參閱《*IAM 使用者指南*》中的 [ABAC 是什麼 AWS？](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)以及[使用資源標籤控制 AWS 資源存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)。 ## 的 ABAC 條件金鑰 AWS KMS 若要根據 KMS 金鑰的標籤和別名授權存取，請在金鑰政策或 IAM 政策中使用下列條件索引鍵。 | ABAC 條件索引鍵 | Description | Policy type (政策類型) | AWS KMS 操作 | | --- | --- | --- | --- | | [aws:ResourceTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) | KMS 金鑰上的標籤 (鍵和值) 與政策中的標籤 (鍵和值) 或標籤模式相符 | 僅限 IAM 政策 | KMS 金鑰資源操作 2 | | [aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) | 請求中的標籤 (鍵和值) 與政策中的標籤 (鍵和值) 或標籤模式相符 | 金鑰政策和 IAM 政策 1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)、[UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) | | [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) | 請求中的標籤索引鍵與政策中的標籤索引鍵相符 | 金鑰政策和 IAM 政策 1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)、[UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) | | [kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) | 與 KMS 金鑰相關聯的別名符合政策中的別名或別名模式 | 僅限 IAM 政策 | KMS 金鑰資源操作 2 | | [kms:RequestAlias](conditions-kms.md#conditions-kms-request-alias) | 代表請求中 KMS 金鑰的別名與政策中的別名或別名模式相符。 | 金鑰政策和 IAM 政策 1 | [Cryptographic operations](kms-cryptography.md#cryptographic-operations)、[DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)、[GetPublicKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html) | 1 可在金鑰政策中使用的任何條件索引鍵也可以在 IAM 政策中使用，但只能在[金鑰政策允許](key-policy-default.md#key-policy-default-allow-root-enable-iam)的情形下。 2*KMS 金鑰資源操作*是針對特定 KMS 金鑰授權的操作。若要識別 KMS 金鑰資源操作，請在 [AWS KMS 許可表](kms-api-permissions-reference.md#kms-api-permissions-reference-table)中尋找 `Resources` 欄 KMS 金鑰的值，以執行操作。 例如，您可以使用這些條件索引鍵來建立下列政策。 + 具有 `kms:ResourceAliases` 的 IAM 政策，允許使用具有特定別名或別名模式的 KMS 金鑰的許可。這與依賴標籤的政策略有不同：雖然您可以在政策中使用別名模式，但每個別名在 AWS 帳戶 和 區域中必須是唯一的。這可讓您將政策套用至一組精選 KMS 金鑰，而不會在政策陳述式中列出 KMS 金鑰的金鑰 ARN。若要為集合新增 KMS 金鑰或從中移除 KMS 金鑰，請變更 KMS 金鑰的別名。 + 具有 `kms:RequestAlias` 的金鑰政策允許委託人在 `Encrypt` 操作中使用 KMS 金鑰，但僅在 `Encrypt` 請求會使用該別名來識別 KMS 金鑰的情形下。 + 具有 `aws:ResourceTag/tag-key` 的 IAM 政策拒絕將 KMS 金鑰與特定標籤索引鍵和標籤值使用的許可。這可讓您將政策套用至一組精選 KMS 金鑰，而不會在政策陳述式中列出 KMS 金鑰的金鑰 ARN。若要為集合新增 KMS 金鑰或從中移除 KMS 金鑰，請標記或取消標記 KMS 金鑰。 + 具有 `aws:RequestTag/tag-key` 的 IAM 政策允許委託人只刪除 `"Purpose"="Test"` KMS 金鑰標籤。 + 具有 `aws:TagKeys` 的 IAM 政策拒絕使用 `Restricted` 標籤索引鍵標記或取消標記 KMS 金鑰的許可。 ABAC 讓存取管理具有靈活性和可擴展性。例如，您可以使用 `aws:ResourceTag/tag-key` 條件索引鍵來建立 IAM 政策，此政策只允許委託人在 KMS 金鑰具有 `Purpose=Test` 標籤時針對特定操作使用 KMS 金鑰。此政策適用於 AWS 帳戶所有區域中的所有 KMS 金鑰。 當連接至使用者或角色時，下列 IAM 政策允許委託人將所有現有的 KMS 金鑰與 `Purpose=Test` 標籤搭配用於指定的操作。若要將此存取權提供給新的或現有的 KMS 金鑰，則您不需要變更政策。只需將 `Purpose=Test` 標籤連接至 KMS 金鑰。同樣地，若要從具有 `Purpose=Test` 標籤的 KMS 金鑰中移除此存取權，請編輯或刪除標籤。 ------ #### [ JSON ] **** ``` { "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" } } } ] } ``` ------ 但是，如果您使用此功能，則請謹慎管理標籤和別名。新增、變更或刪除標籤或別名可能會意外允許或拒絕對 KMS 金鑰的存取。如果他們有管理標籤和別名的許可，則沒有變更主要政策或建立授予之許可的金鑰管理員可以控制對 KMS 金鑰的存取。為了減輕這種風險，請考慮[限制管理標籤的許可](tag-permissions.md#tag-permissions-conditions)和[別名](alias-access.md#alias-access-limiting)。例如，您可能只允許選取的委託人管理 `Purpose=Test` 標籤。如需詳細資訊，請參閱 [使用別名來控制對 KMS 金鑰的存取](alias-authorization.md) 和 [使用標籤來控制對 KMS 金鑰的存取](tag-authorization.md)。 ## 標籤或別名？ AWS KMS 支援具有標籤和別名的 ABAC。這兩種選項都提供靈活、可擴展的存取控制策略，但彼此略有不同。 您可以根據您的特定使用模式，決定 AWS 使用標籤或使用別名。例如，如果您已將標記許可指定給大多數管理員，則根據別名來控制授權策略可能會比較容易。或者，如果接近[每個 KMS 金鑰的別名](resource-limits.md#aliases-per-key)配額，則您可能會偏好基於標籤的授權策略。 以下是一般利益的優勢。 **標籤型存取控制的優勢** + 適用於不同資源類型的相同授權機制 AWS 。 您可以使用相同的標籤或標籤金鑰來控制對多種資源類型的存取，例如 Amazon Relational Database Service (Amazon RDS) 叢集、Amazon Elastic Block Store (Amazon EBS) 磁碟區和 KMS 金鑰。此功能可啟用數種不同的授權模式，這些模式比傳統的角色型存取控制更靈活。 + 授權一組 KMS 金鑰的存取權。 您可以使用標籤來管理對相同 AWS 帳戶 和區域中一組 KMS 金鑰的存取。將相同的標籤或標籤金鑰指派給您選擇的 KMS 金鑰。然後建立以標籤或標籤索引鍵為基礎的簡單、易於維護的政策陳述式。若要為授權群組新增 KMS 金鑰或從中移除金鑰，請新增或移除標籤；您無需編輯政策。 **別名型存取控制的優勢** + 根據別名授權存取密碼編譯操作。 大部分屬性的請求型政策條件，包括 [aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag)，僅影響新增、編輯或刪除屬性的操作。但 [kms:RequestAlias](conditions-kms.md#conditions-kms-request-alias) 條件索引鍵根據用於識別請求中 KMS 金鑰的別名控制對密碼編譯操作的存取。例如，您可以授予委託人在 `Encrypt` 操作中使用 KMS 金鑰的許可，但僅在 `KeyId` 參數值為 `alias/restricted-key-1` 的情形下。若要滿足此條件，需要下列所有項目： + KMS 金鑰必須與該別名相關聯。 + 請求必須使用別名來識別 KMS 金鑰。 + 委託人必須擁有許可才能使用受限於 `kms:RequestAlias` 條件的 KMS 金鑰。 如果您的應用程式通常使用別名名稱或別名 ARN 來引用 KMS 金鑰，則這會特別有用。 + 提供非常有限的許可。 別名在 AWS 帳戶 和 區域中必須是唯一的。因此，授予委託人根據別名存取 KMS 金鑰的許可，可能比為委託人授予標籤型存取權更嚴格。與別名不同的是，標籤可指派給相同帳戶和區域中的多個 KMS 金鑰。如果選擇，則您可以使用別名模式，例如 `alias/test*`，讓委託人可以存取相同帳戶和區域中的一組 KMS 金鑰。不過，允許或拒絕存取特定別名，實現了對 KMS 金鑰非常嚴格的控制。 # 對適用於 的 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)限制為需要管理的別名。