KMS密钥管理

发表于 | 分类于 | 阅读数

KMS目的

禁止业务调用方，本地私自明文存储敏感信息（如密钥）。
确保业务落盘存储是加密的，在内存中加载依然是明文密钥哦，不要混淆概念~

KMS架构

密钥分级

  • 数据密钥DEK：三级密钥，用来加密明文数据的密钥
  • 主密钥CMK：二级密钥，用来加密数据密钥的密钥
  • 根密钥RootKey：一级密钥，用来加密主密钥的密钥

术语

HSM：加密机，一般是芯片硬件，提供根密钥生成和保管
KMS：后台程序，负责从硬件安全模块HSM获取/保存根密钥（内存），派生算法生成主密钥/数据密钥，主密钥加密持久化保存在数据库中（数据密钥可存储可不存储，阿里云是不存储的）
SDK：给业务系统客户端使用，集成KMS API组件，其中的加解密模块就是OpenSSL封装起来的库

最佳实践

主密钥直接加解密

  • 对配置文件的加密
  • 对SSL私钥的加密
    直接加密

敏感信息直接加密是密钥管理服务（KMS）核心的能力，适用于保护小型敏感数据（小于4KB），如密钥、证书、配置文件等。

对象存储OSS数据加密传统模式

  • 客户端加密

    • ①——用户上传文件之前，在本地进行数据加密，文件加密后再上传到OSS，密钥不上传自己管理维护，确保云端永远无法解密。
    • ②——密钥由KMS托管，KMS和用户是一条船上的，目的是一样的，即文件加密后上传到OSS，接下来会讲客户端如何从KMS获取信封加密的三种方式
    • 优点：数据离开客户端就加密，我的数据我做主
    • 缺点：①客户端需要自行管理加密密钥；离开客户端密钥，云端不能在线读取访问，不能在其他客户端同步这些文件

  • 服务端加密

    • ①——云端OSS对收到的文件，数据持久化保存到数据中心的磁盘之前调用KMS进行加密，下载时自动解密，提供静态数据保护
    • ②——云端OSS完全托管，不依赖KMS，即数据加密的密钥和管理由OSS负责，对客户端透明
    • 适用：适合于对于文件存储有高安全性或者合规性要求的应用场景。例如，深度学习样本文件的存储、在线协作类文档数据的存储。并非任何文件都要存储加密，对存储要求低的不用执行服务端加密
      客户端加密/服务端加密

信封加密的三种方式

加密SDK使用场景
（一）、（二）适合KMS与业务系统都在一个机房内网环境下，因为两者之间终究会传输敏感数据（如密钥），当然要求不严格的话外网也适用

Tips：（二）定义为信封加密，虽然用到了主密钥加密
信封加密本地实践

最佳实践——相册云端加密（三）

核心目标：终端用户的数据，只能用户自己看到（手机端、浏览器访问云相册均可），噱头就是云服务提供商也看不到明文，因为是加密存储

适用场景：调用方（终端手机）通过公网去访问云端KMS，而不是内网去请求KMS的解决方案。KMS使用非对称CMK

云空间四重加密技术 
1
2
3
4
5
6
7
8
9
10
蓝钥匙，本地随机key用来加密图片等数据
红钥匙，主密钥CMK公钥，加密蓝钥匙
金钥匙，根密钥，负责生成CMK的公钥和私钥
绿钥匙，手机设备公私钥对，公钥上传到CMK，便于一用户多终端认证+下发红钥匙。设备出厂时，预置了设备证书与公私钥对（存储在TEE），设备的公私钥对每台都不同，用于标识设备的唯一合法身份。

KMS云端存储：红钥匙
云空间存储：加密后的相册数据、加密后的蓝钥匙
手机端存储：红钥匙CMK公钥、绿钥匙设备公私钥，都存在TEE中

效果：认证后，自己的图片只有自己能看到，在手机端、在浏览器中访问云空间等方式，都可以看到明文图片，只不过存储时是加密的

密码托管系统

KMS只是托管了加/解密的key，未托管业务的敏感数据凭证，如数据库凭据、API密钥、账号密码等。
在KMS系统之上封装一下，就是Vault，即凭据托管系统，实现密码托管及自动轮换。
直接加密
注意：凭据的录入、凭据的定期轮换是凭据的产生者——运维平台负责的。密码托管系统只是代为保管凭证，不生产凭据，只是凭据的搬运工

总结

主密钥CMK，租户永远不知道其256位值，只看到主密钥的UUID。当然可以创建多个CMK，一个CMK可以加密多个DEK。KMS的作用就是替各个业务系统加密DEK，安全的存储CMK。

KMS问答

Q：根密钥、主密钥、数据密钥都在哪存储？
A：根密钥在HSM的硬件芯片中，主密钥在KMS的数据库中加密存储，数据密钥在应用系统本地加密存储。

Q：数据密钥DEK怎么生成的，DEK存在KMS中？
A：第一种通过KMS的主密钥CMK生成，但KMS不会存储、管理你的DEK
A：第二种应用系统本地生成，然后发给KMS让它加密。Google推荐的最佳实践

Q：数据密钥DEK的使用和存储？
A：KMS不会存储你的数据密钥，当然也不会存储根密钥，KMS使用根密钥时是在硬件内存中的，不会落地。
A：业务系统加载使用数据密钥时，是在内存中的，明文，不会落地。（当然你非要明文落地，也没人管你）
A：凡是落地的密钥，都要加密，禁止明文存储。

Q：主密钥会在客户端内存中么？
A：主密钥永远不会离开KMS+HSM，故不会在业务系统的内存中。即业务系统永远不知道CMK，只知道UUID。
A：如果业务系统自己生成一个密钥，上传到了KMS中。可以指定这个密钥是CMK，只是委托KMS用根密钥加下密。当然一般场景下，这个密钥是DEK，只是委托KMS用主密钥加下密。

Q：调用方永远不知道明文数据块？
A：KMS只是负责帮你加密或托管密钥key，明文数据毕竟是你提供的，只是避免明文存储，间接的人为看到。

Q：主密钥直接加密和信封加密的区别？
A：主密钥直接加密，待加密可能是key也可能是敏感信息，如果是敏感信息，KMS和业务系统之间传输过程中的风险问题
A：信封加密，KMS和业务系统之间，传输的只能是key
A：不管怎样，KMS和业务系统之间，终究（始终）会传递敏感信息/密钥

Q：主密钥直接加密业务方提供的数据，有啥缺点？
A：主密钥加密的东西，支持最大4KB的数据
A：信封加密降低了网络负载，可提供巨大的性能优势
A：将需要加密的数据通过网络传输到KMS后端，传输过程中的安全风险问题（相比只传输密钥key）

Q：KMS中会保存业务数据么？比如db密码、appkey等
A：KMS的作用是维护DEK&CMK密钥的安全，而不是口令的托管。
A：Vault可以托管db密码、appkey，即密码托管系统，会用到KMS的加密机功能

Q：什么场景即使有了KMS也无法解决？
A：
如果业务逻辑漏洞如越权等，或者控制了机器，这个KMS也防不住。KMS防的是即使你拿到业务源代码、业务的数据库，也无法解密。

Q：KMS系统的AK/SK如何妥善保存？
A：鸡生蛋蛋生鸡的问题，KMS解决业务敏感数据的存储问题，但KMS也需要认证
A：一般还是推荐AK/SK去调KMS，另一种方案是用公有云提供的RAM方案，实例级别访问控制
A：KMS AK在阿里云上的管理方案