• Artigo

Security WatchAcesso seguro em qualquer lugar

John Morello

Uma das tendências evidentes da tecnologia atual é a existência de uma força de trabalho cada vez mais conectada e móvel. Muitas organizações têm pessoal que opera de escritórios distantes, trabalha à distância ou costuma viajar para visitar clientes. A autonomia desses usuários para acessar facilmente aplicativos e dados, independente do local, torna-os mais

produtivos. Entretanto, até recentemente, a possibilidade de acesso remoto seguro costumava implicar a instalação de software de cliente, a digitação de comandos ocultos e a demora na conexão.

Com o passar dos anos, surgiram várias abordagens que transformaram o acesso remoto em uma tecnologia mais simples e mais acessível. Por exemplo, o OWA (Outlook® Web Access) oferece uma forma simples, baseada em navegador, para usuários acessarem e-mails, calendário e contatos, sem as complexidades de uma VPN (Rede Virtual Privada) completa de Camada 3. Apesar de tecnologias como o OWA oferecerem uma parte importante de uma solução de "acesso em qualquer lugar", a maioria das organizações possuem vários aplicativos-chave que não permitem o mesmo tipo de experiência de navegador integrado. Nesses casos, soluções como os Serviços de Terminal oferecem um método eficaz de conceder aos usuários o acesso aos seus aplicativos de qualquer lugar.

No Windows Server® 2008, a Microsoft aperfeiçoou o recurso "pronto para usar" definido nos Serviços de Terminal. Os Serviços de Terminal agora incluem uma janela perfeita, o recurso de publicação por aplicativo chamado RemoteApp, a capacidade do driver de impressão universal no EasyPrint e um portal baseado em navegador chamado TS Web Access. Adicionalmente, e essencial para o cenário de acesso em qualquer lugar, o Windows Server 2008 também inclui o componente TS Gateway que oferece o encapsulamento SSL para o Protocolo RDP, permitindo que ele atravesse firewalls de forma fácil e segura, e dispositivos NAT (Conversão de endereços de rede). O recurso TS Gateway também é integrado a outra nova tecnologia no Windows Server 2008, a NAP (Proteção contra Acesso à Rede), para oferecer inspeção de integridade ao ponto de extremidade do cliente. A combinação de todos esses componentes levam as organizações a criar soluções que permitem aos usuários acessar seus aplicativos e dados de qualquer lugar com facilidade e segurança.

Esta coluna destaca os aspectos da rede e do design de segurança em uma solução de acesso em qualquer lugar, em vez de fornecer detalhes sobre o gerenciamento de componentes de Serviços de Terminal. Descreverei os métodos e práticas recomendadas para criar uma solução com base em tecnologia incluída no Windows Server 2008.

Qual é o problema de redes virtuais privadas de Camada 3?

Ao pensar em uma nova tecnologia, é importante compreender suas vantagens com base nas abordagens atuais; assim, você consegue avaliar com precisão o valor do novo modelo. No caso da VPN de Camada 3, em geral há dois problemas principais a serem resolvidos: segurança e facilidade de uso.

Pode parecer insensato listar a segurança como um problema em meio a tantas VPNs de Camada 3. Afinal, a VPN não tem por objetivo oferecer um encapsulamento seguro através da Internet? Para compreender melhor isso, vamos pensar no que você considera como possíveis ameaças da VPN. Isso não significa que dados transmitidos por essas VPNs correm o risco de interceptação ou violação; a maioria das VPNs de Camada 3 apresentam excelente criptografia do fluxo de dados. Você deve pensar nas ameaças oferecidas por máquinas remotas que têm total acesso a "todas as portas, todos os protocolos" da rede da sua empresa. O problema não são os fluxos de dados que VPNs de Camada 3 criptografam e transportam na rede. Os clientes remotos que se conectam a esses encapsulamentos é que podem colocar em risco sua rede interna. Lembre-se de que a maioria das empresas afetadas por malware como Slammer ou Blaster não foram infectadas por máquinas na sua rede interna, nem por hackers que atravessam seus firewalls. Em vez disso, a infestação ocorreu via trabalhadores remotos que se conectaram às suas redes em VPNs de máquinas infectadas. Quando essas VPNs criam conexões de Camada 3, totalmente roteadas, a máquina remota costuma ter o mesmo acesso (bom e ruim) a recursos internos que uma máquina localizada no chão do centro de dados.

Além disso, a operação de VPNs de Camada 3 costuma ser cara pois elas exigem instalação e configuração de software em máquinas que não são gerenciadas pelo grupo de TI de uma empresa. Por exemplo, a instalação de um cliente VPN na máquina principal de um usuário pode envolver a criação de pacotes de instalação personalizados, orientações detalhadas sobre instalação para o usuário e solução de conflitos em aplicativos na máquina do usuário. Além disso, custos de gerenciamento podem ser altos quando é necessário implantar novas versões do cliente ou quando há alteração nos dados de configuração (como a adição de um novo ponto de extremidade de VPN). Usuários costumam encarar o trabalho com esta VPN como uma experiência não-intuitiva. Como ela só oferece conexão de Camada 3, os aplicativos comerciais do usuário e seus dados não são facilmente acessáveis e visíveis.

Solução de problemas em Serviços de Terminal

Serviços de Terminal, e outras tecnologias VPN de Camada 7 ou de camada de aplicativo, resolvem esses dois problemas permitindo um maior controle sobre os recursos e protocolos que usuários podem acessar e tornando a experiência do usuário final bem mais simples e intuitiva do que antes.

Do ponto de vista da segurança, o recurso diferenciador mais importante entre uma abordagem VPN de Camada 3 e outra que utiliza Serviços de Terminal e TS Gateway é que a conexão à rede interna não é um pipeline totalmente aberto. Para ser mais específico, uma abordagem de Camada 3 cria uma interface virtual na máquina local com capacidade de roteamento total para a rede interna. Já a abordagem TS Gateway só permite que pacotes baseados em RDP atinjam a rede interna. Então, a superfície geral de ataque é muito reduzida e controles mais granulares podem ser aplicados dentro do RDP. Por exemplo, apesar de o RDP fornecer suporte original para redirecionamento de unidade, empresas podem configurar seus TS Gateways para integrá-los à NAP e não permitir a utilização desse recurso, a menos que a máquina remota possa provar que seu software antivírus estava atualizado.

Para usuários finais, a diferença mais óbvia entre uma VPN de Camada 3 e uma abordagem baseada em Serviços de Terminal é uma configuração bem mais simples (em geral, não há uma configuração), além do acesso mais fácil e intuitivo aos seus aplicativos e dados. Como o cliente de Conexão de Área de Trabalho Remota é incorporado ao Windows (e mantido atualizado através de tecnologias de serviço normal como o Windows® Update), em geral, não há software de cliente a ser instalado. Além disso, ao alavancar o TS Web Access, usuários podem visitar uma única URL para localizar seus aplicativos e dados. Basta clicar no aplicativo apropriado para iniciar o TS Gateway, encapsulando com segurança a conexão à Internet. Dessa forma, o aplicativo é enviado diretamente para a área de trabalho do usuário. Ou seja, o aplicativo terá a aparência e o comportamento de um aplicativo instalado localmente, inclusive com a capacidade de copiar, colar e minimizar a barra de tarefas. Ao tornar aplicativos e dados mais detectáveis e a configuração instantânea, uma abordagem baseada em Servidores de Terminal para acesso remoto consegue de fato aumentar a satisfação do cliente e reduzir custos de suporte.

Opções de arquitetura de rede

Há duas abordagens básicas de design de rede que podem ser utilizadas para disponibilizar um servidor TS Gateway na Internet. A primeira encaixa o TS Gateway na rede de perímetro entre dois firewalls de Camada 3/4. A segunda mantém o TS Gateway na rede interna e utiliza um firewall na camada do aplicativo (como Microsoft® ISA Server, Microsoft Intelligent Application Gateway ou diversas soluções de terceiros) para trabalhar sobre a rede de perímetro e inspecionar quadros HTTPS de entrada. Somente após a análise dessas sessões de entrada é que os pacotes são encaminhados ao servidor TS Gateway interno.

Se uma empresa só possui firewalls de Camada 3/4 com inspeção básica de pacote com monitoração de estado, o dispositivo TS Gateway pode ser colocado diretamente na rede de perímetro, conforme mostrado na Figura 1. Neste projeto, o firewall da Internet restringe a conectividade do TS Gateway para permitir que apenas tráfego HTTPS da Internet o alcance. Contudo, o firewall não inspeciona a camada de aplicativo desse tráfego; ele simplesmente encaminha o tráfego para o TS Gateway. Em seguida, o servidor TS Gateway extrai os quadros RDP dos pacotes HTTPS e os encaminha ao servidor back-end adequado. Esses servidores back-end costumam estar separados da rede de perímetro por um segundo firewall, configurado para permitir que quadros RDP do TS Gateway alcancem os servidores internos adequados.

Figura 1 Com um firewall de Camada 3/4, o TS Gateway é colocado na rede de perímetro

Figura 1** Com um firewall de Camada 3/4, o TS Gateway é colocado na rede de perímetro **(Clique na imagem para aumentar a exibição)

Apesar de este cenário ser totalmente suportado e útil para várias empresas, ele possui duas grandes desvantagens. Primeiro, como o TS Gateway recebe tráfego diretamente da Internet, ele está exposto a um nível de risco relativamente maior de pessoas externas mal-intencionadas. Essas pessoas mal-intencionadas podem tentar atacar o gateway através da sessão SSL e, como o firewall front-end só verifica os cabeçalhos, e não as cargas, essas sessões alcançam o gateway. Isso não quer dizer que o TS Gateway é um componente vulnerável; ele passou pelo mesmo projeto e teste rigorosos de segurança que os demais produtos do Windows Server 2008. Entretanto, seu risco relativo é maior neste cenário simplesmente porque ele manipula tráfego não filtrado diretamente da Internet. A segunda grande desvantagem é o aumento na quantidade de tráfego que deve ser permitido entre o gateway e o firewall back-end. Para autenticar usuários, o TS Gateway precisa se comunicar com o Active Directory®. Para permitir essa comunicação, o firewall back-end deve ter exceções para uma maior variedade de portas e protocolos, e não apenas para o HTTPS. Esse nível maior de permissão de comunicação também representa um aumento de risco relativo do projeto.

Uma melhor abordagem para expor um TS Gateway à Internet é a utilização de um firewall de camada de aplicativo (Camada 7) para tratar de sessões HTTPS de entrada antes de elas alcançarem o gateway (ver Figura 2). Neste projeto, ainda podem existir os firewalls de Camada 3/4 tradicionais que constituem uma rede de perímetro. Em vez do TS Gateway, encontramos o firewall Camada 7 no perímetro. Quando o tráfego alcança o firewall de saída, esse firewall filtra tudo, exceto quadros HTTPS e, depois, encaminha esses quadros ao firewall camada 7. O firewall Camada 7 encerra a sessão SSL, inspeciona o conteúdo criptografado do fluxo, bloqueia o tráfego mal-intencionado e, depois, envia os quadros RDP através do firewall back-end para o TS Gateway. Observe que, se você quiser, o firewall Camada 7 também poderá criptografar novamente os quadros antes de enviá-los ao TS Gateway. Talvez esta abordagem não seja necessária na rede privada de uma empresa, mas ela pode ser muito útil em centros de dados hospedados ou redes compartilhadas.

Figura 2 Utilização de um firewall de camada de aplicativo com um dispositivo TS Gateway

Figura 2** Utilização de um firewall de camada de aplicativo com um dispositivo TS Gateway **(Clique na imagem para aumentar a exibição)

Este projeto evita as duas desvantagens da solução anterior. Como o servidor TS Gateway só recebe tráfego inspecionado pelo firewall Camada 7, há menos risco de ataques pela Internet. O firewall Camada 7 deve filtrar esses ataques e enviar apenas tráfego limpo e inspecionado para o gateway.

A segunda grande vantagem dessa solução é o posicionamento do gateway em relação à rede interna. Como o tráfego proveniente da Internet é inspecionado pelo firewall Camada 7 antes de chegar ao gateway, ele pode permanecer na rede interna e ter acesso direto aos controladores de domínio para autenticação e hosts RDP para sessões de usuários. Além disso, o firewall back-end pode ter muito mais políticas restritivas. Em vez de permitir o tráfego de autenticação de RDP e diretório, ele simplesmente precisa permitir sessões RDP do firewall Camada 7 para o TS Gateway. A utilização de um firewall Camada 7 para realizar um front-end de implantação do TS Gateway oferece uma solução mais segura e mais fácil de gerenciar, dispensando a reformulação da rede de perímetro existente.

Integração NAP

Recursos dos Serviços de Terminal

Apesar de um bom projeto de perímetro ser essencial para a solução de acesso em qualquer lugar, também é importante garantir a conformidade e a segurança dos dispositivos de ponto de extremidade. Como o RDP é um protocolo sofisticado, que permite vários tipos de redirecionamento de dispositivos, tais como sessões e impressoras RDP, é fundamental que os clientes conectados à sua solução atendam às políticas de segurança da sua empresa. Por exemplo, mesmo com uma topologia de rede segura, baseada em práticas recomendadas, como aquelas discutidas anteriormente, um usuário final conectado a um servidor de terminal de uma máquina sem segurança ainda pode acabar perdendo dados confidenciais ou tentando incluir arquivos mal-intencionados no servidor de terminal. Apesar de o nível de conectividade e os danos em potencial serem bem menores do que se o usuário estivesse se conectando através de uma VPN de Camada 3, convém gerenciar o risco de perda de dados e garantir a conformidade às políticas de TI.

A NAP (Proteção de Acesso à Rede) é uma nova tecnologia do Windows Server 2008 que permite controlar não apenas quem pode se conectar à rede, mas também os tipos de sistemas através dos quais essas pessoas podem fazer a conexão. Por exemplo, você pode utilizar a NAP para garantir que apenas máquinas com firewalls em execução e antivírus atualizado se conectem à rede. A NAP é uma solução extensível que abrange não apenas a rede interna da empresa, mas também usuários remotos, incluindo aqueles que se conectam através de VPNs de Camada 3 e os que se conectam através do TS Gateway. Ao integrar a NAP ao seu projeto de TS Gateway, você pode garantir que apenas os sistemas que atendam às políticas de segurança possam conectá-lo. Para obter mais detalhes sobre a NAP, consulte a coluna Security Watch na edição de maio de 2007 da TechNet Magazine, disponível online em technetmagazine.com/issues/2007/05/SecurityWatch.

A integração da NAP na implantação de um TS Gateway é um processo simples que envolve um único serviço adicional no design. Este serviço, o NPS (servidor de política de rede), pode ser instalado no próprio servidor TS Gateway ou em uma instância separada do sistema operacional. O TS Gateway MMC é utilizado para criar CAPs (Diretivas de Autorização de Conexão) que definem os recursos RDP permitidos para determinado estado de saúde. O servidor TS Gateway é configurado para verificar o NPS a cada nova tentativa de conexão e para encaminhar a SoH (Declaração de Integridade) para essa conexão ao NPS. O NPS compara a SoH às políticas e informa ao TS Gateway se a conexão deve ou não ser permitida, com base na integridade do cliente.

Conforme ilustrado na Figura 3, se um sistema incompatível não está configurado para utilizar o Windows Update, mas a política de segurança da empresa exige a habilitação de atualizações automáticas, quando um usuário tenta se conectar ao TS Gateway, sua máquina gera e encaminha uma SoH. Essa SoH informa algo como: "Meu firewall está ativado e meu antivírus está atualizado, mas as atualizações automáticas estão desativadas." O TS Gateway simplesmente encaminha essa SoH ao NPS (o TS Gateway não tem lógica para decodificar por si só a SoH) e o NPS compara a SoH às políticas definidas por seu administrador. Como as atualizações automáticas estão desativadas, o NPS determina que a conexão seguiu a política "incompatível" e informa ao TS Gateway que ele não deve permitir a conexão. O TS Gateway descarta a conexão e notifica ao usuário que a máquina não atendeu às políticas de segurança da empresa. O usuário adota a medida corretiva necessária (no caso, ativa as atualizações automáticas) e faz nova tentativa de conexão. Como resultado, é gerada uma nova SoH, o NPS determina a conformidade e o TS Gateway permite que a conexão prossiga.

Figura 3 Apenas sistemas compatíveis podem se conectar

Figura 3** Apenas sistemas compatíveis podem se conectar **(Clique na imagem para aumentar a exibição)

Conclusão

O Windows Server 2008 inclui os fundamentos para uma solução de acesso seguro em qualquer lugar. O TS Gateway apresenta um método seguro para encapsular sessões de áreas de trabalho remotas através da Internet e oferece às empresas uma ótima opção de integração às redes existentes. As opções incluem o posicionamento do TS Gateway diretamente na rede de perímetro ou a utilização de um firewall de Camada 7, como o ISA Server ou o Intelligent Application Gateway, na sua frente. A NAP pode ser associada ao TS Gateway para acrescentar à solução recursos de inspeção de integridade do ponto de extremidade. As verificações de ponto de extremidade permitem que empresas garantam não apenas que conexões remotas sejam geradas por usuários válidos, mas também que elas sejam geradas por máquinas que seguem as políticas de segurança da TI. Quando associadas, essas tecnologias oferecem às empresas recursos de acesso remoto com operação mais segura e mais eficaz, e isso permite aos usuários finais ter experiências melhores. Saiba mais sobre o assunto explorando os sites listados na barra lateral "Recursos de Serviços de Terminal".

John Morelloestá na Microsoft desde 2000. Como consultor sênior, criou soluções de segurança para empresas da lista Fortune 100 e para agências federais civis e militares. Atualmente, ele é gerente de programas sênior do grupo Windows Server e trabalha em tecnologias de acesso em qualquer lugar. Leia o blog da equipe dele em blogs.technet.com/WinCAT.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..