Entra ID: Politica Acceso Condicional Invitados Configuracion Colaboracion Externa — los Seis Valores Predeterminados que Juegan en tu Contra

Tu política de acceso condicional invitados y tu configuración de colaboración externa en Entra ID son en realidad dos superficies de control separadas que la mayoría de los tenants configuran una vez, durante la configuración inicial, y nunca vuelven a revisar. El acceso condicional decide si un invitado ya conectado debe pasar por MFA, un dispositivo conforme, o un método de autenticación más fuerte. La configuración de colaboración externa decide quién puede convertirse en invitado en primer lugar, qué puede ver un invitado una vez dentro, y cuánto tiempo se permite que exista esa cuenta invitada. Un tenant puede tener una excelente cobertura MFA para sus empleados y aun así dejar cada uno de estos valores predeterminados específicos de invitados exactamente donde Microsoft los entrega — lo cual, para varios de ellos, es la opción más permisiva.

Este artículo repasa seis fallos concretos en esa superficie de control de invitados, cada uno vinculado a un valor predeterminado o mecanismo documentado por Microsoft: ninguna política de acceso condicional evalúa realmente los inicios de sesión de los invitados, los invitados pueden invitar a otros invitados, los invitados pueden explorar el directorio, las cuentas invitado nunca expiran, nadie nota a un invitado que nunca inició sesión, y los invitados pueden alcanzar aplicaciones empresariales que nunca les fueron asignadas. Ninguno de estos fallos requiere que un atacante explote una vulnerabilidad — solo requieren que un admin haya aceptado la configuración de fábrica del tenant. Para la vista completa de cómo auditar un tenant de principio a fin, ver Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica.

Política de Acceso Condicional Invitados y Configuración de Colaboración Externa en Entra ID, Definición

El acceso invitado en Entra ID comienza con una invitación — la colaboración B2B crea un objeto de usuario con UserType establecido en Guest en tu directorio, respaldado por credenciales del propio tenant de origen del invitado o su proveedor de identidad. A partir de ahí, dos grupos de configuración independientes gobiernan lo que el invitado puede hacer.

External Collaboration Settings, bajo Entra ID > External Identities, controlan los permisos de invitación de invitados, la visibilidad del directorio para invitados, el autorregistro, y las listas de permitidos/bloqueados de dominios. El acceso condicional (Conditional Access) es un motor de políticas independiente que evalúa cada inicio de sesión, incluidos los de los invitados, contra reglas de asignación que pueden dirigirse a tipos específicos de invitados y usuarios externos — usuarios invitados de colaboración B2B, usuarios miembro de colaboración B2B, usuarios de conexión directa B2B, invitados locales, usuarios de proveedores de servicios, y otros usuarios externos — cada uno de los cuales puede incluirse o excluirse de forma independiente, para un tenant o para todos los tenants.

Estos dos sistemas no se comunican entre sí. Un invitado puede ser invitado bajo la configuración de colaboración más permisiva y aun así ser bloqueado por una política de acceso condicional estricta, o ser invitado bajo una configuración de colaboración estricta y aun así pasar sin problemas por una política de acceso condicional que nunca evalúa a los invitados. Revisar una sin la otra es solo la mitad del panorama — ver La superficie de ataque olvidada: cuentas invitado Azure en tu tenant para el modelo de exposición de invitados más amplio en el que se inscriben los seis fallos de este artículo.

Cómo los Invitados Escapan a la Cobertura del Acceso Condicional

GUEST_NO_CA_POLICY [HIGH] se dispara cuando ninguna política de acceso condicional habilitada incluye explícitamente un tipo de usuario invitado o externo. El control lee la asignación de "usuarios incluidos" de cada política habilitada, así que una base de "Todos los usuarios" no cuenta como cobertura de invitados — esa es exactamente la distinción sobre la que gira el resto de esta sección.

La propia documentación de Microsoft dice que la opción de asignación Todos los usuarios (All users) en el acceso condicional incluye "todos los usuarios del directorio, incluidos los invitados B2B" — así que en teoría, una única política MFA base dirigida a Todos los usuarios ya cubre a todos los invitados. En la práctica, ese mismo conjunto de documentación explica tres formas en que esa cobertura desaparece silenciosamente.

Las Exclusiones Prevalecen sobre las Inclusiones, sin Condición

Microsoft lo afirma sin rodeos: "Cuando una organización incluye y excluye a la vez a un usuario o grupo, ese usuario o grupo queda excluido de la política. La acción de exclusión prevalece sobre la acción de inclusión en una política." Si algún grupo de exclusión que contiene invitados termina adjunto a una política — por cualquier motivo, en cualquier momento — esa política deja de protegerlos, silenciosamente, sin ninguna advertencia en el admin center. Una política que sigue mostrándose como "On" en el admin center mientras excluye discretamente a tu población de invitados se ve idéntica, a primera vista, a las políticas en modo solo informe tratadas en Acceso condicional modo solo informe, exclusiones obsoletas: qué significa realmente «aplicado» — ambos casos dejan al tenant con una falsa sensación de cobertura aplicada.

Las Políticas de Riesgo de Usuario no Pueden Resolverse para Usuarios Externos, así que la Propia Guía de Microsoft es Construir una Exclusión

El riesgo de usuario requiere un restablecimiento de contraseña que el tenant de recursos no puede realizar sobre una identidad externa, así que la solución documentada por Microsoft es: "Puedes evitar que las políticas basadas en riesgo afecten a los usuarios externos creando un grupo en Microsoft Entra ID que contenga a todos los usuarios externos de tu organización. Luego, añade este grupo como exclusión de tus políticas de acceso condicional basadas en riesgo de usuario y riesgo de inicio de sesión." Nótese hasta dónde llega esa recomendación: solo la política de riesgo de usuario es irresoluble para una identidad externa — Microsoft es igual de explícito al decir que "La política de riesgo de inicio de sesión se aplica si el usuario invitado externo satisface el control de concesión." Seguir la guía literalmente, por tanto, elimina una cobertura de riesgo de inicio de sesión que funcionaba, junto con la cobertura de riesgo de usuario rota. Ese grupo de "todos los usuarios externos", una vez que existe por un motivo legítimo, es la palanca más fácil de usar la próxima vez que un inicio de sesión de invitado rompa algo — y reutilizarlo contra la base de MFA o de cumplimiento de dispositivos (no solo la política de riesgo para la que fue creado) es cómo un tenant termina con cero políticas evaluando realmente los inicios de sesión de invitados, aunque "Todos los usuarios" técnicamente los incluya.

Limitar el Alcance a Roles o Grupos en Lugar de Todos los Usuarios

Limitar una política a roles de directorio o grupos específicos en lugar de Todos los usuarios excluye estructuralmente a los invitados siempre que esos roles o grupos se pueblen a partir de datos de RR. HH. internos o datos de rol que los objetos invitado no llevan.

Para otros modos de fallo de cobertura base que no son específicos de invitados, ver Brechas de Cobertura de Política Base de Acceso Condicional Entra ID: Sin Política para Administradores, Todos los Usuarios o Todas las Aplicaciones y la revisión más amplia de exclusiones y alcance en Brechas acceso condicional Entra ID: que errores dejan una exposicion real.

La Configuración de Colaboración Externa que Sale de Fábrica Abierta de Par en Par

Dos de los seis fallos residen enteramente en External Collaboration Settings, y ambos tienen por defecto el extremo más permisivo de una escala de cuatro o tres opciones.

GUEST_TO_GUEST_INVITE — los Invitados Pueden Invitar a Invitados por Defecto

La configuración de invitación de invitados tiene cuatro opciones, desde "Anyone in the organization can invite guest users including guests and non-admins (most inclusive)" hasta "No one in the organization can invite guest users including admins (most restrictive)". La documentación de Microsoft es explícita sobre en cuál arranca un tenant: "Por defecto, todos los usuarios de tu organización, incluidos los usuarios invitados de colaboración B2B, pueden invitar a usuarios externos a la colaboración B2B." Esa es la opción más inclusiva de la lista. A menos que un admin la haya restringido manualmente, cada invitado que hayas invitado alguna vez ha tenido siempre permiso permanente para invitar a más invitados a tu tenant — sin aprobación, sin notificación, sin más registro que la entrada del registro de auditoría de la propia invitación. Endurecimiento del tenant Azure: corregir defaults inseguros trata esto junto con otros valores predeterminados de colaboración que los tenants dejan sin tocar.

GUEST_DIRECTORY_VISIBILITY — el Valor Predeterminado no es la Opción Restrictiva

El acceso de usuario invitado tiene tres niveles: mismo acceso que los miembros, acceso limitado, o restringido solo a su propio perfil. Microsoft marca la opción intermedia como predeterminada: "Guest users have limited access to properties and memberships of directory objects: (Default) This setting blocks guests from certain directory tasks, like enumerating users, groups, or other directory resources. Guests can see membership of all non-hidden groups." El comportamiento de fábrica permite que cualquier invitado enumere la pertenencia de todos los grupos no ocultos de tu directorio — incluidos, si no lo has bloqueado por separado, grupos con pertenencia asignable a roles o privilegiada; ver Grupos Privilegiados Anidados Entra ID, Grupos Asignables a Roles e Invitados en Grupos de Seguridad para lo que un invitado puede aprender solo de esa visibilidad.

Ambas configuraciones viven en la misma página del admin center (External Identities > External collaboration settings). Microsoft documenta un retraso de propagación específico para el nivel de acceso de invitado: tras guardar el ajuste restringido, "The changes can take up to 15 minutes to take effect for guest users."

Invitados a los que Nadie Gobierna

GUEST_NO_EXPIRATION_POLICY — un Invitado Invitado Directamente no Tiene Ninguna Expiración Asociada

Un invitado invitado directamente por correo electrónico, fuera de la gestión de derechos (entitlement management), es lo que la propia terminología de Microsoft llama no gobernado (ungoverned). La documentación de gestión de derechos de Microsoft traza la línea con precisión: los invitados que solicitan acceso a través de un paquete de acceso pueden convertirse en gobernados (governed), lo que significa que "their account will be deleted or disabled in specified days after their last access package assignment expires." Pero "guest users that already existed in your tenant by being invited are ungoverned", y una vez que un invitado no gobernado pierde su última asignación de paquete de acceso, "they'll remain in the tenant indefinitely." Un invitado invitado directamente que nunca estuvo asociado a un paquete de acceso no tiene absolutamente ningún mecanismo de expiración — ni un plazo largo por defecto, ni uno corto, ninguno. Persiste hasta que un humano lo nota y lo elimina a mano, o hasta que un admin construye retroactivamente un proceso de ciclo de vida para detectarlo.

GUEST_NEVER_SIGNED_IN — Invisible para una Revisión de Acceso Estándar hasta que Supera la Ventana de Inactividad

El informe de invitados inactivos de Entra ID (ID Governance > Dashboard > Guest access governance) es la herramienta creada para detectar esto, y trata a los invitados que nunca iniciaron sesión como su propia categoría: el informe separa explícitamente "guests who have never signed in or signed in at least once", y para el grupo que nunca inició sesión, "the inactive days are calculated based on creation date" en lugar del último inicio de sesión, ya que no existe uno. El umbral de inactividad predeterminado es de 90 días. Dos trampas importan operativamente: este informe requiere una licencia Entra ID Governance o Entra Suite, así que los tenants sin esa licencia no pueden abrirlo en absoluto, y las revisiones de acceso construidas para eliminar invitados inactivos omiten deliberadamente a cualquier invitado creado más recientemente que la ventana de inactividad configurada — "this ensures that guests can sign in once before being removed" — así que un invitado reciente, que nunca inició sesión, es invisible para la limpieza mientras dure esa ventana.

Acceso a Aplicaciones que Nunca se Asignó a los Invitados

GUEST_APP_ACCESS_UNRESTRICTED [MEDIUM] — Microsoft indica el valor predeterminado sin rodeos, en su guía sobre cómo restringir una app a un conjunto de usuarios: "Applications registered in a Microsoft Entra tenant are, by default, available to all users of the tenant who authenticate successfully." El control que cambia esto es Require user assignment (exigir asignación de usuario), y es opcional por aplicación, no activado por defecto. Una vez que un invitado ha sido invitado — para un proyecto, un documento compartido, una reunión — es "a user of the tenant" para cualquier otra aplicación que no haya activado la asignación, se haya pretendido o no.

Por Qué este Fallo Sobrevive a una Revisión del Portal

Este fallo es fácil de pasar por alto durante una revisión del portal por cómo falla: "When user assignment isn't required, unassigned users don't see the app on their My Apps, but they can still sign in to the application itself (also known as SP-initiated sign-on) or they can use the User Access URL." Una app que parece bloqueada — porque ningún invitado aparece en su lista de usuarios asignados, y ningún invitado la ve en su página My Apps — puede seguir siendo alcanzable por cualquier invitado que tenga el enlace de inicio de sesión directo, que a menudo es simplemente la URL de inicio de sesión normal de la app. El estado de asignación y la visibilidad no son lo mismo, y solo la asignación controla realmente el acceso.

Los invitados con roles de directorio elevados agravan este fallo específico; ver Rol Admin Invitado Entra Confianza B2B Entre Tenants: Cómo un Usuario Externo Llega a Administrador Global para lo que ocurre cuando un invitado infra-asignado también resulta tener permisos administrativos.

Detección

Ninguno de estos seis fallos aparece como una firma de ataque — son estados de configuración que hay que consultar directamente.

Limitar una Revisión a tu Población de Invitados

Para limitar una revisión de acceso solo a tu población externa, la regla de grupo dinámico que Microsoft da como ejemplo es:

(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)

Sustituye el filtro de dominio por el tuyo, o elimínalo para capturar todos los tipos de invitado.

Remediación

1. Restringir las Invitaciones de Invitados

En External collaboration settings, aléjate del valor predeterminado "Anyone... including guests". Si un puñado de personas realmente necesita derechos de invitación sin un rol admin completo, asígnales el rol Guest Inviter en lugar de dejar las invitaciones abiertas a todo el mundo:

Import-Module Microsoft.Graph.Identity.DirectoryManagement

$roleName = "Guest Inviter"
$role = Get-MgDirectoryRole | where {$_.DisplayName -eq $roleName}
$userId = "<user object ID or UPN>"

$DirObject = @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
  }

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

Una trampa antes de ejecutarlo: Get-MgDirectoryRole "only returns roles that have been activated", y "not all built-in roles are initially activated". En un tenant donde Guest Inviter nunca se ha asignado a través del admin center, $role vuelve vacío y la última línea falla. Asigna el rol una vez en el portal — lo que lo activa implícitamente — o actívalo primero con la API Activate directoryRole.

2. Restringir la Visibilidad del Directorio para Invitados

Cambia a "restricted to properties and memberships of their own directory objects" a menos que un escenario de colaboración concreto realmente requiera que los invitados puedan explorar la pertenencia a grupos.

3. Dar a los Invitados una Política de Acceso Condicional Dedicada y Habilitada

Dirige explícitamente a "Guest or external users" (todos los subtipos que uses), exigiendo como mínimo MFA — no dependas solo de una base de "Todos los usuarios". Luego audita la lista de exclusión de cada política habilitada existente en busca de un grupo "Guest or external users" o "todos los usuarios externos", y confirma que cada uno es intencional y sigue siendo necesario, y no una exclusión de política de riesgo que se filtró a tu base MFA.

4. Convertir a los Invitados en Paquetes de Acceso Gobernados

Hazlo en todos los casos donde un invitado corresponda a un proyecto o compromiso definido, para que la política de ciclo de vida asocie realmente una expiración. Para los invitados que nunca pasarán por la gestión de derechos, construye una revisión de acceso recurrente sobre el grupo dinámico de invitados anterior con un umbral de inactividad y una decisión auto-aplicada de "bloquear y luego eliminar".

5. Activar el Informe de Invitados Inactivos

Esto requiere licenciamiento de Entra ID Governance / Entra Suite. Revisa la categoría de nunca-inició-sesión de forma periódica — esas cuentas son invisibles para una revisión de acceso estándar hasta que superan tu ventana de inactividad.

6. Exigir Asignación en las Aplicaciones Empresariales

Establece "Assignment required" en Yes para cada aplicación empresarial que no deba estar abierta a todo el tenant, y luego asigna explícitamente a los usuarios o grupos — no a los invitados por defecto — que la necesiten. Revisa de nuevo las apps añadidas fuera de tu proceso estándar de onboarding; las apps SAML SSO, las apps de Application Proxy que usan preautenticación de Microsoft Entra, y las apps OAuth 2.0/OpenID Connect que un usuario o admin ha consentido, todas soportan este control.

Cómo lo Detecta EtcSec

EtcSec comprueba cada auditoría de Azure/Entra contra estos seis hallazgos: GUEST_NO_CA_POLICY, GUEST_TO_GUEST_INVITE, GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, GUEST_NEVER_SIGNED_IN, y GUEST_APP_ACCESS_UNRESTRICTED. No todos funcionan igual, y esa diferencia importa a la hora de decidir qué demuestra un resultado limpio.

Tres se evalúan contra el estado real de tu tenant, así que su resultado cambia cuando corriges la configuración subyacente. GUEST_NO_CA_POLICY lee la asignación de usuarios incluidos de cada política de acceso condicional habilitada. GUEST_TO_GUEST_INVITE lee la política de invitación de invitados del tenant. GUEST_NEVER_SIGNED_IN enumera las cuentas invitado sin ningún inicio de sesión interactivo ni no interactivo y reporta el recuento. Esos tres son los que te dicen si la corrección del trimestre pasado sigue vigente después de que el próximo admin toque External Collaboration Settings o el acceso condicional.

Los otros tres — GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, y GUEST_APP_ACCESS_UNRESTRICTED — se plantean como avisos a nivel de tenant en cada auditoría de Azure en lugar de activarse/desactivarse mediante un único indicador del tenant. Léelos como un recordatorio permanente de volver a verificar ese control en el portal, no como evidencia de que está actualmente mal configurado.

Referencias Principales

• Configure external collaboration settings
• Conditional Access: Users, groups, agents, and workload identities
• Authentication and Conditional Access for B2B users
• Convert guest user lifecycle in entitlement management
• Monitor and clean up stale guest accounts
• Manage access to apps
• Restrict a Microsoft Entra app to a set of users
• Restrict guest user access permissions
• List directoryRoles (Microsoft Graph)
• Customize and filter activity logs in Microsoft Entra ID