INTRANETS Seguras e Expansíveis com GET VPN

O termo VPN (Virtual Private Network) é utilizado para representar tecnologias que se propõem a emular as características de uma rede privada mesmo quando os dados são transportados sobre uma infra-estrutura compartilhada.  A motivação comum às várias soluções de VPN é prover uma alternativa ecomonicamente viável aos circuitos dedicados de comunicação WAN, sem comprometer os aspectos de segurança.

Mas o termo segurança é abrangente e pode representar recursos bem distintos quando considerado sob a perspectiva de cada tecnologia analisada. As duas modalidades mais comuns de VPN (IPSec e MPLS-VPN) são otimizadas para resolver problemas complementares e possuem desafios também complementares.

A arquitetura de segurança  IPSec provê respostas para as questões de criptografia de dados, integridade, autenticação e gerenciamento de chaves criptográficas. E tudo isso é feito através de protocolos e algoritmos padronizados, fato este que a tornou uma referência quase onipresente quando o assunto é VPN. No entanto, o modelo IPSec prevê o uso de negociações ponto-a-ponto entre as partes comunicantes e encontra desafios, principalmente de roteamento, quando precisa ser implantada em larga escala.

Já o serviço MPLS-VPN provê a segmentação lógica da Rede de transporte e roteamento otimizado (any-to-any)  mas não traz qualquer definição associada à classe de disciplinas tratadas pelo framework IPSec.

Diante das capacidades expostas, consideremos agora a demanda de montar a Intranet de uma grande empresa que usa Comunicações Unificadas IP entre seus sites (interesse de tráfego any-to-any) mas que, para atender a regulamentações de seu segmento de mercado, precisa lançar mão dos benefícios providos pelo IPSec (especialmente criptografia de dados).

Em primeira análise, duas respostas simplistas poderiam ser apresentadas:

  • Montar sessões IPSec ponto-a-ponto entre cada entidade remota e o site central. Tal abordagem não seria satisfatória, pois poderia comprometer a meta de delay aceitável (150ms) para o tráfego de voz. Além disso, estaríamos abrindo mão da conectividade full-mesh que caracteriza o MPLS.
  • Configurar sessões (túneis) entre cada dois pontos remotos, de modo a evitar a passagem pela localidade central.  Além de ser praticamente ingerenciável sob o ponto-de-vista de configuração, um tal cenário ainda exigiria que cada gateway de VPN remoto (tipicamente um roteador) suportasse um número muito grande de túneis simultâneos, o que implicaria aumento de custo.

Se a mera sobreposição do IPSec ao MPLS não atende as necessidades especificadas, por que não desenvolver uma tecnologia que utilize as definições IPSec sem dispensar a conectividade otimizada provida pelo MPLS ?

Foi exatamente o que a Cisco fez… Tomando por base a RFC 3547 (Group Domain of Interpretation – GDOI) e assumindo a premissa de que para Intranets não é necessário se preocupar com a questão de esconder o endereçamento IP privado, foi criada tecnologia Group Encrypted Transport VPN (GET VPN), cujas características essenciais são elencadas a seguir:

  • Criação de Security Associations para grupos de gateways em vez do tradicional ponto-a-ponto.  Tal escolha se justifica, pois no âmbito de Intranets assume-se que os gateways VPN participantes possuem o mesmo nível de confiança. O controle de admissão de um gateway (Group Member, no contexto GET VPN) a um grupo é efetuado por uma nova entidade denominada Key Server, a qual também é responsável por distribuir, de forma centralizada, as chaves e políticas de criptografia  a serem usadas pelos membros do grupo.
  • Preservação do cabeçalho IP no pacote cifrado, sem mudar o formato do pacote IPSec (ESP) padronizado. Isso significa que um pacote criptografado com GET VPN é um caso particular de IPSec e, portanto, permite o aproveitamento de todos os algoritmos e hardwares criptográficos construídos para a tradicional tecnologia de VPN.

    GET VPN: Preservação do Cabeçalho IP

Alguns benefícios decorrem naturalmente das definições básicas de GET VPN:

  1. A preservação do cabeçalho garante que os pacotes cifrados usem o mesmo roteamento dos pacotes não-cifrados, dispensando assim a criação de uma nova camada de roteamento para o tráfego VPN.
  2. O valor do campo DSCP é automaticamente copiado para o header IP externo e, portanto,  o investimento em QoS (classificação e marcação) continua válido para o tráfego cifrado.
  3. Pode-se contabilizar a utilização da rede, por usuário, independentemente dos pacotes serem cifrados, o que representa um ganho de visibilidade em relação ao IPSec tradicional.
  4. Dado que os Group Members possuem a chave para decifrar o tráfego enviado por qualquer membro do grupo, torna-se natural e direta a distribuição de conteúdo multicast com criptografia (de forma idêntica à que se faria para tráfego não cifrado). Ressalte-se aqui que o GET VPN é a primeira tecnologia a vencer tal desafio.
  5. O gerenciamento de políticas de criptografia é bastante facilitado, pois é feito pelo Key Server de maneira centralizada. Isso é particularmente relevante para os provedeores de serviço que não mais necessitam configurar túneis VPN e definições de interesse de tráfego cifrado em centenas de equipamentos.

    Relações entre os elementos GET VPN (KS e GM)

Um aspecto crítico a se manter em mente é que um roteador habilitado para tal solução não deixa de dispor dos recursos do IPSec clássico. Pode-se empregar GET VPN para a montagem de um grupo Intranet e, ao mesmo tempo, IPSec tradicional para uma conexão Internet segura. Outro ponto relevante é que um mesmo roteador pode participar simultaneamente de vários grupos distintos, permitindo, assim que se obtenha uma solução simples de isolamento de departamentos dentro de uma mesma empresa.

Para obter mais informações sobre o assunto GET VPN, visite o portal:

http://www.cisco.com/go/getvpn

About these ads

Leave a comment

Filed under Português, Redes, Segurança

Comments are closed.