RPC sobre recomendações de implantação HTTP

Esta seção documenta as práticas recomendadas e as configurações de implantação recomendadas para alcançar a máxima segurança e desempenho ao usar o RPC via HTTP. As várias configurações encontradas aqui se aplicam a diferentes organizações com base em vários requisitos de tamanho, orçamento e segurança. Cada configuração também fornece considerações de implantação úteis para determinar qual é o melhor para um determinado cenário.

Para obter informações sobre O RPC de alto volume em cenários HTTP, consulte Balanceamento de Carga do Microsoft RPC.

As seguintes recomendações se aplicam a todas as configurações:

• Use versões do Windows que dão suporte a RPC via HTTP v2.
• Coloque o IIS no computador que executa o Proxy RPC no modo IIS 6.0.
• Não permitir acesso anônimo ao diretório virtual do Proxy RPC.
• Nunca habilite a chave do Registro AllowAnonymous.
• Faça com que seu RPC sobre clientes HTTP use o CertificateSubjectField (consulte RpcBindingSetAuthInfoEx para obter mais informações) para verificar se o Proxy RPC ao qual você se conectou é o Proxy RPC esperado.
• Configure a chave do Registro ValidPorts para conter apenas os computadores aos quais os clientes RPC por HTTP se conectarão.
• Não use curingas na chave ValidPorts ; Fazer isso pode economizar tempo, mas uma máquina completamente inesperada também pode se ajustar ao curinga.
• Use SSL no RPC em clientes HTTP. Se as diretrizes definidas nestas seções forem seguidas, o cliente RPC por HTTP não poderá se conectar sem usar o SSL.
• Configure o RPC em clientes HTTP para usar a Criptografia RPC, além de usar o SSL. Se o cliente RPC por HTTP não puder acessar o KDC, ele poderá usar apenas Negotiate e NTLM.
• Configure computadores cliente para usar o NTLMv2. Defina a chave do Registro LMCompatibilityLevel como 2 ou superior. Consulte msdn.microsoft.com para obter mais informações sobre a chave LMCompatibilityLevel .
• Execute um farm da Web de computadores proxy RPC com a configuração descrita acima.
• Implante um firewall entre a Internet e o Proxy RPC.
• Para obter o desempenho ideal, configure o IIS para enviar uma resposta curta para códigos de erro sem êxito. Como o consumidor da resposta do IIS é um processo automatizado, não há necessidade de que explicações amigáveis sejam enviadas ao cliente; eles serão simplesmente ignorados pelo RPC sobre o cliente HTTP.

As metas básicas do Proxy RPC de uma perspectiva de segurança, desempenho e capacidade de gerenciamento são as seguintes:

• Forneça um único ponto de entrada para RPC sobre o tráfego HTTP na rede do servidor. Ter um único ponto de entrada para RPC sobre o tráfego HTTP em uma rede de servidor tem dois benefícios main. Primeiro, como o Proxy RPC está voltado para a Internet, a maioria das organizações isola esses computadores em uma rede especial chamada rede de perímetro não confiável que é separada da rede organizacional normal. Os servidores em uma rede de perímetro não confiável são cuidadosamente gerenciados, configurados e monitorados para serem capazes de resistir a ataques da Internet. Quanto menos computadores em uma rede de perímetro não confiável, mais fácil será configurar, gerenciar, monitorar e mantê-los seguros. Em segundo lugar, como um único Web Farm com proxies RPC instalados pode atender a qualquer número de RPC por servidores HTTP que residem na rede corporativa, faz muito sentido separar o Proxy RPC do RPC por servidor HTTP e fazer com que o Proxy RPC resida em uma rede de perímetro não confiável. Se o Proxy RPC estivesse no mesmo computador que o RPC sobre o servidor HTTP, as organizações seriam forçadas a colocar todos os seus servidores de back-end em uma rede de perímetro não confiável, o que tornaria muito mais difícil manter a rede de perímetro não confiável segura. Separar a função do Proxy RPC e do RPC sobre o servidor HTTP ajuda as organizações a manter o número de computadores em uma rede de perímetro não confiável gerenciável e, portanto, mais segura.
• Serve como um fusível de segurança para a rede do servidor. O Proxy RPC foi projetado como um fusível dispensável para a rede do servidor – se algo der errado no Proxy RPC, ele simplesmente sairá e, portanto, protegerá o RPC real por servidor HTTP. Se as práticas recomendadas descritas nesta seção tiverem sido seguidas até agora, o RPC sobre tráfego HTTP será criptografado com criptografia RPC além do SSL. A criptografia RPC em si está entre o cliente e o servidor, não entre o cliente e o proxy. Isso significa que o proxy não entende e não pode descriptografar o tráfego RPC que recebe. Ele só entende algumas sequências de controle enviadas a ele pelo cliente que lida com o estabelecimento da conexão, o controle de fluxo e outros detalhes de túnel. Ele não tem acesso aos dados que o RPC por cliente HTTP envia ao servidor. Além disso, o cliente RPC por HTTP deve autenticar-se independentemente no Proxy RPC e no RPC por servidor HTTP. Isso fornece defesa em profundidade. Se o computador proxy RPC ficar comprometido, devido a algum erro de configuração ou uma violação de segurança de algum tipo, os dados que passam por ele ainda estarão seguros contra adulteração. Um invasor que obteria o controle do Proxy RPC pode, no máximo, interromper o tráfego, mas não lê-lo ou adulterar. É aí que entra em jogo a função de fusível do Proxy RPC – ele é dispensável sem que a segurança do RPC sobre o tráfego HTTP seja comprometida.
• Distribua algumas das verificações de acesso e o trabalho de descriptografia entre vários computadores que executam o Proxy RPC em um Web Farm. Ao funcionar bem em um Web Farm, o Proxy RPC permite que as organizações descarreguem a descriptografia de SSL e algumas das verificações de acesso, liberando assim mais capacidade no servidor de back-end para processamento. O uso de um Web Farm de computadores proxy RPC também permite que uma organização aumente sua capacidade de resistir a ataques de Negação de Serviço (DoS) aumentando a capacidade em seus servidores front-end.

Dentro das diretrizes estabelecidas até agora, as organizações ainda têm opções. Cada organização tem opções e comprometimentos entre inconveniência, segurança e custo do usuário:

• Usar a Autenticação Básica ou a Autenticação Integrada do Windows para autenticar-se no Proxy RPC? Atualmente, o RPC via HTTP dá suporte apenas a NTLM – ele não dá suporte a Kerberos. Além disso, se houver um Proxy HTTP ou um firewall entre o cliente RPC por HTTP e o Proxy RPC que insere o via pragma no cabeçalho HTTP, a autenticação NTLM não funcionará. Quando esse não é o caso, as organizações podem escolher entre a autenticação Básica e a NTLM. A vantagem da autenticação Básica é que ela é mais rápida e simples e, portanto, oferece menos oportunidades para ataques de negação de serviço. Mas o NTLM é mais seguro. Dependendo das prioridades de uma organização, ela pode escolher Básico, NTLM ou permitir que seus usuários escolham entre os dois. Se apenas um for escolhido, é melhor desativar o outro do diretório virtual proxy RPC para reduzir o risco de ataque.
• Use o mesmo conjunto de credenciais para o Proxy RPC e o RPC sobre o servidor HTTP ou use credenciais diferentes para cada um? A compensação para essa decisão é entre a conveniência e a segurança do usuário. Poucos usuários gostam de inserir várias credenciais. No entanto, se ocorrer uma violação de segurança em uma rede de perímetro não confiável, ter conjuntos separados de credenciais para o Proxy RPC e o RPC sobre o servidor HTTP fornecerá proteção adicional. Observe que, se credenciais separadas forem usadas e um conjunto de credenciais for as credenciais de domínio do usuário, será aconselhável usar as credenciais de domínio do usuário para o RPC sobre o Servidor HTTP e não para o Proxy RPC.