Actualizado: Azure AD Password Protection pasó a estar disponible de forma generalel 2 de abril de 2019. El servicio es en gran medida el mismo que presenté en este post, con las siguientes actualizaciones:
- Se ha suprimido el límite de dos apoderados.
- Al registrar el proxy y el bosque de Active Directory, ahora están disponibles 3 modos de autenticación . Dos de ellos admiten MFA, por lo que no es necesario tener una cuenta de administrador global sin MFA.
- Se ha actualizado el algoritmo de evaluación de contraseñas prohibidas. Consulte "Cómo se evalúanlas contraseñas" en la documentación de Microsoft. Nota: este algoritmo puede cambiar en cualquier momento, sin previo aviso ni actualización de la documentación.
- Se ha simplificado la concesión de licencias: Todos los usuarios sincronizados con Azure AD deben tener Azure AD Premium P1 o P2. Una vez cumplido este requisito, todos los usuarios de Active Directory tienen licencia para este servicio.
- Los clientes de Preview deben actualizar los agentes; los agentes de Public Preview dejarán de funcionar después del 1 de julio de 2019.
- Mis fuentes de Microsoft me dicen que, con un poco de comunicación previa, los usuarios no están encontrando tan confuso como pensaban el nuevo rechazo de contraseñas comunes con el mensaje estándar "Su contraseña no cumple los requisitos de complejidad".
- ¡Empiece a desplegar!
Microsoft ha proporcionado finalmente un servicio que mitiga el riesgo de seguridad relacionado con las contraseñas más crítico en la empresa hoy en día: las contraseñas comunes. Debería probar esta nueva capacidad de Active Directory hoy mismo para poder implementarla en cuanto esté disponible de forma general.
Este es un artículo largo; si no le interesa la versión resumida (y debería interesarle), puede ir directamente a
- La contraseña común como vector de ataque
- Arquitectura
- Flujo de autenticación en tiempo de ejecución
- Proceso de evaluación de contraseñas
- Ventajas del diseño
- Pasos de la implantación
- Supervisión
- Licencias
- Cosas varias
La contraseña común como vector de ataque
He publicado en este blog y hablado en Cloud Identity Summit (ahora Identiverse) sobre las recomendaciones de Microsoft y el NIST sobre cómo configurar la longitud de la contraseña, la caducidad y otras políticas de contraseña a la luz de su investigación y experiencia sobre el terreno. Una de las principales recomendaciones de ambas organizaciones es el uso de una lista de contraseñas prohibidas, en la que las contraseñas más simples y comunes no están permitidas. (Y sí, estoy aquí para decirte que algunas de las contraseñas más comunes son "password" y "12345678". Temo por la raza humana).
Según Microsoft, los ataques contra contraseñas comunes mediante ataques de "pulverización de contraseñas" han aumentado drásticamente en los últimos meses. Son extremadamente difíciles de defender con herramientas de seguridad convencionales porque el atacante no ataca una sola cuenta con varias contraseñas. En su lugar, utiliza unas pocas contraseñas comunes para atacar varias cuentas. Cada cuenta se intenta sólo unas pocas veces, y tal vez con un largo intervalo entre los intentos para evitar la activación de alertas. La mejor manera de protegerse contra estos ataques es simplemente no tener contraseñas comunes.
La mayoría de las grandes organizaciones utilizan una arquitectura de identidad híbrida en la que las contraseñas se gestionan en un bosque de Active Directory local. Lamentablemente, Active Directory no dispone de una solución lista para usar que prohíba las contraseñas comunes. Como resultado, la mayoría de las organizaciones no tenían protección contra las contraseñas comunes.
Azure AD Password Protection es un servicio híbrido en vista previa pública que proporciona protección contra contraseñas comunes tanto para cuentas organizativas de Azure AD como para cuentas locales de Windows Server Active Directory. Evita que los usuarios y administradores cambien o restablezcan sus contraseñas por otras sencillas y fáciles de descifrar, como "987654321" o "quertyjkl;" (para los mecanógrafos).
Arquitectura
Azure AD Password Protection tiene un componente Azure, un servicio proxy local, un servicio DC y, por último, un filtro de contraseñas personalizado (Figura 1):
Los objetivos de esta arquitectura son 1) utilizar la lista global de contraseñas prohibidas (GBPL) de Azure para proteger las cuentas de Azure AD del uso de contraseñas comunes, 2) permitir a los administradores de Azure crear una lista personalizada de contraseñas prohibidas que aumente la GBPL, y 3) proteger las cuentas de Active Directory de las contraseñas comunes proporcionando un servicio local que utilice la lista consolidada de contraseñas prohibidas.
Azure
Azure AD ha utilizado durante un tiempo una lista de contraseñas prohibidas generada internamente, y también impone el cumplimiento de longitudes mínimas de contraseña más largas. Si introduce una contraseña común, se le recomendará amablemente que vuelva a intentarlo:
El servicio de protección de contraseñas (Figura 3) utiliza la inteligencia de amenazas de Azure para obtener una visión global de las contraseñas prohibidas. La lista se compila a partir de las contraseñas de las listas de credenciales filtradas, más el análisis que el sistema de inteligencia de amenazas de Azure realiza sobre los 20 millones (¡!) de intentos de apropiación de cuentas que detecta a diarioi. Esta lista no contiene todas las contraseñas comunes encontradas, sólo las 1000 más comunes que se utilizan activamente en los ataquesi.
¿Por qué el servicio no comprueba más de 1000 contraseñas comunes? Esto podría ser práctico para Azure, pero no para los servidores locales. En el proceso de evaluación de contraseñas, la contraseña del usuario se compara no solo con las más de 1000 contraseñas prohibidas, sino con miles de variaciones de cada una de ellas. Son muchas contraseñas con las que comparar. Si la lista de contraseñas contuviera 1 millón de contraseñas, podrían ser miles de millones de variaciones de contraseñasii las que tendrían que comprobar sus DC, y se paralizarían con tanta carga.
El control y la configuración de la función de protección por contraseña se gestionan en la hoja Azure Active Directory del portal de gestión, en la nueva sección Métodos de autenticación. El único elemento en esta nueva sección ahora -aunque estoy seguro de que crecerá- es Protección de contraseña (Figura 4).
Además de la lista global de contraseñas prohibidas (GBPL) generada por Azure, la protección de contraseñas de Azure AD ofrece una vista para todo el inquilino de las contraseñas prohibidas que se van a utilizar (TBPL). Por ejemplo, una empresa de servicios financieros puede querer prohibir contraseñas como "hipoteca" o "seguro" además de las contraseñas comunes determinadas globalmente por Azure. (En la figura, he añadido las empresas de automóviles a la lista personalizada). Esta lista consolidada es la que se utiliza en las instalaciones.
Tenga en cuenta que el servicio se ha configurado cuidadosamente para que, si instala componentes locales sin tocar los controles de Azure, el servicio de protección de contraseñas empiece a funcionar inmediatamente, en modo de auditoría, utilizando la lista global de contraseñas prohibidas de Azure.
Servicio proxy
El propósito del servicio proxy Azure AD Password Protection es adquirir el BPL y pasarlo a los DCs. Actuando como un servicio de retransmisión sin estado, el proxy permite a los DC obtener la BPL de Azure AD sin necesidad de tener acceso a Internet (un punto delicado en la seguridad empresarial). El proxy no sondea Azure AD por sí mismo; simplemente reenvía las solicitudes de BPL de los DC al servicio Azure, y reenvía el BPL resultante al DC solicitante. Esto elimina la necesidad de que los propios DC tengan conectividad a Internet.
El servicio proxy puede instalarse en cualquier servidor unido a un dominio. En esta versión preliminar, puede instalarse en uno o dos servidores para proporcionar tolerancia a fallos; se espera que este límite se elimine antes de GA. Tanto el servicio proxy como el bosque de Active Directory deben registrarse en Azure AD mediante el nuevo módulo AzureADPasswordProtection. (Siga atentamente las instrucciones.) Una vez registrado, el proxy se anuncia al DC con un punto de conexión del servicio AzureAdPasswordProtectionProxy bajo el objeto de equipo (Figura 5):
Agente DC
El paquete del agente de CC contiene dos componentes (Figura 6). El primer componente es el propio agente de CC, que se ejecuta como AzureADPasswordProtectionDCAgent. El segundo es un filtro de contraseñas personalizado. Veámoslos en orden inverso.
Un filtro de contraseñas de AD es una DLL personalizada que permite ampliar la funcionalidad básica de una comprobación de validez de contraseñas. El filtro de contraseñas del cliente de Azure AD Password Protection es lo más sencillo posible; lo único que hace es reenviar la solicitud de contraseña al agente del DC y recoger la respuesta de aceptación o denegación del agente.
Dado que el filtro de contraseñas es una pieza integral del sistema de seguridad del DC, un efecto secundario es que el DC debe reiniciarse cada vez que se instala o elimina el agente DC.
El agente de DC es el corazón del servicio local. Durante las operaciones en tiempo de ejecución del DC, el agente comprueba la validez de los cambios de contraseña del usuario con respecto a la política de contraseñas. En segundo plano, se asegura de que el DC tenga una copia actual de la BPL obtenida de Azure AD. Si no la tiene, obtiene una, la procesa para crear una política de contraseñas y la almacena en SYSVOL en
C:WindowsSYSVOLsysvolPolicies{4A9AB66B-4365-4C2A-996C-58ED9927332D}AzureADPasswordProtection.
La forma en que los agentes de los DC (en un despliegue de producción, debería haber uno en cada DC) obtienen y distribuyen la política de contraseñas es bastante elegante:
- Un agente DC en cada sitio Active Directory se despierta aproximadamente una vez por hora para decidir si su copia local de la política de contraseñas en SYSVOL necesita ser refrescada.
- Si es necesario actualizar la política, o si aún no existe una política, solicitará una nueva BPL cifrada a Azure AD a través del proxy, creará una política de contraseñas a partir de ella y la guardará en SYSVOL.
- SYSVOL replica esta política en todos los DC del dominio a través de DFS-R (Figura 7).
Como mucho, un DC por sitio puede solicitar la BPL, pero probablemente serán muchos menos: apenas una vez por hora y dominio. ¿Por qué? Debido a la eficiente replicación de DFS-R de la política a través de SYSVOL. En una red decentemente conectada, una política actualizada se habrá replicado en todos los DC antes de que otros agentes se despierten, y por lo tanto tendrán una política actual y no necesitarán solicitar un nuevo BPL a Azure. Esta arquitectura también asegura que los DCs en entornos bloqueados seguirán recibiendo la política de contraseñas porque la replicación SYSVOL es una parte esencial de la funcionalidad de los DCs.
Flujo de autenticación en tiempo de ejecución
La evaluación de la política de contraseñas prohibidas se integra en el proceso estándar de evaluación de contraseñas de AD (Figura 8):
- El usuario intenta establecer una nueva contraseña, y su DC local gestiona la solicitud.
- En el DC, la solicitud es procesada por el filtro de contraseñas personalizado, que pasa la contraseña al agente del DC.
- El agente del DC compara la contraseña propuesta con la contraseña en SYSVOL y la aprueba o rechaza.
- El éxito o el fracaso se devuelve al usuario.
Proceso de evaluación de contraseñas
La contraseña propuesta por el usuario se compara con una lista de unas 1000 palabras y patrones ("asdf", etc.). Además, se realizan sustituciones de caracteres en la contraseña ($ por s, mayúsculas/minúsculas, etc.). Actualmente, se calcula una puntuación para cada contraseña en el siguiente mannerv:
Cada carácter vale un punto, pero cualquier subcadena que coincida con una palabra/frase/patrón prohibido sólo vale un punto en total. La puntuación mínima permitida es de 5 puntos. Por ejemplo, "Primavera" y "2018" son palabras prohibidas, por lo que "Primavera2018" sólo vale 2 puntos y no estaría permitida.
"Primavera2018asdfj236" se descompone de la siguiente manera:
- Muelle = 1 punto
- 2018 = 1 punto
- asdf = 1 punto
- f, j, 2, 3, 6 = 1 punto cada uno
Total = 8 puntos = APTO
Este proceso permite algunas palabras o frases prohibidas si hay suficientes caracteres aleatorios en la contraseña. Ten en cuenta que también está sujeto a cambios, ya que Microsoft evoluciona su inteligencia de amenazas a escala de la nube en torno a los ataques a contraseñasvi.
La política se aplicará a todos los usuarios del bosque -no hay puerta trasera para los administradores- y se aplicará a todos los procesos de cambio de contraseñavii. La comprobación normal de contraseñas incorrectas con el emulador de CDP no se ve afectada por esta nueva capacidad.
Ventajas del diseño
Este diseño híbrido tiene muchas ventajas:
- El proceso de solicitud y actualización de la BPL está diseñado para tener un impacto extremadamente bajo en las operaciones de los DC. En una red bien conectada, tan solo un DC por dominio y hora solicitará la BPL.
- El proceso de solicitud y actualización funciona con una amplia gama de topologías de red. Los DC no necesitan conectividad a Internet; sólo el proxy necesita acceso a Internet. Y si es necesario, el proxy sólo necesita conectarse a un único DC por dominio mediante RPC (y el puerto es configurable). La replicación de SYSVOL a través de DFSR garantizará que la política de contraseñas llegue a todos los DC del dominio.
- La comprobación de contraseñas pasa por los procesos normales de Active Directory y cualquier cambio en la funcionalidad principal de AD se mantiene al mínimo. Ninguna parte de la operación sale del DC; por ejemplo, nunca se bloquea un intento de cambio de contraseña si el DC debe sondear Azure para obtener un nuevo BPL. El filtro de contraseñas real es lo más sencillo posible.
- El software está diseñado de forma "fail open", es decir, si algún componente no está instalado o no funciona (por ejemplo, el agente del DC está instalado pero el proxy no) se permitirá la contraseña, pero se registrará un error en el registro de eventos del DC.
- Esta arquitectura abierta a fallos permite preinstalar el agente de DC en un servidor que se pretende promover a DC.
- El agente DC ejecuta el mismo código de comprobación de contraseñas que el servicio Azure.
- No necesitas desplegarlo en todos tus DCs para probarlo. De hecho, es una buena forma de desplegarlo de forma incremental.
Pasos de la implantación
Los pasos detallados del despliegue están documentados aquí; como este servicio está en fase de previsualización, espero que se actualicen con regularidad. A grandes rasgos, los pasos son
- Determine en qué equipo(s) unido(s) al dominio desea instalar el servicio proxy, y en qué DCs desea probar. No es necesario que el proxy vaya en el servidor Azure AD Connect o en un DC; cualquier servidor miembro (como un servidor que ya aloje conectores Application Proxy) servirá. Recuerde que no debe utilizar vistas previas públicas en servidores de producción, o al menos contra usuarios de producción; podría promover y aislar un DC en su propio sitio para probarlo contra usuarios específicos.
- Asegúrese de que el servicio de protección de contraseñas de Azure AD esté configurado para el modo Auditoría (el predeterminado) y, opcionalmente, añada cualquier contraseña personalizada al BPL del inquilino.
- Obtenga los bits de vista previa para el servicio proxy de política de contraseñas y el agente de DC del centro de descargas.
- Instale el servicio proxy de política de contraseñas.
- En el servidor proxy,
a. Registre el servicio proxy con Azure AD.
b. Registre el bosque de Active Directory local con Azure AD. - Instale los agentes de CC.
- Reinicia los CC.
Supervisión
En el momento de redactar este documento, la información sobre la actividad del servicio de protección de contraseñas de Azure AD debe recopilarse de los registros de eventos del servidor proxy y del DC. No hay integración con Azure AD Connect Health en este punto de la vista previa pública, ni hay supervisión del agente proxy desde la hoja de Azure AD en el portal proxy.
Los IDs de eventos en el rango 10000 son generados por el filtro de contraseñas, mientras que los IDs en el rango 30000 provienen del agente DC. Encontrará (ligeramente) más información en los mensajes del agente de CC (Figura 9):
El agente DC tiene sus propios contadores de rendimiento en Perfmon bajo Azure AD Password Protection (Figura 10):
También puede utilizar el cmdlet de PowerShell Get-AzureADPasswordProtectionSummaryReport para obtener una vista resumida de la actividad de cambio de contraseñas.
Licencias
¿Qué tipo de licencia de Azure AD requiere esta capacidad? Se desglosa de la siguiente maneraviii:
- Cuentas sólo en la nube: Protección de contraseñas Azure AD con lista global de contraseñas prohibidas: Gratis
- Protección de contraseñas de Azure AD con lista personalizada: Azure AD básico
- Integración con Windows Server AD Protección de contraseñas de Azure AD con lista global de contraseñas prohibidas: Todos los usuarios sincronizados deben tener licencias Azure AD Premium P1
- Azure AD protección de contraseña w / lista personalizada (lo que estoy describiendo en este post): Todos los usuarios sincronizados deben tener Azure AD Premium P1
Una vez más, como se trata de una vista previa pública, está sujeta a cambios.
Cosas varias
- No existe ninguna relación entre las partes locales de Azure AD Password Protection y Azure AD Connect. Por lo tanto, no es necesario instalar el proxy en uno o varios servidores de Azure AD Connect (aunque funcionarán perfectamente en ellos).
- Como no hay cambios en el lado del cliente, cualquier contraseña común rechazada mostrará el error estándar "la contraseña no cumple los requisitos de complejidad" en el cliente.
- La vista previa pública requiere Global Admin en el inquilino tanto para configurar el componente Azure como para instalar el proxy local, y (por supuesto) Domain Admin para instalar el software. Pero MFA no es compatible inicialmente para el registro, por lo que tendrá que quitar MFA de la cuenta de Global Admin que está utilizando para instalar el proxy. Esto se solucionará antes de GAix.
- Si quieres probar algunas de tus propias contraseñas comparándolas con las que el NIST considera contraseñas comunes, echa un vistazo al proyecto NIST Bad Passwords en Github. Además de proporcionarle código de ejemplo para crear su propio comprobador de contraseñas prohibidas en el lado del cliente, puede comprobar si las contraseñas son débiles.
Microsoft se está moviendo agresivamente para adoptar sus recomendaciones y las del NIST sobre políticas de contraseñas. Al prohibir los cambios de contraseñas comunes en Active Directory, Azure AD Password Protection cierra una importante área de riesgo corporativo causada por los ataques a contraseñas. Le recomiendo encarecidamente que evalúe este servicio para desplegarlo una vez que alcance la disponibilidad general.
Prohibir las contraseñas comunes es sólo una parte de su solución de seguridad de identidad, por supuesto. El acceso condicional con control MFA a sus aplicaciones corporativas -tanto basadas en la nube como locales- es otra. A medida que las arquitecturas empresariales pasan de un modelo de seguridad basado en el perímetro a otro basado en la identidad, mantener a salvo los recursos corporativos requiere un enfoque amplio que incluya la seguridad de la identidad, los dispositivos y los datos.
Recursos
ihttps://twitter.com/Alex_A_Simons/status/1009490805369655296
iihttps://twitter.com/Alex_A_Simons/status/1009500870872973312
iiihttps://twitter.com/Alex_A_Simons/status/1009923402998562816
viihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/bd-p/AzureActiveDirectoryAMA
ixhttps://twitter.com/Alex_A_Simons/status/1009490805369655296
