Cloaking (COM)

發行項
05/12/2022

Cloaking 是 COM 安全性功能，可決定用戶端在模擬期間對伺服器專案的身分識別。設定隱藏時，轉送伺服器會遮罩自己的身分識別，並將用戶端的身分識別呈現給用戶端代表其呼叫的伺服器。基本上，伺服器看到的用戶端身分識別是與 Proxy 相關聯的身分識別。 Proxy 的身分識別是由數個因素所決定，其中一個是設定 (任何) 的檢測類型。 Schannel 安全性提供者不支援遮罩。

下列主題提供有關遮蔽的詳細資訊：

Cloaking 的類型
遮蔽如何影響用戶端身分識別
設定 Cloaking
遮蔽和模擬層級
封閉式案例
相關主題

Cloaking 的類型

有兩種類型的遮罩：靜態遮罩和動態遮罩：

使用靜態遮罩 (EOAC_STATIC_CLOAKING) ，伺服器會看到從用戶端到伺服器的第一次呼叫的執行緒權杖。針對第一次呼叫，如果在呼叫 CoSetProxyBlanket期間先前已設定 Proxy 身分識別，則會使用該 Proxy 身分識別。不過，如果先前未設定 Proxy 身分識別，則會使用執行緒權杖。如果沒有線程權杖存在，則會使用進程權杖。針對所有未來的呼叫，會使用第一次呼叫上設定的身分識別。
使用動態遮罩 (EOAC_DYNAMIC_CLOAKING) 時，如果執行緒權杖) 用來判斷用戶端的身分識別，則每次呼叫目前的執行緒權杖 (。如果沒有線程權杖，則會使用進程權杖。這表示在模擬期間代表用戶端呼叫的伺服器，會看到產生呼叫之 COM 用戶端的身分識別，這通常是所需的行為。 (當然，若要讓模擬成功，用戶端必須已指定伺服器授權單位來模擬，方法是設定適當的模擬層級。如需詳細資訊，請參閱模擬 Levels.) 這種類型的遮蔽相當昂貴。

遮蔽如何影響用戶端身分識別

進行加密呼叫且伺服器要求用戶端識別時，通常會取得系結至 Proxy 的身分識別。 (有時候驗證服務會從實際身分識別執行轉譯，但一般而言，Proxy 身分識別是伺服器看到的身分識別。) Proxy 會將身分識別呈現給取決於所設定和其他因素類型的伺服器。

總而言之，用戶端的身分識別是已設定封鎖旗標、進程權杖、執行緒權杖是否存在，以及先前是否已設定 Proxy 身分識別的函式。下表顯示當這些因素不同時，產生的 Proxy 身分識別 (用戶端身分識別) 。

封閉旗標	執行緒權杖存在	先前設定的 Proxy 身分識別	Proxy 身分識別 (用戶端身分識別)
未設定封閉	不小心	不小心	處理權杖或驗證身分識別
EOAC_STATIC_CLOAKING	存在	否	執行緒權杖
EOAC_STATIC_CLOAKING	存在	是	目前的 Proxy 身分識別
EOAC_STATIC_CLOAKING	不存在	否	處理權杖
EOAC_STATIC_CLOAKING	不存在	是	目前的 Proxy 身分識別
EOAC_DYNAMIC_CLOAKING	存在	不小心	執行緒權杖
EOAC_DYNAMIC_CLOAKING	不存在	不小心	處理權杖

下列流程圖說明如何在不同情況下判斷 Proxy 身分識別。

Diagram that shows the flow for determining the proxy identity.

設定 Cloaking

Cloaking 會在 對 CoInitializeSecurity的呼叫中設定為功能旗標，這會設定整個程式的遮蔽。然後會設定遮罩功能，直到用戶端透過呼叫 IClientSecurity：：SetBlanket (或 CoSetProxyBlanket) 變更，以設定 Proxy 的封鎖。

根據預設，不會設定遮罩。若要加以設定，請將EOAC_STATIC_CLOAKING或EOAC_DYNAMIC_CLOAKING傳遞至CoInitializeSecurity或SetBlanket中的pCapabilities參數。

使用 CoInitializeSecurity啟用靜態遮罩時，每個 Proxy 會在您第一次在 Proxy 上呼叫時， (執行緒或進程) 挑選權杖。使用 SetBlanket啟用靜態遮罩時，Proxy 會在該時間挑選執行緒上的權杖。如果呼叫 SetBlanket 時沒有可用的執行緒權杖，則進程權杖會用於 Proxy 的身分識別。基本上， SetBlanket 會修正 Proxy 的身分識別。

使用動態遮罩時，不論動態遮罩是使用 CoInitializeSecurity 還是 搭配 SetBlanket來設定動態遮罩，Proxy 的身分識別都會以相同方式決定。如果有的話，則會使用目前的執行緒權杖;否則，會使用進程權杖。

如果透過 對 CoInitializeSecurity 的呼叫來設定整個進程的遮罩，而且您想要使用進程權杖進行呼叫，請勿在進行呼叫時模擬。

遮蔽和模擬層級

如先前所述，遮罩功能會決定模擬期間向伺服器呈現的身分識別。 Cloaking 提供一種方式，讓伺服器將本身以外的身分識別投影到另一部代表用戶端呼叫的伺服器。模擬層級表示用戶端已提供多少授權。

模擬而不遮蔽運作，但可能不是最佳選擇，因為在某些情況下，最終伺服器必須知道初始呼叫端的身分識別。若未使用遮蔽，就無法達成此目的，因為很難確保只有授權的用戶端可以存取遠端電腦。在沒有遮蔽的情況下使用模擬時，向下游伺服器呈現的身分識別就是立即呼叫進程的身分識別。

不過，在沒有模擬的情況下，遮蔽並不實用。只有在用戶端已設定模擬或委派的模擬層級時，Cloaking 才有意義。 (使用較低的模擬層級時，伺服器無法進行封閉式呼叫。) 是否成功遮蔽是否成功取決於跨電腦界限數目和模擬層級，這表示伺服器必須代表用戶端採取行動的授權量。

在某些情況下，當用戶端將模擬層級設定為 RPC_C_IMP_LEVEL_IMPERSONATE 時，伺服器就很合理。不過，某些限制已生效。如果原始用戶端將模擬層級設定為RPC_C_IMP_LEVEL_IMPERSONATE，轉送伺服器 (做為相同電腦上的用戶端) 只能跨越一部電腦界限。這是因為模擬層級模擬權杖只能跨一部電腦界限傳遞。跨電腦界限之後，只能存取本機資源。提供給伺服器的身分識別取決於所設定的遮蔽類型。如果未設定任何遮蔽，呈現給伺服器的身分識別將會是進行立即呼叫的進程。

若要遮蔽多個電腦界限，您必須同時指定適當的遮罩功能旗標和委派層級模擬。透過這種類型的模擬，用戶端的本機和網路認證都會提供給伺服器，因此模擬權杖可以跨越任意數目的電腦界限。同樣地，呈現給伺服器的身分識別取決於所設定的遮蔽類型。如果未使用委派層級模擬來設定任何遮罩，則呈現給伺服器的身分識別就是進行呼叫的進程。

例如，假設進程 A 會呼叫 B，而 B 呼叫 C。B 已設定遮蔽，而 A 已將模擬層級設定為模擬。如果 A、B 和 C 位於同一部電腦上，則將模擬權杖從 A 傳遞至 B，然後傳遞至 C 即可運作。但是，如果 A 和 C 位於同一部電腦上，且 B 不是，則傳遞權杖會在 A 與 B 之間運作，但無法從 B 傳送至 C。從 B 到 C 的呼叫將會失敗，因為 B 在遮蔽時無法呼叫 C。不過，如果 A 將模擬層級設定為委派，則可以將權杖從 B 傳遞至 C，而且呼叫可能會成功。