RPC über HTTP-Sicherheit

RPC über HTTP bietet zusätzlich zur standardmäßigen RPC-Sicherheit drei Arten von Sicherheit, was dazu führt, dass RPC über HTTP-Datenverkehr einmal durch RPC geschützt wird, und dann doubly durch den Tunnelingmechanismus geschützt wird, der von RPC über HTTP bereitgestellt wird. Eine Beschreibung der standardmäßigen RPC-Sicherheitsmechanismen finden Sie unter Security. Der RPC-über-HTTP-Tunnelingmechanismus fügt der normalen RPC-Sicherheit auf folgende Weise hinzu:

• Bietet Sicherheit über IIS (nur für RPC über HTTP v2 verfügbar).
• Stellt SSL-Verschlüsselung und RPC-Proxyüberprüfung (gegenseitige Authentifizierung) bereit. Auch nur in RPC über HTTP v2 verfügbar.
• Enthält Einschränkungen für das Diktieren der RPC-Proxyebene, welche Computer im Servernetzwerk RPC über HTTP-Aufrufe empfangen dürfen.

Jede dieser drei Sicherheitsfeatures wird in den folgenden Abschnitten ausführlicher beschrieben.

IIS-Authentifizierung

RPC über HTTP kann den normalen Authentifizierungsmechanismus von IIS nutzen. Das virtuelle Verzeichnis für RPC-Proxy kann mithilfe des Rpc-Knotens unter der Standardwebsite im IIS MMC-Snap-In konfiguriert werden:

IIS kann so konfiguriert werden, dass anonymer Zugriff deaktiviert wird und eine Authentifizierung für das virtuelle Verzeichnis für den RPC-Proxy erforderlich ist. Klicken Sie dazu mit der rechten Maustaste auf den Rpc-Knoten, und wählen Sie Eigenschaftenaus. Wählen Sie die Registerkarte Verzeichnissicherheit aus, und klicken Sie auf die Schaltfläche Bearbeiten in der Gruppe Authentifizierung und Zugriffssteuerung, wie hier gezeigt:

Obwohl Sie RPC über HTTP verwenden können, auch wenn das virtuelle RPC-Proxyverzeichnis anonymen Zugriff zulässt, empfiehlt Microsoft aus Sicherheitsgründen dringend, anonymen Zugriff auf dieses virtuelle Verzeichnis zu deaktivieren. Für RPC über HTTP aktivieren Sie stattdessen die Standardauthentifizierung, die integrierte Windows-Authentifizierung oder beides. Denken Sie daran, dass nur RPC über HTTP v2 in der Lage ist, sich bei RPC-Proxy zu authentifizieren, der die standard- oder windows-integrierte Authentifizierung erfordert; RPC über HTTP v1 kann keine Verbindung herstellen, wenn anonymen Zugriff nicht zulassen deaktiviert ist. Da RPC über HTTP v2 die sicherere und robustere Implementierung ist, wird die Sicherheit Ihrer Installationen mit einer Version von Windows verbessert, die sie unterstützt.

Datenverkehrsverschlüsselung

RPC über HTTP kann Datenverkehr zwischen dem RPC-über-HTTP-Client und dem RPC-Proxy mit SSL verschlüsseln. Der Datenverkehr zwischen dem RPC-Proxy und dem RPC-über-HTTP-Server wird mit normalen RPC-Sicherheitsmechanismen verschlüsselt und verwendet ssl nicht (auch wenn SSL zwischen dem Client und dem RPC-Proxy ausgewählt wird). Der Grund dafür ist, dass dieser Teil des Datenverkehrs innerhalb des Netzwerks einer Organisation und hinter einer Firewall reist.

Der Datenverkehr zwischen dem RPC-über-HTTP-Client und dem RPC-Proxy, der im Allgemeinen über das Internet übertragen wird, kann zusätzlich zu dem für RPC ausgewählten Verschlüsselungsmechanismus mit SSL verschlüsselt werden. In diesem Fall wird der Datenverkehr im Internetteil der Route doubly verschlüsselt. Das Verschlüsseln des Datenverkehrs über den RPC-Proxy bietet eine sekundäre Verteidigung, falls der RPC-Proxy oder andere Computer im Umkreisnetzwerk kompromittiert werden. Da der RPC-Proxy die sekundäre Verschlüsselungsebene nicht entschlüsseln kann, hat der RPC-Proxy keinen Zugriff auf die gesendeten Daten. Weitere Informationen finden Sie unter RPC über HTTP-Bereitstellungsempfehlungen. SSL-Verschlüsselung ist nur mit RPC über HTTP v2 verfügbar.

Einschränken von RPC über HTTP-Aufrufe auf bestimmte Computer

Die IIS-Sicherheitskonfiguration basiert auf zulässigen Computer- und Portbereichen. Die Funktion zum Verwenden von RPC über HTTP wird durch zwei Registrierungseinträge auf dem Computer gesteuert, auf dem IIS und der RPC-Proxy ausgeführt werden. Der erste Eintrag ist ein Flag, mit dem die RPC-Proxyfunktionalität umgeschaltet wird. Die zweite ist eine optionale Liste von Computern, an die der Proxy RPC-Aufrufe weiterleiten kann.

Standardmäßig kann ein Client, der den RPC-Proxy kontaktiert, um RPC über HTTP-Aufrufe zu tunneln, nicht auf RPC-Serverprozesse zugreifen, mit Ausnahme der RPC-über-HTTP-Serverprozesse, die auf demselben Computer wie der RPC-Proxy ausgeführt werden. Wenn das ENABLED-Flag nicht definiert oder auf einen Nullwert festgelegt ist, deaktiviert IIS den RPC-Proxy. Wenn das ENABLED-Flag definiert und auf einen Wert ungleich Null festgelegt ist, kann ein Client eine Verbindung mit RPC über HTTP-Server auf dem Computer herstellen, auf dem IIS ausgeführt wird. Damit der Client in einen RPC-über-HTTP-Serverprozess auf einem anderen Computer tunneln kann, müssen Sie der IIS-Computerliste der RPC-Über-HTTP-Server einen Registrierungseintrag hinzufügen.

RPC-Server können RPC nicht über HTTP-Aufrufe akzeptieren, es sei denn, sie forderten rpc speziell auf, RPC über HTTP zu überwachen.

Im folgenden Beispiel wird veranschaulicht, wie Sie die Registrierung so konfigurieren, dass Clients eine Verbindung mit Servern über das Internet herstellen können:

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

Der eintrag ValidPorts ist ein REG_SZ Eintrag, der eine Liste von Computern enthält, an die der IIS-RPC-Proxy RPC-Aufrufe weiterleiten darf, und die Ports, die zum Herstellen einer Verbindung mit den RPC-Servern verwendet werden sollen. Der REG_SZ Eintrag hat folgende Form: Rosco:593; Rosco:2000-8000; Data*:4000-8000.

In diesem Beispiel kann IIS RPC über HTTP-Aufrufe an den Server "Rosco" an die Ports 593 und 2000 bis 8000 weiterleiten. Sie kann auch Anrufe an jeden Server senden, dessen Name mit "Data" beginnt. Es wird an den Ports 4000 bis 8000 verbunden. Darüber hinaus führt der RPC-Proxy vor dem Weiterleiten des Datenverkehrs an einen bestimmten Port auf dem RPC-Über-HTTP-Server einen speziellen Paketaustausch durch, und der RPC-Dienst überwacht diesen Port, um zu überprüfen, ob anforderungen über HTTP akzeptiert werden.

Wenn ein RPC-Dienst auf Port 4500 auf dem Server "Data1" lauscht, aber keinen der RpcServerUseProtseq* Funktionen mit ncacn_httpaufgerufen hat, wird die Anforderung abgelehnt. Dieses Verhalten bietet zusätzlichen Schutz für Server, die aufgrund eines Konfigurationsfehlers auf einen geöffneten Port lauschen; es sei denn, der Server hat ausdrücklich angefordert, auf RPC über HTTP zu lauschen, empfängt er keine Anrufe, die von außerhalb der Firewall stammen.

Einträge im ValidPorts- Schlüssel müssen eine genaue Übereinstimmung mit dem RPC-über-HTTP-Server sein, der vom Client angefordert wird (die Groß-/Kleinschreibung wird nicht beachtet). Um die Verarbeitung zu optimieren, führt der RPC-Proxy keine Kanonisierung des Namens durch, der vom RPC-über-HTTP-Client bereitgestellt wird. Wenn der Client daher nach rosco.microsoft.com fragt und in ValidPorts nur Rosco enthalten, stimmt der RPC-Proxy nicht mit den Namen überein, obwohl beide Namen möglicherweise auf denselben Computer verweisen. Wenn die IP-Adresse von Rosco 66.77.88.99 lautet und der Client nach 66.77.88.99 fragt, aber der ValidPorts Schlüssel nur Rosco enthält, lehnt der RPC-Proxy die Verbindung ab. Wenn ein Client den RPC-über-HTTP-Server nach Name oder nach IP-Adresse fragt, fügen Sie beide in den ValidPorts Schlüssel ein.

IIS liest die Enabled und ValidPorts Registrierungseinträge beim Start vor. Darüber hinaus liest RPC über HTTP den Inhalt der ValidPorts Schlüssel ungefähr alle 5 Minuten neu. Wenn der ValidPorts Eintrag geändert wird, werden die Änderungen innerhalb von 5 Minuten implementiert.

RPC über HTTP v1: Der Webdienst muss beendet und neu gestartet werden, indem der Internet Service Manager verwendet wird, um neue Werte in den Registrierungseinträgen zu implementieren.