Para implementar de manera efectiva la autenticación sin contraseña en Azure en toda su organización, primero debe reflexionar sobre todo el ciclo de vida del usuario. Esto implica procesos como crear una cuenta de usuario sin contraseña, distribuir claves de hardware (por ejemplo, YubiKeys), incorporar usuarios y computadoras personales, autenticarse en la red, implementar acceso condicional y permitir la entrada sin contraseña a recursos que no son de Active Directory, como los sistemas Linux. Sabemos que eso puede ser un gran dolor de cabeza; Si bien no podemos proporcionarle ibuprofeno, ¡podemos ayudarlo a aliviar ese dolor de cabeza al profundizar en cada uno de estos aspectos! ¡Miremos más de cerca!
Aunque Microsoft ha estado discutiendo el concepto de un sistema sin contraseña durante algún tiempo, actualmente carecen de la función para configurar cuentas de usuario sin contraseña. El enfoque más factible es crear cuentas con contraseñas extremadamente largas (que no se registran en ninguna parte) y establecer políticas de acceso condicional que exijan métodos de autenticación sin contraseña. Ofrecemos un excelente tutorial sobre cómo crear usuarios con contraseñas aleatorias, completo con el código de PowerShell para facilitar la creación de usuarios, no es que seamos parciales ni nada por el estilo.
Para organizaciones de cualquier tamaño, uno de los aspectos más desafiantes de implementar la autenticación sin contraseña con claves de hardware (piense en YubiKeys) es su distribución.
En las grandes empresas, la distribución global plantea desafíos importantes, desde navegar por las aduanas hasta la necesidad de un equipo dedicado para administrar y enviar claves, lo que genera una complejidad considerable: ¿quién quiere lidiar con todo eso? Afortunadamente, nuestra experiencia en la distribución de decenas de miles de claves en todo el mundo ha sido invaluable. EZCMS simplifica este proceso con su software de emisión de boletos integrado, lo que ayuda a su departamento de TI a manejar y rastrear el inventario de manera eficiente. Además, nuestro servicio logístico administrado de tarjetas inteligentes y YubiKey utiliza socios para distribuir claves a sus usuarios a nivel internacional.
Las pequeñas empresas enfrentan desafíos diferentes pero igualmente abrumadores. Estas incluyen limitaciones impuestas por los líderes de la industria que no pueden vender claves a organizaciones más pequeñas y la falta de infraestructura para distribuir o imprimir tarjetas inteligentes, lo que dificulta la transición a un sistema sin contraseña. En Keytos, atendemos a organizaciones de todos los tamaños, ayudándolas con todo, desde la impresión de tarjetas inteligentes hasta la adquisición y entrega de llaves de hardware. ¡Nuestro equipo de expertos está dedicado a hacer que su cambio a un entorno sin contraseña sea lo más sencillo posible!
El desafío inicial aquí consiste en presentar a los usuarios el método sin contraseña seleccionado sin usar una contraseña, y al mismo tiempo protegerse contra ataques de ingeniería social a su personal de TI (similar a la violación de datos de restablecimiento de contraseña de MGM donde los atacantes se hicieron pasar por un usuario para obtener una contraseña temporal).
Al consultar las pautas de Microsoft, sugieren utilizar un Pase de Acceso Temporal (TAP); sin embargo, cuando se examina de cerca, un TAP funciona esencialmente como una contraseña de un solo uso (OTP), susceptible a los tipos de ataques mencionados anteriormente, convirtiéndose potencialmente en el punto más vulnerable de todo su sistema. Hemos preparado una guía completa sobre cómo incorporar usuarios sin depender de TAP que valoramos altamente Te recomendamos que consultes. Básicamente, debe implementar un proceso de incorporación de autoservicio, como la función de validación de identificación gubernamental que ofrece EZCMS, como se ilustra en el siguiente vídeo:
Después de crear la identidad del usuario, recomendamos configurar un quiosco para que los usuarios accedan a la aplicación EZCMS independientemente de su computadora personal o permitir que los usuarios remotos se inscriban usando sus propias computadoras. No hay necesidad de preocuparse por las violaciones de seguridad de los dispositivos no administrados, ya que EZCMS incorpora validaciones adicionales.
Posteriormente, el usuario deberá configurar su PC de trabajo. En particular, Windows 11 facilita el inicio de sesión con una clave de seguridad desde la configuración inicial, lo que permite a los usuarios iniciar sesión en sus computadoras por primera vez usando su clave FIDO2, eliminando así la necesidad de una contraseña o un TAP.
Si está utilizando Autopilot, eso significa que también está usando Intune; para autenticarse en su VPN y Wi-Fi, el método más efectivo es utilizar certificados X.509 administrado por Intune SCEP. Tiene la opción de configurar su ADCS CA y servidor SCEP y administrar estos servidores manualmente; sin embargo, también existen servicios PKI de Intune de terceros como EZCA que simplifican enormemente este proceso. Estos servicios le permiten establecer rápidamente una CA respaldada por HSM y configurar un perfil de Wi-Fi sin contraseña en apenas unos minutos.
Después de implementar la autenticación sin contraseña en su organización, el siguiente paso es garantizar que solo se utilicen estos métodos para la autenticación. Microsoft facilita esto con su función de acceso condicional, disponible con una licencia Entra ID Premium P1 o superior, y es una inversión que vale la pena.
Para configurar esto, inicie sesión en Azure Portal como administrador global, navegue hasta Entra ID y luego a Seguridad -> Políticas de acceso condicional -> Nueva política. Cree una política y aplíquela inicialmente a un grupo selecto de usuarios de prueba para evitar bloquear a todos accidentalmente. Elija las aplicaciones a las que desea aplicar esta política. En la sección de condiciones, puede optar por excluir las plataformas de dispositivos que no sean compatibles con el método de autenticación elegido, pero es recomendable aplicarlo en todas las plataformas, ya que los piratas informáticos solo necesitan una única vulnerabilidad para causar estragos. En la sección Conceder de los controles de acceso, establezca “Requerir seguridad de autenticación” en MFA sin contraseña. También es aconsejable implementar los requisitos del dispositivo; Para obtener más detalles sobre la seguridad de los dispositivos, consulte nuestro seminario web sobre seguridad de los dispositivos, aunque este blog no es el lugar para una discusión en profundidad sobre ese tema. tema.
Proteger las cuentas corporativas es sólo el primer paso hacia la autenticación sin contraseña, pero muchas organizaciones se detienen ahí y pasan por alto un componente crítico de su infraestructura: Linux. Tradicionalmente, Linux tiene cuentas locales que no están vinculadas a Active Directory, un sistema adecuado para los primeros días de SSH pero ineficiente para las necesidades de escala y seguridad de los entornos de nube modernos: la sobrecarga del ciclo de vida de las credenciales y la administración de usuarios simplemente no escala. Algunas organizaciones intentan integrar sus máquinas Linux con Active Directory, pero este enfoque, aunque funcional, carece de una seguridad óptima y es vulnerable a interrupciones relacionadas con el DNS. Grandes organizaciones como Google, Facebook, Uber y Netflix han pasado a utilizar certificados SSH.
Los certificados SSH son herramientas criptográficas que otorgan acceso temporal a los nodos de Linux. El desafío radica en su creación: la creación manual es posible, pero Linux carece de un sistema automatizado para verificar los niveles de acceso de los usuarios antes de otorgar permisos. Estas empresas más grandes han desarrollado herramientas internas para verificar los permisos de los usuarios y generar certificados SSH. Aunque estas herramientas internas son propietarias, EZSSH ofrece una solución similar. EZSSH autentica a los usuarios a través de Entra ID, garantiza el cumplimiento de sus políticas de acceso condicional y verifica las ACL de políticas híbridas o RBAC de Azure para puntos finales SSH que no son de Azure. Luego, EZSSH genera un certificado SSH a corto plazo para el acceso de los usuarios. Después de la sesión, el certificado caduca, evitando su uso indebido. ¡Habla de un punto de inflexión!
Esta extensa guía demuestra que, si bien la transición a un sistema totalmente sin contraseña en Azure implica muchos componentes, es totalmente posible siempre que esté completamente preparado. Una vez que haga el cambio a la autenticación sin contraseña, probablemente nunca querrá volver a las viejas costumbres: hemos estado operando con un modelo sin contraseña durante más de dos años y la experiencia ha sido fantástica.
Si está preparado para avanzar en su viaje sin contraseñas, no dude en programar una consulta GRATUITA con uno de nuestros ex expertos en identidad de Microsoft. ¡Esperamos evaluar su estrategia y ayudarlo a garantizar que cada detalle haya sido pensado y abordado!
