AWS Client VPN agora verifica a saúde do dispositivo antes de liberar o túnel

O problema que o Client VPN não resolvia sozinho

Até agora, o AWS Client VPN autenticava quem estava se conectando, mas não sabia nada sobre o quê. Um notebook de terceirizado sem gestão nenhuma e uma máquina totalmente gerenciada pela empresa recebiam exatamente o mesmo túnel, desde que a identidade batesse.

Quem precisava de mais do que isso recorria ao client connect handler, um AWS Lambda acionado no momento da conexão. Funcionava, mas com duas limitações que pesam para quem desenha a arquitetura: a checagem rodava só uma vez, no connect, e só enxergava os dados de dispositivo que o próprio código buscasse. Se o laptop ficasse comprometido às 15h, a sessão aberta às 9h continuava intocada até cair por outro motivo.

O device posture assessment, anunciado pelo time de AWS Networking & Content Delivery, fecha essa lacuna sem tirar o client connect handler do ar: as duas camadas coexistem e qualquer uma pode recusar a conexão, o que permite migrar regras do Lambda para uma política aos poucos em vez de trocar tudo de uma vez.

Como o fluxo funciona na prática

O recurso depende de um device trust provider, o serviço de gestão de endpoint ou segurança que já roda na sua frota e produz sinais de conformidade. No lançamento, três provedores são suportados: CrowdStrike (Windows e macOS), Jamf (macOS) e JumpCloud (Windows, macOS e Ubuntu). O agente de cada um já roda no dispositivo e assina um token que o AWS VPN Client (versão 6.2.0 ou superior, obrigatória) envia junto com o pedido de conexão.

Você registra o provedor no endpoint com o novo parâmetro --device-posture-options, disponível tanto em create-client-vpn-endpoint quanto em modify-client-vpn-endpoint:

aws ec2 modify-client-vpn-endpoint \
--client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
--device-posture-options '{"Enabled": true, "TrustProviders":[{
"TrustProviderType":"crowdstrike",
"TenantId":"TENANT-ID",
"PublicSigningKeyUrl":"https://example.com/keys/jwk.json"}]}'

O Client VPN verifica a assinatura do token contra essa chave pública e confere se o tenant do token bate com o do endpoint antes de ler qualquer atributo. Um token emitido para a frota de outra organização é recusado, não avaliado.

A política fica em Cedar, não em código

Os atributos do token viram variáveis numa política escrita em Cedar, a mesma linguagem de política usada pelo AWS Verified Access. Cada endpoint tem uma política só, e ela decide se a conexão pode carregar tráfego:

permit(principal, action, resource)
when { context.crowdstrike.assessment.overall > 50 };

Identidade e postura do dispositivo chegam no mesmo contexto, então dá para exigir as duas coisas numa única expressão:

when {
context.crowdstrike.assessment.overall > 50 &&
context.saml.memberOf.contains("vpn-users")
};

Essa política é uma camada separada da authorization rule que já existe no Client VPN: a política em Cedar decide se a conexão entra, a authorization rule decide quais destinos de rede ela alcança depois de dentro. As duas continuam valendo ao mesmo tempo.

Os três provedores do lançamento publicam atributos bem diferentes entre si, e isso muda completamente como a política fica escrita:

Como quase nada é comum entre os três, uma política é escrita para o provedor específico que você registrou, não para ser portada entre eles.

Avaliação contínua: a parte que você não construiria sozinho

A diferença real em relação ao client connect handler está aqui. O AWS VPN Client manda um token renovado periodicamente, e o Client VPN reavalia a política a cada token que chega, algo em torno de cinco minutos. Se o score de CrowdStrike de um notebook cai abaixo de 50 no meio da tarde, porque alguém desligou uma configuração de segurança, a sessão é encerrada no próximo refresh do token, sem nenhuma ação manual.

Se o agente do provedor parar ou ficar inacessível, nenhum token novo chega. O Client VPN segura os atributos que já tinha por até 15 minutos, o suficiente para uma sessão sobreviver a uma falha passageira. Passado esse prazo, em vez de derrubar a conexão, ele reavalia a política sem nenhum atributo de dispositivo: uma política que exige postura nega e encerra a sessão, uma política baseada só em identidade continua permitindo.

Vale notar um detalhe que muda o comportamento esperado: a identidade autenticada é capturada uma vez, no connect, e não muda durante a sessão. Então uma política que depende só de atributos de usuário nunca vai mudar de decisão no meio do caminho, só a parte de postura do dispositivo é reavaliada ao vivo.

Shadow mode antes de bloquear qualquer um

A AWS recomenda, com razão, testar toda política nova em shadow mode antes de ativar. Uma política mais rígida do que a frota real consegue cumprir derruba todo mundo de uma vez, e descobrir isso pelos chamados de suporte é o pior jeito de aprender quantos laptops estão com o agente parado.

Com shadow mode ligado, o Client VPN avalia cada conexão contra a política e grava a decisão no log, sem bloquear nada:

aws ec2 modify-client-vpn-endpoint-authorization-policy \
--policy-document 'permit(principal, action, resource)
when { context.crowdstrike.assessment.overall > 50 };' \
--description "Require a healthy device score" \
--shadow-mode enabled

Só depois de ler os logs e confirmar que a política bate com a frota de verdade é que faz sentido desligar o shadow mode.

Métricas e o que vai parar no CloudWatch

Três métricas novas chegam ao namespace AWS/ClientVPN já existente no Amazon CloudWatch, sem nenhuma configuração extra:

• AuthorizationPolicyEvaluationCount: quantas avaliações de política rodaram
• AuthorizationPolicyDeniedConnections: quantas conexões foram recusadas
• AuthorizationPolicyTerminatedConnections: quantas sessões foram encerradas por uma avaliação posterior

Todas por endpoint, o que permite alarmar numa taxa de negação no mesmo dia em que a política entra no ar. Os connection logs ganham um objeto authorization-policy-evaluation em cada conexão avaliada, com a decisão, se veio do connect ou de uma reavaliação, se o shadow mode estava ligado e o status de validação do token. Ativar IncludeAuthorizationPolicyContext nas --connection-log-options traz o contexto inteiro que o Cedar avaliou, útil enquanto você escreve a política e provavelmente informação demais em regime permanente.

Quem mexe com IAM e Zero Trust precisa saber disso

Esse recurso cai direto na mesa de quem escreve política de acesso, não só do time de rede. A política em Cedar junta, numa única expressão, o que antes vivia espalhado entre o IdP (identidade) e um agente de endpoint (postura), e isso é exatamente o tipo de unificação que times de IAM cobram há tempos de soluções de VPN corporativa.

No pilar de Segurança do Well-Architected, o ganho é direto: a janela entre um dispositivo ficar comprometido e perder acesso cai de "até a próxima reconexão" para "próximo refresh de token", algo em torno de cinco minutos. No pilar de Confiabilidade, o trade-off é a janela de 15 minutos de tolerância quando o provedor fica fora do ar: ela evita derrubar sessão por falha passageira, mas também é uma janela em que um dispositivo que acabou de ficar não conforme ainda carrega tráfego com os atributos antigos.

No pilar de Excelência Operacional, o shadow mode e as métricas prontas no AWS/ClientVPN resolvem o problema clássico de política de acesso nova: validar contra a frota real antes de bloquear alguém, sem precisar instrumentar nada à parte.

O que fica de fora e o que checar antes de ativar

Algumas limitações importam na hora de planejar o rollout:

• Só o AWS VPN Client oficial, versão 6.2.0 ou superior, envia o token de postura; outros clientes OpenVPN continuam conectando, mas sem atributo nenhum, e uma política que exige postura os recusa
• O arquivo .ovpn de configuração do usuário precisa ser redistribuído com a diretiva de postura antes de qualquer enforcement
• Um endpoint pode carregar mais de um trust provider ao mesmo tempo, e uma única política pode referenciar atributos de qualquer um deles
• O documento de política tem limite de 10.000 caracteres

A AWS diz que o recurso já está disponível, sem custo adicional, nas regiões onde o Client VPN já roda, e que o preço de endpoint e de conexão do Client VPN não muda. A fonte não cita regiões específicas. Configuração é possível pelo console, AWS CLI, SDKs e AWS CloudFormation, o que facilita colocar o registro do trust provider dentro do mesmo pipeline de infraestrutura como código que já provisiona o endpoint.

Fonte: AWS Networking & Content Delivery Blog