Código de token, tarjeta inteligente o llave FIDO: qué acepta una VPN
Un llavero de códigos, una tarjeta inteligente y una llave FIDO se llaman todos tokens de hardware. Participan en flujos distintos y solo uno de ellos guarda una clave de certificado.
Tres dispositivos con el mismo conector y el mismo anillo de llaves participan en tres intercambios sin relación. Uno muestra un código que un servidor comprueba, otro firma con una clave que nunca sale del dispositivo y otro aprueba un inicio de sesión del navegador mediante un protocolo propio. Por eso, preguntar si una VPN debe usar certificados o tokens de hardware compara un formato con una clase de dispositivo. La respuesta depende de cuál de los tres compró usted realmente.
Nombre la prueba antes del dispositivo
Un token de código de un solo uso produce un valor que un servicio de autenticación valida mediante su propio mecanismo. La VPN puede llegar a ese servicio mediante RADIUS o un proveedor de identidad federado, y el token nunca necesita guardar nada que pertenezca al propio túnel. Lo que demuestra es que la persona tiene el dispositivo que genera el código. No demuestra nada sobre la máquina en la que se escribió el código.
Un token de tipo tarjeta inteligente guarda una clave privada y realiza la operación de firma cuando se le pide, y así se prueba la identidad del certificado sin exportar la clave. El certificado que lo acompaña es material público, y entregar ese certificado es un acto muy distinto de entregar la clave.
Una llave FIDO habla de nuevo un tercer protocolo. El inicio de sesión en el navegador puede usarla en el proveedor de identidad, pero el éxito en ese sitio no significa que la misma llave vaya a aparecer por la interfaz de tarjeta inteligente de un cliente VPN.
Algunos dispositivos implementan varias de estas aplicaciones a la vez, y la documentación del fabricante enumera los modos por separado precisamente por eso. No es prueba de que todas las llaves del mercado admitan todos los modos.
El hardware protege la clave, no la política
Un PIN en un dispositivo con certificado suele autorizar el uso local de la clave, y no es la contraseña que comprueba el sistema de cuentas de la VPN. Guías como las guías de NIST sobre autenticadores llaman a esa entrada local secreto de activación, distinto del autenticador en sí. La garantía viene de todo el diseño, no del número de avisos en pantalla.
La inscripción, la renovación y la retirada siguen siendo del propietario de la identidad en cualquier caso. Alguien sigue decidiendo quién puede inscribirse, vincula la credencial a la persona correcta y hace posible la sustitución cuando se pierde un dispositivo. Comprar una llave nueva no revoca la antigua.
Describa la ceremonia de inicio de sesión antes de elegir hardware: ¿escribe el usuario un código, desbloquea una clave de firma o aprueba un aviso del navegador? Cada respuesta implica un cliente distinto, un ajuste de puerta de enlace distinto y un guion distinto para el servicio de asistencia.
Dónde divergen los flujos en la práctica
Un token de código es el más fácil de desplegar y el más débil frente a una página de imitación convincente, porque un código escrito se puede reenviar en tiempo real. Una llave con certificado resiste esa clase de ataque y cuesta más de operar, ya que la emisión y la revocación pasan a formar parte del servicio. Una llave FIDO se sitúa con el inicio de sesión web y depende por completo de que el proveedor de identidad la admita para esta aplicación.
Los entornos mixtos son habituales y no son automáticamente erróneos: un certificado para el túnel más un token de código para la consola administrativa es una separación coherente, siempre que ambos estén inscritos contra la misma identidad. Lo que se rompe es una separación que nadie documentó, donde el servicio de asistencia no puede decir qué factor le falta a un usuario.
Haga la decisión concreta
Escriba la ceremonia como una secuencia de pasos que ejecuta un usuario real y luego compruebe que el cliente, la puerta de enlace y el proveedor de identidad admiten todos esa secuencia. El desajuste suele aparecer en el último paso, cuando el cliente no puede dirigirse al dispositivo en absoluto.
Después confirme qué ocurre cuando se pierde el dispositivo o caduca el certificado. Si esa respuesta no está escrita, el despliegue tiene un hueco que se descubrirá un lunes por la mañana.
pkcs11-tool --list-slots
pkcs11-tool --list-objects --type cert