RPC по протоколу БЕЗОПАСНОСТИ HTTP

RPC по протоколу HTTP обеспечивает три типа безопасности в дополнение к стандартной безопасности RPC, что приводит к защите RPC через HTTP-трафик один раз с помощью RPC, а затем вдвойне защищен механизмом туннелирования, предоставляемым RPC по протоколу HTTP. Описание стандартных механизмов безопасности RPC см. в разделе "Безопасность". Механизм туннелирования RPC по протоколу HTTP добавляет к обычной безопасности RPC следующим образом:

• Обеспечивает безопасность через СЛУЖБЫ IIS (доступно только для RPC по протоколу HTTP версии 2).
• Обеспечивает шифрование SSL и проверку прокси-сервера RPC (взаимная проверка подлинности). Также доступно только в RPC по протоколу HTTP версии 2.
• Предоставляет ограничения на уровень прокси-сервера RPC, диктующий, какие компьютеры в сети сервера разрешены получать RPC через HTTP-вызовы.

Каждый из этих трех функций безопасности подробно описан в следующих разделах.

Проверка подлинности IIS

RPC по протоколу HTTP может использовать обычный механизм проверки подлинности IIS. Виртуальный каталог для прокси-сервера RPC можно настроить с помощью узла Rpc под веб-сайтом по умолчанию в оснастке MMC IIS:

Службы IIS можно настроить для отключения анонимного доступа и требовать проверку подлинности в виртуальном каталоге для прокси-сервера RPC. Для этого щелкните правой кнопкой мыши узел Rpc и выберите пункт "Свойства". Перейдите на вкладку "Безопасность каталога" и нажмите кнопку "Изменить" в группе проверки подлинности и контроль доступа, как показано ниже.

Хотя вы можете использовать RPC по протоколу HTTP, даже если виртуальный каталог прокси-сервера RPC разрешает анонимный доступ, корпорация Майкрософт настоятельно рекомендует отключить анонимный доступ к этому виртуальному каталогу по соображениям безопасности. Скорее, для RPC по протоколу HTTP включите базовую проверку подлинности, встроенную проверку подлинности Windows или оба. Помните, что только RPC по протоколу HTTP версии 2 может проходить проверку подлинности в прокси-сервере RPC, требующем базовой или интегрированной проверки подлинности Windows; RPC по протоколу HTTP версии 1 не сможет подключиться, если запрет анонимного доступа отключен. Так как RPC по протоколу HTTP версии 2 является более безопасной и надежной реализацией, используя версию Windows, которая поддерживает ее, улучшит безопасность ваших установок.

Примечание.

По умолчанию виртуальный каталог прокси-сервера RPC помечается, чтобы разрешить анонимный доступ. Однако прокси-сервер RPC для RPC по протоколу HTTP версии 2 отклоняет запросы, которые по умолчанию не проходят проверку подлинности.

 

Шифрование трафика

RPC по протоколу HTTP может шифровать трафик между RPC через HTTP-клиент и прокси-сервер RPC с помощью SSL. Трафик между прокси-сервером RPC и RPC через HTTP-сервер шифруется с помощью обычных механизмов безопасности RPC и не использует SSL (даже если ssl между клиентом и прокси-сервером RPC выбран). Это связано с тем, что часть трафика перемещается в сети организации и за брандмауэром.

Трафик между клиентом RPC по протоколу HTTP и прокси-сервером RPC, который обычно перемещается по Интернету, можно зашифровать с помощью SSL в дополнение к тому, какой механизм шифрования был выбран для RPC. В этом случае трафик в интернет-части маршрута становится вдвойне зашифрованным. Шифрование трафика через прокси-сервер RPC обеспечивает вторичную защиту, если прокси-сервер RPC или другие компьютеры в сети периметра скомпрометируются. Так как прокси-сервер RPC не может расшифровать дополнительный уровень шифрования, прокси-сервер RPC не имеет доступа к отправляемым данным. Дополнительные сведения см. в Рекомендации развертывании RPC по протоколу HTTP. Шифрование SSL доступно только с помощью RPC по протоколу HTTP версии 2.

Ограничение RPC через HTTP-вызовы на определенные компьютеры

Конфигурация безопасности IIS основана на разрешенных диапазонах компьютеров и портов. Возможность использования RPC по протоколу HTTP управляется двумя записями реестра на компьютере под управлением IIS и прокси-сервера RPC. Первая запись — это флаг, который переключает функции прокси-сервера RPC. Второй — это необязательный список компьютеров, на которые прокси-сервер может перенаправить вызовы RPC.

По умолчанию клиент, который связывается с прокси-сервером RPC для туннелирования RPC через HTTP-вызовы, не может получить доступ к каким-либо процессам RPC-сервера, кроме процессов RPC через HTTP-сервер, выполняемых на том же компьютере, что и прокси-сервер RPC. Если флаг ENABLED не определен или имеет нулевое значение, СЛУЖБЫ IIS отключает прокси-сервер RPC. Если флаг ENABLED определен и установлен в ненулевое значение, клиент может подключиться к RPC через HTTP-серверы на компьютере под управлением IIS. Чтобы разрешить клиенту туннелировать процесс RPC через HTTP-сервер на другом компьютере, необходимо добавить запись реестра в список RPC компьютера IIS через HTTP-серверы.

Серверы RPC не могут принимать RPC через HTTP-вызовы, если они не запрашивают RPC для прослушивания RPC по протоколу HTTP.

В следующем примере показано, как настроить реестр, чтобы клиенты могли подключаться к серверам через Интернет:

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

Запись ValidPorts — это запись REG_SZ, содержащая список компьютеров, на которых прокси-сервер IIS RPC разрешен переадресовать вызовы RPC, а порты, которые он должен использовать для подключения к серверам RPC. Запись REG_SZ имеет следующую форму: Роско:593; Роско:2000-8000; Данные*:4000-8000.

В этом примере СЛУЖБЫ IIS могут перенаправить RPC через HTTP-вызовы к серверу Rosco на портах 593 и 2000 до 8000. Он также может отправлять вызовы на любой сервер, имя которого начинается с "Data". Он будет подключаться к портам 4000–8000. Кроме того, перед перенаправлением трафика на заданный порт на RPC через HTTP-сервер прокси-сервер RPC выполняет специальный обмен пакетами со службой RPC, прослушивающей этот порт, чтобы убедиться, что он готов принимать запросы по протоколу HTTP.

Пример на основе этих параметров, если служба RPC прослушивает порт 4500 на сервере Data1, но не вызывает одну из функций RpcServerUseProtseq* с ncacn_http, он отклонит запрос. Это поведение обеспечивает дополнительную защиту серверов, прослушивающих открытый порт из-за ошибки конфигурации; Если сервер, специально запрошенный для прослушивания RPC по протоколу HTTP, он не будет получать вызовы, исходящие из-за пределов брандмауэра.

Записи в ключе ValidPorts должны быть точным совпадением RPC на HTTP-сервере, запрашиваемом клиентом (это не учитывает регистр). Чтобы упростить обработку, прокси-сервер RPC не выполняет канонизацию имени, предоставленного RPC через HTTP-клиент. Таким образом, если клиент запрашивает rosco.microsoft.com и в ValidPorts содержит только Rosco, прокси-сервер RPC не будет соответствовать именам, даже если оба имени могут ссылаться на один и тот же компьютер. Кроме того, если IP-адрес Rosco равен 66.77.88.99, а клиент запрашивает только 66.77.88.99, но ключ ValidPorts содержит только Rosco, прокси-сервер RPC отклонит подключение. Если клиент может попросить RPC через HTTP-сервер по имени или по IP-адресу, вставьте оба в ключ ValidPorts .

Примечание.

Хотя RPC включен IPv6, прокси-сервер RPC не поддерживает IPv6-адреса в ключе ValidPorts . Если IPv6 используется для подключения прокси-сервера RPC и RPC через HTTP-сервер, можно использовать только DNS-имена.

 

Службы IIS считываютзаписи реестра Enabled и ValidPorts при запуске. Кроме того, RPC по протоколу HTTP перечитает содержимое ключа ValidPorts примерно каждые 5 минут. Если запись ValidPorts изменена, изменения реализуются в течение 5 минут.

RPC по протоколу HTTP версии 1. Веб-служба должна быть остановлена и перезапущена с помощью Диспетчера служб Интернета для реализации новых значений в записях реестра.