¡Bienvenido, compañero practicante de seguridad de Azure! Estoy dispuesto a apostar mi próximo cheque de pago a que se topó con esta publicación en particular, ya que recientemente la Gerencia le asignó la tarea de ayudar a su organización a realizar la transición a la autenticación sin contraseña. Dado que ya está operando dentro del ecosistema de Azure, pensó que esta publicación era un lugar práctico para comenzar. ¡Sabia decisión! ¿Sabía que las contraseñas comprometidas desempeñaron un papel clave en el 80+% de las ataques de ciberseguridad el año pasado? ? Lo haces ahora. No se trata sólo de ser seguro, sino también de ser práctico y operativamente eficiente. Para aquellos que somos ahorradores y conscientes de los costos, también deben tener en cuenta que hay un tremendo ROI asociado con no usar contraseña, e incluso ahorra unos dólares en tus tarifas de seguro cibernético. ¡Todo bien!
En la siguiente guía, nuestro objetivo es brindarle información sobre cómo puede dejar de tener contraseña en Azure AD. Tenemos la intención de cubrir todo, desde todos los “errores” hasta enlaces, tutoriales paso a paso para cada proceso y sugerencias que garantizarán que esté actualizado con las prácticas recomendadas de seguridad de identidad de Azure.
En el camino hacia la autenticación sin contraseña, se considera que seleccionar qué método(s) de autenticación vas a utilizar ser el proverbial “punto de partida” de toda la operación. Aquí está nuestra opinión sobre sus opciones, sus pros y sus contras, y en qué escenarios funcionan mejor.
Si existe un “viejo río” de autenticación sin contraseña, es CBA, o autenticación basada en certificados. Autenticación con tarjeta inteligente (PIV) utiliza certificados x.509 en una tarjeta inteligente (o tokens de hardware). Este es el único método de autenticación compatible con todas las bibliotecas de autenticación locales y en la nube de Azure, lo que lo convierte en el método de autenticación más versátil.
FIDO2 ha ganado popularidad en la comunidad sin contraseña debido a su reputación de ser más fácil de implementar y más conveniente para autenticarse (que lo es). Algunos de los ejemplos más destacados de claves de seguridad de hardware son la YubiKey y la Titan Security Key de Google. Desafortunadamente, como ocurre con cualquier tecnología nueva, existen algunos problemas de autenticación con sistemas heredados, como los locales, y todavía no hay compatibilidad total con FIDO2 en iOS o Azure PowerShell. ¿Mencionamos que somos miembros orgullosos y titulares de una tarjeta de la Alianza FIDO? …Porque estamos.
Si bien no es el método más seguro, la autenticación telefónica se ha convertido rápidamente en el método de autenticación habitual en la comunidad IAM. ¿Por qué? Fácil: casi todo el mundo lleva consigo su teléfono en todo momento. Por esa sencilla razón, es el método más utilizado en la actualidad. La autenticación telefónica no se considera antiphishing ya que los usuarios son propensos a sufrir fatiga de MFA.
Uno de los conceptos erróneos más comunes sobre la eliminación de contraseñas es que TODOS en la organización requieren el mismo nivel de protección. Simplemente no es cierto. Por ejemplo, su equipo de ventas puede usar sus teléfonos y autenticarse a través de una aplicación, y sus ejecutivos (con datos más valiosos) pueden estar protegidos mediante claves de seguridad de hardware que emplean FIDO2+CBA. Al fin y al cabo, las soluciones sin contraseña son verdaderamente ágiles por naturaleza. Entonces, cuando se trata de esto, es un delicado acto de equilibrio entre usabilidad, costo y tolerancia al riesgo. Aquí hay algunos casos de uso específicos para su consideración:
Si tiene un presupuesto limitado, utilice el método de autenticación sin contraseña más popular, Microsoft Passwordless Authenticator es una gran opción.
¿Por qué?
1) Es completamente gratis.
2) Los usuarios están acostumbrados a utilizar sus teléfonos. Emplearlo como método de autenticación es muy natural.
Nota: los teléfonos no son completamente antiphishing y la fatiga de MFA juega un papel importante en el phishing.
Hemos escrito extensamente este año sobre implementaciones sin contraseña locales, y en cada publicación, hemos hecho todo lo posible para dejar claro que la autenticación PIV con tarjeta inteligente es el camino a seguir en este escenario. Un par de cosas realmente geniales aquí…
1) Las tarjetas inteligentes son significativamente menos costosas en comparación con el costo de las llaves de hardware como YubiKeys.
2) ¡Las tarjetas inteligentes se pueden utilizar para algo más que autenticación! Por ejemplo, puede aprovecharlos como identificaciones de empleados y utilizarlos para acceder al edificio/sala.
Si hay una “desventaja” en este escenario, sería que necesitará hardware adicional (lectores de tarjetas, impresoras de tarjetas inteligentes, etc.) para que esta sea una opción realmente viable. Si bien hoy en día se puede adquirir hardware a un precio razonable, es importante realizar un análisis completo de costo/beneficio antes de realizar cualquier reacción instintiva. Dicho esto, probablemente debería utilizar tarjetas inteligentes en una implementación local. Más información sobre la adquisición de hardware más adelante en la publicación…
La inclinación natural de la mayoría de los profesionales de Azure AD es gravitar hacia FIDO2 en una implementación solo en la nube. Si bien tiene buenas intenciones, un único método de autenticación no es suficiente en este caso de uso, principalmente porque FIDO2 no es compatible con todos los servicios de Microsoft. Por ejemplo, las herramientas que utilizan MSAL, como Azure PowerShell, no admiten la autenticación FIDO2.
Para solucionar este dolor de cabeza, utilizamos la autenticación de certificado FIDO2 + Azure CBA. Básicamente, la forma en que logramos esto fue agregando un certificado de tarjeta inteligente a nuestra credencial FIDO2 (¡YubiKeys, en nuestro caso!). ¡Nuestra herramienta, EZCMS, es la única solución disponible que puede agregar un certificado de tarjeta inteligente y una credencial FIDO2 a una YubiKey en la misma incorporación ¡proceso! ¿La mejor parte? Todas sus necesidades de autenticación se resuelven sin confusión para el usuario final. ¡La mayoría de las veces, ni siquiera saben qué método se empleó para autenticarse!
Tomar la decisión de no usar contraseña es una decisión valiente y ciertamente admiramos su ambición. Dicho esto, todavía tenemos MUCHAS más investigaciones y pruebas por delante para que esta transición sea lo más fluida posible. A continuación se ofrece un vistazo rápido a algunas de las preguntas frecuentes y los próximos pasos asociados con la eliminación total de contraseñas en Azure.
Si bien Microsoft ha estado hablando mucho sobre ser “completamente sin contraseña” desde hace bastante tiempo, TODAVÍA no tienen la opción de crear usuarios sin contraseña. En este caso, creamos usuarios con contraseñas muy largas (que no se almacenan en ningún lugar) y tenemos políticas de acceso condicional que requieren un método de autenticación sin contraseña. Tenemos una excelente guía sobre cómo crear usuarios con contraseñas aleatorias que le brindará usted con el código de PowerShell para crear los usuarios.
Si está leyendo la documentación de Microsoft, le recomendarán usar un TAP, pero si realmente lo analizas, un TAP es solo una contraseña de un solo uso vulnerable a los ataques que mencionamos antes. ¿Necesitas más información? Tenemos un artículo completo sobre cómo incorporar usuarios sin TAP.
TL:DR: Debe tener una opción de incorporación de autoservicio como validación de identificación gubernamental de EZCMS.
Tanto para las empresas grandes como para las pequeñas, una de las partes más difíciles de no utilizar contraseñas con tokens de hardware es la distribución; desde lidiar con la aduana hasta tener un equipo dedicado para administrar y enviar las llaves, puede volverse excepcionalmente complejo. Por suerte, hemos aprendido de la distribución de decenas de miles de claves en todo el mundo y felizmente ofrecemos servicios logísticos gestionados de tarjetas inteligentes y YubiKey donde aprovechamos a nuestros socios en todo el mundo para distribuir claves a sus usuarios. En Keytos, no importa tu tamaño, podemos ayudarte con todo lo relacionado con la logística de hardware.
La mejor manera de autenticarse en su VPN y WIFI es utilizando certificados X.509 administrados a través de Intune SCEP. Puede configurar su servidor CA y SCEP ADCS y mantener esos servidores manualmente; sin embargo, existen servicios PKI de Intune de terceros, como EZCA que hacen que todo el proceso sea MUY fácil. Configure su CA respaldada por HSM y su perfil WIFI sin contraseña en minutos.
Una vez que haya implementado la autenticación sin contraseña en su organización, es hora de exigir que solo se utilicen esos métodos para la autenticación. Afortunadamente, Microsoft lo pone fácil con el acceso condicional (siempre que tenga una licencia Azure Premium P1 o superior, pero definitivamente vale la pena). Para configurar esto, puede ir al portal de Azure como administrador global, hacer clic en Azure AD y luego en Seguridad -> Políticas de acceso condicional -> Nueva política. Asigne un nombre a su política, configure un puñado de usuarios de prueba para probar la política (no desea bloquear a sus usuarios), seleccione las aplicaciones en las que desea aplicar esta política. Establezca sus condiciones (aquí puede excluir plataformas de dispositivos que no admitan el método de autenticación seleccionado; sin embargo, recomendamos aplicarlo en todas partes. Recuerde, los piratas informáticos solo tienen que encontrar un punto débil). Establezca “Requerir Fuerza de Autenticación” en MFA sin contraseña en la sección Conceder de los controles de acceso. También recomendamos configurar los requisitos del dispositivo; Puede ver nuestro seminario web sobre seguridad de dispositivos, pero este blog ya es demasiado largo para profundizar también en la seguridad de dispositivos.
Si bien el primer paso para la autenticación sin contraseña es proteger su cuenta corporativa, muchas organizaciones terminan ahí y se olvidan de una de las partes más grandes de su infraestructura crítica: Linux. De forma predeterminada, Linux está diseñado para tener cuentas locales que no están conectadas a Active Directory. Esto solía ser aceptable, pero en el mundo actual, la sobrecarga del ciclo de vida de las credenciales y la administración de usuarios no se adapta a los requisitos de la nube. Para solucionar esto, muchos intentan unir AD a sus máquinas Linux. Si bien “funciona”, no es tan seguro y propenso a interrupciones relacionadas con el DNS. Líderes de la industria como Google, Facebook, Uber y Netflix han recurrido a los certificados SSH para una autenticación segura de Linux. Entonces, ¿qué son los Certificados SSH? Más sobre eso en el blog.
Como puede ver claramente, no tener contraseñas en Azure puede tener muchas partes móviles, pero es 100% posible. Si está listo para dar el siguiente paso en su viaje sin contraseñas, reserve una llamada con uno de nuestros ingenieros, con más de décadas de experiencia moviendo algunas de las empresas más grandes (incluidas Microsoft) a un entorno totalmente sin contraseña. ¡Estaremos encantados de revisar su plan y asegurarnos de que haya cruzado todos los puntos y las íes!
