使用證書保護 Desired State Configuration 中的憑據
我是 DSC 的新手，並試圖弄清楚如何讓它為我們工作。
我堅持的是如何實際保護憑據。我目前的理解是，它並不是那麼好。
最大的三個問題就是這些。使用公鑰作為解密源如何真正保護這些憑據？推拉場景中哪些電腦需要證書？鑑於這些問題，處理憑證的最佳做法是什麼？
使用證書的公鑰有利於驗證傳輸源。但是將其用作解密密鑰意味著對證書公鑰的訪問決定了對密碼的訪問。
如果您必須將證書推送到需要解密 MOF 文件的每台電腦，那麼有什麼可以阻止普通使用者訪問證書並能夠解密 MOF？說 Active Directory 安全性意味著您最好將其保留為純文字並僅依賴 AD 安全性。
有人可以幫我解決這個問題嗎？
基本理念
- 要配置的主機必須安裝證書（帶有私鑰）。
- 在設置目標節點的本地配置管理器 (LCM) 時，您必須指定該證書的指紋。這告訴 LCM 將使用哪個本地證書（或更準確地說是哪個證書的私鑰）來解密憑證。
- 您的 DSC 配置必須指向僅包含同一證書的證書（公鑰）的文件。這是在配置數據中完成的，因此如果您打算為每個節點使用相同的配置，您可以為每個節點指定不同的證書。
- 生成 MOF 時，生成MOF的機器使用公鑰加密憑證。
- 當目標節點上的 LCM 從拉取伺服器（以 MOF 形式）檢索配置時，它使用由指紋辨識的證書的私鑰來解密憑證對象。
在一些細節
公鑰不能用於解密，並且您沒有與配置生成或分發機器共享私鑰。
聽起來您正在考慮工作流程，就好像所有憑據都使用一個證書一樣。你可以這樣做，但我認為這個想法是每個節點都有自己的密鑰對。
我所說的“普通使用者”是指非管理使用者，無法導出證書的私鑰（除非授予權限），並且由於您不會移動此密鑰，因此幾乎沒有機會它被暴露了。如果使用者是管理員，那麼他們當然可以訪問。
無論是通過未處理的 powershell 配置還是生成的 MOF，都更有可能在配置中儲存純文字憑據。如果它未加密，那麼您必須確保：
- 儲存配置的文件系統/網路共享位置
- 儲存生成的 MOF 的 fs/share
- 您在拉取伺服器上儲存 MOF 的 fs/share
- 確保拉取伺服器通過 SSL 執行（無論如何你都應該這樣做）
- 確保 Pull 伺服器上有身份驗證，否則任何匿名查詢都可以檢索帶有暴露憑據的配置。
我認為 DSC 中的安全憑證做得相當好，但最初設置它有點考驗人。
AD PKI 使這更容易
如果您在 AD 環境中使用 Enterprise 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但是，它是必需的，並且必須在配置數據中，所以如果您之前沒有使用配置數據，那麼您現在就可以了。