当前位置:  开发笔记 > 前端 > 正文

源代码管理中的密码存储

如何解决《源代码管理中的密码存储》经验,为你挑选了2个好方法。

我们将所有应用程序和db密码以纯文本形式存储在源代码管理中.我们这样做是因为我们的构建/部署过程生成了所需的配置文件,并且还执行了需要这些密码的实际部署(即:针对数据库运行sql需要您使用有效凭据登录到数据库).有没有人有类似的需求,你可以实现这种类型的功能,而不是以纯文本形式存储密码?



1> Schwern..:

如果您的计划是存储所有代码和配置信息以直接从版本控制运行生产系统,并且无需人工干预,那么您就会被搞砸.为什么?这完全违反了旧的安全公理"永远不会写下你的密码".让我们通过否定来做证明.

首先,您可以在配置文件中使用纯文本密码.这不好,任何能看到文件的人都可以阅读.

第二次削减,我们将加密密码!但现在代码需要知道如何解密密码,因此您需要将解密密钥放在代码中的某个位置.问题刚刚被推到了一个水平.

使用公钥/私钥怎么样?与密码相同的问题,密钥必须在代码中.

使用未存储在版本控制中的本地配置文件仍然会将密码以及在磁盘上加密时读取它们的方法放在磁盘上并且可供攻击者使用.你可以通过确保配置文件的权限非常有限来强化一些东西,但如果盒子被植根你就搞砸了.

这让我们知道为什么将密码放在磁盘上是一个坏主意.它违反了安全防火墙的概念.一台包含登录信息的受感染机器意味着其他机器将受到损害.一台维护不善的机器可以拆除整个组织.

在某些时候,人类将不得不注入重要的秘密来启动信任链.你可以做的是加密代码中的所有秘密,然后当系统启动时,人工手动输入密钥来解密所有密码.这就像Firefox使用的主密码系统.它是开放的滥用,因为一旦一个密码被泄露,许多系统可能会受到损害,但它很方便,可能更安全,因为用户只需记住一个密码,不太可能写下来.

最后的接触是确保登录信息遭到入侵(并且您应该总是假设它将会受到影响)A)攻击者无法对其做多少事情并且B)您可以快速关闭受感染的帐户.前者意味着只为帐户提供所需的访问权限.例如,如果您的程序只需要从数据库中读取,则必须在限制为SELECT的帐户上登录.通常,删除所有访问权限,然后仅在必要时添加.吝啬删除的权利,以免你从小鲍比表访问.

后者意味着您为每个用户/组织/项目提供他们自己的登录,即使他们可以拥有完全相同的权限和特权并访问相同的数据.这有点麻烦,但这意味着如果一个系统遭到入侵,您可以快速关闭该帐户而无需关闭整个业务.



2> SingleNegati..:

我认为目标是您不希望公司的私人密码可用,加密,解密或以其他方式提供给任何应该允许访问其余来源的人.

这是我如何做到的.我已经从TikiWiki复制了这个模式,它也是这样做的.

在一些通常包含密码的文件中,将它们设置为虚拟值,无关紧要.将其设置为客户应该看到的任何内容.在附近添加注释,供开发人员单独保留此文件并更改第二个文件.

在第二个文件中,如果不存在则创建它,输入实际的密码.安排这个文件被第一个文件包含,导入,等等.

安排您的源代码管理忽略该文件.看起来像这样:

# in .gitignore
localsettings.py

# in settings.py
## Alter this value to log into the snack machine:
## developers: DON'T alter this, instead alter 'localsettings.py'
SECRET_VALUE = ""
try:
  from localsettings import *
except:
  pass

# in localsettings.py
SECRET_VALUE = "vi>emacs"

推荐阅读
coco2冰冰
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有