处理生产配置中的密码以进行自动化部署

Question

我在这里看到了相关问题，但它们似乎并没有完全回答我所需要的。

我们使用 Powershell 脚本来部署我们的应用程序，大多数环境（UAT 等）的配置文件中的密码等信息都是纯文本形式。这不是一个大问题，但是当涉及到 PREPROD 和 PROD 时，这是一个大问题。因此，我们在配置中有一些标记，例如“{{prompt-password}}”，它将提供一个登录对话框（Get-Credential），并且执行部署的人员可以输入凭据，部署将继续。

但这对于自动化部署并没有真正的帮助（意味着通过 TeamCity 等工具进行一键部署）

我是否应该采用非对称加密（ http://msdn.microsoft.com/en-us/library/as0w18af.aspx )，其中密码使用公钥加密，输入在配置中，并存储私钥（如此处所述 http://msdn .microsoft.com/en-us/library/tswxhw92.aspx ）在运行自动化部署，它可以解密密码吗？对密码学之类的东西不是很了解，但这听起来像是正确的方法吗？还有其他建议吗？人们如何处理这种自动化部署？

---

更新：

好的，我已经实施了。我用 C# 编写了一个控制台应用程序，它使用密码学库。该应用程序生成密钥：

RSACryptoServiceProvider rsa = GetRsa(containerName);
File.WriteAllText("keys.kez",rsa.ToXmlString(true));

我还获取了公钥：

File.WriteAllText("public.pke", rsa.ToXmlString(false));

将公钥提供给必须加密密码的任何人，并要求他们在配置中输入密码。将keys.kez 文件放入任何必须运行部署的代理中。

Answer 1

从安全性和简单性的角度来看，非对称加密绝对是赢家。我已经以这种方式非常成功地部署了生产 SaaS 应用程序。

有一些技巧。一，正如您提到的，确保公钥/私钥对安装在主机上，而不是存储在配置文件或代码中。第二，假设 MS 提供的管理和密钥生成工具很弱甚至很糟糕，并相应地进行计划（我们为操作创建了一个简单的 keygen exe，以便在部署期间运行。）

Answer 2

并不是真正的答案，而是建议或其他问题。

为什么不将密码存储在配置文件中的加密字符串中

$credential.Password | ConvertFrom-SecureString | Set-Content c:\temp\password.txt

据我了解文档，使用相同凭据运行的进程可以取回密码

$password = Get-Content c:\temp\password.txt | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential `
         "username",$password

您可以将 $credential.Password 替换为 <代码>读取主机-assecurestring

Answer 3

正如您在问题中所说，您的密码以纯文本形式保存在配置文件的 PROD 中。再多的加密也无济于事。此外，这是一种恶性循环 - 您将如何保护加密密钥？

这里的关键是考虑什么是实用的，以及您的组织在部署时遵循哪种业务工作流程。

让我用一个例子来解释这一点。我们假设到 PROD 的部署是由基础设施团队执行的。该团队有权访问您的配置中所需的密码。出于安全原因，他们绝不会向您（部署开发人员）透露此密码。您希望避免他们在每次安装期间输入密码。想想看，这是你能做的最好的事情了。他们必须至少输入一次密码。

加密解决方案在这里不起作用，因为您的部署包无论如何都需要一种解密密码的方法，并且如果它可以在没有用户输入的情况下解密密码，那么您（开发人员）也可以，这是不可接受的。

由于密码无论如何都以纯文本形式存储在 PROD 配置文件中，因此仅在不知道密码时才让部署包提示输入密码。基础设施团队成员提供密码后，将其保存在本地文件中。更好的是，将其保存在机器范围内的密钥容器中。为此您不需要密码。围绕密钥的下一次安装将是已知的，并且您的安装不需要再次提示输入密钥。当然，如果需要，您也需要提供一种更改存储密钥的方法。

您所描述的标记化方法是有效的。我已经这样做了一段时间，非常成功。 （即通过了外部安全审查）由于您在PROD中确实有纯文本密码，因此PROD必须被视为安全（safe）环境。由于它是安全的，因此在其中缓存（存储其副本）此安全密码没有任何问题。

Answer 4

无论您使用非对称加密还是对称加密，您都需要将解密密钥保留在代码中，以便将安全风险从配置文件转移到可执行文件（代理）。它在混淆方面要好得多，但可以想象，可执行文件可以由有足够决心提取解密密钥的人进行逆向工程。

Answer 5

创建计划作业来运行部署脚本怎么样？设置任务使用特定的用户帐户运行，并授予该帐户相关权限。

Answer 6

一个有趣的问题，我也在多个环境中工作，并且面临着针对不同环境的不同设置的挑战。不过，我们并没有真正将密码放入配置中（机器受到攻击或工程师的错误等......）。如果我们这样做是为了非常不安全的东西，因此我们将它们保留为纯文本。

考虑到这一点，构建机器是否可能没有每个环境的密码列表？

如果你不想将它们保留为纯文本，你也许可以使用 PowerShell 做一些事情 - 我确信 Jaykul 曾以这种方式发表过一篇文章，但我的（快速）谷歌搜索只返回了 Halr 的一些内容（两者都是 PowerShell） MVP，所以这应该很有趣）。

http://halr9000.com/article/531