使用证书保护 Desired State Configuration 中的凭据

Question

我是 DSC 的新手，并试图弄清楚如何让它为我们工作。

我所坚持的是凭据实际上是如何受到保护的。我目前的理解是，它并不是那么好。

三大问题就是这些。使用公钥作为解密源如何真正保护这些凭据？推拉场景下哪些电脑需要证书？鉴于这些问题，处理凭证的最佳做法是什么？

使用证书的公钥有利于验证传输的来源。但是使用它作为解密密钥意味着对证书公钥的访问决定了对密码的访问。

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

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

Answer 1

基本理念

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 环境中使用企业 PKI，很有可能每台机器都设置为向 CA 自动注册，因此它已经有一个特定于机器的证书，可以自行更新。它具有用于此目的的必要设置。

我是如何实现的

由于目前 DSC 的工具非常简单，因此您很可能会创建自己的工作流程来生成配置并编写脚本来提供帮助。

在我的例子中，我有单独的脚本来生成 LCM 元 MOF 和生成节点的实际配置，所以我保护凭据的步骤在两者之间分开。

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

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

参考

我在上面引用了我自己的经验，但这篇文章对这个过程有很大帮​​助：https : //devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state-配置

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

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