密鑰輪換 AES
由於政策，我正在嘗試在我的系統中實施密鑰輪換。在我的系統中，加密數據永遠不會被刪除，也沒有過期日期。
我遇到了 2 個解決方案：
- 生成新密鑰，用舊密鑰解密所有數據，然後用新密鑰加密。
- 用另一個名為“A”的密鑰加密主密鑰（例如），當我需要加密/解密數據時，我使用主密鑰，但對於密鑰輪換，我只需要解密/加密主密鑰。
第一個解決方案很混亂，並且有很多數據可能會出現問題，第二個解決方案看起來很有希望，但是如果主密鑰永遠不會改變並且我仍然加密相同的主密鑰，我真的做了“密鑰輪換”嗎？或者也許我沒有完全理解這個解決方案？
關鍵輪換政策可能……複雜且官僚，具體的措辭可能會規定您必須使用的輪換方法以及執行頻率。
方法 1 不僅混亂且計算量大，而且需要解密所有數據，增加了暴露風險。
方法 2 更為常見，但是您應該使用超過 1 個基於年齡的主密鑰。隨著舊的主密鑰過期，您使用該主密鑰和新的主密鑰重新加密子密鑰。這樣，就沒有一個時間段要求您同時更改所有密鑰，可能是在現在不可能滿足的政策規定的特定時間範圍內。
我的術語將子密鑰定義為加密數據的密鑰，將主密鑰定義為加密子密鑰的密鑰。這種類型的密鑰輪換可以滿足政策要求。
由於加密數據不會過期，我假設數據集會隨著時間的推移而增長。您應該確定可以合理管理多少個主密鑰，以及在需要更改下一個主密鑰之前的合理時間段內，是否有足夠的時間來重新加密其子密鑰。如果您要最大限度地使用 CPU 24/7 來更改密鑰，那麼您就有問題了。
如果政策要求您必須更改數據密鑰，則密鑰輪換週期可能與主密鑰的輪換週期不同，如果數據密鑰週期較長，則使用兩種類型的密鑰輪換將節省大量計算資源。
如果您或其他人有能力創造性地解釋策略，您可以使用分層加密和最後訪問時間來操縱密鑰輪換計劃。例如，主密鑰輪換週期可以在第一次被訪問以解密子密鑰時開始。
如果您實際上希望通過密鑰輪換而不是僅僅滿足策略要求來提高安全性，那麼它們的主密鑰都應該通過硬體加密以一種永遠不會直接暴露的方式進行保護，並且應該嚴格控制和記錄訪問。馬虎的密鑰輪換只會增加更多暴露數據的機會。
密鑰輪換的主要目的是限制使用相同密鑰加密的數據量。重新加密所有內容（或數據密鑰）實際上會使密鑰輪換的整個目的無效。
您可以搜尋雲提供商（aws、azure、ibm、google、..）如何管理密鑰輪換。
每個加密內容還包含用於加密數據的密鑰 ID（和版本）。密鑰輪換意味著創建一個新的密鑰版本，同時保留舊的密鑰材料來解密舊的（現有的）密文。