共用方式為

RPC over HTTP 部署建議

  • 發行項

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

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

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

  • 使用支援 RPC over HTTP v2 的 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 與 RPC 透過 HTTP 伺服器區隔，並讓 RPC Proxy 位於不受信任的周邊網路中很有意義。 如果 RPC Proxy 位於與 RPC over HTTP Server 相同的電腦上，組織會被迫將所有後端伺服器放入不受信任的周邊網路，這會使不受信任的周邊網路更加困難。 將 RPC Proxy 和 RPC over HTTP 伺服器的角色分開，可協助組織將機器數目保留在不受信任的周邊網路管理中，因此更安全。
  • 做為伺服器網路的安全融合。 RPC Proxy 是設計為伺服器網路的可消耗性融合，如果 RPC Proxy 發生問題，則只會傳出，進而透過 HTTP 伺服器保護真正的 RPC。 如果本節中概述的最佳做法到目前為止已遵循，除了 SSL 之外，RPC over HTTP 流量也會使用 RPC 加密進行加密。 RPC 加密本身位於客戶端與伺服器之間，而不是在用戶端與 Proxy 之間。 這表示 Proxy 無法瞭解且無法解密它收到的 RPC 流量。 它只會瞭解由處理連線建立、流量控制和其他通道詳細數據的用戶端傳送給它的一些控制順序。 它無法存取 RPC over HTTP 用戶端傳送至伺服器的數據。 此外，RPC over HTTP 用戶端必須獨立驗證 RPC Proxy 和 RPC over HTTP 伺服器。 這可提供深度防禦。 如果 RPC Proxy 計算機因為某些設定錯誤或某種安全性缺口而遭到入侵，則通過它的數據仍會受到竄改。 可以控制 RPC Proxy 的攻擊者最多可以中斷流量，但無法讀取或竄改。 這是 RPC Proxy 的融合角色作用所在，不需要透過 HTTP 流量遭到入侵的 RPC 安全性即可使用。
  • 在 Web 伺服器陣列中執行 RPC Proxy 的多部機器之間散發部分存取檢查和解密工作。 透過在 Web 伺服器陣列中運作良好，RPC Proxy 可讓組織卸除 SSL 解密和部分存取檢查，從而釋放後端伺服器上的更多容量進行處理。 使用 RPC Proxy 機器的 Web 伺服器陣列，也可讓組織藉由增加前端伺服器上的容量，提高其抵禦阻斷服務攻擊的能力。

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

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