Pedidos de uma regra que só permita a conexão do portátil aprovado muitas vezes terminam como uma entrada de firewall para o endereço público do escritório. Essa regra agora admite todos os dispositivos atrás do endereço. O requisito e a implementação não são a mesma coisa. Separe o que a política quer do que o endereço pode provar.

Três perguntas em um único pedido de política

Divida o pedido em três partes: de onde vem a conexão, a que serviço pode chegar e qual computador apresenta a credencial. Uma regra de endereço de origem responde à primeira, e uma regra de serviço de destino à segunda. Nenhuma identifica a máquina física, porque ambas operam em campos de rede compartilhados por muitos dispositivos. A terceira exige uma credencial emitida para esse dispositivo e que não possa ser reutilizada em silêncio.

Escreva as três respostas separadamente. Uma única linha de firewall não pode satisfazer um requisito que nomeia três.

O que o endereço de origem pode lhe dizer

A tradução de endereços é o motivo habitual pelo qual uma regra de origem de rede admite demais. Tudo o que está atrás de uma saída do escritório aparece como o mesmo endereço público, então a regra concede acesso a todo o grupo. Um endereço fixo dentro da VPN tem a mesma fraqueza em outro lugar: é uma atribuição ligada a uma sessão, não uma propriedade do hardware. Qualquer dispositivo com uma credencial aceita pode abrir essa sessão. Trate o endereço como uma restrição de rede e descreva-o assim.

Isso continua útil para limitar a exposição, e não é autenticação de dispositivo.

Vincule o acesso a uma credencial registrada

Se o requisito é a restrição de dispositivo, use o registro por dispositivo compatível com a VPN e dê a cada computador uma identidade distinta.

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

A listagem do armazenamento mostra o certificado e se há uma chave privada, e a verificação mostra se a cadeia leva à âncora prevista. Um certificado prova a posse da chave privada aceita sob a política configurada; não prova qual máquina física a tinha quando essa chave pode ser exportada e copiada. Dar ao perfil o nome do portátil deixa o segredo exatamente tão transportável quanto antes. Onde a plataforma o admite, chaves protegidas por hardware com uma política de atestação dão um vínculo mais forte, e o registro ainda precisa decidir quem pode receber a credencial.

Teste o limite e depois planeje a remoção

Avalie dois casos: o portátil aprovado e o usuário devem conectar, e outro dispositivo que tenha apenas a conta do usuário não deve. Se o projeto exigir uma verificação de usuário e outra de dispositivo, verifique se o método escolhido aplica ambas na mesma sessão em vez de presumir que duas configurações independentes se combinam.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

A revogação deve remover a identidade aceita do dispositivo, e o tratamento das sessões ativas merece um teste próprio. Um TPM ou um indicador de dispositivo gerenciado não é um atestado limpo de saúde para cada processo da máquina.

Registre a restrição de rede, a credencial do dispositivo e a decisão de registro como três controles com três responsáveis. Isso torna o limite auditável, e é o que um endereço sozinho nunca pode fornecer.

Artigos relacionados