Segurança RPC sobre HTTP

RPC sobre HTTP fornece três tipos de segurança, além da segurança RPC padrão, o que resulta em RPC sobre tráfego HTTP sendo protegido uma vez por RPC e, em seguida, duplamente protegido pelo mecanismo de encapsulamento fornecido por RPC sobre HTTP. Para obter uma descrição dos mecanismos de segurança RPC padrão, consulte Security. O mecanismo de encapsulamento RPC sobre HTTP adiciona à segurança RPC normal da seguinte maneira:

• Fornece segurança através do IIS (disponível apenas para RPC sobre HTTP v2).
• Fornece criptografia SSL e verificação de proxy RPC (autenticação mútua). Também disponível apenas em RPC sobre HTTP v2.
• Fornece restrições no nível de Proxy RPC ditando quais máquinas na rede do servidor têm permissão para receber chamadas RPC sobre HTTP.

Cada um desses três recursos de segurança é descrito com mais detalhes nas seções a seguir.

Autenticação do IIS

RPC sobre HTTP pode aproveitar o mecanismo de autenticação normal do IIS. O diretório virtual para Proxy RPC pode ser configurado usando o nó Rpc no Site Padrão no snap-in MMC do IIS:

O IIS pode ser configurado para desabilitar o acesso anônimo e exigir autenticação no diretório virtual para o Proxy RPC. Para fazer isso, clique com o botão direito do mouse no nó Rpc e selecione Propriedades. Selecione a guia de Segurança de Diretório e clique no botão Editar no grupo Autenticação de e Controle de Acesso, conforme ilustrado aqui:

Embora você possa usar RPC sobre HTTP mesmo quando o diretório virtual Proxy RPC permite acesso anônimo, a Microsoft recomenda fortemente desabilitar o acesso anônimo a esse diretório virtual por motivos de segurança. Em vez disso, para RPC sobre HTTP, habilite a Autenticação Básica, a Autenticação Integrada do Windows ou ambas. Lembre-se de que apenas RPC sobre HTTP v2 é capaz de autenticar em Proxy RPC que requer autenticação básica ou integrada ao Windows; RPC sobre HTTP v1 não poderá se conectar se Não Permitir Acesso Anônimo estiver desabilitada. Como RPC sobre HTTP v2 é a implementação mais segura e robusta, usar uma versão do Windows que a suporte melhorará a segurança de suas instalações.

Observação

Por padrão, o diretório virtual de proxy RPC é marcado para permitir acesso anônimo. No entanto, o proxy RPC para RPC sobre HTTP v2 rejeita solicitações que não são autenticadas por padrão.

 

Encriptação de Tráfego

RPC sobre HTTP pode criptografar o tráfego entre o cliente RPC sobre HTTP e o proxy RPC com SSL. O tráfego entre o proxy RPC e o servidor RPC sobre HTTP é criptografado usando mecanismos de segurança RPC normais e não usa SSL (mesmo que SSL entre o cliente e o proxy RPC seja escolhido). Isso ocorre porque essa parte do tráfego viaja dentro da rede de uma organização e atrás de um firewall.

O tráfego entre o cliente RPC sobre HTTP e o proxy RPC, que geralmente viaja pela Internet, pode ser criptografado com SSL, além do mecanismo de criptografia escolhido para RPC. Nesse caso, o tráfego na parte da Internet da rota torna-se duplamente criptografado. A criptografia do tráfego através do proxy RPC fornece uma defesa secundária, caso o proxy RPC ou outras máquinas na rede de perímetro sejam comprometidas. Como o proxy RPC não pode descriptografar a camada de criptografia secundária, o proxy RPC não tem acesso aos dados que estão sendo enviados. Consulte de recomendações de implantação RPC sobre HTTP para obter mais informações. A criptografia SSL está disponível somente com RPC sobre HTTP v2.

Restringindo chamadas RPC sobre HTTP a determinados computadores

A configuração de segurança do IIS é baseada em intervalos de computador e porta permitidos. A capacidade de usar RPC sobre HTTP é controlada por duas entradas do Registro no computador que executa o IIS e o proxy RPC. A primeira entrada é um sinalizador que alterna a funcionalidade de proxy RPC. O segundo é uma lista opcional de computadores para os quais o proxy pode encaminhar chamadas RPC.

Por padrão, um cliente que contata o proxy RPC para túnel de chamadas RPC sobre HTTP não pode acessar nenhum processo de servidor RPC, exceto os processos de servidor RPC sobre HTTP em execução na mesma máquina que o proxy RPC. Se o sinalizador ENABLED não estiver definido ou definido como um valor zero, o IIS desativará o proxy RPC. Se o sinalizador ENABLED for definido e definido como um valor diferente de zero, um cliente poderá se conectar a servidores RPC sobre HTTP no computador que executa o IIS. Para permitir que o cliente faça um túnel para um processo de servidor RPC sobre HTTP em outro computador, você deve adicionar uma entrada do Registro à lista de servidores RPC sobre HTTP do computador IIS.

Os servidores RPC não podem aceitar chamadas RPC sobre HTTP, a menos que solicitem especificamente que RPC escute em RPC sobre HTTP.

O exemplo a seguir demonstra como configurar o registro para permitir que os clientes se conectem a servidores pela Internet:

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

A entrada ValidPorts é uma entrada REG_SZ que contém uma lista de computadores para os quais o proxy RPC do IIS tem permissão para encaminhar chamadas RPC e as portas que ele deve usar para se conectar aos servidores RPC. A entrada REG_SZ assume a seguinte forma: Rosco:593; Rosco:2000-8000; Dados*:4000-8000.

Neste exemplo, o IIS pode encaminhar chamadas RPC sobre HTTP para o servidor "Rosco" nas portas 593 e 2000 a 8000. Também pode enviar chamadas para qualquer servidor cujo nome comece com "Dados". Ele se conectará nas portas 4000 a 8000. Além disso, antes de encaminhar o tráfego para uma determinada porta no servidor RPC sobre HTTP, o proxy RPC executa uma troca de pacotes especial com o serviço RPC escutando nessa porta para verificar se está disposto a aceitar solicitações por HTTP.

Para obter um exemplo com base nessas configurações de exemplo, se um serviço RPC escutar na porta 4500 no servidor "Data1", mas não tiver chamado uma das RpcServerUseProtseq* funções com ncacn_http, ele rejeitará a solicitação. Esse comportamento fornece proteção adicional para servidores que escutam em uma porta aberta devido a erro de configuração; a menos que o servidor tenha solicitado especificamente para ouvir em RPC sobre HTTP, ele não receberá chamadas originadas de fora do firewall.

As entradas na chave ValidPorts devem ser uma correspondência exata do RPC sobre o servidor HTTP solicitado pelo cliente (não diferencia maiúsculas de minúsculas). Para simplificar o processamento, o proxy RPC não executa a canonicalização do nome fornecido pelo cliente RPC sobre HTTP. Portanto, se o cliente solicitar rosco.microsoft.com e, em ValidPorts, contiver apenas Rosco, o proxy RPC não corresponderá aos nomes, mesmo que ambos os nomes possam se referir à mesma máquina. Além disso, se o endereço IP do Rosco for 66.77.88.99 e o cliente solicitar 66.77.88.99, mas a chave ValidPorts contiver apenas Rosco, o proxy RPC recusará a conexão. Se um cliente pode solicitar o RPC sobre servidor HTTP pelo nome ou pelo endereço IP, insira ambos na chave ValidPorts.

Observação

Embora o RPC esteja habilitado para IPv6, o proxy RPC não oferece suporte a endereços IPv6 na chave ValidPorts. Se o IPv6 for usado para conectar o proxy RPC e o servidor RPC sobre HTTP, somente nomes DNS poderão ser usados.

 

O IIS lê o Enabled e entradas do Registro ValidPorts na inicialização. Além disso, RPC sobre HTTP relê o conteúdo da chave ValidPorts aproximadamente a cada 5 minutos. Se a entrada ValidPorts for alterada, as alterações serão implementadas em 5 minutos.

RPC sobre HTTP v1: O serviço WEB deve ser interrompido e reiniciado usando o Internet Service Manager para que novos valores nas entradas do Registro sejam implementados.