Considerações para publicação de aplicações via proxy reverso

Saudações,

Ao trabalhar no design de soluções e implementação de projetos na parte de segurança para infra Microsoft, tenho tentado montar ambientes visando o melhor cenário possível e nestes casos, não temos muito que falar. É questão de planejar, executar e gerenciar de forma a manter a idéia inicial e o bom andamento do ambiente.

Por outro lado, também analiso ambientes já em operação e ainda fico pasmo com tantos erros na concepção e planejamento dos ambientes. As vezes a economia alcançada na implementação se torna um custo altíssimo no dia a dia do cliente.

Quando o assunto é a publicação de aplicações para acessos externos, a preocupação com segurança deve ser o ítem principal a ser considerado. Por isso a importância do proxy reverso.

O proxy reverso visa proteger aplicações nos acessos externos para que o servidor de aplicação propriamente dito, não fique exposto diretamente na internet.

O uso desta solução tem se tornado constante nas corporações, muito disso por erros do passado onde muitos ambientes invadidos tiveram dados importantes roubados.

Alguns clientes exageram e publicam o acesso a suas aplicações também para requisições internas. Por uma questão de performance, recomendo o acesso direto pelo próprio DNS.

Para publicação de OWA (Outlook Web Access), Lync Server ou SharePoint, recomendo uma topologia mais ou menos como a do desenho abaixo:

Neste desenho vemos uma estrutura de publicação do OWA onde o acesso externo passa por regras de publicação em servidores de proxy reverso (podendo ser Forefront TMG, Forefront UAG, Web Application Proxy ou Application Request Routing), se autentica nos servidores AD e envia a requisição para a infra de servidores Exchange.

O acesso interno não usa o proxy reverso e vai pelo DNS diretamente ao servidor Exchange.

Desta forma, se garante a proteção para os acessos externos e também rapidez nos internos.

Podemos tomar como exemplo este mesmo desenho para publicação de Lync Server e até mesmo para qualquer tipo de aplicação web.

Também considere essa idéia quando for publicar servidores (RDP por exemplo), mas, para este caso em específico, ainda considero mais seguro faze-lo por meio de um acesso VPN.

Use sempre certificado digital

Não foram poucos os lugares que vi aplicações importantes sendo publicadas na WEB sem certificado digital. Pode ser uma recomendação exagerada, tendo em vista o uso sólido do acesso via SSL, mas, ainda assim, prefiro pecar pelo exceço, pois, dando consultoria por aí, a gente se surpreende com o que se vê.

Caso vc não tenha um ambiente CA (Certificate Authority) em sua empresa, vc pode adquirir por entidades certificadoras tais como Certsign.

O melhor investimento se dá na compra de certificados do tipo WildCard – certificados com purpose *.dominio.com – exemplo: *.uilson.net

Este certificado valerá para qualquer aplicação dentro de um domínio. Eles costumam ser mais caros, mas, tem prazo de expiração de 3 anos.

Caso vc tenha mais de um domínio a publicar, vc pode comprar um certificado como o exposto, com a diferença de poder adicionar quantos domínios precisar no purpose do mesmo.

Compartilhamento de aplicações via empresas parceiras

Neste caso, recomendo descartar o uso do proxy reverso. Se sua empresa confia totalmente na parceira para determinadas operações que envolvam o uso de uma aplicação, seria mais interessante um trust relationship entre domínios usando o Active Directory Federation Services (AD FS).

Se sua empresa compartilha o acesso a uma aplicação com apenas um único parceiro externo, o AD FS provê a segurança e a restrição necessária para que todas as brechas possíveis sejam mitigadas.

Espero que as recomendações acima possam ser úteis!

Um abraço

Uilson

CooperaTI

Administrador e coordenador do site!

k2cloud.com.br