密钥管理架构设计概述

msup 发布于2019-06-21 16:55 / 3773人阅读

摘要：相应的密钥版本已无法使用，但密钥材料仍可以使用，并且可重新设置成已启用状态。手动停用的密钥。有效期单个密钥有效期分钟。密钥失效前分钟生成新密钥。密钥管理设计时要充分考虑密钥备份容灾恢复等问题。集中协商各个分别向请求密钥，生成后返回给各个。

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

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/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