共用方式為

RPC over HTTP Security

  • 發行項

RPC over HTTP 除了標準 RPC 安全性之外，還提供三種類型的安全性，這會導致 RPC 上的 RPC over HTTP 流量受到 RPC 保護一次，然後由 RPC over HTTP 提供的通道機制雙重保護。 如需標準 RPC 安全性機制的描述，請參閱 安全性 。 RPC over HTTP 通道機制會以下列方式新增至一般 RPC 安全性：

  • 透過 IIS 提供安全性（僅適用于 RPC over HTTP v2）。
  • 提供 SSL 加密和 RPC Proxy 驗證（相互驗證）。 也僅適用于 RPC over HTTP v2。
  • 提供 RPC Proxy 層級的限制，說明伺服器網路上允許哪些電腦透過 HTTP 呼叫接收 RPC。

下列各節將詳細說明這三項安全性功能。

IIS 驗證

RPC over HTTP 可以利用 IIS 的一般驗證機制。 您可以使用 IIS MMC 嵌入式管理單元中預設網站底下的 Rpc 節點來設定 RPC Proxy 的虛擬目錄：

Screenshot showing the Rpc node under the Default Web Site in the IIS MMC snap-in.

IIS 可以設定為停用匿名存取，並要求對 RPC Proxy 的虛擬目錄進行驗證。 若要這樣做，請以滑鼠右鍵按一下 Rpc 節點，然後選取 [ 屬性 ]。 選取 [ 目錄安全性] 索引標籤，然後按一下 [驗證和存取控制 ] 群組中的 [編輯 ] 按鈕，如下所示：

Screenshot showing the RPC Properties dialog box.

雖然即使 RPC Proxy 虛擬目錄允許匿名存取，Microsoft 仍可透過 HTTP 使用 RPC，但基於安全性考慮，強烈建議停用該虛擬目錄的匿名存取。 相反地，針對 RPC over HTTP 啟用基本驗證、Windows 整合式驗證或兩者。 請記住，只有 RPC over HTTP v2 能夠針對需要基本或 Windows 整合式驗證的 RPC Proxy 進行驗證;如果 停用不允許匿名存取 ，透過 HTTP v1 的 RPC 將無法連線。 由於 RPC over HTTP v2 是更安全且健全的實作，因此使用支援的 Windows 版本可改善安裝的安全性。

注意

根據預設，RPC Proxy 虛擬目錄會標示為允許匿名存取。 不過，透過 HTTP v2 的 RPC Proxy 會拒絕預設未驗證的要求。

 

流量加密

RPC over HTTP 可以加密 RPC over HTTP 用戶端與使用 SSL 的 RPC Proxy 之間的流量。 RPC Proxy 與 RPC over HTTP 伺服器之間的流量會使用一般 RPC 安全性機制加密，而且不會使用 SSL（即使選擇用戶端與 RPC Proxy 之間的 SSL 也一樣）。 這是因為該部分的流量會在組織的網路內和防火牆後方移動。

RPC over HTTP 用戶端與通常透過網際網路傳輸的 RPC Proxy 之間的流量，除了針對 RPC 選擇加密機制之外，還可以使用 SSL 加密。 在此情況下，路由網際網路部分的流量會變成雙重加密。 透過 RPC Proxy 加密流量可提供次要防禦，以防周邊網路中的 RPC Proxy 或其他電腦遭到入侵。 由於 RPC Proxy 無法解密次要加密層，因此 RPC Proxy 無法存取所傳送的資料。 如需詳細資訊， 請參閱 RPC over HTTP Deployment 建議。 SSL 加密僅適用于透過 HTTP v2 的 RPC。

將 RPC 透過 HTTP 通話限制為特定電腦

IIS 安全性設定是以允許的電腦和埠範圍為基礎。 透過 HTTP 使用 RPC 的功能是由執行 IIS 和 RPC Proxy 之電腦上的兩個登錄專案所控制。 第一個專案是切換 RPC Proxy 功能的旗標。 第二個是 Proxy 可以轉送 RPC 呼叫的選擇性電腦清單。

根據預設，與 RPC Proxy 連絡 RPC Proxy 透過 HTTP 呼叫通道 RPC 的用戶端，除了在與 RPC Proxy 相同的電腦上執行的 RPC over HTTP 伺服器進程之外，無法存取任何 RPC 伺服器進程。 如果未定義或將 ENABLED 旗標設定為零值，IIS 會停用 RPC Proxy。 如果已定義 ENABLED 旗標並設定為非零值，用戶端就可以在執行 IIS 的電腦上透過 HTTP 伺服器連線到 RPC。 若要讓用戶端在另一部電腦上透過 HTTP 伺服器進程通道傳送至 RPC，您必須將登錄專案新增至 IIS 電腦的 RPC over HTTP 伺服器清單。

除非 RPC 伺服器特別要求 RPC 透過 HTTP 接聽 RPC，否則無法接受透過 HTTP 的 RPC 呼叫。

下列範例示範如何設定登錄，以允許用戶端連線到網際網路上的伺服器：

HKEY_LOCAL_MACHINE\
   Software\Microsoft\Rpc\RpcProxy\Enabled:REG_DWORD
   Software\Microsoft\Rpc\RpcProxy\ValidPorts:REG_SZ

ValidPorts 專案是一個REG_SZ專案，其中包含允許 IIS RPC Proxy 轉送 RPC 呼叫的電腦清單，以及它應該用來連線到 RPC 伺服器的埠。 REG_SZ專案採用下列形式：Rosco：593;Rosco：2000-8000;Data*：4000-8000。

在此範例中，IIS 可以透過 HTTP 呼叫將 RPC 轉送至埠 593 和 2000 到 8000 的伺服器 「Rosco」。 它也可以傳送呼叫至名稱開頭為 「Data」 的任何伺服器。 它會在埠 4000 到 8000 上連線。 此外，在透過 HTTP 伺服器上將流量轉送至 RPC 上的指定埠之前，RPC Proxy 會與接聽該埠的 RPC 服務執行特殊的封包交換，以確認它願意接受透過 HTTP 的要求。

如需以這些範例設定為基礎的範例，如果 RPC 服務接聽伺服器 「Data1」 上的埠 4500，但沒有呼叫其中 一個 具有 ncacn_HTTP 的 RpcServerUseProtseq* 函式，則會拒絕要求。 此行為為因設定錯誤而接聽已開啟埠的伺服器提供額外的保護;除非伺服器特別要求透過 HTTP 接聽 RPC，否則不會接收源自防火牆外部的呼叫。

ValidPorts 金鑰中的 專案必須與用戶端所要求的 RPC over HTTP 伺服器完全相符（不區分大小寫）。 為了簡化處理，RPC Proxy 不會對 RPC over HTTP 用戶端所提供的名稱執行標準化。 因此，如果用戶端要求 rosco.microsoft.com，而且在 ValidPorts 中 只包含 Rosco，則 RPC Proxy 將不會符合名稱，即使這兩個名稱可能參考相同的電腦也一樣。 此外，如果 Rosco 的 IP 位址是 66.77.88.99，而用戶端會要求 66.77.88.99，但 ValidPorts 金鑰僅包含 Rosco，RPC Proxy 將會拒絕連線。 如果用戶端可能會依名稱或 IP 位址要求 RPC over HTTP 伺服器，請在 ValidPorts 金鑰中 插入這兩者。

注意

雖然 RPC 已啟用 IPv6，但 RPC Proxy 不支援 ValidPorts 金鑰中的 IPv6 位址。 如果使用 IPv6 來連接 RPC Proxy 和透過 HTTP 伺服器的 RPC，則只能使用 DNS 名稱。

 

IIS 會 讀取啟動時的 Enabled 和 ValidPorts 登錄專案。 此外，RPC over HTTP 大約每隔 5 分鐘會重新讀取 ValidPorts 金鑰的內容 。 如果 ValidPorts 專案已變更，則會在 5 分鐘內實作變更。

透過 HTTP v1 的 RPC： WEB 服務必須使用 Internet Service Manager 來停止並重新啟動，才能實作登錄專案中的新值。