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

| 我在这里看到了相关的问题,但是它们似乎并不能完全满足我的需求。 我们使用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中(运行于TeamCity将触发部署且访问受限的VM中)(如在VM中)可以解密密码吗?在密码学和其他方面并不是很强,但是这听起来像是要走的路吗?还有其他建议吗?人们如何处理这种自动化部署? 更新: 好的,我已经执行了它。我已经用C#编写了一个使用密码术库的控制台应用程序。该应用程序生成密钥:
RSACryptoServiceProvider rsa = GetRsa(containerName);
File.WriteAllText(\"keys.kez\",rsa.ToXmlString(true));
我也拿出了公钥:
File.WriteAllText(\"public.pke\", rsa.ToXmlString(false));
将公用密钥提供给任何必须加密密码并要求他们在配置中输入密码的人。将keys.kez文件放入必须运行部署的任何代理中。     
已邀请:
从安全性和简便性的角度来看,非对称加密绝对是赢家。我已经非常成功地以这种方式部署了生产型SaaS应用程序。 有一些技巧。正如您提到的那样,请确保将公钥/私钥对安装在主机上,而不是存储在配置文件或代码中。第二,假设MS提供的管理和密钥生成工具薄弱至可怕,并据此计划(我们为操作在部署期间运行创建了一个简单的keygen exe)。     
并不是真正的答案,而是建议或其他问题。 为什么不将密码存储在配置文件中的加密字符串中
$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
您可以用
read-host -assecurestring
代替
$credential.Password
    
正如您在问题中所说的那样,您的密码以纯文本格式保存在配置文件的PROD中。加密没有任何帮助。另外,这是一个恶性循环-您将如何保护加密密钥? 这里的主要思想是查看组织的实际情况以及部署时遵循的业务流程类型。 让我通过一个例子对此进行解释。假设PROD的部署是由基础架构团队执行的。该团队可以访问您的配置中所需的密码。出于安全原因,他们绝不会向您(部署开发人员)透露此密码。您要避免他们在每次安装过程中输入密码。想一想,这是您可以做的最好的事情。他们将必须至少输入一次密码。 加密解决方案在这里无法真正使用,因为您的部署程序包仍然需要一种方法来解密密码,并且如果无需用户输入就可以解密密码,您(开发人员)也可以这样做,这是不可接受的。 由于无论如何该密码都是以纯文本格式存储在PROD配置文件中的,因此仅在不知道时才让部署程序包提示输入密码。基础结构团队成员提供密码后,将其保存在本地文件中。更好的是,将其保存在机器范围的密钥容器中。您不需要密码。密钥周围的下一次安装将是已知的,并且您的安装无需再次提示输入密钥。当然,如果需要,您还需要提供一种更改存储密钥的方法。 您所描述的标记化方法有效。我已经相当成功地完成了这一工作。 (即已通过外部安全性审查)由于您在PROD中确实有纯文本密码,因此必须将PROD视为安全(安全)环境。而且由于它是安全的,因此在其中缓存(存储副本)该安全密码没有任何问题。     
无论您使用非对称加密还是对称加密,都需要将解密密钥保留在代码中,以便将安全风险从配置文件转移到可执行文件(代理)上。就混淆而言,它要好得多,但是可以想象,可执行文件可以由足够确定要提取解密密钥的人员进行反向工程。     
如何创建计划的作业以运行部署脚本?将任务设置为使用特定的用户帐户运行,并授予该帐户相关的权限。     
一个有趣的问题是,我也在多个环境中工作,并且面临着针对不同环境进行不同设置的挑战。不过,我们实际上并没有在配置中输入密码(受感染的计算机或工程师的错误等)。如果这样做是针对不安全的东西,则我们将其保留为纯文本。 考虑到这一点,构建机器是否可能没有每个环境的密码列表? 如果您不想保留纯文本格式,则可以使用PowerShell进行某些操作-我确定Jaykul曾经在这种方式上发表过一篇文章,但当我(快速)谷歌搜索仅从Halr返回了一些内容时(两者是PowerShell MVP,因此应该很有趣)。 http://halr9000.com/article/531     

要回复问题请先登录注册