RPC via Segurança HTTP

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

• Fornece segurança por meio do IIS (disponível apenas para RPC via HTTP v2).
• Fornece criptografia SSL e verificação de Proxy RPC (autenticação mútua). Também disponível somente no RPC via HTTP v2.
• Fornece restrições no nível do Proxy RPC, ditando quais computadores na rede do servidor têm permissão para receber RPC por chamadas HTTP.

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

Autenticação do IIS

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

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 do Diretório e clique no botão Editar no grupo de Autenticação e Controle de Acesso do, conforme ilustrado aqui:

Embora você possa usar o RPC via HTTP mesmo quando o diretório virtual do Proxy RPC permitir 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 via HTTP, habilite a Autenticação Básica, a Autenticação Integrada do Windows ou ambas. Lembre-se de que somente o RPC via HTTP v2 é capaz de se autenticar no Proxy RPC que exige autenticação básica ou integrada ao Windows; O RPC via HTTP v1 não poderá se conectar se não permitir que de Acesso Anônimo esteja desabilitado. Como o RPC via HTTP v2 é a implementação mais segura e robusta, o uso de uma versão do Windows que dá suporte a ele melhorará a segurança de suas instalações.

Nota

Por padrão, o diretório virtual do proxy RPC é marcado para permitir o 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

O RPC via HTTP pode criptografar o tráfego entre o RPC por cliente HTTP e o proxy RPC com SSL. O tráfego entre o proxy RPC e o RPC no servidor HTTP é criptografado usando mecanismos de segurança RPC normais e não usa SSL (mesmo que o 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 RPC sobre o cliente HTTP e o proxy RPC, que geralmente viaja pela Internet, pode ser criptografado com SSL, além de qual mecanismo de criptografia foi escolhido para RPC. Nesse caso, o tráfego na parte da Internet da rota se torna duplamente criptografado. Criptografar o tráfego por meio do proxy RPC fornece uma defesa secundária, caso o proxy RPC ou outros computadores na rede de perímetro estejam comprometidos. Como o proxy RPC não pode descriptografar a camada de criptografia secundária, o proxy RPC não tem acesso aos dados enviados. Consulte RPC sobre recomendações de implantação HTTP para obter mais informações. A criptografia SSL só está disponível com RPC via HTTP v2.

Restringindo o RPC em chamadas HTTP para determinados computadores

A configuração de segurança do IIS é baseada em intervalos de portas e computadores permitidos. A capacidade de usar o RPC via HTTP é controlada por duas entradas de 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 túnel RPC por chamadas HTTP não pode acessar nenhum processo de servidor RPC, exceto o RPC sobre processos de servidor HTTP em execução no mesmo computador que o proxy RPC. Se o sinalizador ENABLED não estiver definido ou definido como um valor zero, o IIS desabilita o proxy RPC. Se o sinalizador ENABLED for definido e definido como um valor diferente de zero, um cliente poderá se conectar ao RPC por servidores HTTP no computador que executa o IIS. Para permitir que o cliente faça o túnel para um RPC por meio do processo de servidor HTTP em outro computador, você deve adicionar uma entrada de registro à lista de RPC do computador IIS por servidores HTTP.

Os servidores RPC não podem aceitar RPC por chamadas HTTP, a menos que eles solicitaram especificamente que o RPC escutasse no RPC por 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 usa o seguinte formulário: Rosco:593; Rosco:2000-8000; Data*:4000-8000.

Neste exemplo, o IIS pode encaminhar rpc por chamadas HTTP para o servidor "Rosco" nas portas 593 e 2000 a 8000. Ele também pode enviar chamadas para qualquer servidor cujo nome começa com "Dados". Ele se conectará nas portas 4000 a 8000. Além disso, antes de encaminhar o tráfego para uma determinada porta no RPC por servidor HTTP, o proxy RPC executa uma troca de pacotes especial com o serviço RPC escutando nessa porta para verificar se ele está disposto a aceitar solicitações via 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 funções deRpcServerUseProtseq* com ncacn_http, rejeitará a solicitação. Esse comportamento fornece proteção adicional para servidores que escutam em uma porta aberta devido a um erro de configuração; a menos que o servidor tenha solicitado especificamente escutar no RPC por HTTP, ele não receberá chamadas provenientes de fora do firewall.

As entradas no ValidPorts chave 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 canonização do nome fornecido pelo RPC sobre o cliente HTTP. Portanto, se o cliente solicitar rosco.microsoft.com e, em ValidPorts conter apenas Rosco, o proxy RPC não corresponderá aos nomes, mesmo que ambos os nomes possam se referir 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 conter Rosco apenas, o proxy RPC recusará a conexão. Se um cliente puder solicitar o RPC pelo servidor HTTP pelo nome ou por endereço IP, insira ambos na chave ValidPorts.

Nota

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

 

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

RPC via HTTP v1: o 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.