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