Adopción de llaves de acceso en las empresas: matices y desafíos

La transición a las llaves de acceso promete a las organizaciones un camino rentable hacia una autenticación sólida de los empleados, una mayor productividad y el cumplimiento normativo. Ya hemos cubierto todos los pros y los contras de esta solución empresarial en otro artículo detallado. Sin embargo, el éxito de la transición, e incluso su viabilidad, realmente depende de los detalles técnicos y de la implementación específica en numerosos sistemas corporativos.

Admisión de llaves de acceso en sistemas de gestión de identidad

Antes de abordar los obstáculos internos de la empresa y redactar las políticas, tendrás que determinar si tus sistemas de TI básicos están listos para el cambio a llaves de acceso.

Microsoft Entra ID (Azure AD) es totalmente compatible con las llaves de acceso, lo que permite a los administradores establecerlas como el método principal de inicio de sesión. Para implementaciones híbridas con recursos locales, Entra ID puede generar tickets Kerberos (TGT), que posteriormente su controlador de dominio de Active Directory puede procesar.

Sin embargo, Microsoft aún no ofrece compatibilidad nativa con llaves de acceso para inicios de sesión de RDP, VDI o AD solo en las instalaciones. Dicho esto, con algunas soluciones alternativas, las organizaciones pueden almacenar las llaves de acceso en un token de hardware como una YubiKey. Este tipo de token puede admitir simultáneamente la tecnología PIV (tarjetas inteligentes) tradicional y FIDO2 (llaves de acceso). También existen soluciones de terceros para estos escenarios, pero tendrás que evaluar el modo en que su uso afecta a tu postura general de seguridad y al cumplimiento normativo.

Buenas noticias para los usuarios de Google Workspace y Google Cloud, ya que ofrecen compatibilidad total con las llaves de acceso.

Sistemas de gestión de identidad populares como Okta, Ping, Cisco Duo o RSA IDplus también admiten FIDO2 y todas las formas principales de llaves de acceso.

Compatibilidad con las llaves de acceso en dispositivos cliente

Tenemos una publicación detallada sobre el tema. Todos los sistemas operativos modernos de Google, Apple y Microsoft admiten las llaves de acceso. Sin embargo, si tu empresa utiliza Linux, es probable que necesites herramientas adicionales y la compatibilidad general sigue siendo limitada.

Además, si bien para los principales sistemas operativos puede parecer una compatibilidad total a primera vista, hay mucha variedad en la forma en que se almacenan las llaves de acceso, y eso puede causar problemas de compatibilidad. Las combinaciones de varios sistemas, como ordenadores con Windows y teléfonos inteligentes con Android, son las más problemáticas. Podrías crear una llave de acceso en un dispositivo y luego descubrir que no puedes acceder a ella desde otro. Para las empresas con una flota de dispositivos gestionada estrictamente, hay un par de formas de abordar esto. Por ejemplo, podrías hacer que los empleados generen una llave de acceso independiente para cada dispositivo de la empresa que utilicen. Esto implica algo más de configuración inicial: los empleados deberán pasar por el mismo proceso de crear una llave de acceso en cada dispositivo. Sin embargo, una vez hecho esto, iniciar sesión lleva muy poco tiempo. Además, si pierden un dispositivo, no se quedarán completamente bloqueados sin sus datos de trabajo.

Otra opción es utilizar un gestor de contraseñas aprobado por la empresa para almacenar y sincronizar las llaves de acceso en los dispositivos de todos los empleados. Esto también es obligatorio para las empresas que utilizan ordenadores con Linux, ya que su sistema operativo no puede almacenar llaves de acceso de forma nativa. Solo un aviso: este enfoque podría añadir cierta complejidad en lo que respecta a las auditorías de cumplimiento normativo.

Si buscas una solución que casi no tenga problemas de sincronización y que sea compatible con varias plataformas, las llaves de acceso de hardware como YubiKey son la mejor opción. El inconveniente es que pueden ser mucho más caras de implementar y gestionar.

Admisión de llaves de acceso en aplicaciones empresariales

El escenario ideal para incorporar las llaves de acceso a tus aplicaciones empresariales es que todas tus aplicaciones inicien sesión mediante el inicio de sesión único (SSO). De esa manera, solo necesitas implementar la compatibilidad con llaves de acceso en tu solución de SSO corporativa, como Entra ID u Okta. Sin embargo, si algunas de tus aplicaciones empresariales críticas no admiten el SSO, o si esa compatibilidad no está contemplada en tu contrato (lo cual, desafortunadamente, sucede), tendrás que emitir llaves de acceso individuales para que los usuarios inicien sesión en cada sistema por separado. Los tokens de hardware pueden almacenar entre 25 y 100 llaves de acceso, por lo que su principal coste adicional sería en el ámbito administrativo.

Entre los sistemas comerciales populares que son totalmente compatibles con las llaves de acceso se incluyen Adobe Creative Cloud, AWS, GitHub, Google Workspace, HubSpot, Office 365, Salesforce y Zoho. Algunos sistemas SAP también admiten llaves de acceso.

Preparación de los empleados

Implementar llaves de acceso significa poner al día a tu equipo sin importar el escenario. No querrás que se queden rascándose la cabeza tratando de entender nuevas interfaces. El objetivo es que todos se sientan seguros al usar las llaves de acceso en cada dispositivo. Estos son los aspectos clave que tus empleados deben comprender.

• Por qué las llaves de acceso superan a las contraseñas (son mucho más seguras, más rápidas para iniciar sesión y no es necesario cambiarlas).
• Cómo funciona la biometría con las llaves de acceso (los datos biométricos nunca salen del dispositivo y no son almacenados ni procesador por el empleador).
• Cómo obtener su primera llave de acceso (por ejemplo, Microsoft tiene una función de pase de acceso temporal y los sistemas de IAM de terceros a menudo envían un enlace de incorporación; sin embargo, el proceso debe estar bien documentado).
• Qué hacer si su dispositivo no reconoce su llave de acceso.
• Qué hacer si pierden un dispositivo (iniciar sesión desde otro dispositivo que tenga su propia llave de acceso o usar una OTP, tal vez entregada en un sobre cerrado para una emergencia de este tipo).
• Cómo iniciar sesión en sistemas de trabajo desde otros ordenadores (si las políticas de la empresa lo permiten).
• Cómo podría ser un intento de phishing relacionado con llaves de acceso

Las llaves de acceso no son una solución mágica

Pasarse a las llaves de acceso no significa que tu equipo de ciberseguridad pueda simplemente tachar las amenazas de identidad de su lista de riesgos. Está claro que esto dificulta las cosas para los atacantes, pero aún pueden hacer lo siguiente:

• Atacar sistemas que no se hayan pasado a las llaves de acceso.
• Buscar sistemas que aún tengan métodos de inicio de sesión alternativos, como contraseñas y OTP.
• Robar tokens de autenticación de dispositivos infectados con ladrones de información.
• Usar técnicas especiales para eludir las protecciones de las llaves de acceso.

Si bien es imposible falsificar la llave de acceso en sí, los atacantes pueden configurar una infraestructura web falsa para engañar a la víctima para que use el autenticador y valide una sesión maliciosa en un servicio corporativo.

Un ejemplo reciente de este tipo de ataque AiTM se documentó en EE. UU. En ese incidente, la víctima fue atraída a una página de autenticación falsa para un servicio corporativo, donde los atacantes primero robaron su nombre de usuario y contraseña mediante phishing, y luego la confirmación de la sesión al hacer que escaneara un código QR. En este incidente, las políticas de seguridad se configuraron correctamente, por lo que el análisis de este código QR no condujo a una autenticación exitosa. Pero dado que se implementó un mecanismo de este tipo con llaves de acceso, los atacantes esperan que en algún lugar esté configurado incorrectamente y que no se verifique la proximidad física del dispositivo en el que se realiza la autenticación y el dispositivo donde se almacena el autenticador.

En última instancia, el cambio a claves de acceso requiere una configuración detallada de las políticas. Esto incluye tanto políticas de autenticación (como desactivar las contraseñas cuando hay una clave de acceso disponible o prohibir los tokens físicos de proveedores desconocidos) como políticas de supervisión (como registrar los registros de claves de acceso o los escenarios entre dispositivos desde ubicaciones sospechosas).