很高興能宣布推出 AWS Key Management Service (AWS KMS) 外部密鑰存儲。 有監管需求、於本地或 AWS 雲之外存儲和使用其加密密鑰的客戶現在有這項新選擇。 這項新功能允許您將 AWS KMS 客戶管理的密鑰儲存在本地或您選擇的任何位置運行的硬體安全模組 (HSM) 上。
在較高的級別中，AWS KMS 轉發 API 調用來向您的 HSM 安全通訊。 您的密鑰永遠不會離開您的 HSM。 該解決方案允許您使用外部密鑰為絕大多數支持 AWS KMS 客戶管理密鑰的 AWS 服務加密數據，例如 Amazon EBS、AWS Lambda、Amazon S3、Amazon DynamoDB 等超過 100 多種服務。 您現有 AWS 服務的配置參數或代碼無需做任何更改。
這有助於解除受管制工作負載的部分使用情境，在這些工作負載中，加密密鑰應在 AWS 數據中心之外存儲和使用。 但這對於您營運基於雲的基礎設施的方式有重大變化，責任共擔模式也是一個重大轉變。 我們預計只有一小部分客戶能夠啟用此功能。 在大多數情況下，受保護數據的可用性、性能和低延遲操作的額外操作負擔和更大風險將超過 AWS KMS 外部密鑰存儲的感知安全優勢。
接下來將深入了解細節。
立即聯繫 iKala Cloud， 獲取更多 AWS 新資訊
密鑰管理和加密的簡要回顧
當 AWS 服務配置為加密靜態數據時，該服務會從 AWS KMS 請求一個唯一的加密密鑰，我們稱之為數據加密密鑰。為了保護數據加密密鑰，該服務會請求 AWS KMS 使用特定的 KMS 客戶管理密鑰（又稱為根密鑰）加密該密鑰。加密後，數據密鑰可以與其保護的數據一起安全儲存，這種模式稱為信封加密。你可以想像就是一個包含加密數據和用於加密這些數據的加密密鑰的信封。
但是我們如何保護根密鑰呢？ 保護根密鑰是不可或缺的環節，因為它可以解密已經加密的所有數據密鑰。
根密鑰材料被安全地生成並儲存在硬體安全模組中，這是一種用於儲存秘密的硬體。它可以防篡改，其設計使密鑰材料不會以純文本形式離開安全硬體。AWS KMS 使用透過 NIST 140-2 加密模組認證計劃所認證的 HSM。
您可以選擇創建與數據分類綁定的根密鑰，或者創建唯一的根密鑰來保護不同的 AWS 服務，或者通過項目標籤，或者關聯到每個數據所有者，並且每個根密鑰對於每個 AWS 區域都是唯一的。
AWS KMS 將根密鑰稱為客戶管理的密鑰。 當它們代表加密數據的 AWS 服務創建時，它們被稱為 AWS 託管密鑰，例如 Amazon Elastic Block Store (Amazon EBS)、Amazon Simple Storage Service (Amazon S3)、Amazon Relational Database Service (RDS) 或 Amazon 發電機。 為簡單起見，我們稱它們為 KMS 密鑰。 這些是根密鑰，它們永遠不會離開安全的 HSM 環境。 所有 KMS 加密和解密操作都發生在 HSM 的安全環境中。
XKS 代理解決方案
配置 AWS KMS 外部密鑰庫 (XKS) 時，您將使用新的外部信任根替換 KMS 密鑰層次結構。根密鑰現在全部生成並儲存在您提供和操作的 HSM 中。當 AWS KMS 需要加密或解密數據密鑰時，它會將請求轉發給供應商特定的 HSM。
與外部 HSM 的所有 AWS KMS 交互均由外部密鑰存儲代理（XKS 代理）進行調解，該代理由您提供並由您管理。該代理將通用 AWS KMS 請求轉換為供應商的 HSM 可以理解的格式。
XKS 與之通信的 HSM 不位於 AWS 數據中心。
為了向客戶提供更廣泛的外部密鑰管理器選項，AWS KMS 根據多家 HSM、密鑰管理和集成服務供應商（包括 Atos、Entrust、Fortanix、HashiCorp、Salesforce、Thales 和 T-Systems）的反饋開發了 XKS 規範。有關可用性、定價以及如何將 XKS 與這些供應商的解決方案一起使用的訊息，請直接諮詢供應商。
此外，我們將提供 XKS 代理的參考實現，可用於 SoftHSM 或支持 PKCS #11 接口的任何 HSM。 這個參考實現 XKS 代理可以作為容器運行，是用 Rust 構建的，並將在未來幾週內透過 GitHub 提供。
完成 XKS 代理和 HSM 的設置後，您可以在 KMS 中創建對應的外部密鑰庫資源。 您在 HSM 中創建密鑰並將這些密鑰映射到 KMS 中的外部密鑰存儲資源。 接著，您可以將這些密鑰與支持客戶密鑰的 AWS 服務或您自己的應用程序結合使用來加密您的數據。
從 AWS KMS 到 XKS 代理的每個請求都包含元數據，例如調用 KMS API 的 AWS 委託人和 KMS 密鑰 ARN。這允許您在 XKS 代理級別創建額外的授權控制層，超出您的 AWS 帳戶中 已經提供的IAM策略。
XKS 代理實際上是您控制的緊急停止開關。當您關閉 XKS 代理時，所有使用 XKS 密鑰的新加密和解密操作都將停止運行。已經為您的其中一項資源將數據密鑰預置到內存中的 AWS 服務將繼續工作，直到您停用該資源或服務密鑰緩存過期。例如，Amazon S3 在啟用儲存貯體金鑰時會緩存數據密鑰幾分鐘。
共享責任的轉變
根據標準的雲操作程序，AWS 負責維護雲基礎設施的運行狀態。這包括但不限於修補系統、監控網絡、設計高可用性系統等。
當您選擇使用 XKS 時，共享責任模型就會發生根本性轉變。在此模型下，您負責維護 XKS 代理和您的 HSM 的運行狀態。它們不僅必須是安全的且高度可用，而且還要調整大小以維持預期數量的 AWS KMS 請求。這適用於所有涉及的組件：物理設施、電源、冷卻系統、網路、服務器、操作系統等。
根據您的工作負載量，AWS KMS 操作對於需要雲端中加密資料的服務是至關重要的。依賴 AWS KMS 正常運行的典型服務包括 Amazon Elastic Block Store (Amazon EBS)、Lambda、Amazon S3、Amazon RDS、DynamoDB 等。換句話說，這意味著當您負責的基礎設施部分不可用或具有高延遲（通常超過 250 毫秒）時，AWS KMS 將無法運行，將故障級聯到您向其他 AWS 發出的請求服務。您將無法啟動 EC2 實例、調用 Lambda 函數、從 S3 存儲或檢索對象、連接到您的 RDS 或 DynamoDB 數據庫，或依賴存儲在您管理的基礎設施中的 AWS KMS XKS 密鑰的任何其他服務。
就像參與 XKS 的一位產品經理在準備這篇文章時告訴我的，“你正在用自己的氧氣隧道通過一條非常脆弱的路徑”。
如果您有監管或合規性需求，要求您在 AWS 數據中心之外維護加密密鑰，我們建議您使用此功能。僅為支持最關鍵工作負載的根密鑰啟用 XKS。並非所有數據類別都需要根密鑰的外部存儲。將受 XKS 保護的數據集保持在最低限度以滿足您的監管要求，並繼續使用 AWS KMS 客戶管理的密鑰（在您的控制之下）來處理剩餘部分。
一些不是合規性要求的外部密鑰存儲客戶過去也曾要求過這項功能，但當他們意識到類似 XKS 的解決方案所帶來的安全優勢並沒有超過運營成本之後，他們就選擇了基於雲的密鑰存儲和使用現有的 AWS KMS 選項之一。
什麼改變了，又有什麼保持不變？
我來為您總結這些變化。
|
與標準 AWS KMS 密鑰相同的內容 |
發生的變化 |
| 受支持的 AWS KMS API 和密鑰標識符 (ARN) 是相同的。支持客戶託管密鑰的 AWS 服務將與 XKS 一起使用。
AWS 端的保護存取權和監控存取權的方式沒有改變。XKS 使用相同的 IAM 策略和相同的密鑰策略。API 調用記錄在 AWS CloudTrail 中，而 AWS CloudWatch 具有使用指標。
價格與其他 AWS KMS 密鑰和 API 操作相同。 |
價格與其他 AWS KMS 密鑰和 API 操作相同。
您現在擁有了對加密密鑰操作的可用性、持久性、性能和延遲邊界的關注。
您可以在 XKS 代理級別實現另一層授權、審計和監控。XKS 會留在您的網路中。
雖然 KMS 價格保持不變，但您購買 HSM 和維護 XKS 相關基礎架構方面的運行狀況的費用可能會大幅增加。 |
開放規範
對於那些受到嚴格監管的工作負載，我們正在開發 XKS 作為開放互操作性規範。我們不僅與過去提到的主要供應商合作，還打開了一個包含以下材料的 GitHub 儲存庫：
- XKS 代理 API 規範。 這描述了 KMS 發送到 XKS 代理的一般請求的格式及其期望的響應。 任何 HSM 供應商都可以使用該規範為其 HSM 創建 XKS 代理。
- 實現規範的 XKS 代理的參考實現。 HSM 供應商可以修改此代碼來為其 HSM 創建代理。
- 一個 XKS 代理測試客戶端，可用於檢查 XKS 代理是否符合 XKS 代理 API 規範的要求。
其他供應商（例如 SalesForce）宣布了他們自己的 XKS 解決方案，允許他們的客戶選擇自己的密鑰管理方法並將其插入他們選擇的解決方案（包含 SalesForce）。
定價和可用性
外部密鑰存儲在 AWS KMS 之上免費提供。AWS KMS 每個根密鑰每月收費 1 美元，無論密鑰材料存儲在 KMS 上、CloudHSM 上還是您自己的本地 HSM 上。
有關 AWS KMS XKS 當前可用的區域的完整列表，請參考我們的技術文檔。
如果您認為 XKS 將幫助您滿足監管要求，請查看技術文檔和 XKS 常見問題解答。
— seb
