Em arquiteturas VPN tradicionais, o túnel é, na maioria das vezes, gerenciado separadamente da política de identidade. De um lado o diretório corporativo, do outro o sistema de validação VPN, além de um serviço MFA, outra ferramenta para confiança de dispositivo e uma linha de log separada para auditoria. Essa estrutura fragmentada torna o acesso remoto mais frágil do ponto de vista operacional do que seguro.
Saber a senha correta não basta por si só. O dispositivo é gerenciado, a criptografia de disco está ativa, o software de segurança está atualizado, o usuário está no grupo certo, o IP de origem ou a janela de horário são arriscados? Se essas perguntas não forem respondidas antes de o túnel ser aberto, a VPN se transforma em uma porta não controlada que estende a rede corporativa.
O split tunneling, o túnel completo e o acesso por segmento também não são apenas uma questão de rota de rede. O usuário de finanças e o terceirizado não devem acessar a mesma rede; um dispositivo corporativo gerenciado e um dispositivo pessoal não devem ter a mesma autorização. Quando a política de túnel não é projetada em conjunto com identidade, grupo e confiança de dispositivo, o escopo de acesso permanece mais amplo do que o necessário.
No lado operacional o problema também cresce. Se SSL VPN, IKEv2, MFA, política de grupo, registro de sessão e envio ao SIEM forem gerenciados separadamente, a equipe de segurança não consegue ver o quadro completo no momento de um incidente. Quem se conectou, com qual dispositivo se conectou, quais segmentos acessou e por que a conexão foi encerrada devem aparecer em uma única trilha de auditoria.
A abordagem do TR7 AAM trata o acesso VPN não como um serviço de rede separado, mas como a camada de acesso remoto controlado onde convergem as decisões de identidade, MFA, postura de dispositivo, acesso condicional e auditoria.
O TR7 AAM avalia o acesso remoto com cliente como uma decisão de identidade, confiança de dispositivo e escopo de acesso, antes da escolha de protocolo.
O usuário pode ser validado por LDAP/AD, RADIUS, OIDC, SAML ou fonte de usuário local. A mesma decisão de identidade forma a base comum de política para opções de acesso com cliente como SSL VPN ou IKEv2.
A pontuação de confiança do dispositivo é tratada como parte da decisão de acesso condicional. Pode-se aplicar um modelo de acesso amplo para dispositivos gerenciados, acesso restrito para dispositivos pessoais e negação de acesso para dispositivos não confiáveis.
A abordagem SSL VPN baseada em TLS, por operar pela porta 443, facilita a travessia em ambientes corporativos de firewall e proxy. A decisão de split tunneling ou túnel completo pode ser vinculada ao modelo de política.
O IKEv2/IPsec oferece um modelo de acesso remoto compatível com os clientes VPN nativos de sistemas operacionais como Windows, macOS, iOS e Android. A abordagem IKEv2 oferece vantagem prática para a continuidade do túnel em mudanças de rede móvel.
SSL VPN e IKEv2 do TR7 colocam no centro, mais do que o protocolo de túnel, a decisão de identidade, MFA, postura e escopo de acesso do AAM.
O SSL VPN posiciona-se, com sua abordagem de túnel baseada em HTTPS/TLS, para o acesso a recursos corporativos a partir de redes restritas. O uso da porta 443 facilita o acesso em muitos ambientes corporativos, de hotel, de aeroporto ou de rede externa. Esse modelo é especialmente valioso quando clientes adicionais ou portas UDP específicas são restringidas.
O IKEv2/IPsec é adequado para um modelo de acesso remoto corporativo compatível com os clientes VPN nativos do sistema operacional. Em plataformas como Windows, macOS, iOS e Android, pode reduzir a complexidade adicional na experiência do usuário. Em cenários em que usuários móveis mudam de rede, a arquitetura IKEv2 é vantajosa do ponto de vista da reconexão.
A conexão VPN pode ser avaliada em conjunto com a política de acesso condicional do AAM. Identidade do usuário, associação a grupos, IP de origem, janela de horário, confiança de dispositivo e sinais de risco entram no processo de decisão antes de o túnel ser aberto. Essa abordagem retira a VPN da condição de porta aberta no nível de rede. A decisão de acesso é limitada pelo contexto de usuário e dispositivo.
A abordagem MFA do TR7 AAM pode ser usada como um fator de confiança comum também aplicável à decisão de acesso VPN. Métodos como TOTP, SMS OTP ou e-mail OTP reforçam a verificação do usuário. Com um modelo de dispositivo confiável ou verificação baseada em risco, é possível equilibrar experiência do usuário e segurança. Assim, reduz-se a necessidade de operar uma infraestrutura MFA separada para a VPN.
O AAM possui um modelo de provedor de identidade capaz de operar com LDAP/AD, RADIUS, OIDC, SAML e fontes de usuário locais. O acesso VPN não é tratado como um banco de dados de usuário separado ou uma ilha de identidade separada. Seja qual for a identidade com a qual o usuário já é gerenciado na organização, a decisão de abertura do túnel também se vincula ao mesmo contexto de identidade. Essa estrutura simplifica a gestão do ciclo de vida do usuário.
A quais segmentos de rede o usuário pode acessar pode ser associado à associação a grupos ou à política de usuário do AAM. A equipe de finanças pode ser direcionada apenas aos sistemas de finanças, o terceirizado apenas aos serviços de projeto, a equipe de DevOps apenas ao ambiente de desenvolvimento. Esse modelo reduz o erro de conceder acesso a toda a rede após a VPN ser aberta. O acesso por túnel transforma-se em controle de segmento baseado em identidade.
Os sinais de postura de dispositivo ETM podem ser usados para separar dispositivos gerenciados e não gerenciados no acesso por túnel. Criptografia de disco, software de segurança, estado de patches ou sinais de gestão corporativa podem afetar o nível de acesso. Um dispositivo confiável pode ser direcionado à rede completa, e um dispositivo de baixa confiança apenas a backends limitados. Essa abordagem torna visível o risco de dispositivo no acesso remoto.
As sessões VPN podem ser vinculadas à trilha de auditoria com campos como identidade do usuário, IP de origem, horário da sessão, duração da conexão e resultado da política. Esses registros podem ser levados ao fluxo do SIEM e correlacionados com eventos de segurança. A equipe de operações pode ver não apenas que a conexão foi aberta, mas com quais decisões de confiança ela foi aberta. Essa visibilidade é crítica para conformidade e investigação de incidentes.
O split tunneling garante que apenas as faixas de IP da organização ou serviços específicos passem pelo túnel. O túnel completo, por sua vez, leva todo o tráfego do cliente ao ponto de travessia corporativo. Qual modelo será aplicado pode ser definido conforme grupo de usuário, confiança de dispositivo, localização ou nível de risco.
Se a postura de dispositivo se deteriorar durante a conexão, se a pontuação de risco mudar ou se a política de usuário for violada, é necessário encerrar a sessão ou solicitar reautenticação. A arquitetura do TR7 AAM associa essa decisão ao modelo de acesso condicional e auditoria. Essa abordagem retira o acesso VPN da condição de canal permanente esquecido após ser aberto uma vez. O acesso deve ser observável e revogável durante toda a sessão.
Na arquitetura SSL VPN e IKEv2, as capacidades de identidade AAM comprovadas devem ser tratadas em conjunto com os requisitos de operação de túnel.
Os provedores de identidade, MFA, acesso condicional e o conceito de postura de dispositivo ETM são a base confiável desta página. A mensagem principal da página é a vinculação da VPN a esse motor de acesso. O protocolo de túnel posiciona-se como o canal por onde a decisão de identidade e política é aplicada.
A abordagem SSL VPN posiciona-se sobre TLS 1.2+ e a porta 443. Isso oferece vantagem para o acesso a partir de redes restritas. A facilidade de travessia em ambientes corporativos de firewall e proxy é a vantagem prática que se destaca em relação ao IKEv2.
No modelo IKEv2/IPsec, as portas UDP 500 (IKE) e UDP 4500 (NAT-T), o comportamento de NAT-T e as permissões de firewall tornam-se críticos. Em comparação com o SSL VPN, a probabilidade de bloqueio em algumas redes restritas é maior. Por isso, SSL VPN e IKEv2 são opções complementares para diferentes condições de acesso.
Na arquitetura VPN, deve-se planejar o pool de IP de túnel a ser atribuído a cada sessão. Em caso de esgotamento do pool, novas conexões podem ser recusadas ou colocadas em espera. O tamanho do pool e o modelo de gestão devem ser configurados conforme os requisitos de implantação.
No acesso VPN, pode ser necessário que os domínios da organização passem pelo DNS interno e os demais domínios pela resolução externa. O split DNS é o complemento natural do projeto de split tunneling. Esse comportamento depende da arquitetura de implantação e da configuração de política.
Os protocolos de túnel geram custo adicional de cabeçalho. O ajuste de MTU/MSS é importante especialmente para o desempenho do túnel IPsec ESP e TLS. Configurações incorretas podem produzir fragmentação, baixo desempenho ou problemas de conexão em algumas aplicações.
Quando o gateway AAM opera em par, o comportamento de failover das sessões VPN depende da tecnologia de túnel. No lado do IKEv2, a arquitetura de reconexão móvel pode ser vantajosa; no lado do SSL VPN, o projeto de VIP e continuidade de sessão deve ser tratado à parte.
O usuário que trabalha de casa ou em viagem é validado via AAM com sua identidade corporativa e MFA. Se a confiança de dispositivo ETM for suficiente, concede-se acesso a serviços de intranet via SSL VPN; em dispositivos pessoais, o acesso é limitado a segmentos mais restritos.
O técnico de campo pode conectar-se à rede corporativa com o cliente IKEv2 nativo de seu dispositivo móvel. Se o dispositivo tiver perfil gerenciado e alta pontuação de confiança ETM, concede-se acesso mais amplo; em mudanças de rede, a abordagem IKEv2 é mais adequada para o uso móvel.
Ao terceirizado externo é atribuída uma conta de usuário e um grupo restrito válidos apenas durante o período do projeto. O acesso VPN abre-se apenas ao segmento onde estão os backends do projeto, e todas as sessões são vinculadas ao registro de auditoria.
O engenheiro de automação fabril recebe uma política VPN para acessar apenas o segmento OT. O acesso condicional limita a decisão por horário de expediente, grupo de usuário, IP de origem e confiança de dispositivo; não se concede acesso amplo à rede corporativa geral.
Conheça a arquitetura que une o túnel SSL VPN e IKEv2 ao motor de identidade AAM, MFA e postura de dispositivo ETM. Vamos guiá-lo por uma configuração ao vivo no seu próprio ambiente.