密鑰管理架構設計概述

Key Management Service：密鑰管理服務，爲公司加解密、接口簽名等服務提供統一的密鑰管理能力，包括密鑰生成、存儲、下發、更新、銷燬等。

1、概念

一、密鑰屬性：
（1）密鑰狀態

NEW：相應的密鑰版本已準備就緒，可使用。
    USING：相應的密鑰版本已沒法使用，但密鑰材料仍可使用，而且可從新設置成已啓用狀態。
    STOP：手動停用的密鑰。
    LIMIT：限制的密鑰，不可在作加密操做，但能夠用來解密歷史數據。
    DEL：刪除的密鑰，不能再進行任何加密或者解密操做。

（2）密鑰版本：從1.0逐漸增長。
（3）有效期：單個密鑰有效期60分鐘。密鑰失效前10分鐘生成新密鑰。
二、密鑰用途：KMS爲如下場景提供相應的密鑰用途：數據加密、數字簽名、各類場景的key管理。
三、密鑰更新：密鑰更新，不會對歷史數據從新加密，只是在更新的時間點以後，自動使用新密鑰作加密

自定更新，設置更新週期和更新時間
    手動更新，隨時更新，而且不影響自動更新

四、密鑰分級：密鑰分級保證密鑰自己的安全性。

簡單的分級方案：
    第一層：工做密鑰，DEK，用來加密實際的敏感數據。
    第二層：密鑰加密密鑰，又叫作終端主密鑰，KEK，用來加密工做密鑰，在各個終端中存在。
    第三層：非對稱密鑰，數字證書的一部分，用來識別身份，並加密傳輸KEK。

2、思路

一、嚴格校驗用戶端和服務端的身份，避免冒用。身份校驗應以可信的第三方CA爲標準。
二、密鑰管理設計時要充分考慮密鑰備份、容災恢復等問題。
三、在各個關鍵節點要設計降級方案，如向KMS申請密鑰超時，SDK須要支持本地生成臨時密鑰。
四、密鑰更新過程當中必定要保證多節點的密鑰一致性。
五、能在SDK中封裝好的功能儘可能在SDK封裝好，避免與業務線代碼侵入過多。
六、儘可能避免轉加密現象。

3、組成架構

簡單的密鑰管理體系由四大部分組成：
KMS：密鑰管理系統，用來統一管理各種密鑰的生命週期，維護密鑰各種屬性。在密鑰更新的過程當中，實際是由KMS來判斷是否須要更新、向各客戶端下發更新指令，並實際生成密鑰的。
TMS：TOKEN管理系統，用來管理各個系統和密鑰直接的對應權限關係。
CA：統一認證中心，用來生成並下發數字證書，管理數字證書生命週期。
SDK：按照統一標準封裝加解密、簽名等方法，並在後臺與KMS按期通訊，維護密鑰更新流程。

4、密鑰管理方案

初始化階段：
一、各個Service首先在KMS中接入得到身份令牌token
二、各個Service生成本身的RSA公私鑰
三、各個Service拿本身的RSA公鑰去CA申請證書
密鑰準備階段：
一、Service用本身的證書去KMS申請須要的密鑰
二、密鑰保存在Service本地，按期去KMS從新獲取（當有效期設置爲0時，即不在Service本地保存，一次一密）
業務調用階段：
一、Service用獲取到的簽名密鑰作簽名，加密密鑰作加密，調用其餘服務。
二、其餘業務線校驗簽名，返回數據。

5、密鑰管理的一些經驗：

一、何時作數字簽名？
每次接口調用都作數字簽名。
二、數據加密的算法？
建議採用對稱加密AES256位密鑰，待加密的數據類型不一樣，選擇不一樣模式，通常狀況下CBC模式適合大多數場景，XTS模式適合本地存儲場景。
三、如何判斷一條數據是否被加密？
在系統遷移的過程當中，必然出現明文和加密兩種邏輯同事出現的狀況，此時就須要程序判斷數據是明文仍是密文，建議在SDK中提供方法判斷。
四、存儲加密數據庫索引如何處理？
基於安全的設計，相同的明文可能密文不一樣，所以須要創建一條不可逆而且與明文一一對應的值作索引。
五、存儲加密歷史數據如何處理？
第一次加密以前的歷史數據，須要提早先由刷庫工具統一將明文刷成密文，刷庫時，須要先新建一列密文列，將明文列加密後刷到密文列中，以後程序寫入或者更新操做時，須要對明文列、密文列雙寫，讀取操做時只讀取密文列，等程序穩定運行一段時間後，再將明文列刪除。
第一次加密以後，隨着密鑰按期更新，不一樣時期的數據使用不一樣密鑰加密。
六、密鑰如何存儲？
在KMS服務端，工做密鑰須要加密存儲於數據庫中，加密存儲的密鑰可採用分段式密鑰，經過RAID方式將不一樣密鑰段存儲於不一樣介質中。
七、證書如何生成下發？
證書生成下發一般有兩種方式，第一種是SDK生成RSA公私鑰，將RSA公鑰發給CA申請證書，CA用本身的私鑰簽發證書後返回給SDK。第二種是直接CA生成RSA公私鑰，並簽發證書，並下發給SDK。這兩種方式可根據實際業務需求選擇。
證書是對客戶端作身份識別的最重要標識，所以在第一次下發證書時，建議採用可信的第三方系統獨立下發，如SRE發佈系統。若是有有效且安全的手段保證客戶端的合法性，可經過SDK與KMS的交互來下發證書。
八、證書如何驗證，保證客戶端的合法性？
證書驗證須要兩個步驟：
（1）驗證證書的合法性，經過CA的公鑰解密證書，校驗簽名便可驗證證書的合法性、未被篡改。
（2）驗證客戶端持有證書對應的私鑰，KMS向SDK發起challenge，向SDK發送一個隨機數，SDK使用私鑰加密後，返回給KMS，KMS使用證書中的公鑰解密，驗證SDK確實持有合法的私鑰，證實SDK的合法身份。未了保證安全性，KMS發送的隨機數能夠作一次哈希。
九、密鑰協商方式？
密鑰協商可採用集中協商或者分散協商兩種方式。
（1）集中協商：各個SDK分別向KMS請求密鑰，KMS生成後返回給各個SDK。
（2）分散協商：假設有兩個客戶端A和B，A和B使用DH密鑰協商算法，來協商密鑰。