初探企业级密钥管理服务

一、风险与挑战

随着公司业务持续高速增长，内、外部面临的数据安全风险也越来越大，密钥硬编码、用户敏感数据明文存储等等安全问题层出不穷。2018年期间，欧盟正式实施了《一般数据保护法案》（即GDPR），进一步从监管合规角度推动整个互联网大环境下对用户个人数据进行加解密强要求规范的实施。

另外，从公司层面考虑，除了要满足支撑众多业务线的需求，满足数据安全性、监管合规的需求外，还必须要满足业务服务的高可用性以及稳定性。这便要求企业能够提供一整套完善的解决方案，既能够保障企业级数据及密钥安全，又能够实现对海量数据的高效加密保护。密钥管理服务（Key Management Service）就是为了解决上述安全风险和业务诉求，项目代号 「SpiderMan」 。

需求和目标虽然已经明确了，而作为甲方的安全团队，其实更多的是扮演一个驻扎在甲方企业内部的乙方服务型团队，如何摸清楚需要服务的业务方有哪些，这些业务方的实际需求又是什么变得至关重要了。对于很多的业务方而言，在安全与业务的平衡上，主要考虑两个因素：一个是安全风险是否已经严重威胁到业务的发展，不解决就意味着活不下去了（如面临 GDPR 压力的海外业务）；另一个是接入安全服务的成本是否可以接受。这两点因素，特别是最后一点，它要求业务在项目设计阶段就要考虑服务的易用性，以一种接近「轻服务」的方式提供，当然还要建立在保证了稳定性的基础之上，如果平台级服务时常出现不可用的情况，相信你的业务方终有一天会挥手跟你「Say Goodbye」的。

二、服务场景

那么问题来了，你的「目标客户」是谁？换句话说就是服务的主要应用场景及接入方有哪些？要弄清楚这一个问题，一个很好的方式便是要下到“基层”去“访谈”业务，要不厌其烦的和业务去交流沟通；另外一个方式就是你是企业的“老油条”，或者去向“老油条”请教，时间绝对是一个保值的投资，随着时间推移，“老油条”们对业务的了解程度超乎你的想象。

运用这两种方式得到以下的应用场景：

其一是作为应用/网站开发者的用户，程序需要使用密钥、证书用于加密或者签名时，希望密钥管理的功能是安全且独立的，无论应用部署在哪里，都能安全的访问到密钥，绝不接受把明文的密钥到处部署；其二是作为服务开发者的用户，使用指定的密钥加密敏感数据，这样即使数据泄露了，也不会造成太大的影响。

对于第一种场景下的用户需求，可以使用信封加密技术，主密钥存放在 KMS 服务中，只部署加密后的密钥或证书，仅在需要使用时调用 KMS 服务解密密钥或证书。

对于第二种场景下的用户需求，采用基于信封加密技术以及 KMS 开放的 API，服务能够集成 KMS，使用指定的主密钥完成数据密钥的解密，通过数据密钥加解密敏感数据能够轻松的实现明文不落盘的要求。

三、密钥数据加解密

密钥有主密钥与数据密钥两种，其中主密钥用于配置文件中敏感信息加解密，如数据库连接信息，API 的 Token 等；数据密钥用于对数据进行加解密，通常用于加解密数据库中的敏感数据，如生日、地址、手机号、身份证号等。加解密有云端加解密（RPC）和本地加解密（SDK）两种方式，业务方按需调用。

3.1 什么是信封加密？

信封加密也被称为数字信封技术，它是一种综合利用对称加密和非对称加密技术的加密方案，目的是利用对称加密的高性能和非对称加密的易管理。在信封加密方案中，海量的业务数据在存储或通信的过程中使用数据密钥以对称加密的方式加密，而数据密钥又通过主密钥采用非对称加密方式加密保护；而解密时，以本地场景为例，首先将数据密钥密文解密出数据密钥明文，然后通过数据密钥解密出数据明文。

3.2 加密数据流程

1）首先用户通过 KMS 平台创建用户主密钥与数据密钥。

2）创建数据密钥后会得到加密后的数据密钥。

3）用户使用数据密钥时，需要先在 KMS 平台解密得到明文的数据密钥，之后使用数据密钥加密敏感数据。

4）用户将密文数据密钥和密文数据一同存储到持久化存储设备或服务中。

3.3 解密数据流程

1）用户从持久化存储设备或服务中读取密文数据密钥和密文文件。

2）调用 KMS 服务的解密接口，解密数据密钥，取得数据密钥明文。

3）使用明文数据密钥对数据进行解密。

四、身份认证方案

用户身份信息：用户在 KMS 平台上的 secret id 和 secret key。

服务身份信息：PSM（Product Subsys Module，内部服务标识），需要绑定在 KMS 平台上的某一数据密钥下。

4.1 基于 PSM 和 IP 的身份认证

在 KMS 平台上，用户可以创建主密钥，主密钥用于管理数据密钥及小量数据的加解密。用户在创建数据密钥时，需要指定管理它的主密钥，以及数据密钥的 PSM，该 PSM 在 KMS 平台上唯一且创建之后不能再修改 PSM。创建数据密钥后，PSM 即绑定了该数据密钥。

在绑定 PSM 到某一数据密钥后，就可以使用 PSM 作为身份信息。为了对访问进行鉴权，在使用 PSM 时（API 或 SDK），会对 IP 进行限制，只有处于PSM（即某数据密钥）的 IP 白名单中的 IP 才可以进行访问。在创建数据密钥时，当前 IP 会自动加入到白名单中，如果需要在服务器上调用，请确保服务器 IP 处在该 PSM 的 IP 白名单中（KMS 平台可以通过 TCE 可信环境进行 IP 和 PSM 验证，详见基于 TCE Token 的身份认证，这种情况下不需要将服务器 IP 添加到 IP 白名单中）。

除了上面所说的 IP 白名单与 TCE 可信环境验证两种方式，用户也可以通过在环境变量中设置变量的方式进行身份认证。

4.2 基于 TCE Token 的身份认证

TCE (Toutiao Cloud Engine) 在服务升级时存在 IP 漂移的情况，即服务发现没有及时注册新的 IP，延时 20 秒左右，这样可能造成基于 PSM 和 IP 的校验不通过。TCE 提供了可信环境的验证方式，开启服务认证后，容器启动时 Token 会挂载到容器内。KMS SDK 初始化过程中会将 Token 传给 KMS 平台，平台验证 Token 所属 PSM 和数据密钥的 PSM 是否相同。

4.3 基于 Service Mesh 的身份认证

服务化平台提供了服务间身份验证的方案，基于 Proxy 实现。加解密 RPC 服务 EAAS 开启了严格鉴定，调用方需升级 Mesh。

五、优势特点

5.1 高效

所有的业务数据都是采用高效的本地对称加密处理，对业务的访问体验影响很小。而对于数据密钥的创建和加解密开销，除了非常极端的情况下需要采用"一次一钥"的方案，大部分场景下可以在一段时间内复用一个数据密钥的明文和密文，所以大多数情况下这部分开销非常小。

5.2 安全易用

信封加密的安全性类似于常见公钥体系，数据密钥保护业务数据，而KMS平台则保护数据密钥并提供更好的可用性，用户的主密钥无论如何都不会被泄露，只有有用密钥访问权限的对象才有能力操作数据密钥。另外针对业务常使用到的 ORM 框架（主要为 SQLAchemy 和 GORM ）也做了一系列定制化，也从很大程度上减轻了业务方的代码改动成本。

六、尾声

其实无论是 KMS 或者类型的企业级安全服务产品，从技术角度上来说应该都已经比较成熟，很多甲方团队也都自研或者二次开发等形式实现。但如本文开头所说，安全领域尤其是同业务耦合度较高的产品服务的难点在于如何让业务方较好的接受和使用，让安全真正成为业务的属性并不是甩给业务一个盒子去强制使用就完事了，做出一个产品仅仅是开头，复杂环境之下推动至业务方到落地再到不断调优是个需要很多耐心和决心的过程。（ Mel0d6y ）

声明：本文来自字节跳动安全中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如需转载，请联系原作者获取授权。