大家 web 开发时，是怎么样保障正式数据库的账号安全的？

作为类库，写死在程序里。但是程序是编译后的二进制代码，除非黑客挂着内核来调试，否则也看不到数据库密码明文。

配置文件明文，好维护。
都搞到配置文件了，说明都被日穿了。

或者直接把数据库封装成 linux vm 黑盒，对外提供数据访问 API，用的时候就一个开一个 kvm 。
kvm 里写一些保护措施，比如和本地地址绑定后，接口才能正常运行。黑客一旦复制 kvm，没有 root 密码，也解不开进不去。数据就很安全。

配置文件+网络环境隔离

配置文件明文就够了

测试环境有专门的测试库，密钥可以写在配置文件里，里面也不能保存敏感真实数据。
生产环境一般用密钥管理系统，通过发布脚本在发布过程中自动化获取密钥，同时限制好网络的访问等。
这样基本上确保密钥或者数据库连接凭证只存在于机器内存中，同时因为网络限制只有特定应用服务器可以连接特定的库和表，最大限度的保障了安全。

@ysicing "都搞到配置文件了，说明都被日穿了。", 能多防几层总是好的，以前 CSDN 数据库被拖库，就都是明文才那么惨。
如果数据是加密的，黑客还要摸索程序，搞清解密算法。相对要安全一点点吧。

能入侵服务器，都白搭，做好密码不可逆才是关键

数据库地址和账号密码的密文从配置中心读取，本地配置文件存放机密的密钥。
这样关键参数密文和密钥分开来放，另外数据库访问也做了 ip 白名单机制，这样除非是权限很高的内鬼，基本不担心数据库安全问题。

密码明文在配置文件，但是配置文件是自己写的私有格式

写死到源码的一个配置结构，有什么问题吗？

服务器和数据库都是一家云服务商的

@ysicing 不是为了防外人，主要是防内部开发人员啊。

连接字符串里面的密码也可以加密啊.

大部分都是配置文件明文

话说配置文件都被人拿到了，还玩个鸡毛？

防内部人员的话就系统环境变量呀，dll 呀什么的

但是总归是有人要知道吧，这个防的没太大必要

configmap 和 vault 都用

MySQL 是用户名加主机名来区分用户的，主机名设置只允许连接的内网 IP 地址即可

当然是服务器才能直连，然后其他的操作要通过 web 审计平台上操作

1 、配置文件 不属于程序里吗？
2 、正常情况下，能查看到 1 、2 、3 里的，说明已经被 getshell 了吧？都被 GETSHELL 了剩下的顶多时间问题，再不是我也不解密，我顺着你的程序写个脱裤的？
3 、“能多防几层总是好的，以前 CSDN 数据库被拖库，就都是明文才那么惨。” ---不敢苟同，“能多防几层总是好的”，但也要用对地方..否则只是浪费时间....“以前 CSDN 数据库被拖库，就都是明文才那么惨。” CSDN 不是因为数据库密码泄露被脱裤，明文保存 是指数据库保存的密码是明文的...和配置文件没多大关系吧？

我的是配置文件加密，数据库只放在内网，只允许执行 IP 段访问，数据库内关键字段也是加密的

配置中心，这都被撸了的话那就莫得办法了

楼主意思是内部信息安全。可以用配置中心，配置都是加密的，启动时获取配置。线上线下隔离，即使想去连线上的配置中心代码里面打印也连不上

配置中心

CI/CD 的时候自动随机密码。

@iyaozhen 这种应该是大公司的那种级别的做法了吧

env + 个人独立环境

一般用到 3 就足够安全了，实际上大多小项目直接用 2

正常情况是存配置文件，加不加密的无所谓了，然后开启数据库访问地址白名单。

我司都是密钥库里随机抽一个再加点随机数当密钥, 谁也不知道密钥到底是哪个.
上线的时候, 先启动在线密钥爆破线程, 在一个更大点的密钥库里用随机数进行爆破, 大概半个到一个小时后, 就会爆破到正确密钥, 服务就启动起来了.

保证账号安全，谈单个点事没有意义的，安全是遵循木桶理论。你觉得你的这些措施很安全，假如你服务器被人偷走，你这些措施都没用了

这种叫做 Secret Management，具体的放狗搜一下

@chenqh 嗯 还有更细致的。专门有部门搞这个，属于基建

有防火墙控制，数据库只能由特殊 IP 访问，而且没有公网权限

然后就是定期的备份了

用内网配置中心

明文链接有网络要求，仅限于内网链接
密文解密是那些公开了数据库公网访问场景下的必然要求

不过说到底，安全问题是个综合结果，不代表锁大门了就安全，窗户，通风口，下水道等等很多地方都得同步做到安全，整个系统才算安全

用 2 足以，搞加密什么的都是皇帝的新衣。
某些人喜欢用公网 IP 的除外。局域网都长得一模一样，泄漏了又如何，某运营商的第三层跳板机里面还装得盗版 navicat 、CRT 呢。

防内部，那就加层 VPN，有账户密码也连不上

@bthulu 太秀了吧！发版前也需要爆破密码吗？

弄个假的配置文件，连上的是蜜罐。
真的放环境变量。
逃：）

一般写在配置文件里面，做好服务器的防护。
不嫌麻烦的话配置文件里面的密码加密一下，连接数据库的时候解密使用解密后的密码连接。

上配置中心

配置中心下发

@ysicing 没错 ，通过程序漏洞拿到 shell 直接就日穿

@bthulu 你们这个狠啊。。。

重点不是把密码写在哪里，即使是写在代码里面，只要代码不泄漏就是安全的。
当然有代码权限的人通常很多，所以不泄漏代码通常会困难一些。
如果你的代码的价值比数据的价值更高，那你直接写在代码里就好了，没必要折腾别的。

重点是要怎么保证密码不被别人拿到。
比如用加密的配置文件，那么重点是你要把密钥放在哪里，如果密钥和配置文件在一起，加密就是没用的。
如果你有一个安全的地方存密钥，当然也可以直接用这个安全的地方存配置文件，那么加密就是没必要的。

AWS GCP 都有 secret manager 来做这件事情。
当然如果你真的想要保证安全，只是上一个现成的服务当然解决不了问题。比如很多人喜欢在程序启动的时候把配置记在日志里，比如很多开发人员都有登录到服务器上的权限，这些地方都能拿到密码。

写环境变量里

放到 github 上面（狗头）

@bthulu #30 大佬这是一本正经说笑还是确有此事

数据库和服务器加 ip 限制

@godall 使用过的比较好的方式是配置中心，DBA 给一个 key 就好了，需要开发一个插件，也不复杂

不允许远程登陆就行了

1 、配置中心。只需要运维人员掌握权限即可。
2 、打包脚本替换配置文件，打包服务器只允许运维访问。别人要打包发布通过 Jenkins 运行脚本。
3 、各种骚操作，但难度比上面两个办法要大。

@3dwelcome 你真实想多了，你服务器都被日穿了，黑客压根不需要调试你的程序，拿到你的程序后，程序本地跑起拦截你的网络连接请求做中间人攻击，就能截到你的账号密码。

最安全的方式永远是不要让黑客接触到你的程序，一旦接触到你的程序了，什么都是白塔。为什么服务器程序在正常情况下默认比客户端程序安全的多，就是因为正常情况下认为黑客是接触不到服务器程序本体的。一旦这道防火墙被打破，靠什么加密程序，都是骗自己的

@bthulu 这倒是一个新奇的思路，可以保证秘钥只在内存里存在，而且很难拿到，问题是，你司启动一个服务要半个到一个小时？

一堆菜鸡在瞎猜。请个 DBA 。每个账户都可以限定 IP 和权限的。非机器 IP 无法操作。机器都黑进去了。有毛。

一般来说，服务器被入侵了配置文件才可能泄露。可是你家被偷了，你在意这个？人家 hook 你程序搞事情就行了，毕竟正常拿到数据库权限在其他地方也访问不到，权限都限着呢

@abcbuzhiming "你真实想多了，你服务器都被日穿了，黑客压根不需要调试你的程序，拿到你的程序后，程序本地跑起拦截你的网络连接请求做中间人攻击，就能截到你的账号密码。"

上面提到了，程序是和机器绑定在一起的，换了 IP 或换了硬件配置，程序就自动失效了，接口返回的都是错乱数据。
而且程序本体是封装在 Linux KVM 里面运行的，正常黑客没有 root 密码，系统进都进不去，更别说调试了。

防自己人，代码还是程序员写的，是不是得先防程序有后门，防不胜防啊

上线给部署文档如何配置账户， 保存的时候 base64 一下就可以了。明文不行，出了问题运维要跟你扯皮的。由运维组自己去配置账户，开发不用管了。账号泄露也是运维的问题， 跟开发就没什么关系了。

配置文件明文就可以了，限制数据库连接 ip，其余毫无意义。

sql 注入拖库根本不需要账号密码。。

k8s configmap 或者 Apollo 了解下

给一个坐标，运行获取密码

放到配置中心，比如阿波罗

.env
或者配置中心下发

最简单的不用数据库。。。

@3dwelcome 没用的你数据加密的方法还是在代码里面的所以没鸡儿用

肯定放在配置文件 里啊，如果真有高手能看到你的配置文件，肯定早就攻破系统了。

用 2 就行，用 3 的一般是企业合规需求

看到这里这么多评论里有这样的好笑的论点：水桶无论有多高，它盛水的高度取决于其中最低的那块木板，所以咱负责的这块木板做成啥样也没用。

@3dwelcome java： 还可以这样？

真流程规范的公司，开发人员是无法操作正式数据库环境和正式数据的，那是专门的 DBA 的权限。
开发人员只能用开发环境和测试环境的数据库及“假”数据。

配置文件直接放到服务器中，代码只放测试环境的

放在配置文件中就可以了，如果要关注服务器的安全问题，更多的需要关注代码逻辑、基线配置的问题。过于看重配置文件的问题，反而是捡芝麻，丢西瓜。