AWS Key Management Service 常見問答集

AWS KMS 會強制執行您定義的使用和管理政策。您可以選擇允許您的帳戶或其他帳戶的 IAM 使用者及角色使用和管理您的金鑰。

AWS KMS 的設計可確保沒有任何人 (包含 AWS 員工) 可從服務擷取您的純文字 KMS 金鑰。AWS KMS 採用已通過 FIPS 140-2 驗證或正在驗證中的硬體安全模組 (HSM)，來保護金鑰的機密性和完整性。純文字 KMS 金鑰永遠不會離開 HSM，也永遠不會寫入磁碟，只在需要執行請求的加密操作時，才會在 HSM 的揮發性記憶體中使用。服務主機軟體和 AWS KMS HSM 韌體的更新由多方存取控制進行控管，該存取控制是由 Amazon 內部獨立的小組以及符合 FIPS 140-2 標準的 NIST 認證實驗室進行稽核和審查。

如需有關這些安全控制措施的更多詳細資訊，請查看 AWS KMS 加密詳細資訊技術白皮書。您也可以檢閱適用於 AWS KMS HSM 的 FIPS 140-2 憑證和相關的安全政策，以取得 AWS KMS HSM 如何符合 FIPS 140-2 安全要求的詳細資訊。此外，您可以從 AWS Artifact 下載系統和服務機構控管 (SOC) 報告副本，以進一步了解服務用來保護 KMS 金鑰的安全控制措施。

您無需做任何事情。所有 AWS KMS key 無論其建立日期或來源為何，都會自動使用經過 FIPS 140-2 安全層級 3 驗證的 HSM 加以保護。

經過 FIPS 140-2 安全層級 3 驗證的 HSM 會部署在提供 AWS KMS 的所有 AWS 區域中。
備註：根據法規，中國區域的 AWS KMS 無法使用 NIST FIPS HSM，而是使用中國國家商業加密管理局辦公室 (OSCCA) 認證的 HSM。

AWS KMS 是雙層服務。API 端點使用僅支援完美遠期保密的 TLS 加密技術，經由 HTTPS 連線接收用戶端請求。這些 API 端點會先驗證和授權請求，然後將該請求傳送到 AWS KMS HSM 進行加密操作；如果您正在使用 KMS 自訂金鑰存放區功能，則傳送到您的 AWS CloudHSM 叢集。

將您的應用程式設定為連接唯一的區域 FIPS 140-2 驗證 HTTPS 端點。AWS KMS FIPS 140-2 驗證 HTTPS 端點採用 OpenSSL FIPS Object Module 技術。您可以在這裡檢閱 OpenSSL 模組的安全政策。所有提供 AWS KMS 的商業區域都能使用 FIPS 140-2 驗證的 API 端點。

是。AWS KMS 已經過驗證，擁有可協助您符合 PCI DSS 3.2.1 加密和金鑰管理要求 (主要參考第 3.5 和 3.6 節) 的功能和安全控制措施。

有關 AWS 中 PCI DSS 合規服務的更多詳細資訊，可以閱讀 PCI DSS 常見問答集。

您可以請求 AWS KMS 產生資料金鑰，並將其傳回給您自己的應用程式使用。資料金鑰根據您在 AWS KMS 中定義的根金鑰加密，因此您可以安全地存放加密的資料金鑰與加密資料。加密的資料金鑰 (以及來源資料) 如要解密，只能由有權使用原始根金鑰將已加密資料金鑰解密的使用者執行。

否。您只能在服務中建立和使用 AWS KMS key，以協助確認其安全、一致地實施政策，並提供集中化的金鑰使用日誌。

AWS KMS 產生的單區域 KMS 金鑰僅在建立它的區域中存放和使用。使用 AWS KMS 多區域金鑰，您可以選擇將多區域主金鑰複製到同一 AWS 分區內的多個區域。

AWS CloudTrail 中的日誌會顯示所有 AWS KMS API 請求，包括管理請求 (例如，建立、輪換、停用、政策編輯) 和加密請求 (例如，加密/解密)。在您的帳戶中開啟 CloudTrail 可查看這些日誌。

CloudHSM 在 Amazon Virtual Private Cloud (VPC) 提供經驗證的單一租用戶 HSM 叢集，以存放和使用您的金鑰。您可以透過 AWS 以外的獨立身份驗證機制，獲得金鑰使用方法的專屬控制。AWS CloudHSM 叢集中的金鑰互動方式與 Amazon EC2 中執行的應用程式互動方式類似。您可以使用 AWS CloudHSM 支援各種使用案例，像是數位版權管理 (DRM)、公開金鑰基礎設施 (PKI)、文件簽署，以及使用 PKCS#11、Java JCE 或 Microsoft CNG 界面的加密功能。
 

AWS KMS 可協助您透過單一主控台來建立及控制加密金鑰，以用於您的應用程式和全球多個區域支援的 AWS 服務。該服務使用經過 FIPS 140-2 驗證或正在進行驗證的 FIPS HSM 來保護金鑰的安全。在 AWS KMS 集中管理所有金鑰能協助您強制管理哪些人可以在哪些條件下使用金鑰、金鑰輪換的時間，以及可管理金鑰的人員。AWS KMS 與 AWS CloudTrail 整合，可提供您稽核金鑰使用方式的功能，以支援您的監管和合規活動。如果想要直接呼叫服務 API，可使用 AWS 開發套件從應用程式與 AWS KMS 互動；如果想執行用戶端加密，則透過與 AWS KMS 整合的其他 AWS 服務或使用 AWS Encryption SDK。

使用 AWS KMS，您僅需按用量付費，而且沒有最低費用。開始使用服務時，沒有安裝費，使用者無須對服務的使用簽訂任何長期使用期限合約。每個月底將自動向您的信用卡收取當月使用費。

您需支付建立的所有 KMS 金鑰的費用，也需支付每個月超過免費方案之後對服務所進行的 API 請求的費用。
 

要了解目前的定價資訊，請參閱 AWS KMS 定價頁面。

是。使用 AWS 免費方案，您可以在所有區域免費*開始使用 AWS KMS。AWS 服務代您建立的 AWS 受管 AWS KMS key 可隨意存放在您的帳戶中。還有用量免費方案，每月提供免費的服務請求數量。要了解目前的定價資訊，包括免費方案，請瀏覽 AWS KMS 定價頁面。

*與非對稱 KMS 金鑰有關的 API 請求，和對 GenerateDataKeyPair 和 GenerateDataKeyPairWithoutPlaintext API 的請求，都排除在免費方案之外。

除非另有說明，否則我們的價格不包括適用的稅金和稅收 (包括加值稅和適用的營業稅)。帳單地址在日本的客戶若使用 AWS 服務，則需負擔日本消費稅。您可以在這裡進一步了解更多資訊。

是。您可以將自己金鑰管理基礎設施中的金鑰匯入 AWS KMS，並將它與任何整合的 AWS 服務搭配使用或在自己的應用程式內使用。

您可以使用匯入的金鑰對 AWS KMS 中金鑰的建立、生命週期管理和耐久性做更好的控制。匯入的金鑰旨在協助您達到合規要求，包含有能力產生金鑰或在基礎設施中維護一份安全金鑰，以及有能力從 AWS 基礎設施立即刪除匯入的金鑰。

您可以匯入對稱金鑰、非對稱金鑰 (RSA 和橢圓曲線) 和 HMAC 金鑰。

在匯入過程中，必須使用受支援的包裝演算法，以 AWS KMS 提供的公開金鑰包裝您的金鑰。這可確認加密的金鑰只能由 AWS KMS 解密。

有兩個主要的不同之處：
 

1. 您要負責在金鑰管理基礎設施中維護一份匯入的金鑰，如此才能隨時重新匯入它們。不過，AWS 可代您確認 AWS KMS 產生之金鑰的可用性、安全性和耐用性，直到排定刪除金鑰為止。
2. 您可以設定匯入金鑰的過期期間。AWS KMS 會在過期期間後自動刪除金鑰材料。您也可以根據需要刪除匯入的金鑰材料。在這兩種情況下，金鑰材料本身會被刪除，但 AWS KMS 中的 KMS 金鑰參考和相關中繼資料會予以保留，以便將來可以重新匯入金鑰材料。AWS KMS 產生的金鑰沒有過期時間，也無法立即刪除；會有 7 至 30 天的強制等待期間。無論是否匯入金鑰材料，所有客戶受管 KMS 金鑰都可以手動停用或安排刪除。在這種情況下，KMS 金鑰本身會被刪除，而不僅僅是相關的金鑰材料。

將具備有效過期期間的金鑰材料複本重新匯入原始 AWS KMS key 下的 AWS KMS，即可開始使用。

是。將金鑰匯入 AWS KMS key 之後，您將會每幾分鐘收到一個 Amazon CloudWatch 指標，該指標會倒數計時匯入金鑰的過期時間。AWS KMS key 下的匯入金鑰過期時，您還會收到 Amazon CloudWatch 事件。您可以建置在這些指標或事件上作用的邏輯，然後自動重新匯入具有新過期期間的金鑰，以避免出現可用性風險。

在建立用於加密和解密的 KMS 金鑰時，AWS KMS 支援 256 位元金鑰。傳回給呼叫者的產生資料金鑰可以是 256 位元、128 位元或最高到 1024 位元組的任意值。AWS KMS 代表您使用 256 位元的 KMS 金鑰加密和解密時，將使用 Galois Counter Mode (AES-GCM) 中的 AES 演算法。

AWS KMS 支援下列類型的非對稱金鑰︰RSA 2048、RSA 3072、RSA 4096、ECC NIST P-256、ECC NIST P-384、ECC NIST-521 和 ECC SECG P-256k1。 AWS KMS 支援使用 RSA 2048、RSA 3072 和 RSA 4096 金鑰類型的 RSAES_OAEP_SHA_1 和 RSAES_OAEP_SHA_256 加密演算法。加密演算法不可搭配橢圓曲線的金鑰類型 (ECC NIST P-256、ECC NIST P-384、ECC NIST-521 和 ECC SECG P-256k1) 使用。

使用橢圓曲線金鑰類型時，AWS KMS 支援 ECDH 關鍵協議演算法。

使用 RSA 金鑰類型時，AWS KMS 支援 RSASSA_PSS_SHA_256、RSASSA_PSS_SHA_384、RSASSA_PSS_SHA_512、RSASSA_PKCS1_V1_5_SHA_256、RSASSA_PKCS1_V1_5_SHA_384 和 RSASSA_PKCS1_V1_5_SHA_512 的簽署演算法。使用橢圓曲線金鑰類型時，AWS KMS 支援 ECDSA_SHA_256、ECDSA_SHA_384 和 ECDSA_SHA_512 的簽署演算法。

非對稱金鑰材料的公開部分是在 AWS KMS 中產生，其可透過呼叫「Verify」API 來驗證數位簽章，或透過呼叫「Encrypt」API 來加密公開金鑰。公開金鑰也可在 AWS KMS 之外用於驗證或加密。您可呼叫 GetPublicKey API 來擷取非對稱 KMS 金鑰的公開部分。

大小上限為 4 KB。如果想數位簽署超過 4 KB 的資料，可選擇建立資料的訊息摘要，然後傳送至 AWS KMS。數位簽章將建立在資料摘要上，然後傳回。您可在 Sign API 要求中以屬性指定要傳送完整訊息或訊息摘要。提交至需要使用非對稱操作的 Encrypt、Decrypt 或 Re-Encrypt API 的任何資料也必須小於 4 KB。

主控台中的每個金鑰都會有一個「金鑰類型」的新欄位。其值為「非對稱金鑰」或「對稱金鑰」，用於表示金鑰的類型。「DescribeKey」API 將傳回「KeyUsage」欄位，用於指定金鑰將用於簽署、產生 HMAC 或加密。

否。不支援非對稱或 HMAC KMS 金鑰的自動金鑰輪換。一般而言，輪替非對稱金鑰或 HMAC 金鑰可能會對現有工作負載造成極大的損毀，因為您必須淘汰並取代過去與其他方共用的所有金鑰執行個體。如有必要，您可建立新的 KMS 金鑰，然後將現有金鑰別名從舊 KMS 金鑰映射至新 KMS 金鑰，便能手動輪換它們。

否。建立 KMS 金鑰時，您必須指定該金鑰將用於解密或簽署操作。RSA 金鑰類型可用於簽署或加密其中一項操作，但無法同時用於兩者。橢圓曲線金鑰類型只能用於簽署操作。

是。不同的金鑰類型和演算法，其每秒請求數速率限制也不相同。請參閱 AWS KMS 限制頁面以取得詳細資訊。

否。您無法將自訂金鑰存放區功能用在非對稱金鑰。

不能直接使用。AWS KMS 不會存放或將數位憑證與其建立的非對稱 KMS 金鑰建立關聯。您可選擇由 AWS 私有憑證認證機構之類的憑證認證機構為您非對稱 KMS 金鑰中的公開部分核發憑證。如此一來，使用您的公開金鑰的實體便能確定該公開金鑰確實為您所有。

AWS KMS 自訂金鑰存放區會將 CloudHSM 提供的控制功能與 AWS KMS 的整合性和易用性相結合。您可以設定自己的 CloudHSM 叢集，並授權 AWS KMS 將其當作專用金鑰存放區，而不是預設的 AWS KMS key 存放區。在 AWS KMS 中建立金鑰時，您可以選擇在 CloudHSM 叢集產生金鑰材料。在自訂金鑰存放區產生的 KMS 金鑰永遠不會將 HSM 以純文字格式保留在 CloudHSM 叢集，而且使用這些金鑰的所有 AWS KMS 操作只會在您的 HSM 中執行。在所有其他方面，存放在自訂金鑰存放區的 KMS 金鑰會與其他 AWS KMS key 一致。

如果無法決定自己是否適合使用自訂金鑰存放區，可以在這篇部落格找到額外的指導。

由於您控制 AWS CloudHSM 叢集，因此可以選擇管理 KMS 金鑰的生命週期，與 AWS KMS 無關。有三個原因可能會讓您發覺自訂金鑰存放區的實用性。第一個原因，可能明確規定您的金鑰必須放在單租戶 HSM 中保護，或者放在您可以直接控制的 HSM 中。第二個原因，您可能需要能立即從 AWS KMS 移除金鑰材料，並證明您已透過獨立方法完成此操作。第三個原因，您可能需要能夠稽核所有金鑰的使用，而且與 AWS KMS 或 AWS CloudTrail 無關。

相較於預設 AWS KMS key 存放區，在 CloudHSM 提供支援的自訂金鑰存放區管理金鑰有兩個不同之處。您無法將金鑰材料匯入自訂金鑰存放區，也無法讓 AWS KMS 自動輪換金鑰。在所有其他方面，包括可以產生的金鑰類型、金鑰使用別名的方式以及如何定義政策，存放在自訂金鑰存放區中的金鑰其管理方式與任何其他 AWS KMS 客戶受管 KMS 金鑰相同。

否，只有客戶受管 KMS 金鑰可以在 CloudHSM 提供支援的 AWS KMS 自訂金鑰存放區中存放和管理。為了加密資料而由其他 AWS 服務代表您建立的 AWS 受管 KMS 金鑰，一律會在 AWS KMS 預設金鑰存放區中產生和存放。

否，API 請求 AWS KMS 使用 KMS 金鑰加密和解密資料時，處理的方式是一樣的。身份驗證和授權過程與金鑰存放的位置無關。使用 CloudHSM 提供支援的自訂金鑰存放區中的金鑰進行的所有活動，也會以相同的方式記錄到 AWS CloudTrail。不過，實際的加密操作僅在自訂金鑰存放區或預設 AWS KMS key 存放區中進行。

除了 AWS KMS 記錄到 AWS CloudTrail 的活動之外，使用自訂金鑰存放區還提供三種稽核機制。第一種機制，CloudHSM 也將所有 API 活動記錄到 CloudTrail，例如建立叢集以及新增或刪除 HSM。第二種機制，每個叢集也會擷取自己的本機日誌，以記錄使用者和金鑰管理活動。第三種機制，每個 CloudHSM 執行個體會將本機使用者和金鑰管理活動日誌複製到 AWS CloudWatch。

使用 AWS KMS 自訂金鑰存放區時，可協助您確認 AWS KMS 一定可以使用您的金鑰。CloudHSM 的組態錯誤以及 AWS CloudHSM 叢集中的金鑰材料意外刪除，可能會影響可用性。您使用的 HSM 數量以及選擇的可用區域 (AZ)，也會影響叢集的恢復能力。與任何金鑰管理系統一樣，了解金鑰的可用性如何影響加密資料的恢復非常重要。

存放在 CloudHSM 提供支援的 AWS KMS 自訂金鑰存放區中的金鑰，當透過 AWS KMS API 呼叫使用時，速度低於存放在預設 AWS KMS key 存放區中的金鑰。有關目前的效能限制，請參閱 AWS KMS 開發人員指南。

AWS KMS 價格不受使用自訂金鑰存放區的影響。然而，每一個自訂金鑰存放區會要求您的 AWS CloudHSM 叢集至少包含兩個 HSM。這些 HSM 是按照標準 AWS CloudHSM 價格收費。使用自訂金鑰存放區不收取額外費用。

希望使用自訂金鑰存放區的 AWS KMS 使用者需要設定 AWS CloudHSM 叢集、新增 HSM、管理 HSM 使用者以及從備份還原 HSM。這些是對安全性要求很高的任務，您可確認資源和組織控制已經準備到位。

否，不支援將您自己的金鑰材料匯入 AWS KMS 自訂金鑰存放區。存放在自訂金鑰存放區中的金鑰只能在構成 CloudHSM 叢集的 HSM 中產生。

否，目前不支援在不同類型的 AWS KMS key 存放區之間移轉金鑰。所有金鑰的建立和使用都必須在同一個金鑰存放區中，但如果是將自己的金鑰材料匯入預設 AWS KMS key 存放區則除外。

不支援自動輪換 AWS KMS 自訂金鑰存放區中的金鑰材料。金鑰輪換必須手動執行，方法是建立新的金鑰並重新對應您的應用程式程式碼使用的 AWS KMS key 別名，以便將新的金鑰用於將來的加密操作。

是，AWS KMS 不會要求專屬的 AWS CloudHSM 叢集存取權。如果您已經有叢集，可以將它當作自訂金鑰存放區，並繼續用於其他應用程式。但是，如果您的叢集支援較高的非 AWS KMS 工作負載，則使用自訂金鑰存放區中的 KMS 金鑰時，可能會遇到操作輸送量降低的情況。同樣地，自訂金鑰存放區的高 AWS KMS 請求率可能會影響您的其他應用程式。

瀏覽 AWS CloudHSM 網站以取得服務概觀，如需設定和使用服務的更多詳細資訊，請閱讀 AWS CloudHSM 使用者指南。

外部金鑰存放區是您在 AWS 之外擁有和管理的外部金鑰管理基礎設施所支援的自訂金鑰存放區。在外部金鑰存放區中使用 KMS 金鑰的所有加密或解密操作，都會在您的金鑰管理器中透過加密金鑰和操作來執行，這些金鑰和操作在您的控制之下，並且 AWS 無法在實體上進行存取。

XKS 可協助您遵守相關的規則或法規，要求在您的控制之下，並在 AWS 之外存放和使用加密金鑰。

從代表您運作的整合式 AWS 服務或您自己的應用程式向 AWS KMS 發出的請求，將轉傳至您的網路中稱為 XKS Proxy 的元件。XKS Proxy 是一種開放原始碼 API 規範，可協助您和您的金鑰管理供應商建置相關服務，來接受這些請求並將其轉傳至您的金鑰管理基礎設施，以使用其金鑰進行加密和解密。

Thales、Entrust、Atos、Fortanix、DuoKey、Securonix、Utimaco、Salesforce、T-Systems 和 HashiCorp 都有與 XKS Proxy 規範整合的解決方案。如需可用性、定價以及如何使用這些供應商解決方案的資訊，請參閱其各自的文件。我們鼓勵您和您的金鑰管理基礎架構合作夥伴善用開放原始碼 XKS Proxy 規範，來建置滿足您需求的解決方案。XKS Proxy 的 API 規範發布於此處。

外部金鑰支援以下對稱加密操作：Encrypt、ReEncrypt、Decrypt 和 GenerateDataKey。

您可以使用 XKS 金鑰，加密任何使用客戶受管金鑰與 AWS KMS 整合的 AWS 服務中的資料。請在這裡查看支援的服務清單。AWS 服務呼叫 AWS KMS GenerateDataKey API，來請求不重複的純文字資料金鑰以加密您的資料。純文字資料金鑰，連同要與加密資料一起存放的資料金鑰的加密副本傳回至該服務。若要產生資料金鑰的加密副本，純文字資料金鑰首先由存放在 AWS KMS 中的金鑰加密，該金鑰在您的 AWS 帳戶中不重複。然後將此加密資料金鑰轉傳至連線至外部金鑰管理器的 XKS Proxy 實作，以根據您在外部金鑰管理器中定義的金鑰進行第二次加密。產生的雙重加密資料金鑰在 GenerateDataKey API 請求的回應中傳回。

AWS KMS、您的 XKS Proxy 實作，以及外部金鑰管理器之間的網路連線應使用 TLS 等點對點加密協協定進行保護。但是，為了保護您的資料在到達外部金鑰管理器之前離開 AWS KMS，AWS KMS 首先使用您帳戶中的內部管理 KMS 金鑰對其進行加密，該金鑰特定於您的外部金鑰存放區中定義的每個 KMS 金鑰。產生的密文被轉傳至外部金鑰管理器，該管理器使用外部金鑰管理器中的金鑰對其進行加密。雙重加密提供安全控制，即在不使用外部金鑰管理器中金鑰材料的情況下，任何密文都無法解密。它還提供安全控制，即使用 FIPS 140 認證的 AWS KMS HSM 對離開 AWS 網路的密文進行加密。因為您的外部金鑰管理器必須用於解密資料，所以如果您撤銷對 AWS KMS 的存取權，則您的底層加密資料將變得不可存取。

是。當使用將 AWS KMS 用作其金鑰提供者的用戶端對稱加密解決方案時，也可以在您自己的應用程式中使用 XKS 金鑰。AWS 開放原始碼用戶端加密解決方案，如 AWS Encryption SDK、S3 加密用戶端和 DynamoDB 加密用戶端支援 XKS 金鑰。

所有 XKS 金鑰都必須在 KMS 中作為新金鑰建立。無法將現有 KMS 金鑰遷移至外部金鑰管理器中託管的 XKS 金鑰。

您可以在新產生的 XKS 金鑰下重新加密現有資料，前提是 AWS 服務或您自己的應用程式支援該操作。許多 AWS 服務將協助您複製加密資源，並指定一個新的 KMS 金鑰用於加密副本。您可以在 AWS 服務提供的 COPY 命令中設定 XKS 金鑰。您可以呼叫 KMS ReEncrypt API 並設定 XKS 金鑰，藉此對您自己的應用程式中的用戶端加密資料進行重新加密。

與所有客戶受管金鑰一樣，XKS 金鑰在被刪除之前的價格為每個金鑰每月 1 USD。XKS 金鑰下的請求按照與任何其他 AWS KMS 對稱金鑰相同的費率收費。請在 AWS KMS 定價頁面，進一步了解有關定價的資訊。

是。XKS 規格支援自動金鑰輪換，這是大多數支援 XKS 的廠商提供的功能。XKS 金鑰的自動輪換完全發生在外部金鑰管理器中，並與在 KMS 中建立和管理的 AWS KMS key 的自動金鑰輪換方式類似。當您使用輪換的 KMS XKS 金鑰加密資料時，外部金鑰管理器會使用目前的金鑰資料。當您使用輪換的 XKS 金鑰來解密加密文字時，您的外部金鑰管理器會透過用於對其加密的金鑰資料版本。只要之前用於建立早期密文的 XKS 金鑰在外部金鑰管理器中仍然啟用，您就能在這些版本的 XKS 金鑰下成功發出 Decrypt API 請求。

針對不快取金鑰的服務，使用此 XKS KMS 金鑰的下一個 API 呼叫將會失敗。一些服務針對效能、延遲或 KMS 成本管理，實作資料金鑰快取或其他金鑰衍生方案。這些金鑰的快取時間從 5 分鐘到 24 小時不等。目前正在使用的任何受保護資源 (例如 RDS 資料庫或 EC2 執行個體)，在您拒絕存取該金鑰後都會有不同的回應。如需詳細資訊，請參閱相關的 AWS 服務文件。

為了對您的外部金鑰存放區代理進行身分驗證，AWS KMS 使用您在代理上設定並提供給 KMS 的 AWS SigV4 憑證，來簽署對代理的所有請求。AWS KMS 使用伺服器端 TLS 憑證，對您的外部金鑰存放區代理進行身分驗證。或者，您的代理可啟用雙向 TLS，以進一步確保其只接受來自 AWS KMS 的請求。

您使用其他 KMS 金鑰的所有常用 AWS KMS 授權機制 (IAM 政策、AWS KMS key 政策、授權)，與外部金鑰存放區中 KMS 金鑰的工作方式相同。

此外，您及/或您的外部金鑰管理器合作夥伴能夠根據從 AWS KMS 傳送至 XKS Proxy 的每個請求中包含的請求中繼資料，實作第二層授權控制。此中繼資料包括呼叫 AWS 使用者/角色、KMS 金鑰 ARN 和請求的特定 KMS API。這允許您在外部金鑰管理器中對金鑰的使用套用精細的授權政策，而不僅僅是信任來自 AWS KMS 的任何請求。使用這些請求屬性的政策實施選項留給您的個別 XKS Proxy 實作。

涉及 XKS 金鑰的每個到達 AWS KMS 的請求，其產生的不重複 ID 也會轉傳至 XKS Proxy。您可以使用 XKS Proxy 或外部金鑰管理器的日誌資料 (如可用)，來協調對 AWS KMS 的請求與對外部金鑰管理器的請求。此功能允許您驗證在外部金鑰管理器中使用金鑰的所有請求，是否源自您直接或透過整合式 AWS 服務向 AWS KMS 發起的呼叫。

可用性風險：您負責 XKS Proxy 和外部金鑰材料的可用性。該系統必須具有高可用性，以驗證無論何時您需要 XKS 金鑰來解密加密資源或加密新資料，AWS KMS 都可以成功連線至 XKS Proxy，而 XKS Proxy 本身可以連線至您的外部金鑰管理器，以使用金鑰完成必要的加密操作。例如，假設您使用 XKS 金鑰加密 EBS 磁碟區，現在您想要啟動 EC2 執行個體並連接該加密磁碟區。EC2 服務將該磁碟區的不重複加密資料金鑰傳遞給 AWS KMS 以對其進行解密，以便在 Nitro 卡的易失性記憶體中進行佈建，進而解密和加密對該磁碟區的讀/寫操作。如果您的 XKS Proxy 或外部金鑰管理器不可用於解密磁碟區金鑰，您的 EC2 執行個體將無法啟動。在這些類型的故障中，AWS KMS 傳回 KMSInvalidStateException，說明 XKS Proxy 不可用。現在由您根據 KMS 提供的錯誤訊息，來確定 XKS Proxy 和金鑰管理器不可用的原因。

持久性風險：由於金鑰在 AWS 之外的系統中由您控制，因此您對您建立的所有外部金鑰的持久性負全部責任。如果 XKS 金鑰的外部金鑰永久遺失或刪除，則所有在 XKS 金鑰下加密的密文都不可復原。

效能風險：您有責任驗證您的 XKS Proxy 和外部金鑰存放區基礎設施，是否設計有足夠的效能特徵來滿足您的需求。由於使用 XKS 金鑰的每個請求都需要連線至您的外部金鑰存放區，如果來自 AWS KMS 的請求速率超過您的 XKS Proxy 或外部金鑰管理器可支援的請求速率，則您的 XKS Proxy 可能會成為瓶頸。此外，如果從 AWS KMS 到您的 XKS Proxy 的單一請求 (包括一次重試) 所用時間超過 500 毫秒*，AWS KMS 將向其呼叫用戶端傳回 400 錯誤，有效地傳達您的 XKS 金鑰不可用以及呼叫用戶端不得重試。此行為旨在最大限度地降低上游 AWS 服務，或您自己的應用程式必須對基礎設施連線問題導致的偶發性過度延遲做出回應的風險。

*AWS KMS 將嘗試對任何耗時 250 毫秒的請求進行單一重試。如果重試請求也耗時超過 250ms，將向呼叫用戶端傳回 400 錯誤。

由於 AWS 無法控制 AWS KMS 與您的外部金鑰存放區基礎設施之間連線的端對端可用性，因此我們明確排除在公有 KMS 可用性 SLA 中使用 XKS。此外，XKS 金鑰在任何 AWS 服務的可用性 SLA 中排除，在這些服務中，您將設定 XKS 金鑰以加密服務中的資料。