众所周知,在业务使用的过程中我们往往需要使用秘钥进行安全验证,通常一个秘钥往往是一个合法身份的凭证,这里就如孙悟空和六耳猕猴一样,两个人都声称自己叫孙悟空,这个时候验证谁是真正悟空,往往需要让两个悟空回答一些只有真的悟空才能知道的答案,这个只有真的悟空才能回答出来的答案就等同于秘钥。
这里就会衍生出一个问题,秘钥如果泄漏了怎么办,如果只是单纯的使用秘钥作为身份验证,那么这里的确毫无办法,因此秘钥的安全性至关重要,下面将介绍秘钥保存方式。
信封加密
从服务的角度来说,很多情况下会使用到秘钥,如数据库密码,api key等,而往往通常的做法是直接讲这些密码或者api key直接写在配置文件里。这里如果配置文件泄漏后果是不堪设想的。
因此,往往提倡如果明文密码不落盘。这里通常会使用信封加密,主要原理为引入秘钥管理服务,使用数据秘钥(DEK)对数据进行加密,而使用主密钥(KEK)对DEK进行加密,并将DEK加密后的结果与DEK加密后的结果进行保存,解密时使用(KEK)对DEK的加密结果进行解密得到DEK,再使用DEK对数据进行解密,这里对DEK的加解密是在秘钥管理服务中完成,而秘钥管理服务保存KEK,并保证KEK不被泄漏,从而保证了DEK的安全性。
具体流程如下:
总结
1)加密服务验证调用方的身份合法性?
这里主要是通过IAM进行身份验证以及权限控制,通过身份凭证(如access key,access secret)进行身份验证,通过对资源的访问权限控制决定访问权利,身份凭证如何保持?这个似乎是个鸡和蛋的问题。
信封加密
从服务的角度来说,很多情况下会使用到秘钥,如数据库密码,api key等,而往往通常的做法是直接讲这些密码或者api key直接写在配置文件里。这里如果配置文件泄漏后果是不堪设想的。
因此,往往提倡如果明文密码不落盘。这里通常会使用信封加密,主要原理为引入秘钥管理服务,使用数据秘钥(DEK)对数据进行加密,而使用主密钥(KEK)对DEK进行加密,并将DEK加密后的结果与DEK加密后的结果进行保存,解密时使用(KEK)对DEK的加密结果进行解密得到DEK,再使用DEK对数据进行解密,这里对DEK的加解密是在秘钥管理服务中完成,而秘钥管理服务保存KEK,并保证KEK不被泄漏,从而保证了DEK的安全性。
具体流程如下:
![](https://app.yinxiang.com/shard/s38/res/98f95f22-eb2e-456f-b1c3-605eab4616df/2.png)
总结
1)加密服务验证调用方的身份合法性?
这里主要是通过IAM进行身份验证以及权限控制,通过身份凭证(如access key,access secret)进行身份验证,通过对资源的访问权限控制决定访问权利,身份凭证如何保持?这个似乎是个鸡和蛋的问题。
2)秘钥管理服务
目前秘钥管理服务各大公有云提供尝试都有相应的产品,不过如果想自己搭建的话也有一些开源的实现,如下:
https://github.com/hashicorp/vault