Três dispositivos com o mesmo conector e o mesmo anel de chaves participam em três trocas sem relação. Um mostra um código que um servidor verifica, outro assina com uma chave que nunca sai do dispositivo e outro aprova um início de sessão do navegador através de um protocolo próprio. Por isso, perguntar se uma VPN deve usar certificados ou tokens de hardware compara um formato com uma classe de dispositivo. A resposta depende de qual dos três comprou realmente.

Nomeie a prova antes do dispositivo

Um token de código de uso único produz um valor que um serviço de autenticação valida através do seu próprio mecanismo. A VPN pode chegar a esse serviço através de RADIUS ou de um fornecedor de identidade federado, e o token nunca precisa de guardar nada que pertença ao próprio túnel. O que prova é que a pessoa detém o dispositivo que gera o código. Não prova nada sobre a máquina onde o código foi digitado.

Um token do tipo cartão inteligente guarda uma chave privada e executa a operação de assinatura quando solicitado, e é assim que a identidade do certificado é provada sem exportar a chave. O certificado ao lado é material público, e entregar esse certificado é um ato muito diferente de entregar a chave.

Uma chave FIDO fala novamente um terceiro protocolo. O início de sessão no navegador pode usá-la no fornecedor de identidade, mas o sucesso nesse site não significa que a mesma chave aparecerá através da interface de cartão inteligente de um cliente VPN.

Alguns dispositivos implementam várias destas aplicações lado a lado, e a documentação do fornecedor lista os modos separadamente precisamente por isso. Não é prova de que todas as chaves do mercado suportem todos os modos.

O hardware protege a chave, não a política

Um PIN num dispositivo com certificado autoriza normalmente o uso local da chave, e não é a palavra-passe que o sistema de contas da VPN verifica. Orientações como as orientações do NIST sobre autenticadores chamam a essa entrada local segredo de ativação, distinto do autenticador em si. A garantia vem do desenho completo, não do número de pedidos no ecrã.

O registo, a renovação e a remoção continuam a pertencer ao proprietário da identidade em qualquer caso. Alguém continua a decidir quem pode registar-se, vincula a credencial à pessoa certa e torna a substituição possível quando um dispositivo se perde. Comprar uma chave nova não revoga a antiga.

Descreva a cerimónia de início de sessão antes de escolher hardware: o utilizador escreve um código, desbloqueia uma chave de assinatura ou aprova um pedido do navegador? Cada resposta implica um cliente diferente, uma definição de gateway diferente e um guião diferente para o serviço de apoio.

Onde os fluxos divergem na prática

Um token de código é o mais fácil de implementar e o mais fraco contra uma página de imitação convincente, porque um código escrito pode ser reencaminhado em tempo real. Uma chave com certificado resiste a essa classe de ataque e custa mais a operar, já que a emissão e a revogação passam a fazer parte do serviço. Uma chave FIDO fica com o início de sessão web e depende inteiramente de o fornecedor de identidade a suportar para esta aplicação.

Os ambientes mistos são comuns e não são automaticamente errados: um certificado para o túnel mais um token de código para a consola administrativa é uma separação coerente, desde que ambos estejam registados na mesma identidade. O que se quebra é uma separação que ninguém documentou, onde o serviço de apoio não consegue dizer que fator falta ao utilizador.

Torne a decisão concreta

Escreva a cerimónia como uma sequência de passos que um utilizador real executa e depois verifique se o cliente, a gateway e o fornecedor de identidade suportam todos essa sequência. O desajuste costuma aparecer no último passo, quando o cliente não consegue dirigir-se ao dispositivo de todo.

Depois confirme o que acontece quando o dispositivo se perde ou o certificado expira. Se essa resposta não estiver escrita, a implementação tem uma lacuna que será descoberta numa segunda-feira de manhã.

pkcs11-tool --list-slots
pkcs11-tool --list-objects --type cert

Artigos relacionados