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 na proteção da RPC sobre tráfego HTTP uma vez por RPC e, em seguida, duplamente pelo mecanismo de encapsulamento fornecido por RPC sobre HTTP. Para obter uma descrição dos mecanismos de segurança RPC padrão, consulte Segurança. O mecanismo de encapsulamento RPC sobre HTTP é adicional à segurança RPC normal da seguinte maneira:

• Fornece segurança por meio 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 computadores 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 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 do MMC do IIS:

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

Embora você possa usar RPC sobre HTTP mesmo quando o diretório virtual do Proxy RPC permitir o acesso anônimo, a Microsoft recomenda 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 somente o RPC sobre HTTP v2 pode se autenticar no Proxy RPC que requer autenticação básica ou integrado ao Windows. RPC sobre HTTP v1 não poderá se conectar se Não permitir acesso anônimo estiver desabilitado. Como o RPC sobre HTTP v2 é a implementação mais segura e robusta, o uso de uma versão do Windows com suporte melhorará a segurança de suas instalações.

Observação

Por padrão, o diretório virtual do 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.

 

Criptografia 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 se o SSL entre o cliente e o proxy RPC for escolhido). Isso ocorre porque essa parte do tráfego viaja dentro da rede de uma organização e é protegida por um firewall.

O tráfego entre o cliente RPC sobre HTTP e o proxy RPC, que geralmente trafega 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 por meio do proxy RPC fornece uma defesa secundária, caso o proxy RPC ou outros computadores na rede de perímetro sejam comprometidos. 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 Recomendações de implantação de RPC sobre HTTP para obter mais informações. A criptografia SSL está disponível somente com RPC sobre HTTP v2.

Como restringir RPC sobre chamadas HTTP para determinados computadores

A configuração de segurança do IIS é baseada nos 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. A segunda é uma lista opcional de computadores para os quais o proxy pode encaminhar chamadas RPC.

Por padrão, um cliente que entra em contato com o proxy RPC para encapsular chamadas RPC sobre HTTP não pode acessar nenhum processo de servidor RPC, exceto os processos de servidor RPC sobre HTTP em execução no mesmo computador que o proxy RPC. Se o sinalizador ENABLED não estiver definido ou for definido como zero, o IIS desabilitará o proxy RPC. Se o sinalizador ENABLED for 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 tenham solicitado a RPC especificamente para ouvir 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 tem a seguinte forma: Rosco:593;Rosco:2000-8000;Data*:4000-8000.

Neste exemplo, o IIS pode encaminhar chamadas RPC sobre HTTP para o servidor "Rosco" nas portas 593 e 2000 a 8000. Ele também pode enviar chamadas para qualquer servidor cujo nome comece com "Dados". Ele se conectará às 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 ouvindo nessa porta para verificar se ele está disposto a aceitar solicitações por HTTP.

Para obter um exemplo com base nessas configurações de exemplo, se um serviço RPC ouvir na porta 4500 no servidor "Data1", mas não tiver chamado uma das funções RpcServerUseProtseq* com ncacn_http, ele rejeitará a solicitação. Esse comportamento fornece proteção adicional para servidores que ouvem em uma porta aberta devido a um erro de configuração. A menos que o servidor seja especificamente solicitado a 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 servidor RPC sobre HTTP solicitado pelo cliente (não diferencia maiúsculas de minúsculas). Para simplificar o processamento, o proxy RPC não executa a canonização do nome fornecido pelo cliente RPC sobre HTTP. Portanto, se o cliente solicitar rosco.microsoft.com e ValidPorts contiver somente Rosco, o proxy RPC não corresponderá aos nomes, ainda que ambos os nomes se refiram ao mesmo computador. 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 somente Rosco, o proxy RPC recusará a conexão. Se um cliente puder solicitar o servidor RPC sobre HTTP por nome ou por 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ê as entradas do registro Enabled e 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 dentro de 5 minutos.

RPC sobre HTTP v1: i serviço WEB deve ser interrompido e reiniciado usando o Gerenciador de Serviços de Internet para novos valores nas entradas do registro a serem implementadas.