使用 WinRM 進行 PowerShell 遠端處理的安全性考慮
PowerShell 遠端處理是管理 Windows 系統的建議方式。 根據預設，Windows Server 2012 R2 和更新版本會啟用 PowerShell 遠端處理。 本文件涵蓋使用 PowerShell 遠端處理時的安全性考慮、建議和最佳做法。
什麼是 PowerShell 遠端操控？
PowerShell 遠端處理會使用 Windows 遠端管理 （WinRM），讓使用者在遠端電腦上執行 PowerShell 命令。 WinRM 是 Web Services for ManagementWS-Management 通訊協定的Microsoft實作。 您可以在 執行遠端命令找到有關使用 PowerShell 遠端處理的更多資訊。
PowerShell 遠端並不等同於使用 Cmdlet 指令的 ComputerName 參數來在遠端電腦上執行，因為後者使用遠端過程調用（RPC）作為其基礎通訊協定。
PowerShell 遠端處理預設設定
使用 WinRM 的 PowerShell 遠端功能會接聽下列端口：
- HTTP：5985
- HTTPS：5986
根據預設，PowerShell 遠端處理只允許來自 Administrators 群組成員的連線。 會話會在使用者的內容下啟動，因此套用至個別使用者和群組的所有操作系統訪問控制都會在透過PowerShell遠端連線時繼續套用至它們。
在私人網路上，PowerShell 遠端處理的預設 Windows 防火牆規則會接受所有連線。 在公用網路上，預設的 Windows 防火牆規則只允許來自相同子網內的 PowerShell 遠端連線。 您必須明確變更該規則，才能在公用網路上開啟所有連線的 PowerShell 遠端處理。
警告
公用網路的防火牆規則是為了保護電腦免於可能的外部惡意連線嘗試。 拿掉此規則時請小心。
進程隔離
PowerShell 遠端處理會使用 WinRM 進行電腦之間的通訊。 WinRM 會在 Network Service 帳戶下以服務的形式執行，並產生以使用者帳戶身分執行的隔離進程，以裝載 PowerShell 執行個體。 以一位使用者身分執行的 PowerShell 實例，無法存取以其他使用者身分執行 PowerShell 實例的進程。
由 PowerShell 遠端產生的事件記錄
Mandiant 的研究人員在 BlackHat 會議上發表了一個演講，提供了 PowerShell 遠端會話所產生的事件記錄檔和其他安全證據的良好摘要。 如需詳細資訊，請參閱 調查 PowerShell 攻擊。
加密和傳輸通訊協定
考慮 PowerShell 遠端連線的安全性時，從初始驗證和進行中的通訊兩個觀點來看，這樣做頗有幫助。
不論所使用的傳輸通訊協議為何（HTTP 或 HTTPS），WinRM 一律會在初始驗證之後加密所有 PowerShell 遠端通訊。
初始驗證
驗證會確認用戶端對伺服器的身分識別，而理想情況下，也會確認伺服器對用戶端的身分識別。
當用戶端使用電腦名稱連線到網域伺服器時，預設驗證通訊協定會 Kerberos。 Kerberos 可保證使用者身分識別和伺服器身分識別，而不會傳送任何類型的可重複使用認證。
當用戶端使用其IP位址連線到網域伺服器，或連線到工作組伺服器時，就無法進行 Kerberos 驗證。 在這種情況下，PowerShell 遠端處理會依賴 NTLM 通訊協定驗證。 NTLM 驗證通訊協定可保證使用者身分識別，而不會傳送任何類型的可委派認證。 為了證明使用者身分識別，NTLM 通訊協定要求用戶端和伺服器都會從使用者的密碼計算會話密鑰，而不需要交換密碼本身。 伺服器通常不知道用戶的密碼，因此它會與域控制器通訊，該域控制器知道用戶的密碼，並計算伺服器的會話密鑰。
不過，NTLM 通訊協定並不保證伺服器身分識別。 如同使用NTLM進行驗證的所有通訊協定，具有已加入網域電腦之計算機帳戶存取權的攻擊者可能會叫用域控制器來計算NTLM會話密鑰並模擬伺服器。
預設會停用NTLM型驗證。 您可以在目標伺服器上設定 SSL，或在用戶端上設定 WinRM TrustedHosts 設定，以啟用 NTLM。
使用 SSL 憑證在 NTLM 型連線期間驗證伺服器身分識別
由於 NTLM 驗證通訊協定無法確保目標伺服器的身分識別（僅知道密碼），因此您可以將目標伺服器設定為使用 SSL 進行 PowerShell 遠端處理。 將 SSL 憑證指派給目標伺服器（如果由用戶端也信任的證書頒發機構單位簽發），可啟用 NTLM 型驗證，保證使用者身分識別和伺服器身分識別。
忽略以 NTLM 為基礎的伺服器身分識別錯誤
如果無法將 SSL 憑證部署到 NTLM 連線的伺服器，您可以將伺服器新增至 WinRM TrustedHosts 列表，以隱藏產生的身分識別錯誤。 將伺服器名稱新增至 TrustedHosts 清單不應視為主機本身可信任的任何形式語句，因為 NTLM 驗證通訊協定無法保證您實際上連線到您想要連線的主機。 相反地，您應該將 TrustedHosts 設定視為您想要隱藏無法驗證伺服器身分識別所產生的錯誤主機清單。
持續進行的通訊
初始驗證完成後，WinRM 會加密進行中的通訊。 當您透過 HTTPS 連線時，WinRM 會使用 TLS 通訊協定來交涉用來傳輸資料的加密。 當您透過 HTTP 連線時，WinRM 會使用初始驗證通訊協定交涉的訊息層級加密。
- 基本身份驗證不提供加密。
- NTLM 驗證會使用具有128位金鑰的 RC4 加密。
- TGS 票證中的
etype決定了 Kerberos 驗證加密。 這是新式系統上的 AES-256。 - CredSSP 加密方法會使用交握中協商的 TLS 加密套件。
進行第二個跳躍
根據預設，PowerShell 遠端處理會使用 Kerberos（如果有的話）或 NTLM 進行驗證。 這兩種通訊協議都會向遠端計算機進行驗證，而不會傳送認證給遠端計算機。 這是最安全的驗證方式，但由於遠端計算機沒有用戶的認證，因此無法代表使用者存取其他計算機和服務。 這稱為 第二個躍點問題。
有數種方式可以避免這個問題。 如需這些方法的描述，以及每個方法的優缺點，請參閱 在 PowerShell 遠端處理中建立第二個躍點。
