密钥管理架构设计概述

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密钥协商算法，来协商密钥。