VPN: o que é, como funciona, IPsec, acesso remoto e critérios de projeto

Entenda como funciona uma VPN corporativa, as diferenças entre site-to-site e acesso remoto, IPsec, TLS, roteamento, segurança, desempenho, testes e critérios de projeto.

Confira!

Uma VPN (Virtual Private Network) é uma tecnologia de comunicação que cria um caminho lógico protegido sobre uma rede que não é, por si só, confiável. Em ambientes corporativos, ela é usada principalmente para interligar redes, permitir acesso remoto controlado e proteger tráfego entre pontos que atravessam a Internet ou outras infraestruturas compartilhadas.

Tecnicamente, uma VPN não “torna a Internet privada”. Ela estabelece uma associação de segurança entre duas extremidades e aplica mecanismos como autenticação, criptografia, integridade, encapsulamento e controle de tráfego. Dependendo da arquitetura, a proteção pode ocorrer entre dois gateways, entre um usuário e um gateway corporativo ou entre aplicações e serviços específicos.

Os dois cenários clássicos são site-to-site, quando duas ou mais redes são interligadas, e remote access, quando um usuário ou dispositivo remoto acessa recursos corporativos. IPsec continua sendo uma referência para proteção na camada IP, enquanto TLS é amplamente utilizado em soluções de acesso remoto e aplicações. A escolha correta depende de requisitos de segurança, disponibilidade, desempenho, segmentação, autenticação, operação e governança — e não apenas do protocolo disponível no firewall.

Uma VPN corporativa, portanto, deve ser tratada como parte da arquitetura de rede e segurança. Seu projeto precisa considerar endereçamento, roteamento, identidade, políticas de acesso, capacidade, alta disponibilidade, observabilidade, ciclo de vida criptográfico, documentação e critérios de aceite.

O que uma VPN protege — e o que ela não protege

A principal função de uma VPN é proteger a comunicação entre as extremidades do túnel. Isso pode incluir confidencialidade, integridade, autenticação da origem e proteção contra determinados tipos de repetição de pacotes. No IPsec, esses serviços são implementados por mecanismos definidos para proteção do tráfego IP e por processos de gerenciamento de chaves.

Uma VPN, porém, não substitui controles de segurança no endpoint, segmentação, autenticação forte, políticas de identidade, EDR, firewall, DNS seguro ou monitoração. Se um notebook comprometido estabelece uma VPN válida, o túnel pode transportar tráfego malicioso de forma perfeitamente criptografada. O túnel protege o caminho; ele não transforma automaticamente a origem em confiável.

Essa distinção é crítica em arquiteturas modernas. A tendência de segurança é reduzir a confiança implícita associada ao simples fato de um dispositivo estar “dentro” da rede. Modelos de Zero Trust deslocam a decisão para identidade, postura do dispositivo, contexto, aplicação e privilégio mínimo.

Controle	O que resolve	O que não resolve sozinho
VPN	Proteção do tráfego em trânsito entre extremidades	Comprometimento do endpoint
Firewall	Filtragem e aplicação de política de tráfego	Identidade completa do usuário
MFA	Redução de risco de credencial comprometida	Malware no dispositivo
EDR/XDR	Detecção e resposta no endpoint	Proteção criptográfica do caminho
Segmentação	Limita movimento lateral	Autenticação do usuário
DNS seguro	Ajuda a controlar resolução e destinos	Proteção do túnel
SIEM	Correlação e investigação de eventos	Prevenção isolada do incidente

A arquitetura correta combina esses controles de forma coerente. O artigo sobre gerenciamento de redes aprofunda a visão operacional de configuração, desempenho e segurança, enquanto monitoramento de rede trata da observabilidade necessária para verificar se o serviço está funcionando como projetado.

Como funciona uma VPN em termos de rede

O funcionamento pode ser entendido como uma sequência: identificação do tráfego que deve ser protegido, estabelecimento da associação segura, negociação de parâmetros criptográficos, encapsulamento dos pacotes e encaminhamento pela rede de transporte.

No caso do IPsec, políticas definem quais fluxos devem entrar no túnel. O gateway ou host identifica o tráfego correspondente, aplica o tratamento de segurança e encapsula o pacote para transporte até a outra extremidade. Na chegada, a extremidade remota valida a associação, verifica integridade, descriptografa quando aplicável e entrega o pacote à rede de destino.

Esse processo introduz overhead. O pacote original recebe cabeçalhos adicionais e, em determinados modos, um novo cabeçalho IP completo. Por isso, MTU e MSS precisam ser avaliados. Uma VPN mal dimensionada pode apresentar fragmentação, retransmissões, queda de desempenho ou falhas aparentemente intermitentes em aplicações específicas.

A compreensão do comportamento do tráfego também depende dos fundamentos de tráfego de rede. Quando a VPN atravessa múltiplos links, operadoras ou ambientes cloud, o caminho lógico precisa ser analisado de ponta a ponta, e não apenas em cada firewall isoladamente.

VPN site-to-site

A VPN site-to-site conecta redes completas por meio de gateways. É comum em filiais, unidades industriais, escritórios, data centers, nuvens privadas ou ambientes híbridos. Os dispositivos finais normalmente não precisam executar um cliente VPN; eles enviam o tráfego ao gateway padrão, e o equipamento de borda aplica a política de túnel.

Em uma topologia simples, a matriz estabelece um túnel com uma filial. Em organizações maiores, podem existir múltiplos túneis, topologias hub-and-spoke, malhas parciais ou integrações com SD-WAN. A escolha afeta roteamento, convergência, disponibilidade, escalabilidade e operação.

A definição não pode ser feita apenas olhando quantas unidades existem. É necessário conhecer:

• sub-redes e sobreposições de endereçamento;
• protocolos e aplicações que precisam atravessar o túnel;
• requisitos de latência e jitter;
• banda agregada e picos;
• criticidade dos serviços;
• necessidade de redundância;
• comportamento de roteamento durante falhas;
• dependências de DNS, autenticação e serviços centrais;
• requisitos de logs e rastreabilidade.

Em redes corporativas, a VPN deve ser tratada como parte da arquitetura, não como uma configuração isolada de firewall.

Hub-and-spoke, malha e topologias híbridas

Na topologia hub-and-spoke, filiais se conectam a um concentrador central. O modelo simplifica políticas e operação, porém pode criar dependência excessiva do hub e caminhos indiretos para comunicação entre filiais.

Uma malha completa reduz determinados caminhos indiretos, mas cresce rapidamente em quantidade de túneis e complexidade. Em ambientes maiores, soluções de roteamento dinâmico, SD-WAN ou overlays podem reduzir a necessidade de administrar manualmente cada relação ponto a ponto.

A escolha deve comparar simplicidade, latência, resiliência, segurança e esforço operacional. Não existe uma topologia universalmente superior.

VPN de acesso remoto

No acesso remoto, o usuário ou dispositivo estabelece uma sessão segura com um concentrador, firewall ou serviço de acesso. A autenticação pode envolver credencial, certificado, MFA e validação de postura do endpoint.

O projeto precisa definir o que acontece depois da autenticação. Um usuário autenticado não deveria receber acesso indiscriminado a todas as sub-redes. O princípio de menor privilégio recomenda limitar a sessão aos recursos necessários para a função, considerando grupos, perfis, aplicações e contexto.

Também é necessário definir comportamento do DNS, rotas, proxy, acesso à Internet, atualização de políticas, logs e resposta a incidentes. Em ambientes com grande número de usuários remotos, o acesso deixa de ser uma simples função do firewall e passa a exigir capacidade, governança e operação contínua.

Acesso remoto de administradores e terceiros

Usuários privilegiados exigem controles adicionais. Administradores, integradores, fornecedores e equipes de manutenção podem possuir acesso a ativos de alta criticidade. A autenticação deve ser forte, o privilégio deve ser mínimo e, quando aplicável, o acesso deve ser temporário e aprovado.

Em ambientes OT, industriais ou de missão crítica, a VPN não deve criar um atalho permanente entre Internet e redes sensíveis. É comum combinar VPN, bastion host, jump server, segmentação, gravação de sessão e controle por janela de manutenção.

O registro de quem acessou, quando, por quanto tempo e quais recursos foram utilizados é parte da evidência de segurança.

Full tunnel e split tunnel

Em full tunnel, praticamente todo o tráfego do cliente é encaminhado pelo túnel corporativo. Isso aumenta a visibilidade e a aplicação centralizada de controles, mas também eleva o consumo de banda e a carga da infraestrutura.

Em split tunnel, apenas determinados destinos ou redes corporativas passam pela VPN; o restante segue diretamente pela conexão local do usuário. A vantagem é reduzir carga e latência para serviços de Internet. A desvantagem é criar um caminho simultâneo entre a rede local/Internet e o ambiente corporativo, o que exige controles adicionais.

Critério	Full tunnel	Split tunnel
Inspeção centralizada	Maior	Parcial
Consumo de banda corporativa	Maior	Menor
Latência para SaaS/Internet	Pode aumentar	Normalmente menor
Dependência do concentrador	Alta	Menor
Superfície operacional	Mais centralizada	Mais distribuída

A decisão deve ser baseada em risco e arquitetura. Não existe uma regra universal de que um modelo seja sempre superior ao outro. Em organizações que utilizam fortemente SaaS, o full tunnel pode criar tromboning desnecessário; em ambientes com requisitos rígidos de inspeção, ele pode ser preferível.

IPsec: arquitetura e componentes

IPsec é uma arquitetura de segurança para IP. Ele pode operar em IPv4 e IPv6 e é usado amplamente em VPNs site-to-site e também em determinados modelos de acesso remoto.

O componente mais conhecido para proteção de dados é o ESP (Encapsulating Security Payload). Ele pode prover confidencialidade e integridade, conforme a configuração. O gerenciamento de chaves e a negociação de associações de segurança são realizados por mecanismos como IKEv2.

Uma implementação moderna deve avaliar algoritmos suportados, políticas criptográficas, grupos de Diffie-Hellman, certificados, tempos de vida das associações, Perfect Forward Secrecy quando aplicável e interoperabilidade entre fabricantes.

O ponto central é evitar configurações herdadas sem revisão. Um túnel “que funciona há anos” pode permanecer operacional com parâmetros que já não representam o nível de segurança desejado.

Tunnel mode e transport mode

No tunnel mode, um pacote IP inteiro é protegido e encapsulado em outro pacote IP. É o modelo mais comum para interligação entre gateways e redes distintas.

No transport mode, a proteção se aplica principalmente à carga útil do pacote original, preservando o cabeçalho IP original em maior grau. Seu uso é mais específico.

Para projeto de VPN corporativa, não basta conhecer os nomes dos modos. É necessário entender onde estão as extremidades de segurança, quais endereços serão visíveis no transporte e como roteamento e políticas serão aplicados.

IKEv2 e negociação de segurança

IKEv2 estabelece e gerencia as associações necessárias ao IPsec. Durante a negociação, as partes autenticam-se e concordam sobre parâmetros criptográficos e chaves.

O projeto deve responder, entre outras, às seguintes questões:

1. Como cada extremidade será autenticada?
2. Serão usados certificados, chaves pré-compartilhadas ou integração com identidade?
3. Quais propostas criptográficas serão permitidas?
4. Como ocorrerá a renovação de chaves?
5. Como será tratada a indisponibilidade de uma extremidade?
6. Como serão monitoradas falhas de negociação?
7. Como será administrado o ciclo de vida de certificados?

Essas decisões fazem parte da segurança operacional. Não basta definir “usar IPsec”.

Chaves pré-compartilhadas e certificados

Chaves pré-compartilhadas podem ser adequadas em cenários simples, mas tornam-se difíceis de governar em ambientes com muitos túneis. Reutilizar a mesma chave em várias relações cria concentração de risco e dificulta revogação seletiva.

Certificados permitem identidade criptográfica mais estruturada, porém introduzem dependência de PKI, emissão, renovação e revogação. A decisão deve considerar escala e capacidade operacional.

TLS e o uso histórico do termo SSL VPN

Muitas soluções comerciais ainda utilizam a expressão SSL VPN, mas o protocolo SSL foi substituído por versões modernas do TLS. Tecnicamente, o termo comercial permaneceu, enquanto a implementação atual utiliza TLS.

O TLS protege sessões e é amplamente empregado em portais, gateways e clientes de acesso remoto. A arquitetura pode oferecer acesso a aplicações específicas, túneis mais amplos ou combinações conforme o produto.

A distinção entre IPsec e TLS não deve ser reduzida a “camada 3 versus camada 7”. Produtos modernos incorporam múltiplos mecanismos, agentes e políticas. A comparação correta deve considerar escopo de acesso, identidade, postura do endpoint, integração com diretórios, suporte a aplicações, desempenho e operação.

Autenticação, certificados e MFA

A segurança do túnel depende da confiança nas extremidades. Em site-to-site, certificados digitais oferecem vantagens de escalabilidade e governança em comparação com chaves pré-compartilhadas distribuídas manualmente, especialmente em ambientes com muitas unidades.

Em acesso remoto, MFA reduz o risco de uso indevido de credenciais. Entretanto, autenticação forte deve ser combinada com controles de autorização. A pergunta correta não é apenas “quem é o usuário?”, mas “a quais recursos este usuário pode acessar, a partir de qual dispositivo e em que condição?”.

Certificados também precisam de gestão de ciclo de vida: emissão, armazenamento seguro, renovação, revogação e inventário. Expiração não planejada de certificado é uma causa recorrente de indisponibilidade em serviços seguros.

Segmentação e menor privilégio

Um dos erros mais graves é usar a VPN como extensão irrestrita da LAN. Quando uma sessão remota recebe acesso amplo, qualquer comprometimento de credencial ou endpoint ganha maior potencial de movimento lateral.

A política deve ser orientada por necessidade de comunicação. Usuários financeiros não precisam acessar redes de engenharia; terceiros de manutenção não precisam alcançar estações administrativas; filiais não precisam necessariamente trocar tráfego entre si.

Matrizes de comunicação são úteis para transformar necessidade de negócio em regras de rede. Elas também simplificam revisão periódica e auditoria.

Roteamento, NAT e sobreposição de endereços

VPNs corporativas frequentemente expõem problemas de endereçamento que não eram visíveis enquanto redes permaneciam isoladas. Duas filiais podem usar a mesma faixa privada, como 192.168.1.0/24, tornando o roteamento ambíguo quando precisam comunicar-se.

O projeto deve identificar sobreposições antes da implantação. As opções incluem renumeração, NAT entre domínios, segmentação ou arquiteturas intermediárias. Cada alternativa cria consequências operacionais.

NAT também interfere na negociação e no transporte de determinados protocolos. Soluções modernas tratam NAT traversal, mas o comportamento precisa ser validado quando existem múltiplas camadas de tradução, links de operadoras, CGNAT ou equipamentos intermediários.

Roteamento estático ou dinâmico

Túneis simples podem usar rotas estáticas. Em malhas maiores, protocolos dinâmicos podem melhorar convergência e operação, desde que controlados por políticas adequadas.

A decisão deve considerar quantidade de prefixos, número de sites, mudanças frequentes, redundância e necessidade de convergência automática. Introduzir roteamento dinâmico sem governança também pode propagar rotas indevidas.

O desenho precisa definir filtros, preferência de caminhos e comportamento durante perda de túnel.

MTU, MSS e fragmentação

A VPN adiciona bytes ao pacote. Se o caminho não suportar o tamanho resultante, pode ocorrer fragmentação ou descarte. Aplicações TCP podem apresentar lentidão, travamentos em uploads, falhas em páginas específicas ou sessões aparentemente aleatórias.

O diagnóstico deve considerar MTU efetiva, Path MTU Discovery, MSS clamping quando necessário e comportamento de ICMP. Bloquear mensagens essenciais de ICMP pode impedir o ajuste adequado do tamanho de pacote.

Esse tipo de problema demonstra por que VPN é assunto de engenharia de rede, não apenas de parametrização de appliance.

Desempenho e capacidade

A capacidade nominal do link não é a mesma coisa que a capacidade de VPN do equipamento. Criptografia, inspeção, número de túneis, número de usuários, tipo de algoritmo e demais funções de segurança consomem recursos.

O dimensionamento deve considerar:

• throughput criptografado sustentado;
• picos de tráfego;
• quantidade simultânea de túneis;
• usuários concorrentes;
• tamanho médio de pacotes;
• inspeção de segurança aplicada ao tráfego;
• HA e comportamento durante failover;
• crescimento previsto;
• margem operacional.

Um equipamento que atende 1 Gbit/s de tráfego simples pode não entregar a mesma capacidade com IPsec, IPS, antivírus e demais mecanismos habilitados.

Latência, jitter e aplicações em tempo real

Aplicações de voz, vídeo, VDI e controle remoto podem ser mais sensíveis a latência e jitter que aplicações transacionais. O projeto precisa avaliar caminho, distância geográfica e tratamento QoS.

A criptografia não é necessariamente o principal fator de latência em equipamentos adequados. Muitas vezes, o caminho pela Internet, o desvio por um concentrador central ou o congestionamento do link tem impacto maior.

Alta disponibilidade e continuidade

VPNs que sustentam aplicações críticas precisam de estratégia de continuidade. Isso pode envolver links redundantes, pares de firewalls em HA, múltiplos concentradores, túneis alternativos e roteamento dinâmico.

A redundância deve ser testada. Ter dois links não garante failover adequado se ambos dependem do mesmo caminho físico, da mesma operadora, da mesma alimentação ou do mesmo equipamento intermediário.

A análise deve observar o serviço ponta a ponta. O artigo sobre infraestrutura resiliente aprofunda essa visão de dependências e continuidade.

RTO e recuperação do serviço

Para VPN, métricas práticas incluem tempo de detecção da falha, tempo de failover, tempo de renegociação e tempo de restabelecimento da aplicação.

Se a comunicação suporta processos críticos, esses valores devem ser definidos e testados. A simples existência de um segundo link não demonstra que o requisito foi atendido.

DNS, identidade e serviços dependentes

Uma VPN pode estar tecnicamente estabelecida e ainda assim o usuário não conseguir trabalhar. Isso ocorre quando DNS, autenticação, NTP, diretórios, certificados ou rotas para serviços essenciais não foram considerados.

DNS é particularmente importante. O cliente pode precisar resolver nomes internos, públicos ou ambos. Split DNS, prioridades de resolvedores e comportamento do sistema operacional precisam ser definidos.

Em acesso remoto, o desenho deve mapear todas as dependências necessárias para autenticar, resolver nomes, acessar aplicações e registrar eventos.

Logs, monitoramento e observabilidade

Uma VPN corporativa deve produzir evidências suficientes para operação e segurança. Logs de estabelecimento, autenticação, desconexão, falha de negociação e mudança de estado ajudam a reconstruir incidentes.

Além dos logs, métricas permitem observar:

• disponibilidade dos túneis;
• latência;
• perda de pacotes;
• throughput;
• usuários simultâneos;
• tentativas de autenticação;
• falhas por proposta criptográfica;
• tempo de reconexão;
• eventos de failover.

Ferramentas de NetFlow podem complementar a visibilidade sobre fluxos, enquanto plataformas de monitoramento ajudam a diferenciar indisponibilidade de túnel, congestionamento e falha de aplicação.

VPN e Zero Trust

VPN tradicional cria um caminho de rede protegido. Zero Trust procura reduzir a confiança implícita e tornar a decisão de acesso mais granular e contextual.

Por isso, VPN e Zero Trust não são necessariamente mutuamente exclusivos. Uma organização pode manter túneis IPsec entre sites e, ao mesmo tempo, adotar políticas Zero Trust para usuários e aplicações. O ponto é não usar a existência do túnel como único critério de confiança.

CISA e outras autoridades recomendam que organizações avaliem abordagens modernas como Zero Trust, SSE e SASE para cenários de acesso, especialmente quando modelos tradicionais de VPN criam visibilidade insuficiente ou superfície operacional excessiva.

SSE e SASE

SSE agrupa funções de segurança entregues como serviço, como acesso Zero Trust, secure web gateway e CASB. SASE combina capacidades de rede e segurança em uma arquitetura mais ampla.

Esses modelos podem reduzir a necessidade de backhaul para aplicações SaaS e permitir políticas orientadas à identidade. Entretanto, site-to-site IPsec continua sendo relevante em muitas interligações de infraestrutura, cloud e OT.

VPN em ambientes cloud e híbridos

Nuvens públicas frequentemente utilizam túneis IPsec como uma das formas de conectar redes on-premises a VPCs ou VNets. O princípio de projeto é semelhante, mas o roteamento e a redundância seguem recursos específicos da plataforma.

É necessário definir prefixos, gateways, BGP quando aplicável, caminhos redundantes e limites do serviço. A dependência de Internet ou de circuitos privados também muda a estratégia de continuidade.

Uma migração para cloud não elimina a engenharia de rede; ela desloca parte da arquitetura para componentes virtuais e serviços gerenciados.

VPN em OT e infraestrutura crítica

Em ambientes industriais, concessionárias, data centers, transporte ou instalações críticas, a VPN pode ser usada para manutenção remota e interconexão. O risco é elevado porque o acesso pode alcançar sistemas com consequências físicas.

Boas práticas incluem:

• segmentação entre IT e OT;
• jump host controlado;
• MFA;
• acesso temporário;
• aprovação por janela;
• logs detalhados;
• restrição por origem e destino;
• monitoramento da sessão;
• procedimentos de revogação;
• testes periódicos.

A engenharia deve considerar indisponibilidade e segurança simultaneamente.

Principais riscos de projeto e operação

Os riscos mais recorrentes não estão apenas na criptografia. Eles surgem na combinação entre arquitetura, configuração e governança.

Risco	Consequência possível	Controle de engenharia
Redes sobrepostas	Roteamento incorreto	Plano de endereçamento
Algoritmos legados	Redução de segurança	Baseline criptográfica
Falta de MFA	Uso indevido de credenciais	MFA e identidade
Acesso excessivo	Movimento lateral	Segmentação e mínimo privilégio
Sem redundância	Indisponibilidade	HA e caminhos alternativos
MTU incorreta	Falhas intermitentes	Testes e ajuste de MTU/MSS
Logs insuficientes	Baixa rastreabilidade	Centralização de eventos
Certificado expirado	Queda de serviço	Gestão de ciclo de vida
Rotas indevidas	Exposição de redes	Filtros e revisão
Chaves compartilhadas	Revogação difícil	Identidade individualizada

Como projetar uma VPN corporativa

Um projeto consistente começa pela necessidade e pelos fluxos, não pelo equipamento. Primeiro é necessário identificar quem se comunica com quem, quais aplicações dependem da comunicação, qual criticidade existe e quais requisitos de segurança devem ser atendidos.

Depois, a arquitetura define topologia, gateways, políticas, autenticação, endereçamento, roteamento, redundância e operação.

Uma sequência prática é:

1. levantar redes, aplicações e dependências;
2. mapear fluxos e criticidade;
3. definir requisitos de segurança;
4. selecionar modelo de acesso;
5. definir autenticação e autorização;
6. projetar endereçamento e roteamento;
7. dimensionar capacidade;
8. definir HA e contingência;
9. estabelecer logging e monitoramento;
10. criar plano de testes e aceite;
11. documentar configuração e operação.

Quando a infraestrutura existente não está devidamente documentada, um Levantamento Cadastral de Engenharia pode ser necessário antes da consolidação da arquitetura.

Migração de uma VPN existente

Migrar túneis em produção exige planejamento porque falhas de rota, NAT ou política podem interromper aplicações. A mudança deve mapear dependências antes de alterar gateways ou parâmetros criptográficos.

O plano de migração pode prever coexistência temporária, janela de mudança, rollback, teste por aplicação e validação com usuários críticos.

Alterar simultaneamente firewall, endereçamento, operadora e método de autenticação aumenta a dificuldade de diagnóstico. Sempre que possível, mudanças devem ser sequenciadas de forma verificável.

Troubleshooting: onde procurar quando a VPN não funciona

O diagnóstico precisa separar camadas. Uma falha pode ocorrer antes, durante ou depois do estabelecimento do túnel.

Uma sequência útil é:

1. verificar conectividade IP entre as extremidades;
2. verificar negociação IKE;
3. verificar associação IPsec;
4. validar seletores de tráfego;
5. verificar rotas;
6. verificar NAT;
7. verificar políticas de firewall;
8. validar DNS;
9. testar MTU e MSS;
10. testar aplicação.

Essa sequência evita atribuir toda falha à “VPN” quando o problema está em DNS, roteamento ou aplicação.

Testes e critérios de aceite

Uma VPN não deve ser aceita apenas porque “o ping passa”. O comissionamento precisa validar as condições que realmente caracterizam o serviço.

Os testes podem incluir:

• estabelecimento e renovação do túnel;
• autenticação válida e inválida;
• rotas esperadas e rotas não permitidas;
• DNS interno e externo;
• throughput;
• latência e perda;
• MTU;
• failover de link;
• failover de equipamento;
• reconexão após falha;
• acesso conforme perfil;
• geração de logs;
• expiração ou revogação de credencial;
• comportamento de aplicações críticas.

Os resultados devem ser registrados. Para ambientes críticos, o serviço de Comissionamento de Equipamentos pode estruturar testes, evidências e aceite técnico.

Documentação mínima

A documentação deve permitir que outra equipe compreenda, opere e recupere o serviço. Isso inclui diagrama lógico, matriz de fluxos, endereçamento, rotas, políticas, método de autenticação, certificados, requisitos criptográficos, redundância, monitoração e procedimentos de contingência.

Informações sensíveis, como segredos e chaves, não devem ser inseridas indiscriminadamente em diagramas ou memoriais. O documento precisa separar arquitetura e parâmetros de operação de credenciais protegidas.

A ausência de documentação transforma pequenas mudanças em atividades de alto risco.

Como contratar projeto ou revisão de uma VPN

A contratação deve descrever o problema e os entregáveis esperados. Pedir apenas “configuração de VPN” tende a reduzir o escopo a uma atividade pontual, sem assegurar arquitetura, segurança, testes ou documentação.

Um escopo tecnicamente estruturado pode exigir:

• levantamento da rede existente;
• matriz de comunicação;
• requisitos de segurança;
• arquitetura proposta;
• plano de endereçamento e roteamento;
• política de autenticação;
• baseline criptográfica;
• estratégia de HA;
• plano de migração;
• plano de testes;
• documentação As-Built;
• critérios objetivos de aceite.

Quando a organização já possui uma solução implantada e precisa verificar se a arquitetura está coerente, uma Revisão e Validação Técnica de Projetos — Design Review pode ser aplicada à análise independente de requisitos, interfaces e riscos.

O que exigir do contratado

A contratação deve exigir profissional ou equipe com domínio de redes, segurança, roteamento e infraestrutura associada. Em ambientes críticos, experiência em alta disponibilidade, cloud ou OT pode ser necessária.

Entregáveis devem ser verificáveis. “Configurar e entregar funcionando” é um critério insuficiente. O contratante precisa receber documentação, memória de decisões, resultados de testes e parâmetros que permitam operação futura.

Considerações finais

VPN continua sendo uma tecnologia central para interligação segura de redes e acesso remoto, mas seu valor depende do projeto completo. A segurança real resulta da combinação entre criptografia, identidade, segmentação, roteamento, monitoramento, continuidade, documentação e testes.

Em ambientes simples, uma configuração básica pode ser suficiente. Em ambientes corporativos críticos, a VPN deve ser tratada como um serviço de infraestrutura sujeito a requisitos, evidências e critérios de aceite. A evolução para Zero Trust, SSE ou SASE não elimina automaticamente a necessidade de túneis; ela muda a forma como confiança e autorização são aplicadas.

Referências técnicas

[1] IETF. RFC 4301 — Security Architecture for the Internet Protocol. Disponível em: https://www.rfc-editor.org/rfc/rfc4301.

[2] IETF. RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2). Disponível em: https://www.rfc-editor.org/rfc/rfc7296.

[3] IETF. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3. Disponível em: https://www.rfc-editor.org/rfc/rfc8446.

[4] NIST. SP 800-46 Rev. 2 — Guide to Enterprise Telework, Remote Access, and BYOD Security. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-46/rev-2/final.

[5] CISA. Modern Approaches to Network Access Security. Disponível em: https://www.cisa.gov/news-events/alerts/2024/06/18/cisa-and-partners-release-guidance-modern-approaches-network-access-security.

Perguntas frequentes

VPN é a mesma coisa que firewall?

Não. A VPN protege a comunicação entre extremidades e o firewall aplica políticas de controle de tráfego. Em ambientes corporativos, os dois controles normalmente trabalham em conjunto.

Qual a diferença entre VPN site-to-site e VPN de acesso remoto?

A site-to-site interliga redes por gateways. A VPN de acesso remoto estabelece uma sessão entre um usuário ou dispositivo e a infraestrutura corporativa.

IPsec e TLS são concorrentes?

Não necessariamente. Eles protegem comunicações em arquiteturas diferentes e podem coexistir. A escolha depende do tipo de acesso, das aplicações, da identidade, da operação e dos requisitos de segurança.

Split tunnel é inseguro?

Não é inerentemente inseguro, mas cria um modelo de tráfego diferente e exige avaliação de risco, postura do endpoint, política de acesso e monitoramento.

Como saber se uma VPN está bem dimensionada?

É necessário verificar throughput criptografado, usuários e túneis simultâneos, tamanho de pacotes, inspeções habilitadas, redundância, picos e crescimento previsto.

O que deve ser testado no aceite de uma VPN?

Devem ser testados conectividade, autenticação, rotas, DNS, MTU, desempenho, failover, perfis de acesso, logs e comportamento das aplicações críticas.

Materiais técnicos complementares

Conteúdos principais sobre o tema

• Gerenciamento de Redes: FCAPS, SNMP, configuração, desempenho e segurança
• Monitoramento de Rede: métricas, disponibilidade, desempenho e observabilidade

Conteúdos técnicos correlatos

• NetFlow: o que é, como funciona e como analisar tráfego de rede
• Tráfego de Rede: fluxos, carga, broadcast, multicast e capacidade
• Infraestrutura Resiliente: princípios de engenharia e continuidade de serviços

Serviços relacionados

• Levantamento Cadastral de Engenharia
• Design Review em Projetos de Engenharia
• Comissionamento de Equipamentos