保持秘密不受源代码控制-我们只是在解决问题吗？

我继承了一些项目，其中秘密位于App.config和类似文件的源代码控制中。幸运的是，它不是公共存储库，因此风险并不像以前那样严重。我正在寻找更好的方法来管理此问题，例如Azure KeyVault。（但我不希望这个问题专门针对该解决方案。）

总的来说，我们不只是解决问题吗？例如，使用Azure KeyVault，应用程序ID和应用程序秘密成为您不受源代码控制的事情。这是一个不幸的典型例子，说明这种情况容易出错。其他方法最终都变得相似，其中包含您必须保护的API密钥或密钥库文件。

在我看来，像Azure KeyVault这样的产品没有比将您的秘密保存在单独的配置文件中并确保它位于您的.gitignore或等效文件中更好，并且毫无意义地更复杂。该文件必须根据需要通过边信道共享。当然，人们可能会不安全地将其通过电子邮件相互发送给对方...

有没有一种方法可以管理秘密，而不仅仅是解决问题？我相信这个问题有一个明确定义的答案。以此类推，如果我要问HTTPS不仅能解决问题，答案是CA密钥随您的OS一起分发，而我们信任它们是因为我们信任OS的分发方法。（我们是否应该单独提出一个问题...）

您可能会说您只是在解决问题。最终，必须有一个秘密存储在您的应用程序可以访问的位置，以便拥有密码，ssh密钥等。

但是，如果做得正确，您会将问题从难以正确解决的地方转移到可以更好地防御的地方。例如，在公开的github仓库中存储秘密非常类似于将房门钥匙粘贴在前门上。任何想要他们的人都不会遇到麻烦。但是，如果您转到内部网络上的密钥库，而没有外部连接，则可以更好地保护密码。这更像是将钥匙放在口袋里。丢失它们不是不可能的（例如，相当于提供您的Azure密码），但是它限制了您的曝光度，而不是敲击门上的钥匙。

出于某些原因，不应将加密密钥和凭据之类的机密检查到源代码管理中。首先显然是加密密钥和凭据应始终基于需要了解，并且源代码管理不是防止信息泄露的可靠方法。您不希望在源代码管理中获得此类机密的另一个原因通常是因为机密通常（但并非总是）特定于您的应用程序将在其中运行的环境的特定属性。（例如，获取私钥以创建数字Web服务授权所需的签名），该Web服务的特定端点可能正在需要QA签名的QA环境中运行。

处理环境（或全球机密）的正确方法是像对待其他任何环境配置属性一样对待它，并带有附加的安全控制措施。一个设计良好，独立且可版本控制的代码模块在所有环境中都应该相同，从而可以部署它们的环境来通知应用程序其属性（例如，数据库连接详细信息，凭据，Web服务端点，文件路径等）。对应用程序至关重要的配置详细信息已被外部化，并成为环境的配置参数。

现在来解决您的一些争论：

总的来说，我们不只是解决问题吗？

没有完美的安全性，但是将问题“转移”到可以放置其他措施和控制措施的区域将提高难度，并减少意外或恶意泄露机密的可能性。在设计必须保护机密数据的系统时，要遵循的一个好的经验法则是，始终将控件置于一体。我的意思是，要确保发生机密信息或安全事件的意外或恶意泄露，那么必须有故障或两个或多个控制措施。

一个很好的例子是将加密文件存储在服务器上。我还有一个秘密解密密钥，必须将其保密在另一个文件中。

• 将密钥和加密文件存储在同一服务器上（0控制，任何有权访问该服务器的人都可以轻松获取机密信息）
• 执行上述步骤并保护文件对两个文件的访问，以使其只能由OS的应用程序运行时用户读取（1控件，损害root用户或应用程序运行时用户的密码将使攻击者获得机密信息）
• 将密钥存储在外部密钥库中，并通过多种安全措施来获取密钥，例如IP地址白名单，证书身份验证以及其他可以访问其文件系统上加密文件的应用程序的措施。（多个控件，安全控件的多个故障必须发生，才能破坏机密数据）

再次，没有完美的安全性，但是拥有多个控件的目标确保了发生多个错误才能进行公开。

在我看来，Azure KeyVault之类的产品并没有更好，更复杂的东西，

复杂的是，毫无意义是完全主观的。在没有现实地考虑到暴露机密数据的严重性的情况下，我们无法就附加安全性的无意义进行讨论。如果人们可以使用机密数据将非法电汇转出您的金融机构，那么像金库这样的东西就是毫无意义的。

而不是将机密信息保存在单独的配置文件中，并确保其位于您的.gitignore或等效文件中。

直到有人不小心将其检查到源代码管理中，现在机密永远被嵌入到源代码管理历史记录中。

当然，人们可能会不安全地将其通过电子邮件相互发送给对方...

安全不仅是技术问题，还是人的问题。那将是无关紧要的，但是我觉得此时您正试图说服自己摆脱需要做的事情。

有没有一种方法可以管理秘密，而不仅仅是解决问题？我相信这个问题有一个明确定义的答案。以此类推，如果我要问HTTPS不仅能解决问题，答案是CA密钥随您的OS一起分发，而我们信任它们是因为我们信任OS的分发方法。

安全性并不能总是使问题消失，而是在很多时候将控制权置于问题周围。您的类推是简洁的，因为实际上这正是公私钥加密的作用。我们通过向我们的CA赋予未减轻的，完全的信任来保证CA拥有公共证书的实体的身份，从而将问题“移交给CA”。基本上，只要发生灾难性的一系列失败（例如，失去对CA的信任）就不会导致安全问题。

与很多事情一样，安全性是您必须基于主观标准，数据的性质，披露的后果，风险偏好，预算等来划分的界线。

值得考虑使用git secret项目（http://git-secret.io/），以使git repo中的秘密文件使用非对称密钥进行加密。公钥也在存储库中，私钥不在。

这种方法的特点是：

• 当新用户/机器需要解密安全​​文件时，他会发布/发送他的公共gpg（gnu隐私卫士又名pgp）密钥。已经可以解密安全文件的用户可以使用新的附加密钥对其进行重新加密-在该新用户可以使用其私钥对安全文件进行解密之后。
• 显然，您需要控制哪些人可以提交/推送到git存储库。否则，攻击者可以提交自己的公共密钥，并等待，直到获得授权的人员将使用此新的已泄露的公共密钥重新加密受保护的文件。