AWS KMS：我需要多少個金鑰？

隨著組織持續進行雲端之旅，雲端中的資料安全成為首要任務。不論是保護客戶資訊、智慧財產，還是符合法規要求的資料，加密都是基本的安全控制措施。這就是 AWS 金鑰管理服務 (AWS KMS) 的用武之地，提供 AWS 上加密金鑰管理的強大基礎。

客戶經常會首先問到的問題之一是：「我實際上需要多少金鑰？」這個看似簡單的問題需要仔細考慮多種因素。雖然 AWS KMS 讓加密變得簡單，但組織需要考慮其金鑰管理策略的幾個方面。這些包括選擇 AWS 管理的金鑰、客戶管理的金鑰，或是導入自己的金鑰 (BYOK)，以及決定集中式或分散式金鑰管理方法。每個選項在安全性、控制和操作負擔方面都有其優勢和權衡。透過了解這些選擇以及它們如何符合組織的需求，您可以制定有效且高效的金鑰管理策略。

在這篇文章中，我們探討了影響您 AWS KMS 金鑰策略的主要考量因素，從組織結構到合規要求。您應該維持由單一團隊控制所有金鑰的集中式金鑰管理方法，還是採用由各個團隊管理自己金鑰的分散式模式？這些決策很重要，因為它們與 AWS 的共享責任模型有關，其中 AWS 維護雲端的安全性，而客戶則負責雲端中的安全性，包括加密金鑰的正確管理和使用。

概覽 – 什麼是 AWS 金鑰管理服務？

AWS 金鑰管理服務 (AWS KMS) 是一項 AWS 管理的服務，讓您可以方便地創建和控制用於加密資料的加密金鑰。您在 AWS KMS 中創建的金鑰由 FIPS 140 Level 3 驗證的硬體安全模組 (HSM) 保護。金鑰永遠不會在未加密的情況下離開 AWS KMS。要使用或管理您的 KMS 金鑰，您需要與 AWS KMS 互動。

客戶負責決定要加密哪些資料，選擇適當的加密金鑰，並在 AWS 服務中實施加密，這需要使用金鑰政策的幫助。客戶還負責透過 AWS CloudTrail 等服務監控和審計加密金鑰的使用。

客戶責任的一個關鍵方面是確定如何管理金鑰以及需要多少 KMS 金鑰。這一決定取決於多種因素，如資料分類、應用架構、法規要求和操作需求。我們在接下來的部分中更詳細地探討這些領域。

金鑰策略的指導原則

以下是四個指導工程原則，根據我們的經驗，這些原則有助於創建一個安全且易於維護的系統。它們將幫助您根據管理需求確定組織所需的 KMS 金鑰的大致數量。

原則 1 – 資料分類：如果系統處理不同分類等級的資料，則應使用單獨的資料資源和單獨的 KMS 金鑰來分別管理和審計對資料的訪問。對於類似分類的資料或單一類型的資料，使用一個 KMS 金鑰可能是合理的。

為什麼這很重要：這一原則有助於確保將資料分類為不同敏感度等級的資料根據對該分類的加密金鑰的訪問進行適當保護，從而降低未經授權訪問的風險並簡化治理。

原則 2 – 應用：多個應用可以在一個 AWS 帳戶中運行。我們建議您為每個應用使用不同的 KMS 金鑰，因為當訪問管理委派給兩個或更多應用管理員時，管理單個金鑰的訪問可能成為一項複雜的任務。對於在不同 AWS 帳戶中運行的應用，使用單獨的 KMS 金鑰以進一步利用帳戶邊界，限制安全事件發生時的潛在影響。對於不同的應用階段（如開發、測試或生產），使用單獨的金鑰。

為什麼這很重要：這種方法隔離了對應用的訪問和應用對資料的訪問。這減少了無意中訪問金鑰的潛在影響。

原則 3 – AWS 服務：當您考慮跨多個 AWS 服務的金鑰管理時，請關注服務和資料的性質。如果您正在處理一種類型的資料（例如，客戶資訊），該資料作為一個應用或工作流程的一部分流經多個 AWS 服務，請考慮使用單一 KMS 金鑰。這簡化了金鑰管理，同時保持一致的訪問控制。例如，一個存儲在 Amazon 簡單儲存服務 (Amazon S3) 中的客戶記錄，經由 AWS Lambda 處理，然後存儲在 Amazon DynamoDB 中，可以在這些服務中使用相同的 KMS 金鑰，如原則 1 所述。

然而，如果您在同一應用中處理不同類型的資料（例如，財務記錄和用戶偏好）跨越多個 AWS 服務，請考慮在每個服務基礎上使用單獨的 KMS 金鑰。這允許更細粒度的訪問控制，並遵循最小特權原則。例如，在電子商務應用中，您可能會使用一個 KMS 金鑰來加密 Amazon 關聯式資料庫服務 (Amazon RDS) 中的支付資訊，並使用不同的金鑰來加密 Amazon Redshift 中的用戶瀏覽歷史。

使用一個金鑰或多個金鑰的決定應基於您的資料分類政策和訪問控制要求。通過這種方法，您可以保持金鑰管理策略與資料治理政策一致，無論您使用的是哪種 AWS 服務。

為什麼這很重要：這一原則在簡化需求與對不同 AWS 服務的資料訪問進行細粒度控制的要求之間取得了平衡。

原則 4 – 職責分離：金鑰政策定義了誰可以管理和誰可以使用金鑰。在不同的加密使用案例和不同的管理員的情況下，我們建議您創建單獨的 KMS 金鑰。職責分離的另一個方面是，通過 KMS 金鑰政策，可以讓兩個不同的主體負責管理資料和資料解密訪問。然而，這不會影響金鑰的數量。

為什麼這很重要：這一原則支持實施最小特權訪問，並有助於在金鑰管理中保持明確的責任。

通過應用這些原則，您可以制定一個金鑰管理策略，描述您可能需要多少 KMS 金鑰，並在安全性、合規性和操作效率之間取得平衡。在接下來的部分中，我們探討如何在各種情境中應用這些原則。

金鑰管理策略的示例及集中式和分散式方法的比較

除了前面討論的指導原則外，您的組織結構及其特定需求在確定最合適的金鑰管理方法時也起著至關重要的作用。在實施金鑰管理策略時，組織通常從三種主要方法中選擇：集中式、分散式或混合模式。選擇取決於組織的結構、需求和操作環境。每種方法在特定的組織情境中提供了不同的優勢。

分散式方法是我們推薦的方法，因為大多數客戶符合以下情境：

擁有自主業務單位的組織或治理控制提供金鑰使用的監督
開發團隊敏捷且金鑰的所有權可以集中審計的公司
在多個法規框架下運作的公司
需要在特定 AWS 區域運作的公司

集中式 KMS 方法最適合以下情境：

需要嚴格的合規監督和集中管理的組織
擁有集中安全或資料保護功能的公司

在混合模式中，集中和分散之間有一個混合：

核心金鑰政策由中央管理
日常金鑰操作由團隊處理

例如，組織或公司可以有獨立的產品團隊，但有一個集中安全團隊。

示例 1 (混合)：一個擁有公共產品目錄資料和機密客戶資料的零售網站應使用兩個 KMS 金鑰——一個用於在 Amazon S3 中加密的公共目錄，另一個用於在 Amazon RDS 和其他 AWS 服務中加密的客戶資料。

理由：這一建議主要基於原則 1（資料分類）。公共目錄資料和機密客戶資料代表不同的分類等級，這證明了使用單獨金鑰的合理性。這一方法還得到了原則 3（AWS 服務）的支持，因為資料存在於不同的 AWS 服務中，且性質各異。

這種方法的好處：

為每種資料類型實施適當的訪問控制
獨立管理每個資料分類的加密
增強整體資料安全性和合規性

示例 2 (分散式)：一個擁有多個應用團隊的醫療公司可以為每個應用團隊使用單獨的 KMS 金鑰，根據每個團隊的資料和角色制定不同的金鑰政策。

理由：這一建議主要基於原則 2（應用）。在醫療公司內運作的多個應用團隊，每個團隊可能處理不同類型的資料並具有不同的訪問要求，單獨的 KMS 金鑰提供了對每個團隊的加密和訪問的獨立管理。這一方法還得到了原則 4（職責分離）的支持，允許制定團隊特定的金鑰政策。

這種方法的好處：

保持對資料訪問的細粒度控制。
實施團隊特定的加密政策。
在整個組織中維護最小特權原則。
增強資料安全性：通過使用單獨的金鑰，公司限制了對任何給定金鑰的不當訪問的影響，實現了更精確的訪問控制，促進了獨立的金鑰輪換計劃，並提高了對每個應用的金鑰使用的監控和審計能力。
簡化與醫療法規的對齊：單獨的金鑰支持資料隔離要求，實現細粒度的基於角色的訪問控制，提供每個應用資料訪問的明確審計跟蹤，並允許定制的資料生命周期管理。這一功能對於符合各種醫療合規標準（如 HIPAA）至關重要。
允許高效且分散的金鑰管理，根據每個應用團隊的需求量身定制。

這些示例展示了如何應用指導原則可以導致一個結構良好的金鑰管理策略，適合不同組織和使用案例的特定需求。

金鑰管理的考量因素

當您實施金鑰管理策略時，除了金鑰的數量外，還需要考慮多個因素。本節探討這些考量因素，以幫助您就金鑰管理方法做出明智的決策。

金鑰類型

AWS 提供不同類型的 KMS 金鑰，每種金鑰都有其優勢和使用案例。

AWS 擁有的金鑰由 AWS 在服務帳戶中管理，跨多個客戶帳戶使用，並且不提供客戶可見性或審計能力。當對金鑰沒有管理或審計要求，但需要對靜態資料進行加密時，選擇 AWS 擁有的金鑰。

AWS 管理的金鑰完全由 AWS 管理，僅用於您的 AWS 帳戶。雖然客戶可以在 AWS 管理控制台中查看這些金鑰並在 AWS CloudTrail 日誌中跟蹤其使用情況，但他們無法直接控制或修改這些金鑰。當管理金鑰不是必需的，但需要審計跟蹤時，選擇 AWS 管理的金鑰。值得注意的是，AWS 管理的金鑰每年會自動輪換，這對於許多使用案例來說可能很方便。

客戶管理的金鑰提供最高級別的控制和自定義，允許創建金鑰政策並控制金鑰輪換。然而，客戶管理的金鑰提供了更大的靈活性，允許您設置自己的輪換計劃，甚至在需要滿足法規要求時啟用輪換。當您需要對金鑰使用進行嚴格控制並能夠通過金鑰政策共享金鑰或控制訪問、詳細的審計能力、符合特定合規要求，或能夠將金鑰管理與現有流程和工具集成時，選擇客戶管理的金鑰。

在 AWS 管理和客戶管理金鑰之間的決策通常歸結於自動管理的便利性與對細粒度控制和自定義的需求之間的平衡。隨著金鑰數量的增加，管理的複雜性也會增加。更多的金鑰意味著需要創建、管理和審計更多的政策。確保合適的人擁有合適的金鑰訪問權變得更加具有挑戰性。然而，為了幫助審計 KMS 金鑰訪問，您可以使用 IAM 訪問分析器來確定對金鑰的外部訪問。管理多個金鑰的輪換計劃需要更多的努力，更多的金鑰意味著需要分析和監控更多的政策，以及不斷增加的成本。

成本

安全性應該是主要考量，但成本也是一個因素。每個客戶管理的金鑰都會產生每月的存儲成本。AWS 管理和客戶管理的 KMS 金鑰都會產生 API 使用成本。金鑰輪換會隨著時間推移增加成本，因為舊的金鑰版本會被保留。

可管理性

在安全性和可管理性之間找到合適的平衡至關重要。金鑰太少可能無法提供足夠的職責分離或細粒度訪問控制，而金鑰太多可能導致增加的複雜性、更高的成本和潛在的管理不善。

具體要求

不同的行業和地區可能對金鑰管理有具體要求。一些法規可能要求職責分離，需要多個金鑰。某些合規標準可能要求特定的金鑰輪換或審計跟蹤要求。

通過仔細考慮這些因素以及前面討論的指導原則，您可以制定一個金鑰管理策略，在安全性、合規性、成本效益和操作效率之間取得平衡，滿足您的具體需求。重要的是要從整體上考慮您的 KMS 策略，不僅考慮您當前的安全需求，還要考慮長期的管理影響。定期審查和調整您的金鑰管理策略將確保它繼續滿足您不斷變化的需求，同時保持強大的安全性和合規性。

結論

正如我們在整篇文章中所探討的，為您的組織確定最佳的 AWS KMS 金鑰數量是一個微妙的決策，需要在安全性、合規性、成本和操作效率之間取得平衡。我們討論的指導原則——資料分類、應用隔離、AWS 服務整合和職責分離——為做出這些決策提供了堅實的框架。請記住，沒有一種適合所有情況的解決方案；正確的方法取決於您的具體需求和情況。

在實施或完善您的 KMS 金鑰策略時，請考慮以下步驟：首先，對您當前的資料資產、其分類以及與之互動的應用和服務進行徹底審計。接下來，根據我們討論的原則繪製出理想的金鑰管理結構。然後，評估您提出的策略的成本和操作負擔，根據需要進行調整，以找到適合您組織的平衡。最後，逐步實施您的策略，從最敏感或最關鍵的資料資產開始。

請記住，金鑰管理是一個持續的過程。隨著您的資料環境的演變、新的合規要求的出現或 AWS 引入新功能，定期審查和更新您的策略。通過仔細應用我們討論的原則和考量因素，您可以創建一個強大、可擴展且高效的金鑰管理策略，幫助提升整體安全態勢並滿足您組織的獨特需求。

如果您對這篇文章有意見，請在下方的評論區提交評論。如果您對這篇文章有疑問，請聯繫 AWS 支援。

Hardik Thakkar
Hardik 是 AWS 全球金融服務 (GFS) 的原型解決方案架構師。他專注於在 AWS 上設計安全架構和基礎，利用他的安全專業知識為金融服務客戶服務。他的重點領域包括安全優先的設計模式、金融服務合規框架，以及幫助機構在 AWS 上構建強大的雲端基礎設施。