Todo sobre el ámbito de grupo de AGDLP para Active Directory – Cuenta, Global, Local de Dominio, Permisos

Últimamente he recibido algunas preguntas de clientes potenciales sobre el ámbito de grupo de seguridad de AD. Quería tomar un minuto para dar una visión general de lo que son los ámbitos de grupo y por qué son significativos. También hablaré un poco sobre los modelos de mejores prácticas de Microsoft para el uso del alcance de los grupos y discutiré algunos de los aspectos positivos y negativos de cada uno.

Es importante entender el alcance de los grupos si desea controlar eficazmente los riesgos en la forma de utilizar los grupos de AD. El alcance de un grupo determina dónde se puede aplicar el grupo en el bosque o el dominio. El alcance también determina quién puede ser miembro de un grupo. Debido a que Microsoft no ha incorporado muchas limitaciones en Active Directory con respecto a los grupos que pueden anidarse dentro de cada uno, el anidamiento de grupos puede presentar enormes riesgos de seguridad y operativos para una organización. La única ayuda real que ofrece AD para combatir los riesgos potenciales del anidamiento de grupos de seguridad es el ámbito del grupo.

Hay tres ámbitos de grupo: universal, global y local del dominio. Cada ámbito de grupo define los posibles miembros que puede tener un grupo y dónde se pueden aplicar los permisos del grupo dentro del dominio. La tabla que aparece a continuación se ha extraído directamente de Microsoft Technet y ofrece toda la información sobre las reglas de alcance de los grupos. Pero las reglas son sólo la mitad de la historia. La otra mitad, más importante, se encuentra en la comprensión de cómo utilizar y aplicar correctamente estos ámbitos.

El alcance del grupo Puede incluir como miembros al grupo… Se pueden asignar permisos al grupo en… El alcance del grupo se puede convertir en…
Universal
  • Accounts from any domain within the forest in which this Universal Group resides
  • Global groups from any domain within the forest in which this Universal Group resides
  • Universal groups from any domain within the forest in which this Universal Group resides
Any domain or forest
  • Domain local
  • Global (as long as no other universal group exist as members)
Global
  • Accounts from the same domain as the parent global group
  • Global groups from the same domain as the parent global group
Member permissions can be assigned in any domain Universal (as long as no other domain local groups exist as members)
Domain Local
  • Accounts from any domain
  • Global groups from any domain
  • Universal groups from any domain
  • Domain local groups but only from el mismo dominio que el grupo local del dominio padre
Los permisos de los miembros sólo se pueden asignar dentro del mismo dominio que el grupo local del dominio padre Universal (siempre que no existan otros grupos locales del dominio como miembros)

El objetivo de un AD bienarquitectura de AD es proporcionar a los usuarios apropiados ni más ni menos que los niveles necesarios de acceso a la información y a los recursos necesarios para hacer su trabajo. Los modelos de seguridad basados en roles, atributos y recursos son diferentes formas que las organizaciones utilizan para lograr este objetivo en toda la infraestructura de TI, incluyendo AD. Para lograr estos modelos en el entorno es necesario comprender adecuadamente el alcance de los grupos y cómo aplicarlo. AGDLP y AGUDLP son los modelos estructurales de mejores prácticas de Microsoft para la arquitectura de AD y pueden ayudar a las organizaciones a seguir estos modelos de seguridad.

El modelo AGDLP proporciona una guía sobre cómo anidar grupos entre sí sin comprometer la seguridad ni sacrificar la eficiencia operativa. El modelo estipula lo siguiente: Las Cuentas de usuario y de equipo deben ser miembros de grupos Globales, que a su vez son miembros de grupos Locales de Dominio que describen los Permisos de los recursos.

El razonamiento detrás de esto puede ser un poco complicado, pero haré mi mejor esfuerzo para desglosarlo aquí. Los grupos globales se utilizan para contener cuentas de usuarios y equipos y pueden incluir otros grupos globales del mismo dominio. Piensa en los grupos globales como «grupos de cuentas». Estos grupos incluirán usuarios que son iguales en el sentido de que todos forman parte del mismo dominio, ya que los grupos globales no pueden contener miembros de otros dominios. Además, es probable que los usuarios tengan otros puntos en común, como pertenecer al mismo departamento, tener el mismo jefe o alguna otra similitud de esa naturaleza. Por ejemplo, todos los usuarios que están en el departamento de Marketing de la sede central de Nueva York de una empresa se pondrían en el mismo grupo global llamado «Marketing».

Debido a la flexibilidad de sus restricciones de pertenencia, los grupos locales de dominio son ideales para conceder permisos sobre los recursos. En concreto, estos grupos se utilizan porque se pueden añadir a ellos grupos del dominio principal, así como de otros dominios y bosques de confianza. Esto permite a los administradores conceder acceso a un recurso a cualquier persona del entorno en caso de necesitarlo. Si los grupos globales son los «grupos de cuentas», los grupos locales del dominio son los «grupos de recursos». Un ejemplo de un grupo de recursos en acción puede ser un grupo local de dominio que otorga acceso a un archivo compartido llamado «Documentos de Marketing». Al anidar el grupo global «Marketing de Nueva York» dentro del grupo local de dominio «Documentos de Marketing», acabamos de dar a todos los usuarios del departamento de Marketing de Nueva York acceso al contenido del recurso compartido Documentos de Marketing. He aquí una representación gráfica de este escenario AGDLP:

Flujo de trabajo AGDLP

El uso de grupos locales de dominio adquiere especial importancia cuando se trata de situaciones que implican bosques de confianza. En un caso como éste, es muy probable que las cuentas de un bosque necesiten acceder a los recursos del otro bosque. Si se utilizara un grupo global para conceder acceso a un recurso, no habría forma de que las cuentas del segundo bosque tuvieran acceso a ese recurso, ya que las cuentas y los grupos no pueden anidarse en grupos globales de un dominio o bosque diferente.

Para continuar con nuestro ejemplo, quizás nuestra empresa ficticia adquiere otra empresa en Miami y los grupos de TI deciden confiar en los bosques de las dos empresas juntas. Si seguimos el modelo AGDLP, el departamento de Marketing de la empresa de Miami debería tener su propio grupo global en su bosque. Para que el departamento de Marketing de la nueva empresa tenga acceso al recurso compartido de Documentos de Marketing, lo único que tiene que hacer el administrador es anidar el grupo global de Marketing de Miami en el grupo local del dominio de Documentos de Marketing. Vea la representación gráfica de abajo para una mirada simplificada:

AD Workflow Multiple

El modelo AGUDLP es muy similar a AGDLP (como el nombre sugiere) pero introduce la «U» de grupos universales en la ecuación. Las membresías de estos grupos se almacenan en el catálogo global, lo que es más bien una necesidad en entornos multidominio. El uso de este modelo depende realmente de la confianza que se tenga en el catálogo global en la organización. Si hay un interés en que el catálogo global sea lo más completo posible (tal vez tiene una gran fuerza de trabajo móvil y depende en gran medida de que los empleados puedan encontrarse fácilmente en Outlook), entonces el modelo AGUDLP ayudará en este esfuerzo. Sin embargo, para entornos más pequeños que sólo tienen un único dominio, este modelo puede añadir una capa innecesaria de complejidad.

La razón por la que estos modelos son la mejor práctica de Microsoft es doble. Desde el punto de vista de la seguridad, si uno utilizara grupos globales para dar permisos a los usuarios sobre los recursos, tendría que añadir usuarios de otros dominios y bosques en el dominio donde residen los recursos. Generalmente, los dominios y bosques separados existen por una razón y las delineaciones entre dominios y bosques no deben ser borrosas. Al utilizar grupos locales de dominio para conceder permisos a recursos específicos, un administrador puede dar a los miembros de otros dominios y bosques acceso al recurso sin necesidad de darles acceso directo al resto del dominio donde vive ese recurso. Con demasiada frecuencia, vemos que las organizaciones utilizan grupos globales para definir los permisos sobre los recursos y, como resultado, acaban sobredimensionando el acceso y los derechos cuando los usuarios entran y salen del grupo.

Desde una perspectiva operativa, los modelos AGDLP y AGUDLP también facilitan la gestión de la pertenencia a grupos en el sentido de que los permisos y la organización de los usuarios se gestionan en lugares distintos. Los permisos de los recursos se establecen para los grupos locales del dominio y no es necesario cambiarlos una vez que se han determinado, lo que limita la frecuencia con la que es necesario salir al recurso para ajustar estos permisos. Además de contener restricciones incorporadas para la membresía, los grupos globales también se cambian fácilmente y, por lo tanto, proporcionan un lugar perfecto para que los usuarios residan, ya que los usuarios se mueven constantemente por la organización necesitando diferentes niveles de acceso.

Hay que tener en cuenta que sólo porque estos modelos son las mejores prácticas de Microsoft, no son perfectos para todos. En entornos más grandes, el uso de grupos locales de dominio para gestionar los permisos de los recursos puede llevar a la generación de un número muy grande de grupos. Esto podría dar lugar a que un usuario sea miembro de miles de grupos en el momento en que se le conceda acceso a todos los recursos que necesita y podría, a su vez, dar lugar a problemas como la hinchazón de tokens.

Al final del día, seguir los modelos AGDLP y AGUDLP ofrece algunos beneficios muy reales a una organización. El problema a menudo radica en la implementación de la infraestructura para seguir el modelo, dado que depende de algo más que un administrador inteligente para barajar los grupos en AD. Estos modelos requieren una vigilancia y supervisión constantes por parte de TI para su aplicación. Hay que dar muchos pasos para implementarlos y mantenerlos, como asignar propietarios a los grupos que entiendan las necesidades de los usuarios en esos grupos, asegurar que los usuarios correctos estén en los grupos correctos y que los grupos contengan los permisos correctos sobre los recursos.

La buena noticia es que hay herramientas que pueden ayudar con estos pasos. StealthAUDIT proporciona un punto de partida para encaminar a las organizaciones ayudándolas a entender a qué grupos se les está concediendo acceso actualmente, qué usuarios están en esos grupos y qué derechos tienen esos usuarios. Además, StealthAUDIT puede ayudar en la transformación del modelo de acceso de una organización y en la identificación de los propietarios de los grupos, poniendo el poder en manos de la empresa para gestionar sus propios grupos, ya que ellos saben mejor que nadie quién necesita acceso a qué. Aunque la adopción de AGDLP o AGUDLP puede suponer un esfuerzo monumental, los beneficios residuales pueden contribuir en gran medida a garantizar un entorno seguro y sostenible.

Conoce StealthAUDIT aquí.

¡No te pierdas ningún post! Suscríbase al blog de seguridad The Insider Threat aquí:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *