Cloaking (COM)

  • Artikel

Cloaking ist eine COM-Sicherheitsfunktion, die bestimmt, welche Identität der Client beim Identitätswechsel an den Server projiziert. Wenn das Cloaking festgelegt ist, maskiert der Zwischenserver seine eigene Identität und stellt die Identität des Clients dem Server vor, den er im Auftrag des Clients aufruft. Im grunde; Die Clientidentität, die vom Server angezeigt wird, ist die identität, die dem Proxy zugeordnet ist. Die Identität des Proxys wird durch mehrere Faktoren bestimmt, von denen einer die Art der Cloaking ist, die (falls vorhanden) festgelegt wird. Das Cloaking wird vom Sicherheitsanbieter Schannel nicht unterstützt.

Die folgenden Themen enthalten weitere Informationen zum Cloaking:

Arten von Cloaking

Es gibt zwei Arten von Cloaking: statisches Ummanteln und dynamisches Ummanteln:

  • Bei statischem Cloaking (EOAC_STATIC_CLOAKING) sieht der Server das Threadtoken vom ersten Aufruf eines Clients an den Server. Wenn die Proxyidentität beim ersten Aufruf zuvor während eines Aufrufs von CoSetProxyBlanket festgelegt wurde, wird diese Proxyidentität verwendet. Wenn die Proxyidentität jedoch zuvor nicht festgelegt wurde, wird das Threadtoken verwendet. Wenn kein Threadtoken vorhanden ist, wird das Prozesstoken verwendet. Für alle zukünftigen Aufrufe wird die Identität verwendet, die für den ersten Aufruf festgelegt ist.
  • Bei dynamischer Ummantelung (EOAC_DYNAMIC_CLOAKING) wird bei jedem Aufruf das aktuelle Threadtoken (wenn ein Threadtoken vorhanden ist) verwendet, um die Identität des Clients zu bestimmen. Wenn kein Threadtoken vorhanden ist, wird das Prozesstoken verwendet. Dies bedeutet, dass Server, die während des Identitätswechsels im Namen des Clients aufgerufen werden, die Identität des COM-Clients sehen, der den Aufruf ausgelöst hat, was im Allgemeinen das gewünschte Verhalten ist. (Damit der Identitätswechsel erfolgreich ist, muss der Client dem Server die Berechtigung zum Identitätswechsel erteilt haben, indem er eine entsprechende Identitätswechselebene festlegt. Weitere Informationen finden Sie unter Identitätswechselebenen.) Diese Art der Ummantelung ist teuer.

Auswirkungen von Cloaking auf die Clientidentität

Wenn ein verschlüsselter Aufruf erfolgt und der Server den Client nach seiner Identität fragt, erhält er normalerweise die Identität, die an den Proxy gebunden ist. (Manchmal führt der Authentifizierungsdienst eine Übersetzung aus der tatsächlichen Identität durch, aber im Allgemeinen ist die Proxyidentität die Identität, die der Server sieht.) Der Proxy stellt dem Server eine Identität dar, die von der Art der festgelegten Ummantelung und anderen Faktoren abhängt.

Zusammenfassend ist die Identität des Clients eine Funktion des Cloaking-Flags, des Prozesstokens, des Vorhandenseins oder Fehlens eines Threadtokens und der Angabe, ob die Proxyidentität zuvor festgelegt wurde. Die folgende Tabelle zeigt die resultierende Proxyidentität (Clientidentität), wenn diese Faktoren variieren.

Verschließen von Flags Threadtokenpräsenz Proxyidentität zuvor festgelegt Proxyidentität (Clientidentität)
Cloaking nicht festgelegt
 Ist doch egal
 Ist doch egal
 Verarbeiten von Token oder Authentifizierungsidentität
EOAC_STATIC_CLOAKING
 Anzahl
 Nein
 Threadtoken
EOAC_STATIC_CLOAKING
 Anzahl
 Ja
 Aktuelle Proxyidentität
EOAC_STATIC_CLOAKING
 Nicht vorhanden
 Nein
 Token verarbeiten
EOAC_STATIC_CLOAKING
 Nicht vorhanden
 Ja
 Aktuelle Proxyidentität
EOAC_DYNAMIC_CLOAKING
 Anzahl
 Ist doch egal
 Threadtoken
EOAC_DYNAMIC_CLOAKING
 Nicht vorhanden
 Ist doch egal
 Token verarbeiten

Das folgende Flussdiagramm veranschaulicht, wie die Proxyidentität in verschiedenen Situationen bestimmt wird.

Diagramm, das den Ablauf zum Ermitteln der Proxyidentität zeigt.

Festlegen von Cloaking

Cloaking wird als Funktionsflag in einem Aufruf von CoInitializeSecurity festgelegt, wodurch das Cloaking für den gesamten Prozess festgelegt wird. Die Cloaking-Funktion wird dann festgelegt, bis der Client sie durch einen Aufruf von IClientSecurity::SetBlanket (oder CoSetProxyBlanket) ändert, wodurch die Cloaking für den Proxy festgelegt wird.

Standardmäßig ist das Cloaking nicht festgelegt. Übergeben Sie zum Festlegen EOAC_STATIC_CLOAKING oder EOAC_DYNAMIC_CLOAKING an den pCapabilities-Parameter in CoInitializeSecurity oder SetBlanket.

Wenn die statische Ummantelung mithilfe von CoInitializeSecurity aktiviert ist, übernimmt jeder Proxy beim ersten Aufruf des Proxys ein Token (Thread oder Prozess). Wenn die statische Ummantelung mithilfe von SetBlanket aktiviert ist, übernimmt der Proxy das Token im Thread zu diesem Zeitpunkt. Wenn beim Aufruf von SetBlanket kein Threadtoken verfügbar ist, wird das Prozesstoken für die Identität des Proxys verwendet. Grundsätzlich korrigiert SetBlanket die Identität des Proxys.

Beim dynamischen Cloaking wird die Identität des Proxys auf die gleiche Weise bestimmt, unabhängig davon, ob die dynamische Ummantelung mithilfe von CoInitializeSecurity oder mit SetBlanket festgelegt wird. Das aktuelle Threadtoken wird verwendet, wenn es eines gibt. andernfalls wird das Prozesstoken verwendet.

Wenn die Ummantelung für den gesamten Prozess über einen Aufruf von CoInitializeSecurity festgelegt ist und Sie Mit dem Prozesstoken Aufrufe tätigen möchten, sollten Sie beim Tätigen von Anrufen keine Identität annehmen.

Cloaking- und Identitätswechselebenen

Wie bereits erwähnt, bestimmt die Cloaking-Funktion, welche Identität einem Server beim Identitätswechsel angezeigt wird. Das Cloaking bietet eine Möglichkeit für einen Server, eine andere Identität als die eigene auf einen anderen Server zu projizieren, den er im Auftrag des Clients aufruft. Die Identitätswechselebene gibt an, wie viel Autorität der Client dem Server erteilt hat.

Der Identitätswechsel ohne Verhüllen funktioniert, ist aber möglicherweise nicht die beste Wahl, da in einigen Fällen der endgültige Server die Identität des ersten Aufrufers kennen muss. Dies kann nicht ohne Cloaking erreicht werden, da es schwierig ist, sicherzustellen, dass nur autorisierte Clients auf einen Remotecomputer zugreifen können. Wenn der Identitätswechsel ohne Tarnung verwendet wird, ist die Identität, die einem Downstreamserver angezeigt wird, die Identität des sofort aufrufenden Prozesses.

Das Ummanteln ist jedoch ohne Identitätswechsel nicht sinnvoll. Das Cloaking ist nur sinnvoll, wenn der Client eine Identitätswechselebene für Identitätswechsel oder Delegat festgelegt hat. (Bei niedrigeren Identitätswechselebenen kann der Server keine verhüllten Aufrufe tätigen.) Ob das Cloaking erfolgreich ist, hängt von der Anzahl der überschrittenen Computergrenzen und von der Identitätswechselebene ab, die angibt, wie viel Autorität der Server hat, um im Auftrag des Clients zu handeln.

In einigen Situationen ist es sinnvoll, dass der Server die Tarnung festlegt, wenn der Client die Identitätswechselebene auf RPC_C_IMP_LEVEL_IMPERSONATE festlegt. Es gelten jedoch bestimmte Einschränkungen. Wenn der ursprüngliche Client die Identitätswechselebene auf RPC_C_IMP_LEVEL_IMPERSONATE festlegt, kann der Zwischenserver (der als Client auf demselben Computer fungiert) nur eine Computergrenze überdecken. Dies liegt daran, dass ein Identitätswechseltoken nur über eine Computergrenze übergeben werden kann. Nachdem die Computergrenze überschritten wurde, kann nur auf lokale Ressourcen zugegriffen werden. Die dem Server angezeigte Identität hängt von der Art der festgelegten Ummantelung ab. Wenn kein Cloaking festgelegt ist, ist die Identität, die einem Server angezeigt wird, die Identität des Prozesses, der den sofortigen Aufruf vornimmt.

Um mehrere Computergrenzen zu überschließen, müssen Sie sowohl ein geeignetes Kennzeichen für die Ummantelungsfunktion als auch einen Identitätswechsel auf Delegatebene angeben. Bei dieser Art des Identitätswechsels werden sowohl die lokalen Anmeldeinformationen als auch die Netzwerkanmeldeinformationen des Clients an den Server übergeben, sodass das Identitätswechseltoken eine beliebige Anzahl von Computergrenzen überschreiten kann. Auch hier hängt die dem Server angezeigte Identität von der Art der festgelegten Ummantelung ab. Wenn kein Cloaking mit Identitätswechsel auf Delegatenebene festgelegt wird, ist die Identität, die einem Server angezeigt wird, die Identität des Prozesses, der den Aufruf ausrichtet.

Angenommen, Prozess A ruft B auf, und B aufruft C. B hat cloaking festgelegt, und A hat die Identitätswechselebene auf Identitätswechsel festgelegt. Wenn sich A, B und C auf demselben Computer befinden, funktioniert die Übergabe des Identitätswechseltokens von A an B und dann an C. Wenn sich A und C jedoch auf demselben Computer befinden und B nicht, funktioniert das Übergeben des Tokens zwischen A und B, aber nicht von B nach C. Der Aufruf von B nach C schlägt fehl, da B C während der Mantelung nicht aufrufen kann. Wenn A jedoch die Identitätswechselebene auf Delegat festlegt, kann das Token von B an C übergeben werden, und der Aufruf kann erfolgreich sein.

Tarnungsszenarien

In der folgenden Abbildung ruft Prozess A B auf, ruft C auf, ruft D auf, wenn die Mantelung nicht festgelegt ist. Daher sieht jeder Zwischenprozess die Identität des Prozesses, der ihn aufgerufen hat.

Diagramm, das den Prozess zeigt, wenn das Klonen nicht festgelegt ist.

Bei statischer Ummantelung sieht der Server die Proxyidentität, die während des ersten Aufrufs vom Client an den Server festgelegt wurde. Die folgende Abbildung zeigt ein Beispiel für die Proxyidentität, die während eines Aufrufs von B an C festgelegt wird. Bei einem nachfolgenden Aufruf sieht Prozess D die Identität von B, wenn die statische Ummantelung von B und C festgelegt wird.

Diagramm, das den Prozess zum statischen Ummanteln zeigt.

Beim dynamischen Cloaking basiert die Identität des Aufrufers während des Identitätswechsels auf dem aktuellen Threadtoken, sofern vorhanden. Die folgende Abbildung zeigt die Situation, in der B und C dynamische Mantelung festlegen und D die Identität von A sieht, trotz eines früheren Aufrufs von B nach C.

Diagramm, das den Prozess zum dynamischen Ummanteln zeigt.

Delegierung und Identitätswechsel