Acesso VPN para conta de serviço: certificado ou login compartilhado

Dois desenhos cobrem quase toda configuração de VPN sem assistência: um login humano compartilhado guardado num script, ou um certificado de máquina vinculado ao host. Eles falham em pontos diferentes, e isso importa mais do que a velocidade de montagem. Uma senha armazenada quebra quando o dono a altera ou sai da empresa; um certificado quebra quando expira ou quando o host é reconstruído sem a chave. Três condições decidem qual custo você consegue carregar, e nenhum dos desenhos limita nada até que a política de autorização o faça.

Comece pela tarefa, não pela conta

A tarefa define a fronteira: quais destinos, quais serviços, em que horários, por quanto tempo uma sessão pode durar. Uma rota de túnel é apenas metade dessa fronteira. O gateway decide se a sessão é permitida; o recurso por trás dele decide o que a sessão pode fazer. Escreva a lista primeiro, com um responsável nomeado, porque os dois desenhos de identidade precisam satisfazê-la.

Mantenha autenticação e autorização separadas enquanto você anota tudo. A autenticação responde quem está se conectando; a autorização responde a que a sessão pode chegar depois. O RADIUS transporta a segunda parte como atributos tais como Filter-Id, Framed-IP-Address, Session-Timeout e Class, e o gateway os anexa assim que o login é bem-sucedido. Um desenho que troca o login e deixa a autorização intacta não limitou nada.

Login humano compartilhado: a senha vira a fronteira

Reutilizar uma conta humana é o caminho mais rápido e o que envelhece pior. A credencial é uma senha, então ela acaba num script, num arquivo de ambiente e numa configuração de agendador, e cada cópia precisa de rotação. Quando o dono a altera numa sexta-feira, a tarefa falha na execução seguinte e ninguém está olhando.

O MFA é onde esse desenho costuma desmoronar. Um script não consegue responder a um pedido de aprovação, então a conta é excluída da política, que é exatamente a conta que um atacante escolheria. Exclusões, contornos de local confiável e isenções por conta se multiplicam, e nenhuma delas é visível para a próxima pessoa que lê as configurações do locatário.

A atribuição é o outro custo. Cada sessão no log do gateway carrega o mesmo nome de usuário, então a sincronização noturna não pode ser distinguida do trabalho da pessoa que a escreveu, e revogar a tarefa significa revogar essa pessoa.

Certificado de máquina: identidade vinculada ao host

Um certificado muda a pergunta de o que a conta sabe para o que o host é. Com EAP-TLS o cliente apresenta um certificado e prova a posse da chave privada correspondente; o servidor de políticas mapeia o sujeito ou a conta de computador para um grupo e aplica a política desse grupo. Sem prompt, sem segredo compartilhado parado num arquivo de texto.

A fronteira que ele cria é mais estreita do que as pessoas esperam. Um certificado autentica o host, não a tarefa, e qualquer pessoa com root ou administração local pode usar essa chave naquele host. Guarde a chave onde a plataforma a protege: não exportável no repositório de certificados do Windows, respaldada por TPM onde o perfil permite, ou um arquivo 0600 de propriedade do root no Linux. Comprometer o host é comprometer a credencial.

A expiração é a falha recorrente. Um certificado que expira num domingo para a tarefa no domingo, e o gateway costuma relatar uma falha de autenticação genérica em vez de nomear a data. Verifique as datas a partir do host da tarefa como parte do runbook:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

A revogação precisa de um caminho que o gateway verifique. O OpenVPN lê uma CRL pela opção crl-verify, e o strongSwan depende de CRL ou OCSP conforme o perfil de conexão é construído. Se nenhum dos dois estiver ligado, remover um host significa esperar o certificado expirar.

Três condições que decidem entre eles

Faça a comparação contra a plataforma que você tem, não contra um desenho de referência.

Primeira condição: o gateway consegue autorizar uma identidade de máquina? Se ele só mapeia um nome de usuário RADIUS para um usuário do diretório, um certificado autentica o host e depois trava na autorização. Segunda condição: a tarefa precisa de acesso a recursos que só uma conta de usuário carrega, como um compartilhamento mapeado ou uma licença por assento? Então uma identidade de máquina não substitui, e a resposta honesta é uma conta de usuário dedicada com uma política delimitada. Terceira condição: quem consegue girar a credencial sem uma pessoa no circuito? O registro automatizado torna os certificados baratos de manter; uma senha conhecida por uma pessoa, não.

Leia a tabela como uma lista de custos, não como um ranking. A coluna do segredo armazenado ganha em velocidade de revogação e em compatibilidade com recursos que só entendem contas de usuário; a coluna do certificado ganha em rotação e em não enfraquecer o MFA para fazer um script funcionar.

Coloque o limite na política, depois da autenticação

Qualquer que seja a identidade escolhida, o limite de permissão pertence à política que roda depois da autenticação. No NPS, as políticas de rede são avaliadas em ordem e a primeira política que corresponde a todas as condições aplica suas configurações, então uma política ampla colocada acima de uma estreita decide o resultado, não importa o que o cliente apresente. A Microsoft documenta o modelo de condições e configurações no seu panorama de políticas do NPS.

Dê à tarefa seu próprio grupo ou condição de política, baseada em algo que a identidade da máquina carrega: um modelo de certificado, um identificador de estação de chamada ou um endereço de um pool dedicado. Depois limite a sessão com atributos: um Filter-Id para o papel ao qual seu gateway o mapeia, um Session-Timeout curto para que uma tarefa travada se autentique de novo em vez de manter uma sessão por dias, e um Framed-IP-Address de um pool que você protege com firewall do outro lado. A autorização da aplicação permanece separada: um túnel até um servidor de banco de dados não é permissão para ler uma tabela dentro dele.

Verifique as recusas, depois planeje a remoção

Acesso que funciona não prova nada sobre privilégio mínimo. Teste as recusas: conecte-se com a identidade da tarefa e tente alcançar um destino fora da lista, abra uma segunda sessão concorrente se o gateway deve permitir apenas uma, e repita o login depois de revogar a credencial.

Depois confirme a mesma sessão em dois lugares. O log do gateway mostra a identidade que se autenticou; o log do servidor de políticas mostra qual política correspondeu e quais atributos ela devolveu. No OpenVPN o servidor registra o nome comum do certificado, e o ipsec statusall no strongSwan imprime o túnel estabelecido com a identidade em uso. Se os dois logs discordam sobre a identidade, a política está correspondendo a algo diferente do que você supõe.

A remoção pertence ao desenho, não a uma força-tarefa de limpeza. Anote tudo a excluir (certificado ou conta, associação a grupo, política de rede, entrada no pool, regra de firewall no alvo) e execute isso uma vez enquanto a tarefa ainda é fácil de reconstruir.

Se você está começando hoje, trabalhe nesta ordem: escreva a lista de recursos, escolha a identidade com as três condições, coloque o limite na política e exercite uma negação antes de a tarefa entrar em produção.