Palavras-passe VPN versus certificados de cliente: o que recupera mais rápido

Uma implementação pede nome de utilizador e palavra-passe, outra um certificado de cliente e uma terceira ambos. A escolha muda muito mais do que a caixa de início de sessão: decide como as credenciais são emitidas, como expiram, como é a recuperação às 2 da manhã e quem pode revogar o acesso para exatamente um dispositivo. Compare o ciclo de vida operacional e não a caixa de diálogo.

Uma palavra-passe é um segredo de conta validado por um processo de autenticação, enquanto um certificado é uma identidade mais a prova de posse da sua chave privada. São objetos diferentes com modos de falha diferentes.

Duas provas diferentes, duas caixas diferentes

Uma palavra-passe prova o conhecimento de um segredo partilhado, por isso o servidor compara um hash e o sistema de contas detém o ciclo de vida. Um certificado prova a posse de uma chave privada, e o servidor verifica uma cadeia de assinaturas até uma CA em que confia. O segundo pode identificar um dispositivo em vez de uma pessoa, e é por isso que as implementações emitem frequentemente um por portátil. Uma frase-passe que protege um ficheiro de chave é ainda uma terceira coisa: guarda o ficheiro em repouso e não é a palavra-passe da conta VPN.

A verificação do servidor continua necessária em qualquer combinação. Credenciais válidas enviadas para um endpoint cuja identidade deixou de verificar continuam a ser credenciais entregues a quem respondeu, e é por isso que a verificação do certificado do servidor pertence ao perfil básico e não a um passo de resolução de problemas.

A emissão, a expiração e a revogação são o custo real

As palavras-passe são baratas de emitir e caras de suportar: reposições, política, reutilização e a fila do helpdesk. Os certificados deslocam esse custo para o início, onde é necessária uma CA, um processo de assinatura e um canal de distribuição, e depois acrescentam um calendário de expiração que ninguém recorda. Ambos precisam de revogação planeada. Um certificado revogado precisa de uma CRL que cada servidor leia realmente, e uma conta desativada precisa que o backend de autenticação a recuse na ligação seguinte e não na sincronização seguinte.

Nenhum dos mecanismos se torna seguro por existir. A questão é qual ciclo de vida a equipa consegue operar de forma consistente.

O que se quebra quando um dispositivo se perde

Para um portátil perdido, remova a autorização que esse dispositivo realmente utilizou. Repor a palavra-passe não revoga o certificado, e emitir um certificado novo não altera a palavra-passe de uma conta não relacionada. Identidades separadas por dispositivo tornam possível uma remoção dirigida, enquanto credenciais partilhadas significam que retirar um dispositivo afeta vários. Escreva o procedimento de recuperação para cada mecanismo antes de precisar dele, incluindo quem pode assinar um certificado de substituição fora do horário de trabalho.

Exercite o caminho de revogação em vez de o assumir: revogue uma identidade de teste, confirme que o servidor a recusa numa ligação nova e depois restaure-a. Um processo de revogação nunca exercitado tende a falhar exatamente quando é necessário.

Operar ambos sem duplicar o trabalho

Muitas implementações combinam os dois de propósito: um certificado para o dispositivo e uma credencial de conta para a pessoa, de modo que um portátil roubado não basta e uma palavra-passe divulgada também não. Essa combinação só compensa quando os dois ciclos de vida permanecem separados e ambos estão automatizados. Caso contrário, o helpdesk gere duas filas e o ganho de segurança fica teórico.

Escolha o método que os clientes do serviço e as ferramentas de gestão realmente suportam. Enfraquecer a verificação para que um perfil desadequado se ligue inverte todo o sentido, e um perfil editado até conseguir ligar-se é muitas vezes um que já não verifica aquilo para que foi construído.

Registe que prova cada implementação exige e como cada uma é revogada. O próximo incidente vai pedir exatamente isso.