Modelo de confianza cero y consejos de seguridad de Active Directory - Administración de plataformas Microsoft - Blogs - Quest Community
Si está interesado en la seguridad de Active Directory, sin duda habrá oído hablar del modelo Zero Trust. En resumen, Zero Trust es un excelente modelo de seguridad para los entornos de TI modernos porque supone que las infracciones son inevitables y que ya hay actores maliciosos dentro de su ecosistema de TI. Por lo tanto, no se debe confiar implícitamente en ningún usuario, servicio u otra entidad, y siempre se debe buscar activamente actividad anómala que pueda indicar una amenaza a la seguridad.
Eso es todo lo que voy a decir aquí sobre qué es Zero Trust. Para obtener una introducción más profunda al modelo Zero Trust, recomiendo leer la publicación del blog “Zero Trust: qué es, por qué lo necesita y cómo comenzar”. "
En lugar de ello, me centraré en cómo implementar un modelo de confianza cero en su entorno de Active Directory local o híbrido. Específicamente, ofreceré tres mejores prácticas que pueden ser una parte valiosa de una estrategia de Confianza Cero porque fortalecen drásticamente la seguridad de Active Directory.
No confíe en las cuentas de administrador: proporcione privilegios elevados solo por períodos de tiempo finitos.
Las cuentas permanentes con mucho poder son algo intrínsecamente peligroso. Los administradores que hacen mal uso de sus derechos elevados, ya sea deliberada o accidentalmente, pueden causar un daño enorme, y un atacante que compromete una cuenta privilegiada es una amenaza crítica.
En consecuencia, un modelo de Confianza Cero implica otorgar a los administradores privilegios elevados sólo cuando los necesitan y sólo durante el tiempo que los necesiten. Hay varias formas de lograr esta escalada de privilegios "justo a tiempo" en Active Directory, incluidas las siguientes:
- Modelo ESAE (Bosque Rojo): durante varios años, Microsoft defendió el modelo Entorno de administración de seguridad mejorada (ESAE), en el que las cuentas que tienen acceso privilegiado se mantienen en un bosque administrativo especial y altamente seguro, comúnmente llamado un bosque rojo. Parte de este modelo era que estos usuarios se convertirían en miembros de los objetos "msDS-ShadowPrincipal" durante un período de tiempo. Estos objetos se asignan a grupos poderosos en dominios administrados, lo que esencialmente significa que un administrador podría obtener privilegios de administrador de dominio durante un período de tiempo sin ser miembro del grupo de administradores de dominio. Sin embargo, la arquitectura ESAE es compleja y normalmente sólo es eficaz para las cuentas más potentes de Active Directory. Por lo tanto, Microsoft ya no recomienda ESAE para la mayoría de los clientes. (Las excepciones son situaciones en las que la necesidad de una seguridad sólida supera la mayor complejidad y los costos operativos de ESAE, como los laboratorios de investigación fuera de línea y los sistemas de control industrial).
- Pertenencia a grupo temporal : a las cuentas de Active Directory normalmente no se les asignan permisos directamente; en cambio, obtienen sus privilegios a través de la membresía en grupos particulares. Siempre ha sido posible implementar software que proporcione membresía a un grupo por un período de tiempo limitado, pero al hacerlo, la cuenta generalmente dejaba permisos para los tickets Kerberos emitidos que podían persistir mucho después de que el usuario ya no era miembro del grupo que los proporcionó. esos permisos. Windows 2016 cambió esto: ahora se puede asignar a las membresías de grupo un valor de “tiempo de vida”, con una caducidad de ticket sincronizada. Esto significa que el propio Active Directory caducará a un usuario de un grupo privilegiado y el ticket Kerberos del usuario caducará poco después.
- Cuentas de administrador temporales : ¿Qué es mejor que tener una cuenta de administrador sin privilegios? Tener la cuenta deshabilitada hasta que sea necesario utilizarla. Los sistemas de gestión de identidades privilegiadas utilizan un sistema de entrada y salida para que las cuentas privilegiadas que no se utilizan no representen una amenaza.
Cualquiera que sea el método que elija para escalar privilegios justo a tiempo como parte de su modelo Zero Trust, asegúrese de poder especificar “quién puede hacer qué y cuándo”. Considere también el uso de software como Change Auditor para Active Directory para auditar de cerca la actividad de las cuentas de usuarios regulares y privilegiados e incluso evitar cambios accidentales o deliberados en objetos críticos de seguridad de Active Directory.
No confíes en la contraseña: considera alejarte de las contraseñas.
Los investigadores de seguridad y las grandes empresas de TI están empezando a darse cuenta de lo que los usuarios saben desde hace mucho tiempo: ¡las contraseñas son horribles! En particular, la antigua práctica de obligar a los usuarios a elegir contraseñas muy complejas y cambiarlas una vez por trimestre fue una pesadilla tanto para los usuarios como para el servicio de asistencia técnica y, en última instancia, no aumentó tanto la seguridad de Active Directory.
Un modelo Zero Trust implica confiar mucho menos en una única contraseña. Aquí hay algunas opciones:
- Si tiene un entorno híbrido de Active Directory y usa servicios de Microsoft 365, sus usuarios ya tienen una cuenta de Azure AD y una cuenta de Active Directory. Considere la posibilidad de hacer la transición de sus usuarios para que aprovechen Azure AD como su fuente de autenticación principal, ya que Azure AD ahora puede emitir tickets de concesión de tickets para dominios de Active Directory locales. Esto permite a sus usuarios utilizar puntos finales que no están unidos a un dominio (¡ni siquiera híbridos!) y acceder a recursos de red que requieren autenticación Kerberos. El uso de Azure AD para la autenticación no solo libera a los usuarios de la necesidad de usar periódicamente una VPN para autenticarse, sino que también habilita todas las excelentes funciones de seguridad de Azure Active Directory, desde Windows Hello y otras opciones sin contraseña hasta opciones como el filtrado geográfico y los viajes imposibles. .
- Si no tiene un entorno híbrido de Active Directory o no es posible hacer de Azure AD su fuente de autenticación principal, invierta en un sistema de autenticación multifactor que se integre con Active Directory. De esa manera, incluso si una cuenta de usuario necesita una contraseña, no será necesario cambiarla con frecuencia y representará una amenaza mucho menor si se ve comprometida.
No confíe en las cuentas de administrador de AD en la nube: todas las cuentas con roles privilegiados en Azure AD o Microsoft 365 deben ser solo en la nube.
Microsoft invirtió una gran cantidad de recursos de ingeniería para que Active Directory y Azure Active Directory funcionen estrechamente juntos. En un entorno híbrido de Active Directory, es fácil aprovechar la infraestructura y las credenciales que ya ha implementado en las instalaciones para acceder a datos, aplicaciones e infraestructura en la nube de Microsoft.
De hecho, puede resultar demasiado fácil. Muchas organizaciones que pasaron a una implementación híbrida de Active Directory querían aprovechar sus políticas y procesos locales existentes para la administración en la nube, por lo que simplemente hicieron que sus cuentas administrativas locales y cuentas de servicio fueran híbridas. Esta arquitectura ha dado lugar a algunos ataques muy graves a la infraestructura de la nube, en los que los atacantes utilizan la complejidad y la naturaleza heredada de Active Directory para atacar sistemas e información en la nube.
En pocas palabras: cualquier cuenta que tenga una función privilegiada en Azure AD o Microsoft 365 nunca debe ser híbrida: ¡debe ser solo en la nube!
Pensamientos finales
Estas tres prácticas recomendadas proporcionan una base sólida para implementar un modelo de Confianza Cero. Sin embargo, tenga en cuenta que no constituyen una lista de verificación para “lograr” Zero Trust. De hecho, implementar cualquier modelo de seguridad no es cuestión de adoptar algunas mejores prácticas o implementar una solución de software; más bien, requiere crear un marco de seguridad en capas que involucre una amplia gama de tecnologías, procesos y políticas, y evaluarlo y mejorarlo constantemente a medida que evolucionan su entorno de TI, sus requisitos comerciales y el panorama de amenazas. Recuerde, un modelo Zero Trust, como la seguridad de Active Directory, es un viaje, no un destino.
