As VPNs Estão Mortas: O Argumento da Engenharia para o Zero Trust

O perímetro que deixou de existir

O Verizon 2024 Data Breach Investigations Report atribui mais de 80% das violações de aplicações web a roubo ou abuso de credenciais. Os atacantes não fizeram túneis através de firewalls. Simplesmente fizeram login. No entanto, a maioria dos orçamentos de segurança empresarial continua a alocar a maior parte da despesa a uma tecnologia construída para um mundo onde todos os funcionários trabalhavam dentro de um escritório físico: a Rede Privada Virtual (VPN).

Durante vinte anos, a cibersegurança corporativa baseou-se num conceito medieval, o castelo e o fosso. Firewalls e VPNs formavam o fosso. Se um funcionário se autenticava com sucesso no gateway, recebia implicitamente confiança e acesso amplo a toda a rede interna. Esta arquitetura foi desenhada quando o “perímetro” era uma fronteira real e física: a espinha dorsal ethernet do edifício do escritório. Todos os servidores, bases de dados e ferramentas internas viviam dentro desse perímetro, e a VPN era simplesmente um túnel seguro de volta para os raros trabalhadores remotos.

Esse perímetro deixou de existir. Os funcionários usam portáteis pessoais em Wi-Fi de aeroporto. Ferramentas SaaS críticas correm em infraestrutura de terceiros na AWS, Azure e GCP. APIs internas estão distribuídas por contentores que sobem e descem a cada poucos minutos. Quando uma VPN é comprometida, através de uma password roubada, um endpoint comprometido, ou um exploit zero-day no próprio concentrador VPN, o atacante ganha movimento lateral por tudo. Pode enumerar serviços internos tranquilamente, exfiltrar bases de dados e implementar ransomware, tudo sem disparar um único alerta, porque a rede já decidiu confiar nele.

A mudança de paradigma Zero Trust

A resposta arquitetónica está codificada no standard NIST SP 800-207 Zero Trust Architecture. O Zero Trust impõe uma inversão fundamental: nenhum utilizador, dispositivo ou segmento de rede é confiável por defeito. A confiança nunca é concedida com base na localização de rede. Em vez disso, a confiança é continuamente avaliada por pedido com base em sinais de risco dinâmicos.

Em vez de autenticar um utilizador uma vez no gateway da VPN e conceder-lhe uma sessão a nível de rede, o Zero Trust autentica e autoriza cada pedido HTTP individual com base numa matriz de sinais em tempo real: Quem é o utilizador? O dispositivo é gerido pelo MDM da empresa? O sistema operativo está totalmente atualizado? O browser está atualizado? Estão a fazer login de uma localização geograficamente impossível (ex: Lisboa e Xangai na mesma hora)? Passaram um desafio MFA com suporte de hardware via FIDO2/WebAuthn, ou continuam a usar códigos SMS que podem ser SIM-swapped?

A diferença concetual é profunda. Uma VPN diz: “Provaste a tua identidade uma vez, por isso aqui tens toda a rede.” O Zero Trust diz: “Tens de provar a tua identidade continuamente, e mesmo assim, só recebes acesso ao recurso específico que estás a pedir agora.”

Identity-Aware Proxies na prática

A implementação concreta do Zero Trust para aplicações web assenta no Identity-Aware Proxy (IAP). Originalmente implementado em escala pela iniciativa BeyondCorp da Google, o IAP elimina inteiramente a necessidade de clientes VPN no desktop.

Quando um engenheiro tenta aceder a um serviço interno (um ambiente de staging, um dashboard Grafana, um servidor Jenkins CI) navega para um URL HTTPS padrão no browser. Não instala um cliente VPN. Não configura split tunneling. O IAP fica na borda da rede e interceta o pedido HTTP antes de chegar ao serviço de destino. Comunica com o fornecedor SSO corporativo (Okta, Azure AD, Google Workspace) para verificar a identidade do utilizador, avalia a postura do dispositivo endpoint, verifica o pedido contra uma política de acesso granular, e só então faz proxy da ligação, estritamente para aquela aplicação individual.

# Política Zero Trust IAP concetual (ex: Cloudflare Access, Google IAP)
routes:
  - path: /dashboard-interno
    target_service: dashboard-interno-v1
    access_policy:
      require_mfa: true
      require_managed_device: true
      allowed_groups: ["engenharia", "devops"]
      deny_if:
        risk_score: "HIGH"
        geo_country_not_in: ["PT", "GB", "US"]

  - path: /painel-admin
    target_service: painel-admin-v2
    access_policy:
      require_mfa: true
      require_hardware_key: true  # Apenas FIDO2, sem fallback SMS
      allowed_groups: ["platform-admins"]
      session_duration: "1h"      # Re-autenticação a cada hora

Serviços como o Cloudflare Access e o Google Cloud IAP tornaram este padrão acessível a organizações muito mais pequenas que a Google. Uma startup de 20 pessoas pode implementar um IAP em frente ao seu servidor de staging em menos de uma hora, eliminando imediatamente a necessidade de uma VPN enquanto ganha controlo de acesso granular e auditável que a VPN nunca proporcionou.

A VPN não morreu em todo o lado

É importante não sobrecorrigir. As VPNs continuam a ser a solução correta para casos de uso específicos. Se uma aplicação requer conectividade TCP ou UDP em bruto (não HTTP), um IAP não consegue fazer proxy. Sistemas legacy on-premise que não podem ser expostos via HTTPS continuam a necessitar de um túnel a nível de rede. Para estes casos, protocolos VPN modernos como o WireGuard oferecem performance dramaticamente melhor do que IPsec ou OpenVPN legacy, a implementação em kernel-mode do WireGuard tipicamente atinge 3–5x mais throughput com overhead de CPU significativamente menor e uma codebase de aproximadamente 4.000 linhas versus as 100.000+ do OpenVPN.

O erro arquitetónico não é usar uma VPN (é usar a VPN como o único mecanismo de controlo de acesso para toda a organização. A VPN deve ser um túnel estreito e rigorosamente delimitado para o pequeno número de serviços legacy que não podem ser colocados atrás de um IAP. Tudo o resto) cada dashboard web interno, cada API, cada ferramenta CI/CD, deve ficar atrás de um proxy ciente de identidade.

A segurança como acelerador de velocidade

As VPNs causam imensa fricção. Exigem software cliente no desktop, consomem CPU e memória da máquina do funcionário, perdem a ligação constantemente durante transições de rede (Wi-Fi para mobile), e geram um fluxo contínuo de tickets de suporte de TI. Segundo as diretrizes da OWASP sobre controlo de acesso, o princípio do menor privilégio deve ser aplicado na camada da aplicação, não na camada da rede.

Ao migrar para um IAP e uma arquitetura Zero Trust, as empresas alcançam dois objetivos aparentemente contraditórios em simultâneo: melhoram drasticamente a sua postura de segurança ao eliminar o movimento lateral na rede, e aumentam a velocidade das equipas de desenvolvimento ao tornar o acesso a uma plataforma interna tão fluido como fazer login num site público. A equipa de segurança ganha logs de auditoria por pedido. A equipa de engenharia perde o cliente VPN. Ambos os lados ganham.

A transição não é um projeto de fim-de-semana. Requer um inventário completo dos serviços internos, uma implementação SSO/IdP madura, e uma estratégia de gestão de dispositivos (o tipo de migração de infraestrutura que o x078 arquiteta para ambientes B2B. Mas a alternativa) continuar a confiar num modelo de perímetro com 25 anos num mundo onde o perímetro é uma ficção, é um convite para a próxima manchete de violação de dados.