本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon SQS 金鑰管理 Amazon SQS 與 AWS Key Management Service (KMS) 整合，以管理伺服器端加密 (SSE) 的 [KMS 金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)。如需 SSE 資訊和金鑰管理定義，請參閱 [Amazon SQS 中的靜態加密](sqs-server-side-encryption.md)。Amazon SQS 使用 KMS 金鑰驗證和保護用於加密和解密訊息的資料金鑰。以下各節提供有關在 Amazon SQS 服務中使用 KMS 金鑰和資料金鑰的資訊。 ## 設定 AWS KMS 許可 每個 KMS 金鑰都必須有一個金鑰政策。請注意，您無法修改 Amazon SQS AWS 受管 KMS 金鑰的金鑰政策。此 KMS 金鑰的政策包括帳戶中的所有主體 (獲授權可使用 Amazon SQS) 使用加密佇列的許可。 Amazon SQS 會根據來電者的 AWS 登入資料來區分來電者，無論他們使用的是不同的 AWS 帳戶、IAM 使用者或 IAM 角色。此外，具有不同範圍政策的相同 IAM 角色將被視為不同的請求者。不過，使用 IAM 角色工作階段時，僅變更 ，`RoleSessionName`同時保留相同的 IAM 角色和範圍政策不會建立不同的請求者。因此，指定 AWS KMS 金鑰政策主體時，請避免單獨使用`RoleSessionName`差異，因為這些工作階段會被視為相同的請求者。 或者，您也可以在指派給主體 (這些主體會產生和消費加密訊息) 的 IAM 政策中，指定必要的許可。如需詳細資訊，請參閱《AWS Key Management Service 開發人員指南》**中的 [在 AWS KMS中使用 IAM 政策](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html)。 **注意** 雖然您可以設定全域許可以從 Amazon SQS 傳送和接收，但 AWS KMS 需要明確命名 IAM 政策 `Resource`區段中特定區域中 KMS 金鑰的完整 ARN。 ### 設定 AWS 服務的 KMS 許可 數個 AWS 服務可做為事件來源，將事件傳送至 Amazon SQS 佇列。若要允許這些事件來源使用加密佇列，您必須建立客戶受管 KMS 金鑰，並在金鑰政策中新增許可，服務才能使用所需的 AWS KMS API 方法。執行下列步驟來設定許可。 **警告** 變更用於加密 Amazon SQS 訊息的 KMS 金鑰時，請注意，使用舊 KMS 金鑰加密的現有訊息將保持使用該金鑰加密。若要解密這些訊息，您必須保留舊的 KMS 金鑰，並確保其金鑰政策授予 Amazon SQS `kms:Decrypt`和 的許可`kms:GenerateDataKey`。更新至用於加密新訊息的新 KMS 金鑰後，請確保在刪除或停用舊 KMS 金鑰之前，處理所有以舊 KMS 金鑰加密的現有訊息並從佇列中移除。 1. 建立客戶管理的 KMS 金鑰。如需詳細資訊，請參閱*《AWS Key Management Service 開發人員指南》*中的[建立索引鍵](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)。 1. 若要允許 AWS 服務事件來源使用 `kms:Decrypt`和 `kms:GenerateDataKey` API 方法，請將下列陳述式新增至 KMS 金鑰政策。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "service.amazonaws.com" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*" }] } ``` ------ 將上述範例中的 "service" 取代為事件來源的*服務名稱*。事件來源包括下列服務。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-key-management.html) 1. 使用 KMS 金鑰的 ARN [設定現有的 SSE 佇列](sqs-configure-sse-existing-queue.md)。 1. 提供加密佇列的 ARN 至事件來源。 ### 設定生產者的 AWS KMS 許可 當[資料金鑰重複使用期間](#sqs-how-does-the-data-key-reuse-period-work)到期時，生產者下次呼叫 `SendMessage` 或 `SendMessageBatch` 也會觸發呼叫 `kms:Decrypt` 和 `kms:GenerateDataKey`。呼叫 `kms:Decrypt` 是為了在使用新資料金鑰之前，先驗證其完整性。因此，生產者對於 KMS 金鑰必須擁有 `kms:Decrypt` 和 `kms:GenerateDataKey` 許可。 將下列陳述式新增至生產者的 IAM 政策。請記得對金鑰資源和佇列資源使用正確的 ARN 值。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-east-2:123456789012:key/111112222233333" }, { "Effect": "Allow", "Action": [ "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:123456789012:MyQueue" } ] } ``` ------ ### 設定取用者的 AWS KMS 許可 當資料金鑰重複使用期間到期時，消費者下一次呼叫 `ReceiveMessage` 也會觸發呼叫 `kms:Decrypt`，以在使用新資料金鑰之前，先驗證其完整性。因此，消費者對於用來加密指定佇列中訊息的 KMS 金鑰，必須擁有 `kms:Decrypt` 許可。如果佇列做為[無效字母佇列](sqs-dead-letter-queues.md)使用，則消費者對於用來加密來源佇列中訊息的 KMS 金鑰，還必須擁有 `kms:Decrypt` 許可。將下列陳述式新增至消費者的 IAM 政策。請記得對金鑰資源和佇列資源使用正確的 ARN 值。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-2:123456789012:key/111112222233333" }, { "Effect": "Allow", "Action": [ "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:*:123456789012:MyQueue" } ] } ``` ------ ### 使用混淆代理人保護設定 AWS KMS 許可 當金鑰政策陳述句中的主體為 [AWS 服務主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services)，則可使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 或 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 全域條件金鑰來防止[混淆代理人問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)。若要使用這些條件金鑰，請將值設定為要加密之資源的 Amazon Resource Name (ARN)。如果您不知道資源的 ARN，請改為使用 `aws:SourceAccount`。 在此 KMS 金鑰政策中，允許帳戶 `111122223333` 擁有的*服務*的特定資源為 `Decrypt` 和 `GenerateDataKey` 動作呼叫 KMS，這些都會在 SSE 使用 Amazon SQS 期間發生。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "sqs.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*", "Condition": { "ArnEquals": { "aws:SourceArn": [ "arn:aws:sqs:us-west-1:111122223333:resource" ] } } } ] } ``` ------ 使用啟用 SSE 的 Amazon SQS 佇列時，下列服務支援 `aws:SourceArn`： + Amazon SNS + Amazon S3 + CloudWatch Events + AWS Lambda + CodeBuild： + Amazon Connect Customer Profiles + AWS Auto Scaling + Amazon Chime ## 了解資料金鑰重複使用期間 [資料金鑰重複使用期間](sqs-server-side-encryption.md#sqs-sse-key-terms)定義 Amazon SQS 可重複使用相同資料金鑰的最長持續時間。當資料金鑰重複使用期間結束時，Amazon SQS 會產生新的資料金鑰。請注意下列有關重複使用期間的準則。 + 較短的重複使用期間可提供更好的安全性，但會導致更多呼叫 AWS KMS，這可能會產生超出 免費方案的費用。 + 雖然加密和解密的資料金鑰是分別快取，但重複使用期間同時套用到這兩個資料金鑰的副本。 + 當資料金鑰重複使用期間結束時，對 `SendMessage`的下一個呼叫或 `SendMessageBatch`通常會觸發對 方法的 AWS KMS `GenerateDataKey`呼叫，以取得新的資料金鑰。此外，下一個呼叫 `SendMessage`和 `ReceiveMessage`將觸發呼叫 AWS KMS `Decrypt`，以在使用前驗證資料金鑰的完整性。 + [委託人 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Principal)(AWS 帳戶 或使用者） 不會共用資料金鑰 （由唯一委託人傳送的訊息一律會取得唯一資料金鑰）。因此，對 的呼叫量 AWS KMS 是資料金鑰重複使用期間使用的唯一主體數量的倍數。 ## 估算 AWS KMS 成本 為了預測成本並更好地了解您的 AWS 帳單，您可能想知道 Amazon SQS 使用您的 KMS 金鑰的頻率。 **注意** 下列公式可以提供預期成本的良好概念，但由於 Amazon SQS 的分佈特性，實際成本可能會比較高。 若要計算`R`每個佇列*的 API 請求數量 (*)，請使用下列公式： ``` R = (B / D) * (2 * P + C) ``` `B` 是帳單週期 (以秒為單位)。 `D` 是[資料金鑰重複使用期間](sqs-server-side-encryption.md#sqs-sse-key-terms) (以秒為單位)。 `P` 是傳送至 Amazon SQS 佇列的生產[主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Principal)數目。 `C` 是從 Amazon SQS 佇列接收的消費主體數目。 **重要** 一般來說，生產主體會導致消耗主體的雙倍成本。如需詳細資訊，請參閱 [了解資料金鑰重複使用期間](#sqs-how-does-the-data-key-reuse-period-work)。 如果生產者和消費者有不同的 使用者，成本會增加。 以下為計算範例。如需確切的定價資訊，請參閱 [AWS Key Management Service 定價](https://aws.amazon.com/kms/pricing/)。 ### 範例 1：計算 2 個委託人和 1 個佇列的 AWS KMS API 呼叫數量 此範例假設如下： + 帳單週期是 1 月 1-31 日 (2,678,400 秒)。 + 資料金鑰重複使用期間設為 5 分鐘 (300 秒)。 + 有 1 個佇列。 + 有 1 個生產主體和 1 個消費主體。 ``` (2,678,400 / 300) * (2 * 1 + 1) = 26,784 ``` ### 範例 2：計算多個生產者和消費者以及 2 個佇列的 AWS KMS API 呼叫數量 此範例假設如下： + 帳單週期是 2 月 1-28 日 (2,419,200 秒)。 + 資料金鑰重複使用期間設為 24 小時 (86,400 秒)。 + 有 2 個佇列。 + 第 1 個佇列有 3 個生產主體和 1 個消費主體。 + 第 2 個佇列有 5 個生產主體和 2 個消費主體。 ``` (2,419,200 / 86,400 * (2 * 3 + 1)) + (2,419,200 / 86,400 * (2 * 5 + 2)) = 532 ``` ## AWS KMS 錯誤 當您使用 Amazon SQS 和 時 AWS KMS，您可能會遇到錯誤。下列參考說明錯誤和可能的疑難排解解決方案。 + [常見的 AWS KMS 錯誤](https://docs.aws.amazon.com/kms/latest/APIReference/CommonErrors.html) + [AWS KMS 解密錯誤](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html#API_Decrypt_Errors) + [AWS KMS GenerateDataKey 錯誤](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html#API_GenerateDataKey_Errors)