Grupos Privilegiados Anidados Entra ID, Grupos Asignables a Roles e Invitados en Grupos de Seguridad

Qué Son los Grupos Asignables a Roles y los Grupos Privilegiados Anidados en Entra ID

Grupos privilegiados anidados Entra ID, grupos asignables a roles: esta búsqueda compuesta cubre uno de los rincones menos auditados del control de acceso de Microsoft Entra ID — el privilegio anidado a través de grupos asignables a roles, y un invitado que se cuela en un grupo de seguridad por pertenencia en lugar de por invitación, formando juntos una ruta silenciosa hacia Administrador Global que la mayoría de los tenants nunca ha mapeado.

Un grupo asignable a roles es un grupo de seguridad con la propiedad isAssignableToRole establecida en true (o «Los roles de Microsoft Entra se pueden asignar a este grupo» en Sí en el portal). Asignar un rol de Microsoft Entra a un grupo en lugar de a usuarios individuales permite a una organización gestionar la pertenencia a roles mediante cambios de pertenencia al grupo en lugar de llamadas repetidas a la API de asignación de roles. Según la documentación de Microsoft, crear grupos asignables a roles requiere Microsoft Entra ID P1 o P2, la propiedad isAssignableToRole es inmutable una vez creado el grupo, un grupo asignable a roles no puede usar pertenencia dinámica, y un tenant puede tener un máximo de 500 grupos asignables a roles. Microsoft también «protege» específicamente a los propietarios de los grupos asignables a roles para reducir el riesgo de elevación de privilegios sobre el propio objeto grupo.

Los grupos privilegiados anidados describen un grupo que es miembro de otro grupo que porta roles de Entra privilegiados o acceso a recursos — la misma lógica de «ruta hacia Domain Admin» que existe en Active Directory on-prem (véase anidamiento peligroso de grupos en Active Directory), aplicada al directorio en la nube. Microsoft bloquea explícitamente la versión más obvia de esto: un grupo no puede ser miembro activo de un grupo asignable a roles. Lo que Microsoft sí permite — y lo que la mayoría de los tenants no ha contemplado — es que un grupo sea miembro elegible de un grupo asignable a roles a través de Privileged Identity Management (PIM) para grupos.

Finalmente, los invitados en grupos de seguridad son un problema distinto de la gobernanza de invitaciones a invitados. Este artículo no trata sobre quién puede invitar a un invitado (véase Cuentas de Invitado de Azure: la Superficie de Ataque Olvidada para ese ángulo) — trata de una cuenta de invitado que termina siendo miembro de un grupo de seguridad que porta acceso o elegibilidad de rol, mediante anidamiento o una regla de pertenencia dinámica, sin que nadie haya decidido explícitamente conceder nada a ese invitado.

Grupos Privilegiados Anidados Entra ID Asignables a Roles: La Cadena de Escalada

Paso 1 — Un grupo no privilegiado se anida como miembro elegible

PIM para grupos permite a un administrador configurar asignaciones elegibles en dos direcciones: o bien los usuarios se añaden activamente a un grupo y el propio grupo se hace elegible para un rol, o bien un rol se asigna activamente a un grupo y los usuarios se hacen elegibles para la pertenencia a ese grupo — y, según la propia documentación de Microsoft sobre PIM para grupos, un grupo también puede configurarse como miembro elegible de otro grupo, incluido uno asignable a roles. Como la restricción de pertenencia activa en los grupos asignables a roles solo bloquea la pertenencia directa y permanente, un grupo de menor privilegio puede configurarse como miembro elegible de un grupo asignable a roles sin violar esa restricción.

Paso 2 — No se aplica ningún flujo de aprobación en la activación

PIM para grupos admite los mismos controles de política que PIM para roles de Entra: exigir aprobación, imponer MFA en la activación, exigir una justificación de negocio y limitar la duración máxima de activación. Cuando estos controles no están configurados — lo cual es la postura predeterminada en muchos tenants que adoptaron PIM para grupos sin reforzarlo — cualquier miembro del grupo de nivel inferior puede autoactivar su pertenencia elegible en el grupo privilegiado y heredar el rol que ese grupo porta (Administrador Global, Administrador de Roles Privilegiados, Administrador de Aplicaciones, etc. — véase Acceso Privilegiado Azure: Demasiados Administradores Globales sobre por qué un acceso de Administrador Global permanente y fácilmente alcanzable ya es un hallazgo común).

Paso 3 — Un invitado se cuela a través del mismo grupo

El grupo anidado del Paso 1 raramente nació como un grupo «privilegiado» — a menudo es un equipo de proyecto, un grupo de acceso a aplicaciones, o un grupo con una regla de pertenencia dinámica amplia. Si una cuenta de invitado se añadió a ese grupo (directamente, o porque la regla dinámica del grupo se escribió más ampliamente de lo previsto — por ejemplo, coincidiendo con atributos que no excluyen de forma fiable userType eq Guest; véase la retirada del operador de regla de grupo dinámico memberOf para ver cómo estas reglas ya están cambiando), el invitado hereda la misma ruta elegible hacia el grupo asignable a roles que cualquier usuario miembro. Nadie revisó explícitamente si «este invitado debería ser elegible para Administrador Global» — el anidamiento de grupos tomó esa decisión implícitamente.

Cuenta de invitado
  -> miembro del grupo de seguridad "Project-Falcon" (pertenencia dinámica o manual)
      -> "Project-Falcon" es miembro elegible de "Tier0-Admins" (grupo asignable a roles)
          -> a "Tier0-Admins" se le asigna activamente el rol Administrador Global
              -> el invitado autoactiva su pertenencia elegible (sin aprobación requerida)
                  -> el invitado ahora tiene Administrador Global durante la ventana de activación

La herramienta de evaluación EntraFalcon de Compass Security documenta la misma debilidad subyacente desde un ángulo de evaluación ofensiva: marca cualquier grupo que no sea asignable a roles, ni esté sincronizado desde on-premises, ni esté ubicado dentro de una Unidad Administrativa de Gestión Restringida como un grupo privilegiado «desprotegido» (ID de hallazgo GRP-005 en sus informes), porque ninguna de esas tres propiedades está garantizada para un grupo que solo se vuelve privilegiado de forma transitiva, mediante anidamiento.

Detección

Aquí, la detección significa encontrar los grupos asignables a roles, encontrar qué está anidado de forma elegible dentro de ellos, y encontrar a los invitados en el árbol de grupos que los alimenta — nada de esto aparece como una única alerta por defecto.

# Microsoft Graph — enumerar grupos asignables a roles
GET https://graph.microsoft.com/v1.0/groups?$filter=isAssignableToRole eq true&$select=id,displayName,membershipRuleProcessingState

# Microsoft Graph — invitados transitivamente dentro de un grupo específico
GET https://graph.microsoft.com/v1.0/groups/{group-id}/transitiveMembers/microsoft.graph.user?$filter=userType eq 'Guest'

// Sentinel / Log Analytics — cambios de pertenencia de grupo que alimentan una lista de vigilancia de ID de grupos privilegiados
AuditLogs
| where OperationName in ("Add member to group", "Add owner to group")
| where TargetResources[0].id in (privilegedGroupIds)
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].displayName)

Remediación

1. Inventaríe todos los grupos asignables a roles con la consulta de Graph isAssignableToRole eq true anterior — no confíe en la memoria del tenant sobre «los grupos que creamos para esto». Asigne un propietario a cada uno y elimine a los propietarios que ya no necesiten ese acceso, ya que la propia guía de Microsoft señala la propiedad no gobernada como el principal riesgo de elevación sobre estos objetos.
2. Exija aprobación y MFA en la activación para toda asignación elegible de PIM para grupos que termine en un grupo asignable a roles, y establezca una duración máxima de activación acotada en lugar de dejarla abierta.
3. Prohíba el anidamiento de grupos hacia grupos asignables a roles donde no sea operativamente necesario. La propia guía de Microsoft recomienda limitar o evitar los grupos anidados para rutas de elevación de roles, porque cada nivel de anidamiento añade propietarios de grupo que pueden gestionar indirectamente quién llega al rol, lo hayan pretendido o no.
4. Audite las reglas de pertenencia dinámica que alimentan cualquier grupo en una cadena privilegiada, y haga explícita la exclusión de invitados (userType -ne "Guest") en lugar de asumirla — un grupo asignable a roles en sí no puede usar pertenencia dinámica, pero los grupos anidados por debajo de él sí, y es exactamente ahí donde una regla amplia causa el daño.
5. Ejecute revisiones de acceso sobre la pertenencia de grupos asignables a roles y sobre las cadenas de pertenencia elegible, no solo sobre las asignaciones de roles directas — una revisión trimestral limitada a «quién tiene Administrador Global» no detectará a un invitado dos niveles de anidamiento por debajo.
6. Elimine a los invitados de los grupos de seguridad a los que nunca debieron unirse. Si la presencia de un invitado en un grupo solo se explica por «la regla dinámica lo captó» o «alguien lo añadió al grupo equivocado», trate eso como un incidente que cerrar, no como un detalle de configuración para anotar más tarde.

Estos controles se integran en una revisión más amplia — véase cómo auditar la seguridad de Microsoft Entra ID para situar la higiene de grupos y PIM respecto al acceso condicional, MFA y permisos de aplicaciones.

Cómo Detecta Esto EtcSec

La auditoría de Azure/Entra ID de EtcSec verifica exactamente esta cadena: Grupos Anidados con Acceso Privilegiado (AZ_GROUP_NESTED_PRIVILEGED) marca los grupos que alcanzan un grupo asignable a roles mediante anidamiento elegible o transitivo, Grupos Asignables a Roles (AZ_GROUP_ROLE_ASSIGNABLE) inventaría cada grupo isAssignableToRole y su postura de propiedad/aprobación, y Usuarios Invitados en Grupos de Seguridad (AZ_GROUP_GUEST_IN_SECURITY) saca a la luz las cuentas de invitado dentro de grupos de seguridad, ya sea que se les haya invitado directamente o que hayan obtenido la pertenencia mediante anidamiento o una regla dinámica. Controles relacionados — Rol de Administrador Asignado a un Grupo (PA_GROUP_ASSIGNED_ADMIN) y Grupos Privilegiados sin Monitoreo de Cambios (AZ_GROUP_PRIVILEGED_CHANGES) — extienden la misma auditoría a las asignaciones de rol a grupos y a si los cambios de pertenencia en esos grupos realmente se registran y revisan.