Tres dispositivos co mesmo conector e o mesmo anel de chaves participan en tres intercambios sen relación. Un mostra un código que comproba un servidor, outro asina cunha chave que nunca sae do dispositivo e outro aproba un inicio de sesión do navegador mediante un protocolo propio. Por iso, preguntar se unha VPN debe usar certificados ou tokens de hardware compara un formato cunha clase de dispositivo. A resposta depende de cal dos tres comprou vostede realmente.

Nomee a proba antes do dispositivo

Un token de código dun só uso produce un valor que un servizo de autenticación valida mediante o seu propio mecanismo. A VPN pode chegar a ese servizo mediante RADIUS ou un provedor de identidade federado, e o token nunca necesita gardar nada que pertenza ao propio túnel. O que demostra é que a persoa ten o dispositivo que xera o código. Non demostra nada sobre a máquina na que se escribiu o código.

Un token de tipo tarxeta intelixente garda unha chave privada e realiza a operación de sinatura cando se lle pide, e así se proba a identidade do certificado sen exportar a chave. O certificado que o acompaña é material público, e entregar ese certificado é un acto moi distinto de entregar a chave.

Unha chave FIDO fala de novo un terceiro protocolo. O inicio de sesión no navegador pode usala no provedor de identidade, pero o éxito nese sitio non significa que a mesma chave vaia aparecer pola interface de tarxeta intelixente dun cliente VPN.

Algúns dispositivos implementan varias destas aplicacións á vez, e a documentación do fabricante enumera os modos por separado precisamente por iso. Non é proba de que todas as chaves do mercado admitan todos os modos.

O hardware protexe a chave, non a política

Un PIN nun dispositivo con certificado adoita autorizar o uso local da chave, e non é o contrasinal que comproba o sistema de contas da VPN. Guías como as guías de NIST sobre autenticadores chaman a esa entrada local segredo de activación, distinto do autenticador en si. A garantía vén de todo o deseño, non do número de avisos na pantalla.

A inscrición, a renovación e a retirada seguen sendo do propietario da identidade en calquera caso. Alguén segue decidindo quen pode inscribirse, vincula a credencial á persoa correcta e fai posible a substitución cando se perde un dispositivo. Comprar unha chave nova non revoga a antiga.

Describa a cerimonia de inicio de sesión antes de elixir hardware: escribe o usuario un código, desbloquea unha chave de sinatura ou aproba un aviso do navegador? Cada resposta implica un cliente distinto, un axuste de pasarela distinto e un guión distinto para o servizo de asistencia.

Onde diverxen os fluxos na práctica

Un token de código é o máis fácil de despregar e o máis débil fronte a unha páxina de imitación convincente, porque un código escrito pódese reenviar en tempo real. Unha chave con certificado resiste esa clase de ataque e custa máis de operar, xa que a emisión e a revocación pasan a formar parte do servizo. Unha chave FIDO sitúase co inicio de sesión web e depende por completo de que o provedor de identidade a admita para esta aplicación.

Os ambientes mixtos son habituais e non son automaticamente erróneos: un certificado para o túnel máis un token de código para a consola administrativa é unha separación coherente, sempre que ambos estean inscritos contra a mesma identidade. O que se rompe é unha separación que ninguén documentou, onde o servizo de asistencia non pode dicir que factor lle falta a un usuario.

Faga a decisión concreta

Escriba a cerimonia como unha secuencia de pasos que executa un usuario real e logo comprobe que o cliente, a pasarela e o provedor de identidade admiten todos esa secuencia. O desaxuste adoita aparecer no último paso, cando o cliente non pode dirixirse ao dispositivo en absoluto.

Despois confirme que ocorre cando se perde o dispositivo ou caduca o certificado. Se esa resposta non está escrita, o despregamento ten un oco que se descubrirá un luns pola mañá.

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

Artigos relacionados