为什么在版本控制中存储密码是个坏主意？

#1 楼

我的看法是，不将密码存储在Git（或其他版本控制）中是一种惯例。我想一个人可能会决定不以各种结果来强制执行它，但这就是为什么人们普遍不赞成这样做的原因：


Git使您难以从源代码历史记录中删除密码，这可能使人们错误地认为密码已在当前版本中删除。
通过将密码置于源代码管理中，您基本上决定与可以访问存储库的任何人（包括将来的用户）共享密码。这会使在开发人员团队中建立角色（可能具有不同的特权）复杂化。
源代码控制软件往往变得相当复杂，尤其是“多合一”系统。这意味着该系统可能最终会受到威胁，从而导致密码泄漏。
其他开发人员可能不知道密码已存储，并且可能会错误处理存储库-在源代码中包含密钥意味着必须格外小心共享代码时（即使在公司内部；也可能需要加密通道）。

我不能说与infosec相关的每个模式都是好的，但是在破坏它们之前总是一个好方法考虑您的威胁模型和攻击媒介的想法。如果这个特定的密码被泄露，攻击者使用它来危害公司会有多困难？

#2 楼

首先，非安全性原因：

密码更改工作流程

密码更改独立于软件应用程序代码。如果DBA更改了数据库密码，那么开发人员必须更新代码，重新构建并发布到生产环境并尝试安排所有时间是否有意义？密码是运行时配置工件，而不是开发工件。应该通过配置文件，环境变量或您使用的任何配置范型注入它们。

授权范围

通常，版本控制系统提供授权控制，因此只有授权用户才能访问它。但是在存储库中，权限通常是读/写或只读的，或者可能像GitHub提供的那样。您不太可能找到允许开发人员获取源代码而不是密码的安全约束。如果可以克隆存储库，则可以克隆存储库。期。在许多环境中，开发人员无法完全访问生产。有时他们具有对生产数据库的只读访问权限，有时没有访问权限。如果开发人员通常确实具有访问权限，但是您不希望所有实习生，新员工等都具有访问权限，该怎么办？

环境

如果您有多个访问权限，该怎么办？环境，例如开发环境，QA环境，登台和生产？您会将他们的所有密码存储在版本控制中吗？该应用程序如何知道要使用哪个？该应用程序将需要一种了解环境的方法，最终将其作为配置设置。如果可以将环境名称设置为配置设置，则可以将数据库密码设置为配置设置（以及连接字符串，用户名等）。

历史记录

其他人提到过，版本控制旨在保留历史记录。因此，较旧的密码仍然可以检索，这可能不是最好的选择。

妥协

我们有多少次在新闻中看到某些产品的源代码泄露给世界的头条新闻？源代码是版本控制中的任何内容。这可能是不将密码放入版本控制中的首要原因！

但是...

也就是说，密码需要存储在某个地方。上面提到的这些隐患不一定意味着它们根本不应该存储在版本控制中，相反，它们不应该存储在版本控制中的产品源代码存储库中。为配置管理，操作等使用单独的存储库是非常合理的。关键是在安全性凭证方面将操作与开发分开，而不必完全避免版本控制。

此外，对于非生产环境，我存储了外部系统的密码和API密钥默认情况下在产品源代码中的配置文件中。为什么？为了使开发人员在签出代码时不费吹灰之力，他们只需构建并运行它即可，而不必获取额外的配置文件。这些凭证很少更改，不会导致任何商业秘密。但是我永远不会用生产机密来做到这一点。

#3 楼

请记住，必须根据您的用例量身定制建议，这一点始终很重要。例如，美国国家安全局（NSA）为保护他们在下雨天所停留的所有零日时间而采取的安全措施应比为保护猫图片张贴站点上的投票所采取的安全措施严格得多。在一个极端情况下，我可以考虑一个示例，将密码/令牌/等保存在私有git存储库中可能是合理的：

如果该存储库只能由一个人访问并且应用程序不存储任何有价值的信息。

，那就去城镇吧！只需记住@ d33tah在回答中所说的话-从git存储库中清除内容可能非常困难（毕竟，要永久保留所有内容的历史记录），因此，如果您决定继续前进，与更多人合作，但又不想让他们获得对您所有系统的完全访问权限，那么您的头上就会有些头疼。

这就是它的真正含义向下。您的代码存储库在某种程度上是“公共的”，即使仅与协作者共享。仅仅因为您想与某人合作并不意味着要向他们授予对您的基础结构的完全访问权限（实际上，这是将密码/令牌放入代码存储库时发生的情况）。很容易想到“是的，但是我相信与我合作的人！”，但是由于多种原因，这简直就是看待情况的错误方式：


在实际操作中，很大一部分数据泄漏始于内部参与者（合作者，员工）。根据一项研究，大约43％的数据泄露是由内部参与者造成的。其中有一半是故意的，有一半是偶然的。
最后一点很重要，为什么这不仅仅与信任有关。大约20％的数据泄露是偶然的，是内部人员造成的。我很聪明，知道我不够聪明，无法始终保持一切正常。如果我公开我的存储库以为一些有趣的集成工具腾出空间，而忘记了我的证书怎么办？如果我有一个忘记加密的备用硬盘驱动器从办公室走了怎么办？如果我的密码之一泄露了，有人用它来猜测我的git存储库（咳嗽gentoo github存储库咳嗽）的帐户密码怎么办？我可以犯许多偶然的错误，这可能会导致我的git存储库暴露出来，如果发生这种情况，并且我在那里有凭据，并且发现它们的人知道他们在看什么，那么我很可能会被发现。听起来很像，但事实是，这就是违规行为的发生方式。
即使我信任某个人，也不意味着我必须让他们拥有一切使用权[插入俗气的名言，讲述权力如何损坏]。同样，将凭据放入git存储库意味着我有可能将所有基础架构的全部访问权限授予所有协作者。总是有机会您不认识您，也不像您想的那样认识他们，他们可能会决定做不该做的事情。即使您亲自认识并信任每个协作者中的每个人，但这并不意味着他们不会犯上述错误（或我没有提到的无尽选择）中的一些意外释放您的代码。

简而言之，良好的安全性是关于分层防御的。大多数黑客之所以发生，是因为黑客在一个区域发现了弱点，从而使他们可以利用另一区域的弱点，从而导致了其他地方的失败，最终使他们获得了丰厚的回报。确保您的情况有意义的尽可能多的安全保护措施可以确保整个过程的安全。这样，当备份硬盘驱动器走出您的办公室时，您意识到它没有被加密，您不必询问“这是否是有针对性的攻击，现在我是否需要更改我到处都有的每个凭据，因为它们都在备份驱动器上的git存储库中吗？”。同样，根据您的情况，这可能不适用于您，但希望这有助于解释在什么情况下这可能很重要。

#4 楼

将机密（密码，证书，密钥）与源代码分开可以根据不同的策略管理源和机密。就像所有工程师都可以阅读源代码一样，只有直接负责生产服务器的人员才能访问这些机密。

这使开发人员的工作更加轻松，因为他们不受严格的安全策略的约束。保护秘密所需的东西。可以使源代码控制策略更加方便。

#5 楼

与许多其他安全性“最佳做法”一样，此约定是确保不会因不良习惯或例行程序而出错的简便方法。

如果您始终记得自己的敏感密码在您的版本控制系统，以及
如果您从不授予不应访问该存储库密码的人，并且
如果您的存储库按照这些机密要求安全地存储，以及
如果您的部署过程同样也很安全，受到保护并且不受未经授权的人员的侵害，并且
如果您可以确定存储库的所有备份和副本都是...，则可以添加更多特定于上下文的“ if”。

...然后，您可以将密码很好地存储在版本控制系统中。

在大多数情况下，至少其中一个“如果”不完全兼容符合您的条件，或者超出您的控制范围。

例如，在许多设置中，开发人员不应该访问生产数据库。或者将备份系统外包给另一个部门。或将您的构建过程外包到云中。

这就是为什么总的来说，最好不要将密码存储在版本控制系统中，这是确保您不会陷入陷阱的最佳实践。因为你没有考虑他们。与在版本控制下安全存储密码所需满足的一长串条件相比，“ git中没有密码”更容易记住。

#6 楼

其他答案很好，但也要考虑备份问题。如果代码存储库备份不包含有关如何访问服务器或管理员帐户的敏感信息，则可以更灵活地存储代码存储库备份的位置，方式和时间。

从另一个安全性更高专注的角度来看，对于您的业务中不道德的竞争对手而言，仅代码备份可能是一个有趣的目标。根据您的业务，“法治”国家/地区中的大多数竞争对手都不会碰它。具有密码的代码备份将成为对您的用户数据感兴趣或有意勒索您的公司的任何犯罪组织的目标。

使用类似密码时，密码存储库破坏所造成的损失将更大。原因。您是要窃取和发布源代码，还是让所有用户遭受身份盗窃，可能因无法保护其私人数据（考虑GDPR）而面临针对您的潜在诉讼甚至刑事诉讼？

#7 楼

“当我们远离文明生活时，为什么直接将您的钥匙放在您的大门上实际上有那么糟糕？”

因为那些想做坏事的人会很容易做，而且成本很高为他们努力不是太高。随身携带钥匙，不要靠近门。常识。

私人回购？有多少人可以下载它？多少人连接到其计算机？然后...他们都摆脱了危险吗？

#8 楼

它还取决于源代码控制系统。

Git的态度是源代码控制系统应该为您提供可靠的项目历史。拥有一个不错的态度。但是，结果是，如果您将密码签入git，很难将其从存储库中删除。

为此，Perforce具有“ obliterate”命令。如果您签入了密码，或者有人签入了8 GB未压缩的视频文件，或者有人签入了某些侵犯他人版权且永远不应该被签入的第三方代码，或者被解雇了很多色情内容的人，他们上班的最后一天，您可以“抹去”它。它已完全从存储库和历史记录中删除。