RPC za pośrednictwem zabezpieczeń HTTP

RPC przez HTTP zapewnia trzy typy zabezpieczeń oprócz standardowych zabezpieczeń RPC, co powoduje, że RPC przez ruch HTTP jest chroniony raz przez RPC, a następnie podwójnie chronione przez mechanizm tunelowania zapewniany przez RPC za pośrednictwem protokołu HTTP. Aby uzyskać opis standardowych mechanizmów zabezpieczeń RPC, zobacz Security. Mechanizm RPC za pośrednictwem tunelowania HTTP dodaje normalne zabezpieczenia RPC w następujący sposób:

• Zapewnia zabezpieczenia za pośrednictwem usług IIS (dostępne tylko dla RPC za pośrednictwem protokołu HTTP w wersji 2).
• Zapewnia szyfrowanie SSL i weryfikację serwera proxy RPC (wzajemne uwierzytelnianie). Dostępne również w RPC tylko za pośrednictwem protokołu HTTP w wersji 2.
• Zapewnia ograniczenia dotyczące dyktowania na poziomie serwera proxy RPC, które maszyny w sieci serwera mogą odbierać RPC za pośrednictwem wywołań HTTP.

Każda z tych trzech funkcji zabezpieczeń została opisana bardziej szczegółowo w poniższych sekcjach.

Uwierzytelnianie usług IIS

RPC za pośrednictwem protokołu HTTP może korzystać z normalnego mechanizmu uwierzytelniania usług IIS. Katalog wirtualny serwera proxy RPC można skonfigurować przy użyciu węzła Rpc w domyślnej witrynie sieci Web w przystawce MMC usług IIS:

Usługi IIS można skonfigurować tak, aby wyłączyć dostęp anonimowy i wymagać uwierzytelniania w katalogu wirtualnym serwera proxy RPC. W tym celu kliknij prawym przyciskiem myszy węzeł Rpc i wybierz pozycję Właściwości. Wybierz kartę zabezpieczeń katalogu, a następnie kliknij przycisk Edytuj w grupie Authentication and Access Control, jak pokazano poniżej:

Mimo że można użyć wywołania RPC za pośrednictwem protokołu HTTP nawet wtedy, gdy katalog wirtualny serwera proxy RPC zezwala na dostęp anonimowy, firma Microsoft zdecydowanie zaleca wyłączenie dostępu anonimowego do tego katalogu wirtualnego ze względów bezpieczeństwa. Zamiast tego w przypadku wywołania RPC za pośrednictwem protokołu HTTP włącz uwierzytelnianie podstawowe, zintegrowane uwierzytelnianie systemu Windows lub oba te elementy. Pamiętaj, że tylko RPC za pośrednictwem protokołu HTTP v2 jest w stanie uwierzytelnić się na serwerze proxy RPC wymagającym uwierzytelniania podstawowego lub zintegrowanego z systemem Windows; RPC za pośrednictwem protokołu HTTP v1 nie będzie można nawiązać połączenia, jeśli nie zezwalaj na dostęp anonimowy jest wyłączony. Ponieważ RPC za pośrednictwem protokołu HTTP w wersji 2 jest bezpieczniejszą i niezawodną implementacją, użycie wersji systemu Windows, która obsługuje, poprawi bezpieczeństwo instalacji.

Szyfrowanie ruchu

RPC za pośrednictwem protokołu HTTP może szyfrować ruch między wywołaniami RPC za pośrednictwem klienta HTTP i serwera proxy RPC przy użyciu protokołu SSL. Ruch między serwerem proxy RPC i RPC za pośrednictwem serwera HTTP jest szyfrowany przy użyciu normalnych mechanizmów zabezpieczeń RPC i nie używa protokołu SSL (nawet w przypadku wybrania protokołu SSL między klientem a serwerem proxy RPC). Dzieje się tak dlatego, że część ruchu przemieszcza się w sieci organizacji i za zaporą.

Ruch między RPC za pośrednictwem klienta HTTP i serwera proxy RPC, który zazwyczaj podróżuje przez Internet, może być szyfrowany przy użyciu protokołu SSL oprócz mechanizmu szyfrowania wybranego dla RPC. W takim przypadku ruch w Internecie części trasy staje się podwójnie szyfrowany. Szyfrowanie ruchu przez serwer proxy RPC zapewnia pomocniczą ochronę, w przypadku naruszenia zabezpieczeń serwera proxy RPC lub innych maszyn w sieci obwodowej. Ponieważ serwer proxy RPC nie może odszyfrować pomocniczej warstwy szyfrowania, serwer proxy RPC nie ma dostępu do wysyłanych danych. Aby uzyskać więcej informacji, zobacz RPC over HTTP Deployment Recommendations (Zalecenia dotyczące wdrażania HTTP za pośrednictwem protokołu HTTP). Szyfrowanie SSL jest dostępne tylko w przypadku protokołu RPC za pośrednictwem protokołu HTTP v2.

Ograniczanie wywołań RPC przez wywołania HTTP do niektórych komputerów

Konfiguracja zabezpieczeń usług IIS jest oparta na dozwolonych zakresach komputerów i portów. Możliwość korzystania z procedury RPC za pośrednictwem protokołu HTTP jest kontrolowana przez dwa wpisy rejestru na komputerze z uruchomionymi usługami IIS i serwerem proxy RPC. Pierwszy wpis to flaga, która przełącza funkcję serwera proxy RPC. Druga to opcjonalna lista komputerów, do których serwer proxy może przekazywać wywołania RPC.

Domyślnie klient, który kontaktuje się z serwerem proxy RPC w celu tunelowania RPC za pośrednictwem wywołań HTTP, nie może uzyskać dostępu do żadnych procesów serwera RPC z wyjątkiem RPC przez procesy serwera HTTP uruchomione na tej samej maszynie co serwer proxy RPC. Jeśli flaga ENABLED nie jest zdefiniowana lub ustawiona na wartość zero, usługi IIS wyłącza serwer proxy RPC. Jeśli flaga ENABLED jest zdefiniowana i ustawiona na wartość niezerową, klient może nawiązać połączenie z RPC za pośrednictwem serwerów HTTP na komputerze z uruchomionymi usługami IIS. Aby umożliwić klientowi tunel do procedury RPC przez proces serwera HTTP na innym komputerze, należy dodać wpis rejestru do listy RPC komputera usług IIS za pośrednictwem serwerów HTTP.

Serwery RPC nie mogą akceptować wywołań RPC za pośrednictwem wywołań HTTP, chyba że zażądali, aby RPC nasłuchiwać na RPC za pośrednictwem protokołu HTTP.

W poniższym przykładzie pokazano, jak skonfigurować rejestr, aby umożliwić klientom łączenie się z serwerami przez Internet:

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

Wpis ValidPorts jest wpisem REG_SZ zawierającym listę komputerów, do których serwer proxy RPC usług IIS może przekazywać wywołania RPC, a porty, których należy używać do łączenia się z serwerami RPC. Wpis REG_SZ ma następującą formę: Rosco:593; Rosco:2000-8000; Dane*:4000-8000.

W tym przykładzie usługi IIS mogą przekazywać RPC za pośrednictwem wywołań HTTP do serwera "Rosco" na portach 593 i 2000 do 8000. Może również wysyłać wywołania do dowolnego serwera, którego nazwa zaczyna się od "Dane". Na portach od 4000 do 8000 zostanie nawiązane połączenie. Ponadto przed przekazaniem ruchu do danego portu na serwerze HTTP przez serwer HTTP serwer proxy RPC wykonuje specjalną wymianę pakietów z usługą RPC nasłuchującą na tym porcie, aby sprawdzić, czy jest gotów zaakceptować żądania za pośrednictwem protokołu HTTP.

Na przykład na podstawie tych przykładowych ustawień, jeśli usługa RPC nasłuchuje na porcie 4500 na serwerze "Data1", ale nie wywoła jednego z RpcServerUseProtseq* funkcji z ncacn_http, odrzuci żądanie. To zachowanie zapewnia dodatkową ochronę serwerów nasłuchujących na otwartym porcie z powodu błędu konfiguracji; chyba że serwer zażądał nasłuchiwania wywołań RPC za pośrednictwem protokołu HTTP, nie będzie odbierał wywołań pochodzących z zewnątrz zapory.

Wpisy w kluczu ValidPorts muszą być dokładnie zgodne z RPC przez serwer HTTP zapytany przez klienta (nie jest uwzględniana wielkość liter). Aby usprawnić przetwarzanie, serwer proxy RPC nie wykonuje kanonizacji nazwy dostarczonej przez RPC za pośrednictwem klienta HTTP. W związku z tym, jeśli klient prosi o rosco.microsoft.com, a w ValidPorts zawierać tylko Rosco, serwer proxy RPC nie będzie zgodny z nazwami, mimo że obie nazwy mogą odwoływać się do tej samej maszyny. Ponadto, jeśli adres IP Rosco to 66.77.88.99, a klient prosi o 66.77.88.99, ale klucz ValidPorts zawiera tylko rosco, serwer proxy RPC odmówi połączenia. Jeśli klient może poprosić o wywołanie procedury RPC przez serwer HTTP według nazwy lub według adresu IP, wstaw oba w kluczu ValidPorts.

Usługi IIS odczytują wpisy rejestru włączone i ValidPorts podczas uruchamiania. Ponadto RPC przez HTTP ponownie odczytuje zawartość klucza ValidPorts co około 5 minut. Jeśli wpis ValidPorts zostanie zmieniony, zmiany zostaną zaimplementowane w ciągu 5 minut.

RPC za pośrednictwem protokołu HTTP v1: Należy zatrzymać i ponownie uruchomić usługę sieci Web przy użyciu programu Internet Service Manager, aby można było zaimplementować nowe wartości w wpisach rejestru.