Empfehlungen zur RPC-über-HTTP-Bereitstellung

In diesem Abschnitt werden bewährte Methoden und empfohlene Bereitstellungskonfigurationen für maximale Sicherheit und Leistung bei Verwendung von RPC über HTTP dokumentiert. Die hier gefundenen Konfigurationen gelten für unterschiedliche Organisationen basierend auf unterschiedlichen Größen-, Budget- und Sicherheitsanforderungen. Jede Konfiguration bietet außerdem Bereitstellungsüberlegungen, die hilfreich sind, um zu bestimmen, welche für ein bestimmtes Szenario am besten geeignet ist.

Informationen zu RPC über HTTP-Szenarien mit hohem Volumen finden Sie unter Microsoft RPC Load Balancing.

Die folgenden Empfehlungen gelten für alle Konfigurationen:

• Verwenden Sie Versionen von Windows, die RPC über HTTP v2 unterstützen.
• Platzieren Sie IIS auf dem Computer, auf dem der RPC-Proxy im IIS 6.0-Modus ausgeführt wird.
• Anonymen Zugriff auf das virtuelle RPC-Proxyverzeichnis nicht zulassen.
• Aktivieren Sie niemals den Registrierungsschlüssel AllowAnonymous.
• Verwenden Sie die CertificateSubjectField- (weitere Informationen finden Sie unter RpcBindingSetAuthInfoEx), um zu überprüfen, ob der rpc-Proxy, mit dem Sie verbunden sind, der erwartete RPC-Proxy ist.
• Konfigurieren Sie den ValidPorts Registrierungsschlüssel so, dass er nur Computer enthält, mit denen der RPC über HTTP-Clients eine Verbindung herstellt.
• Verwenden Sie keine Wildcards im ValidPorts--Schlüssel; Dies kann Zeit sparen, aber ein völlig unerwarteter Computer kann auch auf den Platzhalter passen.
• Verwenden Sie SSL auf RPC über HTTP-Clients. Wenn die in diesen Abschnitten beschriebenen Richtlinien befolgt werden, kann der RPC-über-HTTP-Client keine Verbindung herstellen, ohne SSL zu verwenden.
• Konfigurieren Sie RPC über HTTP-Clients für die Verwendung der RPC-Verschlüsselung zusätzlich zur Verwendung von SSL. Wenn der RPC über HTTP-Client den KDC nicht erreichen kann, kann er nur Negotiate und NTLM verwenden.
• Konfigurieren Sie Clientcomputer für die Verwendung von NTLMv2. Legen Sie den LMCompatibilityLevel Registrierungsschlüssel auf 2 oder höher fest. Weitere Informationen zum LMCompatibilityLevel Schlüssel finden Sie unter msdn.microsoft.com.
• Führen Sie eine Webfarm von RPC-Proxycomputern mit der oben beschriebenen Konfiguration aus.
• Stellen Sie eine Firewall zwischen dem Internet und dem RPC-Proxy bereit.
• Um eine optimale Leistung zu erzielen, konfigurieren Sie IIS so, dass eine kurze Antwort für Fehlercodes ohne Erfolg gesendet wird. Da der Verbraucher der IIS-Antwort ein automatisierter Prozess ist, ist es nicht erforderlich, benutzerfreundliche Erklärungen an den Client zu senden; sie werden einfach vom RPC-über-HTTP-Client ignoriert.

Die grundlegenden Ziele des RPC-Proxys aus Sicherheits-, Leistungs- und Verwaltbarkeitsperspektive sind die folgenden:

• Stellen Sie einen einzelnen Einstiegspunkt für RPC über HTTP-Datenverkehr in das Servernetzwerk bereit. Die Verwendung eines einzelnen Einstiegspunkts für RPC über HTTP-Datenverkehr in ein Servernetzwerk hat zwei Hauptvorteile. Erstens, da der RPC-Proxy mit dem Internet konfrontiert ist, isolieren die meisten Organisationen solche Computer in einem speziellen Netzwerk, das als nicht vertrauenswürdiges Umkreisnetzwerk bezeichnet wird, das vom normalen Organisationsnetzwerk getrennt ist. Server in einem nicht vertrauenswürdigen Umkreisnetzwerk werden sehr sorgfältig verwaltet, konfiguriert und überwacht, um Angriffen aus dem Internet standzuhalten. Je weniger Computer in einem nicht vertrauenswürdigen Umkreisnetzwerk vorhanden sind, desto einfacher ist es, sie zu konfigurieren, zu verwalten, zu überwachen und zu schützen. Da eine einzelne Webfarm mit installierten RPC-Proxys eine beliebige Anzahl von RPC-über-HTTP-Servern im Unternehmensnetzwerk bedienen kann, ist es sehr sinnvoll, den RPC-Proxy vom RPC-über-HTTP-Server zu trennen und den RPC-Proxy in einem nicht vertrauenswürdigen Umkreisnetzwerk zu befinden. Wenn sich der RPC-Proxy auf demselben Computer wie der RPC-über-HTTP-Server befand, würden Organisationen gezwungen sein, alle ihre Back-End-Server in ein nicht vertrauenswürdiges Umkreisnetzwerk zu versetzen, wodurch es viel schwieriger wäre, das nicht vertrauenswürdige Umkreisnetzwerk sicher zu halten. Durch die Trennung der Rolle des RPC-Proxys und des RPC-über-HTTP-Servers können Organisationen die Anzahl der Computer in einem nicht vertrauenswürdigen Umkreisnetzwerk verwalten und somit sicherer halten.
• Dient als Sicherheitssicherung für das Servernetzwerk. Der RPC-Proxy ist als expendierbare fuse für das Servernetzwerk konzipiert – wenn im RPC-Proxy ein Fehler auftritt, geht er einfach aus und schützt so den echten RPC über HTTP-Server. Wenn die in diesem Abschnitt beschriebenen bewährten Methoden bisher befolgt wurden, wird der RPC-über-HTTP-Datenverkehr zusätzlich zu SSL mit RPC-Verschlüsselung verschlüsselt. Die RPC-Verschlüsselung selbst liegt zwischen dem Client und dem Server, nicht zwischen dem Client und dem Proxy. Dies bedeutet, dass der Proxy den empfangenen RPC-Datenverkehr nicht versteht und nicht entschlüsseln kann. Es versteht nur einige Steuerungssequenzen, die der Kunde mit Verbindungsaufbau, Flusssteuerung und anderen Tunneldetails an sie gesendet hat. Er hat keinen Zugriff auf die Daten, die der RPC über HTTP-Client an den Server sendet. Darüber hinaus muss sich der RPC-über-HTTP-Client unabhängig vom RPC-Proxy und dem RPC-über-HTTP-Server authentifizieren. Dies bietet eine tiefe Verteidigung. Wenn der RPC-Proxycomputer aufgrund eines Konfigurationsfehlers oder einer Sicherheitsverletzung in irgendeiner Art kompromittiert wird, sind die Daten, die sie durchlaufen, weiterhin vor Manipulationen geschützt. Ein Angreifer, der die Kontrolle über den RPC-Proxy erlangen würde, kann den Datenverkehr höchstens unterbrechen, aber nicht lesen oder manipulieren. Hier kommt die Sicherungsrolle des RPC-Proxys ins Spiel – es ist expendierbar, ohne dass die Sicherheit des RPC-über-HTTP-Datenverkehrs kompromittiert wird.
• Verteilen Sie einige der Zugriffsprüfungen und Entschlüsselungsvorgänge auf mehreren Computern, auf denen RPC-Proxy in einer Webfarm ausgeführt wird. Durch eine ordnungsgemäße Funktion in einer Webfarm ermöglicht der RPC-Proxy Organisationen das Entladen der SSL-Entschlüsselung und einiger Zugriffsprüfungen, wodurch mehr Kapazität auf dem Back-End-Server zur Verarbeitung freigegeben wird. Die Verwendung einer Webfarm von RPC-Proxycomputern ermöglicht es einer Organisation auch, ihre Fähigkeit zu erhöhen, Denial of Service (DoS)-Angriffe zu widerstehen, indem sie die Kapazität auf ihren Front-End-Servern erhöhen.

In den bisher dargelegten Richtlinien haben Organisationen immer noch Auswahlmöglichkeiten. Jede Organisation hat Auswahlmöglichkeiten und Kompromittierungen zwischen Unannehmlichkeiten, Sicherheit und Kosten:

• Verwenden Sie die Standardauthentifizierung oder die integrierte Windows-Authentifizierung, um sich beim RPC-Proxy zu authentifizieren? RPC über HTTP unterstützt derzeit nur NTLM – kerberos wird nicht unterstützt. Wenn ein HTTP-Proxy oder eine Firewall zwischen dem RPC-über-HTTP-Client und dem RPC-Proxy vorhanden ist, der die über Pragma im HTTP-Header einfügt, funktioniert die NTLM-Authentifizierung nicht. Wenn dies nicht der Fall ist, können Organisationen zwischen standard- und NTLM-Authentifizierung wählen. Der Vorteil der Standardauthentifizierung besteht darin, dass sie schneller und einfacher ist und daher weniger Möglichkeiten für Denial-of-Service-Angriffe bietet. Aber NTLM ist sicherer. Abhängig von den Prioritäten einer Organisation kann sie "Basic", "NTLM" auswählen oder den Benutzern die Auswahl zwischen den beiden ermöglichen. Wenn nur eines ausgewählt wird, empfiehlt es sich, den anderen aus dem virtuellen RPC-Proxyverzeichnis zu deaktivieren, um das Angriffsrisiko zu verringern.
• Verwenden Sie denselben Satz von Anmeldeinformationen sowohl für den RPC-Proxy als auch für den RPC-über-HTTP-Server, oder verwenden Sie unterschiedliche Anmeldeinformationen für jeden? Der Kompromiss für diese Entscheidung liegt zwischen Benutzerfreundlichkeit und Sicherheit. Einige Benutzer möchten mehrere Anmeldeinformationen eingeben. Wenn jedoch eine Sicherheitsverletzung in einem nicht vertrauenswürdigen Umkreisnetzwerk auftritt, bietet die Verwendung separater Anmeldeinformationen für den RPC-Proxy und den RPC-über-HTTP-Server zusätzlichen Schutz. Wenn separate Anmeldeinformationen verwendet werden und eine Gruppe von Anmeldeinformationen die Domänenanmeldeinformationen des Benutzers ist, empfiehlt es sich, die Domänenanmeldeinformationen des Benutzers für den RPC-über-HTTP-Server und nicht für den RPC-Proxy zu verwenden.