Recomendações de implantação RPC sobre 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 RPC sobre HTTP. As várias configurações aqui encontradas 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 cenários de RPC sobre HTTP de alto volume, consulte Microsoft RPC Load Balancing.

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

• Utilize versões do Windows que suportem RPC sobre HTTP v2.
• Coloque o IIS na máquina que executa o Proxy RPC no modo IIS 6.0.
• Não permita acesso anônimo ao diretório virtual do Proxy RPC.
• Nunca habilite a chave do Registro AllowAnonymous.
• Faça com que seus clientes RPC sobre HTTP usem 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 o ValidPorts chave do Registro para conter apenas máquinas às quais os clientes RPC sobre 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 caber no curinga.
• Use SSL em clientes RPC sobre HTTP. Se as diretrizes estabelecidas nestas seções forem seguidas, o cliente RPC sobre HTTP não poderá se conectar sem usar SSL.
• Configure clientes RPC sobre HTTP para usar criptografia RPC além de usar SSL. Se o cliente RPC sobre HTTP não puder acessar o KDC, ele poderá usar apenas Negociar e NTLM.
• Configure máquinas cliente para usar 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 uma web farm de máquinas Proxy RPC com a configuração descrita acima.
• Implante um firewall entre a Internet e o Proxy RPC.
• Para um 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 explicações amigáveis a serem enviadas ao cliente; eles simplesmente serão ignorados pelo cliente RPC sobre HTTP.

Os objetivos básicos do Proxy RPC de uma perspetiva de segurança, desempenho e capacidade de gerenciamento são os seguintes:

• Forneça um único ponto de entrada para o tráfego RPC sobre HTTP na rede do servidor. Ter um único ponto de entrada para o tráfego RPC sobre HTTP em uma rede de servidor tem dois benefícios principais. Primeiro, como o Proxy RPC está voltado para a Internet, a maioria das organizações isola essas máquinas 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 máquinas em uma rede de perímetro não confiável, mais fácil será configurá-las, gerenciá-las, monitorá-las e mantê-las seguras. Em segundo lugar, como uma única Web Farm com Proxies RPC instalados pode atender a qualquer número de Servidores RPC sobre HTTP residentes na rede corporativa, faz muito sentido separar o Proxy RPC do Servidor RPC sobre HTTP e fazer com que o Proxy RPC resida em uma rede de perímetro não confiável. Se o Proxy RPC estivesse na mesma máquina que o Servidor RPC sobre HTTP, as organizações seriam forçadas a colocar todos os seus servidores 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 servidor RPC sobre HTTP ajuda as organizações a manter o número de máquinas em uma rede de perímetro não confiável gerenciável e, portanto, mais seguro.
• Servir como um fusível de segurança para a rede do servidor. O Proxy RPC é projetado como um fusível descartável para a rede do servidor - se algo der errado no Proxy RPC, ele simplesmente sai e, portanto, protege o RPC real sobre o servidor HTTP. Se as práticas recomendadas descritas nesta seção tiverem sido seguidas até agora, o tráfego RPC sobre HTTP será criptografado com criptografia RPC, além de 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 lidam com o estabelecimento da conexão, controle de fluxo e outros detalhes de tunelamento. Ele não tem acesso aos dados que o cliente RPC sobre HTTP envia para o servidor. Além disso, o cliente RPC sobre HTTP deve autenticar-se independentemente no Proxy RPC e no servidor RPC sobre HTTP. Isso proporciona uma defesa em profundidade. Se a máquina de Proxy RPC ficar comprometida, devido a algum erro de configuração ou uma violação de segurança de algum tipo, os dados que passam por ela ainda estarão protegidos 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 adulterá-lo. É aqui que a função de fusível do Proxy RPC entra em jogo – é dispensável sem que a segurança do tráfego RPC sobre HTTP seja comprometida.
• Distribua parte das verificações de acesso e do trabalho de descriptografia entre várias máquinas que executam o Proxy RPC em uma Web Farm. Ao funcionar bem em uma Web Farm, o Proxy RPC permite que as organizações descarreguem a descriptografia SSL e algumas das verificações de acesso, liberando mais capacidade no servidor back-end para processamento. O uso de uma Web Farm de máquinas 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 escolhas. Cada organização tem opções e compromissos entre inconveniência do usuário, segurança e custo:

• Usar a Autenticação Básica ou a Autenticação Integrada do Windows para autenticar no Proxy RPC? Atualmente, RPC sobre HTTP suporta apenas NTLM – não suporta Kerberos. Além disso, se houver um proxy HTTP ou um firewall entre o cliente RPC sobre 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 autenticação Básica e 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 Basic, NTLM ou permitir que seus usuários escolham entre os dois. Se apenas um for escolhido, é melhor desativar o outro do diretório virtual RPC Proxy para reduzir o risco de ataque.
• Usar o mesmo conjunto de credenciais para o Proxy RPC e o Servidor RPC sobre HTTP ou usar credenciais diferentes para cada um? A contrapartida para esta decisão é entre a conveniência e a segurança do utilizador. 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 Servidor RPC sobre 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, é aconselhável usar as credenciais de domínio do usuário para o Servidor RPC sobre HTTP e não para o Proxy RPC.