开发者社区> 问答> 正文

配置文件中的密码有没有必要加密?

通常情况下,我们将类似数据库连接类的信息保存在配置文件中,java里面喜欢用properties文件,以前没有考虑过,将文件中的密码加密,现在领导要求必须加密,那么,有没有必要对密码进行加密?如果有人能进入服务器,看这个配置文件的话,我想,加不加密的也没有多少意义吧?

展开
收起
蛮大人123 2016-02-29 17:07:13 4317 0
1 条回答
写回答
取消 提交回答
  • 我说我不帅他们就打我,还说我虚伪

    我看到的一种做法是将数据库的UserName、DatabaseName、Password全放到该user的环境变量里。
    生产环境的密码放在App配置文件中,那它通常也会进入源码版本库[见备注],这样普通的开发者就能checkout知道密码,但生产环境的密码是不需要让开发者知道的,而且是不应该让刚进入开发的实习生知道的。生产服务器的密码应该由运维人员统一管理。将密码放到环境变量中,开发者只需要一个get_env("db_password")这样的代码获取密码。
    再回到你所担心问题:「如果有人能进入服务器,看这个配置文件的话,我想,加不加密的也没有多少意义吧?」,所以将密码交给运维人员管理,普通开发者不需要直接登录生产服务器,应用部署更新都是交给运维或者通过rsync发布,登录入口减少了,安全性就有所提高。将不同的应用以不同的用户身份运行,其它用户的环境变量也不会泄漏。
    对了,配置文件加密是无助于提高安全性的。能得到配置文件通常意味着也能得到项目的源码[见备注],能得到源码也就能得到解密方式。更何况,DB服务器一般应该配置了iptables限制访问来源,密码只是整个安全环节中的一小点而已。
    备注:
    1.App的配置文件是应该受版本管理的
    2.在我看来一般的App部署环境没有复杂多变到某种程度,不将密码放到配置文件中,也就没必要为配置文件单独开设一个版本库,和源码同一个repo更省事;我自己的做法是将真正使用的settings.ini放到gitignore中,而在部署时执行一次cp settings_for_product.ini settings.ini。事实上如果目标环境并不多的话,我的做法是在源码版本库里存放多个版本的settings_for_A_cloud.ini、settings_for_B_cloud.ini,只是部署脚本中,不同目标环境,cp参数有所不同。

    2019-07-17 18:50:36
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
基于可信计算与加密计算 打造云上原生计算安全 立即下载
\"视频服务特色解决方案——直播连麦与点播加密 \" 立即下载
量子加密通信技术 立即下载