密鑰管理架構設計概述

msup 發布于2019-06-21 16:55 / 3758人閱讀

摘要：相應的密鑰版本已無法使用，但密鑰材料仍可以使用，并且可重新設置成已啟用狀態。手動停用的密鑰。有效期單個密鑰有效期分鐘。密鑰失效前分鐘生成新密鑰。密鑰管理設計時要充分考慮密鑰備份容災恢復等問題。集中協商各個分別向請求密鑰，生成后返回給各個。

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

一、概念

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

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

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

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

4、密鑰分級：密鑰分級保證密鑰本身的安全性。

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

二、思路

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

三、組成架構

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

四、密鑰管理方案

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

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

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

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11483.html

大型網站技術架構-入門梳理

摘要：使用緩存兩個前提條件數據訪問熱點不均衡數據某時段內有效，不會很快過期反向代理本地緩存分布式緩存異步旨在系統解耦。大型網站技術架構-入門梳理標簽：架構設計 [TOC] 羅列了大型網站架構涉及到的概念，附上了簡單說明前言本文是對《大型網站架構設計》(李智慧著)一書的梳理，類似文字版的思維導圖全文主要圍繞性能，可用性，伸縮性，擴展性，安全這五個要素性能，可用性，伸縮性...

wawor4827 2019-08-06 13:19 評論0 收藏0
FIDO UAF 結構概述 v1.1

摘要：結構概述版本協議中文文檔。根據已配置的認證器元數據驗證認證器的可靠性，確保只有可信賴的認證器注冊使用。利用認證機構提供的認證元數據來對認證器的真實性和可靠性進行驗證。具體來說，是通過認證器元數據中發布的認證公鑰完成驗證。 FIDO UAF 結構概述版本 v1.1 FIDO UAF協議中文文檔。現在FIDO UAF有關的文章還比較少，這主要是文檔翻譯和UAF系統概要介紹。 FIDO...

neu 2019-06-21 16:34 評論0 收藏0
Kubernetes和OpenStack的多云端網絡

摘要：上周，在舉行的上，發布，整合和。多虧存儲應用程序會話到數據庫通常來說是下載安裝或者是，我們不需要特定的負載均衡器，運行完全沒有問題。用負載均衡器描述的展示了浮動和私有集群。特別感謝來自的的支持和在測試過程中作出的貢獻。上周，在Austin舉行的OpenStack Summit上，CoreOS發布Stackanetes，整合Kubernetes和OpenStack。一個月前，Core...

Hwg 2019-07-01 16:21 評論0 收藏0