TecTop
Las contraseñas son un desastre, MFA puede ser más un recurso provisional que una solución para el phishing y ejecutar su propia infraestructura de clave pública para certificados es mucho trabajo. El objetivo a largo plazo es pasar a credenciales sin contraseña que no puedan ser suplantadas.
“Las contraseñas son un gran problema: un gran problema de usabilidad y un gran problema de gestión”, dijo a TechRepublic Alex Weinert, vicepresidente de seguridad de identidad de Microsoft. “Hay diferentes formas de eludir el uso de contraseñas, y la forma tradicional es tener una contraseña de todos modos, pero luego respaldarla con otra cosa”.
Desafortunadamente, debido a la ingeniería social, este método aún es inseguro.
“Cada vez más, nos estamos moviendo hacia credenciales resistentes al phishing, porque el problema de respaldar una contraseña con otra cosa es que si alguien adivina su contraseña, puede engañarlo para que apruebe la otra parte”, dijo Weinert.
VER: Política de seguridad de dispositivos móviles (TechRepublic Premium)
Las dos opciones de autenticación multifactor que cuentan como resistentes al phishing son las claves de seguridad FIDO, que incluyen opciones biométricas integradas como Windows Hello y verificación de identidad personal y tarjetas de acceso común.
Salta a:
La actualización de certificados a través de ADFS es complicada y costosa
Irónicamente, si usted es una organización consciente de la seguridad en una industria regulada que ya hizo el arduo trabajo de adoptar el estándar de oro anterior (tarjetas inteligentes que tienen un certificado de seguridad y lo validan contra una autoridad de certificación en su infraestructura), es posible que se quede atascado. ejecutando ADFS mientras intenta pasar a las nuevas claves FIDO. Esto es especialmente cierto para las empresas con una política BYOD.
Hasta hace poco, la única forma de usar PIV y CAC con Azure AD era ejecutar ADFS en su propia infraestructura, federada con su autoridad de certificación. Usar ADFS como servidor para firmar tokens SAML significa administrar certificados de firma.
“Administrar certificados es difícil, administrar certificados de forma segura es muy difícil y la infraestructura local es increíblemente difícil de defender”, dijo Weinert. “Si vas a hacerlo, debes poder poner muchos recursos en ello”.
La infraestructura local es propensa a sufrir ataques
No todas las organizaciones tienen esos recursos disponibles, y gran parte del impulso para mover la infraestructura de identidad a la nube se debe a lo difícil que es mantenerla segura en sus propios servidores. Weinert señaló como ejemplo las filtraciones de datos recientes.
“La brecha casi siempre proviene de la infraestructura local”, dijo. “En la mayoría de los entornos, ingresar a la VPN no es tan difícil, porque todo lo que necesito es que un usuario en ese entorno haga clic en un enlace incorrecto y obtenga malware, y ahora tengo el mando y control dentro de la VPN. A partir de ahí, es un trabajo relativamente corto hacer un movimiento lateral a un servidor que está haciendo algo importante como validar certificados o firmar cosas».
Un ataque reciente colocó malware a nivel de sistema en un servidor ADFS, lo que permitió a los atacantes envolver el proceso e interceptar firmas, aunque la organización estaba usando un HSM. Eso fue hecho por lo que Weinert llama un atacante bastante sofisticado.
“Ahora que lo han hecho, todos lo intentarán”, advirtió.
Certificados móviles y Azure AD
Windows Hello, los tokens FIDO y las claves de acceso le brindan la misma autenticación sólida que la autenticación basada en servidor sin tener que ejecutar una infraestructura de certificados. Sin embargo, algunas organizaciones aún no pueden hacer ese movimiento.
“El objetivo a largo plazo es que no tengamos personas que administren su PKI en absoluto, porque es mucho más fácil para ellos y mucho más seguro” tenerlos administrados en la nube, dijo Weinert. “Ejecutar su propia PKI es algo de lo que probablemente todo el mundo quiera alejarse, pero nadie puede hacerlo al instante”.
La autenticación basada en certificados en Azure AD agrega compatibilidad con tarjetas inteligentes a Azure AD, y ahora puede establecer una política que requiera MFA resistente al phishing para iniciar sesión en aplicaciones nativas y basadas en la web en iOS y Android usando claves de seguridad FIDO. Esto también funciona para la aplicación Microsoft Authenticator en iOS y Android con YubiKey para iniciar sesión en aplicaciones que no usan la última versión de la biblioteca de autenticación de Microsoft.
El uso de claves de hardware permite a los equipos proporcionar certificados a trabajadores remotos, BYOD y otros dispositivos no administrados, sin tener que alejarse de su infraestructura existente hasta que esté listo. También tiene más confianza en que el certificado está protegido, porque nunca sale de la protección de hardware de la clave de seguridad: si proporciona certificados directamente en los dispositivos, debe confiar en el PIN del dispositivo, y establecer una política de PIN más estricta puede ser un problema. gran éxito para la productividad del usuario.
Una buena seguridad mejora la productividad
Además de que las organizaciones obtienen una mejor seguridad, los empleados obtienen una mejor experiencia porque no tienen que asegurarse de que su dispositivo móvil se conecte con la frecuencia suficiente para tener un certificado actualizado o lidiar con tantas solicitudes de autenticación que se fatigan con MFA y simplemente haga clic en sí en lo que podría ser un ataque de phishing. El uso de un certificado, en el teléfono o a través de una clave de seguridad, significa que no necesita preguntar al usuario en absoluto.
Demasiadas organizaciones piensan que solicitar a los usuarios que inicien sesión con MFA repetidamente cada una o dos horas mejora la seguridad. Hace lo contrario, advirtió Weinert.
“Es contraproducente, y no solo porque es frustrante para el usuario”, dijo. “Ahora no puedes usar un aviso interactivo como medida de seguridad, porque van a decir que sí”.
Lo comparó con los cambios de contraseña forzados.
“A primera vista, parece una buena idea, pero en realidad es la peor idea de todas”, dijo Weinert. “Cambiar su contraseña no hace más que facilitar que un atacante adivine la siguiente contraseña o adivine la contraseña que tiene ahora, porque las personas son predecibles”.
Una clave de hardware también es más portátil: si alguien obtiene un teléfono nuevo, o un trabajador de primera línea inicia sesión en un quiosco compartido o recibe un dispositivo diferente todos los días, puede usar el token de inmediato.
Mobile Azure AD Certificate-Based Access está en versión preliminar pública e inicialmente solo funciona con claves de seguridad YubiKey que se conectan a un puerto USB: Microsoft planea agregar compatibilidad con NFC, así como con más proveedores de hardware.
También encaja con otras mejoras en Azure AD que puede resultarle útil. Si ya usa una YubiKey para asegurar el acceso a Active Directory y ADFS, el mismo certificado en la clave de seguridad ahora le permitirá autenticarse en recursos protegidos por Azure AD como Azure Virtual Desktop.
Combine esto con las nuevas políticas granulares de acceso condicional en Azure AD para elegir qué nivel de MFA se requiere para diferentes aplicaciones. Ahora puede permitir el acceso a aplicaciones heredadas que podrían no ser compatibles con FIDO con opciones como TOTP sin tener que permitir eso para todas las aplicaciones.
Estas son opciones que no fuerzan una elección falsa entre productividad y seguridad, señala Weinert.
“Si inhibe la productividad de alguien, como organización o como usuario, siempre elegirá la productividad sobre la seguridad”, dijo. “Si desea que las personas tengan mejores prácticas de seguridad, lo que debe hacer es hacer que la forma segura de hacer las cosas sea la forma productiva de hacerlo”.
