AWS Encryption SDK 最佳實務

當你開始使用AWS Encryption SDK，使用您偏好的最新版本程式設計語言。如果您一直在使用AWS Encryption SDK，請盡快升級至每個最新版本。這可確保您使用建議的組態，並利用新的安全性屬性來保護您的資料。如需有關支援版本的詳細資訊，包括移轉和部署指南，請參閱支援和維護和的版本 AWS Encryption SDK。

如果新版本棄用程式碼中的元素，請盡快取代它們。棄用警告和代碼註釋通常會推薦一個很好的替代方案。

為了讓重大升級更容易且不容易發生錯誤，我們偶爾會提供暫時或過渡版本。使用這些版本及其隨附的文件，以確保您可以在不中斷生產工作流程的情況下升級應用程式。

所以此AWS Encryption SDK將最佳實踐設計為其預設值。只要有可能，使用它們。對於默認不切實際的情況，我們提供替代方案，例如沒有簽名的算法套件。我們還為高級用戶提供自定義的機會，例如自定義密鑰環，主密鑰提供商和加密材料管理器（CMM）。謹慎使用這些高級替代方案，並盡可能通過安全工程師驗證您的選擇。

為了改進密碼編譯操作的安全性，請包含加密內容在加密數據的所有請求中都有一個有意義的值。使用加密內容是選用的，但卻是建議的密碼編譯最佳實務。加密內容提供額外的驗證資料 (AAD)，包括AWS Encryption SDK。儘管它不是秘密，但是加密內容可以幫助您保護完整性和真實性您的加密數據。

在 中AWS Encryption SDK，您只能在加密時指定加密內容。解密時，AWS Encryption SDK在加密訊息的標頭中使用加密內容AWS Encryption SDK傳回：在您的應用程式傳回純文字資料之前，請確認您用來加密訊息的加密內容包含在解密訊息所用的加密內容中。如需詳細資訊，請參閱程式設計語言中的範例。

當您使用命令列界面時，AWS Encryption SDK驗證您的加密內容。

所以此AWS Encryption SDK產生唯一的資料金鑰來加密每則純文字訊息。然後，它使用包裝您提供的密鑰來加密數據密鑰。如果您的包裝金鑰遺失或刪除，您的加密資料將無法復原。如果您的密鑰不安全，則您的數據可能容易受到攻擊。

使用包裝受安全金鑰基礎架構保護的金鑰，例如AWS Key Management Service(AWS KMS。當您使用原始 AES 或原始 RSA 金鑰時，請使用符合您安全要求的隨機來源。產生並儲存包裝金鑰，並在硬體安全模組 (HSM) 中產生並儲存包裝金鑰，例如AWS CloudHSM，是最佳實務。

使用金鑰基礎結構的授權機制，將包裝金鑰的存取限制為只有需要金鑰的使用者。落實最佳實務原則，例如最低權限。當您使用AWS KMS keys，使用實務的金鑰政策和 IAM 政策最佳實務原則。

這始終是最佳做法指定您的包裝鍵在解密和加密時明確。當你這樣做，AWS Encryption SDK只會使用您指定的金鑰。這種做法可確保您只使用您想要的加密金鑰。適用於AWS KMS包裝密鑰，它還可以通過防止您無意中使用其他密鑰來提高性能AWS 帳戶或區域，或嘗試使用您沒有權限使用的密鑰進行解密。

加密時，密鑰環和主密鑰提供者AWS Encryption SDK耗材需要您指定包裝鍵。它們使用所有且僅使用您指定的包裝鍵。使用原始 AES 金鑰環、原始 RSA 金鑰圈和 JCE 進行加密和解密時，您還需要指定包裝金鑰MasterKeys。

但是，當使用解密時AWS KMS金鑰圈和主要金鑰提供者，您不需要指定包裝金鑰。所以此AWS Encryption SDK可以從加密資料金鑰的中繼資料中取得金鑰識別碼。但是，我們建議指定包裝索引鍵是我們建議的最佳實務。

若要在使用時支援此最佳作法AWS KMS包裝金鑰，我們建議以下內容：

指定時AWS KMS包裝密鑰進行解密是不切實際的，您可以使用發現提供程序。所以此AWS Encryption SDK在 C 和 JavaScript 支持AWS KMS探索 keyring。具有探索模式的主要金鑰提供者可在 1.7 版中使用 Java 和 Python。x和更高版本. 這些探索提供者，僅用於解密AWS KMS包裝密鑰，明確指示AWS Encryption SDK使用任何加密資料金鑰的包裝金鑰。

如果您必須使用探索提供者，請使用其探索篩選器功能來限制他們使用的包裝鍵。例如，AWS KMS區域探索 Keyring只使用特定的包裝鍵AWS 區域。您也可以設定AWS KMSkeyring 和AWS KMS 主金鑰提供者僅使用包裝金鑰尤其是AWS 帳戶。此外，與往常一樣，使用金鑰政策和 IAM 政策來控制您的存取AWS KMS包裝鍵。

使用帶有簽名的算法套件是最佳實踐。數位簽章驗證郵件寄件者已獲授權傳送郵件並保護郵件的完整性。所有版本AWS Encryption SDK默認情況下使用帶簽名的算法套件。

如果您的安全性需求不包含數位簽章，您可以選取不含數位簽章的演算法套件。不過，我們建議您使用數位簽章，尤其是當一群使用者加密資料，而另一組使用者將資料解密時。

使用關鍵承諾安全性功能是最佳作法。通過驗證唯一的身分資料金鑰加密了您的數據，金鑰承諾防止您解密可能導致多個純文本消息的任何密文。

所以此AWS Encryption SDK提供完整的加密和解密支援，並從中開始提供關鍵承諾2.0 版本.x。根據預設，您的所有郵件都會透過金鑰承諾進行加密和解密。1.7 版本.x的AWS Encryption SDK可以使用密鑰承諾解密密文。它旨在幫助舊版的用戶部署 2.0 版本。x成功地。

主要承諾的 Support 包括新的演算法套件和一個新的訊息格式產生的密文只比密文大 30 個字節，沒有密鑰承諾。該設計將其對性能的影響降到最低，因此大多數用戶可以享受關鍵承諾的好處。如果您的應用程式對大小和效能非常敏感，您可能會決定使用承諾政策設定以停用金鑰承諾產品或允許AWS Encryption SDK在沒有承諾的情況下解密郵件，但只有在必須的情況下才這樣做。

這是最佳做法限制加密資料金鑰的數量在您解密的郵件中，尤其是來自不受信任來源的郵件。使用無法解密的大量加密資料金鑰來解密訊息可能會造成延長延遲、耗盡費用、限制您的應用程式以及其他共用您帳戶的資訊，並可能耗盡您的金鑰基礎結構。沒有限制，加密訊息最多可以有 65,535 (2^16-1) 的加密資料金鑰。如需詳細資訊，請參閱 限制加密的資料金鑰。