ABAC 故障診斷 AWS KMS - AWS Key Management Service
存取因標籤變更而變更存取因別名變更而變更因別名配額而拒絕存取延遲的授權變更因別名更新而失敗的請求

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

ABAC 故障診斷 AWS KMS

根據金鑰的標籤和別名來控制對KMS金鑰的存取，既方便又強大。但是，很容易出現一些您想要防止的可預測錯誤。

存取因標籤變更而變更

如果刪除標籤或變更其值，則僅根據該標籤存取KMS金鑰的主體將被拒絕存取KMS金鑰。當拒絕政策陳述式中包含的標籤新增至KMS金鑰時，也會發生這種情況。將政策相關標籤新增至KMS金鑰可以允許存取應被拒絕存取KMS金鑰的主體。

例如，假設委託人可以根據Project=Alpha標籤存取KMS金鑰，例如以下範例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"
        }
      }
    }
  ]
}

如果從該KMS索引鍵刪除標籤或變更標籤值，則委託人將不再擁有使用索引KMS鍵進行指定操作的許可。當委託人嘗試讀取或寫入使用客戶受管金鑰之 AWS 服務中的資料時，這可能變得很明顯。若要追蹤標籤變更，請檢閱您的 CloudTrail日誌，以取得 TagResource或 UntagResource 項目。

若要還原存取權而不更新政策，請變更KMS金鑰上的標籤。這個動作的影響最小，除了很短的一段時間，該動作會在整個 AWS KMS中有效。為了防止類似錯誤，請僅將標記和取消標記許可提供給需要的委託人，並將其標記許可限制為他們需要管理的標籤。在變更標籤之前，搜尋政策以偵測取決於標籤的存取，並在所有具有標籤的區域中取得KMS金鑰。變更特定標籤時，您可以考慮建立 Amazon CloudWatch 警示。

存取因別名變更而變更

如果別名已刪除或與不同的KMS金鑰相關聯，則僅根據該別名存取KMS金鑰的主體將被拒絕存取KMS金鑰。當與KMS金鑰相關聯的別名包含在拒絕政策陳述式中時，也可能發生這種情況。將政策相關別名新增至KMS金鑰也可以允許存取應被拒絕存取KMS金鑰的主體。

例如，下列IAM政策陳述式使用 kms：ResourceAliases 條件索引鍵，允許使用指定別名存取帳戶不同區域中的KMS索引鍵。

{
  "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"
          ]
        }
      }
    }
  ]
}

若要追蹤別名變更，請檢閱 CreateAlias、 UpdateAlias和 DeleteAlias項目的 CloudTrail 日誌。

若要還原存取權而不更新政策，請變更與KMS金鑰相關聯的別名。由於每個別名只能與帳戶和區域中的一個KMS金鑰相關聯，因此管理別名比管理標籤更困難。還原對某個KMS金鑰上某些主體的存取權可能會拒絕相同或其他主體對不同KMS金鑰的存取權。

若要避免發生此錯誤，請僅將別名管理許可提供給需要的委託人，並將其別名管理許可限制為需要管理的別名。在更新或刪除別名之前，請搜尋政策以偵測取決於別名的存取，並在與別名相關聯的所有區域中尋找KMS金鑰。

因別名配額而拒絕存取

經授權以公里使用KMS金鑰的使用者：如果KMS金鑰超過該帳戶和區域每個KMS金鑰配額的預設別名，則 條件會取得AccessDenied例外狀況。 ResourceAliases

若要還原存取權，請刪除與KMS金鑰相關聯的別名，使其符合配額。或使用替代機制讓使用者存取 KMS金鑰。

延遲的授權變更

您對標籤和別名所做的變更最多可能需要五分鐘的時間，才能影響KMS金鑰的授權。因此，標籤或別名變更可能會在影響授權之前反映在API操作的回應中。此延遲可能比影響大多數 AWS KMS 操作的短暫最終一致性延遲更長。

例如，您可能有一個IAM政策，允許某些主體將任何KMS金鑰與"Purpose"="Test"標籤搭配使用。然後將"Purpose"="Test"標籤新增至KMS金鑰。雖然TagResource操作完成且ListResourceTags回應確認標籤已指派給KMS金鑰，但委託人可能無法存取KMS金鑰最多五分鐘。

若要防止錯誤，請將此預期延遲建置到您的程式碼中。

因別名更新而失敗的請求

當您更新別名時，您可以將現有的別名與不同的KMS金鑰建立關聯。

解密和指定別名名稱或別名ARN的ReEncrypt請求可能會失敗，因為別名現在與未加密密碼文字的KMS金鑰相關聯。這種情況通常會傳回 IncorrectKeyException 或 NotFoundException。或者，如果請求沒有 KeyId或 DestinationKeyId 參數，則操作可能會失敗，AccessDenied因為呼叫者不再能夠存取加密密碼文字的KMS金鑰。

您可以透過查看 CreateAlias、 和 CloudTrail 日誌項目的DeleteAlias日誌UpdateAlias來追蹤變更。您也可以在ListAliases回應中使用 LastUpdatedDate 欄位的值來偵測變更。

例如，下列ListAliases範例回應顯示 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金鑰。請僅將別名管理許可提供給需要的委託人，並將其別名管理許可限制為需要管理的別名。