version-control - 如何避免在版本控制中存储密码？

Question

您使用什么策略来避免在版本控制中存储密码？

目前，我将开发/测试/生产密码保存在三个不同的文件中，并在部署期间使用相应的文件。所有这一切都致力于版本控制，但我对此不太满意，因为并非所有开发人员都需要知道这些密码（尤其是外包的，他们只有在项目持续时才可以访问，可能只有一个月）。

在数据库中存储密码不是一个好的选择：

在 Spring 上下文（Java 应用程序）初始化期间我需要大部分数据，并且我不想构建用于连接单个数据库的脚手架，然后连接到其余数据库并初始化应用程序的其余部分
一些密码仅与部署相关；访问不同服务器、密钥库等的密码；这些是应用程序启动后无法加载的东西，因为它根本不加载它

我正在考虑将部署配置从开发人员机器转移到专用计算机，该计算机从版本控制中检查代码并运行构建/部署脚本，但我不确定什么是最好的方法。

我还需要说，我不想要最终的安全性：我只想避免在每个开发人员的磁盘上都设置密码并使其过于简单。

所以我在问你的经验/最佳实践。你怎么做呢？

score 10 · Accepted Answer

例如，我倾向于将特定于环境的配置属性放入不在源代码管理中且不属于构建过程的属性文件中。在设置新环境时，该设置的一部分是创建包含数据库地址、凭据和名称、相关远程主机名称等内容的属性文件。

在 Spring 中，您使用PropertyPlaceholderConfigurer加载属性文件。它只需要 Spring 可以找到，这通常意味着将它放在应用程序服务器下的适当目录中。

或者，您使用wrapper来运行应用程序服务器，并且 JVM 启动选项包括将这些属性文件添加到类路径中，以便 Spring 可以找到它们。

score 7 · Accepted Answer

我已经看到了两种方法：

score 3 · Accepted Answer

这并非在所有情况下都有效，但这就是使用 NT AUTHORITY\NETWORK SERVICE 作为服务标识的光荣之处。如果使用此标识，则无需为其维护密码——您可以只使用 DOMAINNAME\MACHINENAME$ 形式的计算机的 AD 凭据来访问受保护的网络和数据库。

当然，有一些关键的事情需要注意——其中最重要的是没有两个共享安全边界的应用程序像这样托管在同一台服务器上。

score 0 · Accepted Answer

将密码放在 o/s 用户环境变量中。

只有该用户或 root 可以读取该值，与文件相同，但将其签入源代码控制的可能性为零。

score 0 · Accepted Answer

我认为在存储库之外有一个local_settings很好。

score 0 · Accepted Answer

您可以以加密形式存储它们，而不是不存储它们。因此，您不必在新开发人员开始时一直通过 IM 或电子邮件发送凭据文件的痛苦……您只需告诉他们一次项目特定的主密码，以便他们可以加密凭据。

6 回答 6