密钥管理架构设计概述
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密钥协商算法，来协商密钥。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
