密钥管理架构设计概述

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