信封加密存储秘钥

众所周知，在业务使用的过程中我们往往需要使用秘钥进行安全验证，通常一个秘钥往往是一个合法身份的凭证，这里就如孙悟空和六耳猕猴一样，两个人都声称自己叫孙悟空，这个时候验证谁是真正悟空，往往需要让两个悟空回答一些只有真的悟空才能知道的答案，这个只有真的悟空才能回答出来的答案就等同于秘钥。
这里就会衍生出一个问题，秘钥如果泄漏了怎么办，如果只是单纯的使用秘钥作为身份验证，那么这里的确毫无办法，因此秘钥的安全性至关重要，下面将介绍秘钥保存方式。

信封加密

从服务的角度来说，很多情况下会使用到秘钥，如数据库密码，api key等，而往往通常的做法是直接讲这些密码或者api key直接写在配置文件里。这里如果配置文件泄漏后果是不堪设想的。

因此，往往提倡如果明文密码不落盘。这里通常会使用信封加密，主要原理为引入秘钥管理服务，使用数据秘钥(DEK)对数据进行加密，而使用主密钥(KEK)对DEK进行加密，并将DEK加密后的结果与DEK加密后的结果进行保存，解密时使用(KEK)对DEK的加密结果进行解密得到DEK,再使用DEK对数据进行解密，这里对DEK的加解密是在秘钥管理服务中完成，而秘钥管理服务保存KEK,并保证KEK不被泄漏，从而保证了DEK的安全性。

具体流程如下：



总结

1）加密服务验证调用方的身份合法性？

这里主要是通过IAM进行身份验证以及权限控制，通过身份凭证(如access key，access secret)进行身份验证,通过对资源的访问权限控制决定访问权利，身份凭证如何保持？这个似乎是个鸡和蛋的问题。

2）秘钥管理服务

目前秘钥管理服务各大公有云提供尝试都有相应的产品，不过如果想自己搭建的话也有一些开源的实现，如下：
https://github.com/hashicorp/vault