Determinar una visión completa de los derechos de acceso en una red Microsoft puede ser una tarea difícil, como puede atestiguar cualquiera que se haya sometido a una auditoría reciente. La recopilación y organización de los datos de seguridad en informes detallados puede llevar mucho tiempo y esfuerzo. Hay múltiples razones por las que el proceso de recopilación de datos es difícil y lleva mucho tiempo, pero el factor común es que la información de seguridad está dispersa en múltiples almacenes de seguridad.
En un entorno Windows, la información del almacén de seguridad se dispersa en los siguientes métodos:
- Las entidades de seguridad (usuarios y grupos) están dispersas en Active Directory y en las bases de datos de seguridad de los servidores miembros (SAM).
- Los grupos pueden estar profundamente anidados (por ejemplo, el grupo A está en el grupo B está en el grupo C está en ....)
- La pertenencia a un grupo puede abarcar bases de datos de seguridad (por ejemplo, domain\domain admins está en server\Administrators)
- Un dominio Windows puede confiar en otros dominios Windows y en dominios Kerberos externos.
- Existen listas de control de acceso (ACL) en un objeto que se está protegiendo
Si bien es eficaz almacenar la información en un único almacén, puede plantear problemas a la hora de elaborar informes sobre la información. Las herramientas administrativas actuales carecen de la sofisticación necesaria para proporcionar informes de acceso reales, ya que están a un paso o dos de proporcionar una visión holística del acceso. Las siguientes afirmaciones señalan algunas de las limitaciones de las herramientas administrativas que impiden la capacidad de informar eficazmente sobre el acceso.
- Las herramientas administrativas imponen una visión limitada del proceso administrativo y se centran en la tarea inmediata en lugar de en todo el ciclo de vida de la gestión de identidades y accesos. Esto deja en manos de los administradores la validación de la configuración en otra herramienta o la confianza en que los demás procesos se hayan realizado correctamente.
- Las herramientas administrativas no proporcionan la vinculación necesaria para informar sobre el uso de identidades en el entorno.
- Las herramientas administrativas dependen de que otras funciones de aprovisionamiento se hayan realizado correctamente. (Por ejemplo, añadir un grupo a una ACL no permite al administrador ajustar la pertenencia a un grupo, ya que para ello se necesita una herramienta distinta con un propósito distinto).
Como las herramientas administrativas actuales no van más allá de su contexto de seguridad actual, el personal administrativo debe visitar cada tienda, extraer los datos y fusionarlos manualmente en informes significativos.
Resolver los retos
Mientras creaba una solución, que CSS lanzó el año pasado como herramienta software llamada Distributed Authorization Reporting Tool (DART), me encontré con numerosos retos que había que resolver. El descubrimiento de grupos fue quizás el obstáculo más importante al que me enfrenté durante el desarrollo de la solución. Algunas de las cosas que hicieron realmente interesante el proceso de codificación fueron, por ejemplo, la forma en que funcionaban e interactuaban los grupos:
Los grupos son de varios tipos (locales, globales y universales) y pueden estar protegidos.
- Los grupos pueden tener (sub)grupos como miembros
- Los grupos pueden anidarse en profundidad. A medida que aumenta el nivel de anidamiento, la cantidad de grupos a los que debe asociarse un usuario en los informes aumenta exponencialmente. Por ejemplo, un dominio con 20.000 usuarios y 12.000 grupos puede convertirse rápidamente en 1.600.000 relaciones de seguridad.
- Los grupos pueden anidarse en las bases de datos de seguridad (por ejemplo, los administradores de dominio en el grupo de administradores de un servidor miembro).
- Los grupos pueden tener más de 5.000 miembros, lo que requiere un tratamiento especial a la hora de enumerarlos.
- La pertenencia de un usuario a un grupo no se concede necesariamente por ser "miembro de" un grupo. La pertenencia a un grupo también puede calcularse.
No todos los usuarios forman parte del grupo calculado "usuarios del dominio". El grupo principal de un usuario puede ser reasignado a otro grupo. La lección es - no puedes tratar a todos los usuarios como miembros del grupo sólo porque pertenezcan a ese dominio.
A medida que abordaba cada cuestión, rápidamente empecé a ver que las interrelaciones de los datos de seguridad serían fundamentales para desarrollar una solución. Como descubriría, la clave de la solución era construir una tabla que mostrara la relación de los usuarios con los grupos y que pudiera compararse fácilmente con una ACL. Me gusta referirme a estas asociaciones como "cadenas de seguridad", ya que muestran al usuario y cómo se convirtió en miembro de un grupo concreto.
Estén atentos a mi próxima entrada de la serie: El SID sigue siendo el mismo...
