RPC over HTTP 部署建議

本節記載最佳做法和建議的部署設定，以在使用 RPC over HTTP 時達到最大安全性和效能。 此處找到的各種設定會根據各種大小、預算和安全性需求，套用不同的組織。 每個設定也提供部署考慮，有助於判斷最適合特定案例的部署考慮。

如需有關大量 RPC over HTTP 案例的資訊，請參閱 Microsoft RPC 負載平衡。

下列建議適用于所有組態：

• 使用支援透過 HTTP v2 之 RPC 的 Windows 版本。
• 將 IIS 放在以 IIS 6.0 模式執行 RPC Proxy 的電腦上。
• 不允許匿名存取 RPC Proxy 虛擬目錄。
• 永遠不要啟用 AllowAnonymous 登錄機碼。
• 讓 RPC over HTTP 用戶端使用 CertificateSubjectField (請參閱 RpcBindingSetAuthInfoEx ，以取得詳細資訊) ，以確認您所連線的 RPC Proxy 是您預期的 RPC Proxy。
• 將 ValidPorts 登錄機碼設定為只包含 RPC over HTTP 用戶端將連線的電腦。
• 請勿在 ValidPorts 金鑰中使用萬用字元;這麼做可以節省時間，但完全未預期的機器也可以符合萬用字元。
• 透過 HTTP 用戶端在 RPC 上使用 SSL。 如果遵循這些章節中所述的指導方針，RPC over HTTP 用戶端將無法在沒有使用 SSL 的情況下連線。
• 除了使用 SSL 之外，將 RPC over HTTP 用戶端設定為使用 RPC 加密。 如果 RPC over HTTP 用戶端無法連線到 KDC，它只能使用 Negotiate 和 NTLM。
• 將用戶端電腦設定為使用 NTLMv2。 將 LMCompatibilityLevel 登錄機碼設定為 2 或更新版本。 如需LMCompatibilityLevel金鑰的詳細資訊，請參閱msdn.microsoft.com。
• 使用上述設定來執行 RPC Proxy 電腦的 Web 服務器陣列。
• 在網際網路與 RPC Proxy 之間部署防火牆。
• 為了達到最佳效能，請將 IIS 設定為傳送短回應，以取得非成功錯誤碼。 由於 IIS 回應的取用者是自動化程式，因此不需要將使用者易記的說明傳送給用戶端;RPC over HTTP 用戶端只會忽略它們。

從安全性、效能和管理性的觀點來看，RPC Proxy 的基本目標如下：

• 提供透過 HTTP 流量進入伺服器網路之 RPC 的單一進入點。 將 RPC 透過 HTTP 流量進入伺服器網路的單一進入點有兩個主要優點。 首先，由於 RPC Proxy 面向網際網路，大部分的組織都會在稱為不受信任的周邊網路的特殊網路中隔離這類電腦，這與一般組織網路不同。 不受信任的周邊網路中的伺服器會非常仔細地管理、設定及監視，以承受來自網際網路的攻擊。 不受信任周邊網路中較少的機器，設定、管理、監視並保護它們安全越容易。 其次，由於已安裝 RPC Proxy 的單一 Web 服務器陣列可以透過位於公司網路上的 HTTP 伺服器服務任意數目的 RPC，因此，透過 HTTP 伺服器分隔 RPC Proxy 與 RPC Proxy 並讓 RPC Proxy 位於不受信任的周邊網路中相當合理。 如果 RPC Proxy 位於與 RPC over HTTP Server 相同的電腦上，組織會強制將其所有後端伺服器放入不受信任的周邊網路，這會使未受信任的周邊網路更安全。 分隔 RPC Proxy 和 RPC over HTTP 伺服器的角色，可協助組織將機器數目保留在可管理的不受信任周邊網路中，因此更安全。
• 做為伺服器網路的安全融合。 RPC Proxy 是設計為伺服器網路的可耗用融合，如果 RPC Proxy 發生錯誤，它只會流出，進而透過 HTTP 伺服器保護真正的 RPC。 如果本節中概述的最佳做法到目前為止已遵循，除了 SSL 之外，也會使用 RPC 加密來加密 RPC over HTTP 流量。 RPC 加密本身位於用戶端與伺服器之間，而不是用戶端與 Proxy 之間。 這表示 Proxy 無法瞭解，而且無法解密它收到的 RPC 流量。 它只會瞭解用戶端處理連線建立、流程式控制制和其他通道詳細資料所傳送的一些控制順序。 它無法存取 RPC over HTTP 用戶端傳送至伺服器的資料。 此外，RPC over HTTP 用戶端必須獨立向 RPC Proxy 和 RPC over HTTP 伺服器進行驗證。 這可提供深度防禦。 如果 RPC Proxy 電腦因為某些設定錯誤或某種安全性缺口而遭到入侵，則通過它的資料仍會受到竄改的安全。 可控制 RPC Proxy 的攻擊者最多可以中斷流量，但無法讀取或竄改它。 這是 RPC Proxy 的 Fuse 角色開始運作的位置，不需要透過 HTTP 流量危害 RPC 的安全性即可使用。
• 在 Web 服務器陣列中執行 RPC Proxy 的多部機器之間散發一些存取檢查和解密工作。 透過在 Web 服務器陣列中正常運作，RPC Proxy 可讓組織卸載 SSL 解密和一些存取檢查，進而釋放後端伺服器上的更多容量進行處理。 使用 RPC Proxy 電腦的 Web 服務器陣列也可讓組織藉由在其前端伺服器上增加容量，來承受拒絕服務 (DoS) 攻擊的能力。

到目前為止所設定的指導方針中，組織仍然有選擇。 每個組織在使用者不便、安全性和成本之間都有選擇和危害：

• 使用基本驗證或 Windows 整合式驗證向 RPC Proxy 進行驗證？ RPC over HTTP 目前僅支援 NTLM – 它不支援 Kerberos。 此外，如果 RPC over HTTP 用戶端與 透過 PRAgma 在 HTTP 標頭中插入 的 RPC Proxy 之間有 HTTP Proxy 或防火牆，NTLM 驗證將無法運作。 在此情況下，組織可以在基本和 NTLM 驗證之間進行選擇。 基本驗證的優點是更快速且更簡單，因此提供較少的拒絕服務攻擊機會。 但 NTLM 更安全。 根據組織的優先順序，它可以選擇 [基本]、[NTLM]，或允許使用者在兩者之間選擇。 如果只選擇其中一個，最好從 RPC Proxy 虛擬目錄關閉另一個目錄，以降低攻擊的風險。
• 針對 RPC Proxy 和 RPC over HTTP Server 使用相同的認證集，或針對每個認證使用不同的認證？ 此決策的取捨是在使用者的便利性和安全性之間。 少數使用者想要輸入多個認證。 不過，如果安全性外泄發生在不受信任的周邊網路中，則具有 RPC Proxy 和 RPC over HTTP Server 的個別認證集可提供額外的保護。 請注意，如果使用個別認證，而其中一組認證是使用者的網域認證，建議您針對 RPC over HTTP Server 使用使用者的網域認證，而不是使用 RPC Proxy。