使用证书保护所需状态配置中的凭据

我是DSC的新手，正在尝试弄清楚如何使它对我们有用。

我所坚持的是如何实际保护凭据。我目前的理解是，这还不是很好。

三大问题是这些。使用公共密钥作为解密源如何真正保护那些凭据？哪些计算机在推和拉方案中需要证书？鉴于这些问题，处理凭证的最佳实践是什么？

使用证书的公共密钥可以很好地验证传输源。但是，将其用作解密密钥意味着对证书公用密钥的访问决定了对密码的访问。

如果必须将证书推送到需要解密MOF文件的每台计算机，那么有什么方法可以阻止普通用户访问证书并能够解密MOF？说活动目录安全性意味着您最好以纯文本形式保留它，而仅依靠AD安全性。

有人可以帮我解决这个问题吗？

基本思想

1. 要配置的主机必须安装证书（带有私钥）。
2. 设置目标节点的本地配置管理器（LCM）时，必须指定该证书的指纹。这告诉LCM将使用哪个本地证书（或更准确地说是哪个证书的私钥）来解密证书。
3. 您的DSC配置必须指向仅包含同一证书的证书（公共密钥）的文件。这是在配置数据中完成的，因此，如果要为每个节点使用相同的配置，则可以为每个节点指定不同的证书。
4. 生成MOF时，生成MOF 的机器会使用公钥来加密凭据。
5. 当目标节点上的LCM从拉取服务器（以MOF格式）检索配置时，它将使用由指纹标识的证书的私钥来解密凭据对象。

详细介绍

公钥不能用于解密，并且您不与配置生成或分发计算机共享私钥。

似乎您正在考虑工作流程，就好像所有证书都使用一个证书一样。您可以这样做，但是我认为每个节点都有自己的密钥对。

我指的是“非管理员用户”，“平均用户”不能导出证书的私钥（除非已授予权限），并且由于您不会随意移动此密钥，因此几乎没有机会它被暴露了。如果用户是管理员，那么他们当然可以访问。

无论是通过未处理的powershell配置还是通过生成的MOF，将纯文本凭据存储在配置中的可能性都更大。如果未加密，则必须确保：

• 配置存储的文件系统/网络共享位置
• 存储生成的MOF的fs / share
• 将MOF存储在拉取服务器上的fs / share
• 确保提取服务器在SSL上运行（无论如何，您都应该这样做）
• 确保在Pull服务器上进行身份验证，否则任何匿名查询都可以使用公开的凭据检索配置。

我认为DSC中的安全凭据相当不错，但是最初要对其进行设置有点麻烦。

AD PKI使这更容易

如果您在AD环境中使用Enterprise PKI，则很有可能会将每台计算机设置为通过CA自动注册，因此它已经具有可以续订的特定于计算机的证书。它具有用于此目的的必要设置。

我如何实施

由于目前DSC尚无此工具，因此您可能会创建自己的工作流以生成配置并编写脚本以提供帮助。

就我而言，我有用于生成LCM meta MOF和用于生成节点的实际配置的单独脚本，因此，保护​​凭据的步骤在这两者之间是分开的。

在LCM生成脚本中，我实际上在CA的域中查询以找到与所配置机器的主机名相对应的证书。我检索证书（CA没有专用密钥，只有公用），并将其保存到路径中以备后用。将元MOF配置为使用证书的指纹。

在节点配置脚本中，我将配置数据设置为使用cert文件（仅再次使用公共密钥）。生成MOF时，将使用该证书对凭据进行加密，并且只能使用特定节点上的私钥对其进行解密。

参考

我在上面引用了我自己的经验，但是本文在此过程中提供了很大帮助：https : //devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state-组态

我必须自己填补一些漏洞。它们显示的示例中要注意的一件事是，它们Thumprint在节点配置中提供了。这对于节点配置不是必需的。他们只是同时生成配置和LCM元配置，并使用配置数据存储指纹以供在那里使用。

最后一段可能令人困惑，但是在本文的上下文中更有意义。如果您不同时生成两个配置，那么它们的示例似乎很奇怪。我测试过了 Thumbprint加密凭据的配置数据中不需要。CertificateFile虽然是必需的，并且必须在配置数据中，所以如果您以前不使用配置数据，那么现在就可以使用。