如何保护配置文件中的敏感信息,比如数据库密码

[cppc]

我们产品部署在甲方数据中心，同事(以下简称 A,算是项目经理)反馈甲方要求不得保存明文敏感信息：

• 各种密码、密钥都是敏感信息
• 存储位置包含磁盘文件、数据库

我提出方案有

1. 数据加密: 配置文件中的敏感信息加密保存,解密密钥保存在配置文件中。A 的意见:加密密钥也属于密码、密钥。
2. 用管分离: 使用密码库,配置中心之类的基础设施,我们拉取配置信息。A 的意见: 连接配置中心需要用户名 /口令,也是密码；配置中心连数据库需要数据密码，也是密码。

我不确定是 A 自己没有理解需求，还是甲方确实这么提出，这不就无限套娃么。

我们的客户是金融行业，请问这方面有无具体的技术规范？如果我的方案可行，要怎么样才具有说服力呢？

PS: A 坚持认为自己已经跟甲方沟通好了，不愿意再去询问具体要求

[pckillers]

把有线网卡 MAC 设置为数据库账号的密码，写死进代码。这样就没有密码了。这是硬件加密！必须这台服务器才能访问!

[libook]

如果描述不清需求，让 A 提一个草案，根据草案来理解需求。

文件、数据库里的敏感信息可以加盐加密，秘钥放在配置文件里，配置文件分成敏感配置文件和非敏感配置文件，非系统管理员禁止接触到敏感配置文件，这样确保仅当程序部署在正式服务器上的时候才能读到敏感配置文件。

不同环境的敏感配置信息不同，比如数据库秘钥在开发、测试、正式环境用三套不一样的。

用 K8s 的话可以利用 K8s 自带的 Secret 机制，在 pod 部署的时候才挂载上敏感配置文件。

想方便一点的话可以用配置中心，可以更细粒度地划分权限，配置中心配置 IP 白名单，仅受到信任的服务器可以访问，这样即便开发人员接触到配置中心的 Access Key 也不会有问题。

其实上面说了这么多核心思路就是把敏感配置信息和代码分离。

防范系统管理员基本是不可能的，因为跟服务器没有物理隔离（可以直接操作服务器），顶多加堡垒机和三权分立来制约一下。

安全都是相对的，没有绝对的安全，只有防范特定问题的安全，所以也可以问一下需要防范哪些问题，看是不是一个 X/Y 问题。

[angryfish]

加密狗吧，狗在密码在，狗不在密码不在

[tomczhen]

如果一开始假定运行环境就是不可信的，软件方案再怎么纠结也没用。非要抬杠，建议上 TMP 模块解决。

[hhjswf]

@swulling 你就没看懂 op 说的，连密文都不能有

[swulling]

@hhjswf 我相信我看懂了，而且也做过好多类似的需求。

「 A 的意见是说解密密钥保存在配置文件中」这个只需要把解密密钥写死在代码里就行了。

[swulling]

就是这个方案的修改：

> 数据加密: 配置文件中的敏感信息加密保存,解密密钥保存在配置文件中。A 的意见:加密密钥也属于密码、密钥。

数据加密: 配置文件中的敏感信息加密保存,解密密钥写死到代码里。

[liuzhaowei55]

一般来说研发不掌握线上生产权限，而运维拥有线上权限，所以通过启动命令注入环境变量，程序读取，是比较通用的交互方式

[swulling]

不要用安全的角度理解客户的需求，而是要满足客户的内部规章制度。

- toB 安全的第一要义。


举几个安全漏洞修复的实际例子：

- 客户内部安全扫描出 Nginx 漏洞，是因为 nginx 会输出版本号，老版本有 CVE 。解决办法并不是升级 nginx ，而是让 nginx 不要输出版本号或者输出高版本的伪造的版本号。
- 客户内部安全扫描出 MySQL 弱密码，解决办法也不是更换 MySQL 密码，而是直接设置访问 IP 白名单，不让扫描机器扫到这个 MySQL 。


太多太多了，不做这行不了解这些套路。

[alvinbone88]

金融行业应该有硬件加密方案，问问就行了

[cppc]

@swulling 哎，这个我当时就想到了，A 担心甲方询问处理细节，到时候不好回答，也就是说他内心是不认可这种方案的

[cppc]

@wolfie 我方服务需要自动启动，启动脚本里面不能写密码之类

[swulling]

@cppc 大家都是这么做的，你就放心搞吧，总比没有方案强。

[duduaba]

密码加密后直接写在代码里，说不定这种骚操作还是最终的方案。

[37Y37]

看看我们之前的方案 https://blog.ops-coffee.cn/s/dpgqiel4wcmgdqh1aeg4gw

[sparky]

没有绝对的安全，只能不断提高破解的成本

[janus77]

用配置中心，然后配置中心只开放少数几个账户，用硬件加密。甲方自己内部要看也必须通过硬件。硬件给他们的技术部门自己拿着，后面有锅就可以自然甩出去了

[cppc]

@janus77 我们之前做过的方案跟这个有相似之处，解密密钥在硬件中，只能写入不能读取，可以调用硬件在设备内部执行解密算法，这样，最外层的密钥在设备中，设备由甲方运维持有，也就丢掉了这个烫手的东西。

我纠结的就是我附言 1 里面提到的，这个方案侵入性太强，所有应用都需要置入操作硬件的 SDK ，修改服务的启动逻辑。要命的是，我们用到的开源中间件也得去改造，一旦改造，性质就变了，公司得负责到底。


我希望的方案和 @libook 相似
1. 要对信息进行区分，敏感信息也要分重要程度
2. 根据 [JR/T 0071—2012] ，安全分为物理层、网络层、主机层、应用层等，那么在特定外部安全环境下，一些不那么重要的敏感信息，可以存储明文。问题在于我不是权威，我的理解算个 P ，苦于没有可参照的成功案例，没有具体的权威规范。

[PHPer233]

用 AES 算法对密码加密，将密文保存在配置文件中。解密的密钥通过 jvm 启动参数传递给程序。

[bxb100]

@Vieufoux Valut +1