RPC-über-HTTP-Bereitstellungsempfehlungen

In diesem Abschnitt werden bewährte Methoden und empfohlene Bereitstellungskonfigurationen für maximale Sicherheit und Leistung bei Verwendung von RPC über HTTP dokumentiert. Die verschiedenen hier aufgeführten Konfigurationen gelten für unterschiedliche Organisationen basierend auf unterschiedlichen Größen-, Budget- und Sicherheitsanforderungen. Jede Konfiguration bietet auch Bereitstellungsüberlegungen, die nützlich 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-Lastenausgleich.

Die folgenden Empfehlungen gelten für alle Konfigurationen:

• Verwenden Sie Windows-Versionen, 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.
• Lassen Sie den anonymen Zugriff auf das virtuelle Verzeichnis des RPC-Proxys nicht zu.
• Aktivieren Sie niemals den Registrierungsschlüssel AllowAnonymous.
• Stellen Sie sicher, dass Ihre RPC-über-HTTP-Clients certificateSubjectField (weitere Informationen finden Sie unter RpcBindingSetAuthInfoEx ) verwenden, um zu überprüfen, ob der RPC-Proxy, mit dem Sie eine Verbindung hergestellt haben, der erwartete RPC-Proxy ist.
• Konfigurieren Sie den ValidPorts-Registrierungsschlüssel so, dass er nur Computer enthält, mit denen die RPC-über-HTTP-Clients eine Verbindung herstellen.
• Verwenden Sie keine Feldhalter im ValidPorts-Schlüssel . Dies kann Zeit sparen, aber ein völlig unerwarteter Computer kann auch auf den Platzhalter passen.
• Verwenden Sie SSL für RPC-über HTTP-Clients. Wenn die in diesen Abschnitten beschriebenen Richtlinien befolgt werden, kann der RPC-über-HTTP-Client keine Verbindung ohne SSL herstellen.
• 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 mit 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 auf Fehlercodes ohne Erfolg gesendet wird. Da der Consumer der IIS-Antwort ein automatisierter Prozess ist, müssen keine benutzerfreundlichen Erklärungen an den Client gesendet werden. Sie werden einfach vom RPC-über-HTTP-Client ignoriert.

Die grundlegenden Ziele des RPC-Proxys aus Sicht von Sicherheit, Leistung und Verwaltbarkeit sind die folgenden:

• Stellen Sie einen einzelnen Einstiegspunkt für RPC-über HTTP-Datenverkehr in das Servernetzwerk bereit. Ein single point of entry für RPC-über HTTP-Datenverkehr in ein Servernetzwerk hat zwei Standard Vorteile. Erstens, da der RPC-Proxy mit dem Internet konfrontiert ist, isolieren die meisten Organisationen solche Computer in einem speziellen Netzwerk, dem sogenannten nicht vertrauenswürdigen Umkreisnetzwerk, 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. Zweitens: 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 befindet, wären Organisationen gezwungen, alle back-End-Server in ein nicht vertrauenswürdiges Umkreisnetzwerk zu versetzen, was die Sicherheit des nicht vertrauenswürdigen Umkreisnetzwerks erheblich erschweren würde. 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 entsrauchbare Sicherung für das Servernetzwerk konzipiert – wenn auf dem RPC-Proxy etwas schief geht, 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 befindet sich 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 vom Client an sie gesendet wurden, die sich mit Verbindungsaufbau, Ablaufsteuerung und anderen Tunnelingdetails befassen. Es 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 beim RPC-Proxy und beim RPC-über-HTTP-Server authentifizieren. Dies bietet eine ausführliche Verteidigung. Wenn der RPC-Proxycomputer aufgrund eines Konfigurationsfehlers oder einer Sicherheitsverletzung kompromittiert wird, sind die Daten, die ihn durchlaufen, weiterhin sicher vor Manipulationen. 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 – er ist entbehrlich, ohne dass die Sicherheit des RPC-über-HTTP-Datenverkehrs kompromittiert wird.
• Verteilen Sie einige der Zugriffsprüfungen und Entschlüsselungsarbeiten auf mehrere Computer, auf denen der RPC-Proxy in einer Webfarm ausgeführt wird. Durch die gute Funktion in einer Webfarm ermöglicht der RPC-Proxy Organisationen das Auslagern der SSL-Entschlüsselung und einiger Zugriffsprüfungen, wodurch mehr Kapazität auf dem Back-End-Server für die Verarbeitung freigegeben wird. Die Verwendung einer Webfarm mit RPC-Proxycomputern ermöglicht es einem organization, seine Fähigkeit zu erhöhen, Denial-of-Service-Angriffen (DoS) standzuhalten, indem die Kapazität auf den Front-End-Servern erhöht wird.

Innerhalb der bisher festgelegten Richtlinien haben Organisationen immer noch Wahlmöglichkeiten. Jede organization hat Optionen und Kompromisse zwischen Benutzerannehmlichkeiten, 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 das via Pragma in den HTTP-Header einfügt, funktioniert die NTLM-Authentifizierung nicht. Wenn dies nicht der Fall ist, können Organisationen zwischen Basic- und NTLM-Authentifizierung wählen. Der Vorteil der Standardauthentifizierung ist, dass sie schneller und einfacher ist und daher weniger Möglichkeiten für Denial-of-Service-Angriffe bietet. NTLM ist jedoch sicherer. Abhängig von den Prioritäten eines organization kann er Basic, NTLM auswählen oder seinen Benutzern die Wahl zwischen den beiden ermöglichen. Wenn nur eins ausgewählt wird, ist es am besten, das andere aus dem virtuellen Verzeichnis des RPC-Proxys zu deaktivieren, um das Risiko eines Angriffs 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 besteht zwischen Benutzerfreundlichkeit und Sicherheit. Nur wenige Benutzer möchten mehrere Anmeldeinformationen eingeben. Wenn jedoch in einem nicht vertrauenswürdigen Umkreisnetzwerk eine Sicherheitsverletzung auftritt, bieten separate Anmeldeinformationen für den RPC-Proxy und den RPC-über-HTTP-Server zusätzlichen Schutz. Beachten Sie, dass es ratsam ist, die Domänenanmeldeinformationen des Benutzers für den RPC-über-HTTP-Server und nicht für den RPC-Proxy zu verwenden, wenn separate Anmeldeinformationen verwendet werden und ein Satz von Anmeldeinformationen die Domänenanmeldeinformationen des Benutzers sind.