我是 DSC 的新手，正在尝试弄清楚如何让它为我们服务。
我困惑的是凭证究竟是如何保护的。我目前的理解是，它并不是那么好。
最大的三个问题是：使用公钥作为解密源如何真正保护这些凭证？在推送和拉取场景中哪些计算机需要证书？鉴于这些问题，处理凭证的最佳实践是什么？
使用证书的公钥可以很好地验证传输源。但将其用作解密密钥意味着访问证书的公钥就决定了访问密码。
如果您必须将证书推送到每台需要解密 MOF 文件的计算机，那么有什么可以阻止普通用户访问证书并解密 MOF 呢？说活动目录安全性意味着您不妨将其保留为纯文本并仅依赖 AD 安全性。
有人能帮助我理解这一点吗？
答案1
基本思想
- 要配置的主机必须安装证书（带有私钥）。
- 设置目标节点的本地配置管理器 (LCM) 时，必须指定该证书的指纹。这会告诉 LCM 将使用哪个本地证书（或更准确地说是哪个证书的私钥）来解密凭据。
- 您的 DSC 配置必须指向仅包含该证书（公钥）的文件。这在配置数据中完成，因此如果您打算对每个节点使用相同的配置，则可以为每个节点指定不同的证书。
- 当 MOF 生成时，公钥被生成 MOF 的机器用来密編凭证。
- 当目标节点上的 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-configuration
我必须自己填补一些漏洞。在他们展示的示例中，需要注意的一点是，他们Thumprint在节点配置中提供了。这对于节点配置来说不是必需的；他们只是同时生成配置和 LCM 元配置，并使用配置数据存储指纹以供在那里使用。
最后一段可能令人困惑，但在本文的上下文中更有意义。如果您不是同时生成两个配置，那么它们的示例看起来很奇怪。我测试了它；Thumbprint在配置数据中加密凭据不是必需的。CertificateFile但是是必需的，并且它必须在配置数据中，因此如果您以前没有使用配置数据，那么您现在会使用。