Que son las cuentas invitado Azure?
Las cuentas invitado Azure son identidades B2B que viven en su tenant de Microsoft Entra ID pero representan a usuarios de otra organizacion o de proveedores externos. El modelo es util: permite dar acceso a Teams, SharePoint, aplicaciones empresariales y grupos sin crear cuentas internas completas. El riesgo no aparece por el simple hecho de tener invitados, sino cuando el tenant deja de gobernar quien puede invitarlos, a que recursos entran, que controles de autenticacion se exigen y cuando se revoca ese acceso.
Microsoft documenta que la configuracion de External collaboration settings controla quien puede invitar invitados, que dominios estan permitidos o bloqueados y que nivel de visibilidad tienen esos invitados dentro del directorio. Microsoft tambien recomienda usar Conditional Access y access reviews para el acceso externo, porque una invitacion sin ownership claro suele durar mucho mas que el proyecto que la justifico. En la practica, el riesgo de guest access casi siempre combina cuatro fallos: permisos de invitacion demasiado amplios, acceso heredado a grupos o apps, MFA inconsistente para externos y cuentas antiguas que nadie revisa.
Cuentas invitado Azure: donde empieza el riesgo real
La pregunta correcta no es "tenemos invitados?" sino "que puede hacer un invitado despues de aceptar la invitacion?". Un guest puede terminar en grupos de Microsoft 365, aplicaciones integradas con Entra ID, sitios de SharePoint, equipos de Teams y flujos de aprobacion. Si el tenant permite que usuarios normales inviten a cualquiera, si el patrocinador del invitado no se revisa y si las politicas de acceso externo son mas debiles que las politicas internas, la cuenta guest se convierte en una ruta de persistencia silenciosa.
Los escenarios mas peligrosos suelen ser estos:
| Area | Riesgo tecnico | Por que importa |
|---|---|---|
| Invitacion | Cualquier usuario puede invitar externos | Un atacante con una cuenta interna comprometida puede introducir su propia identidad externa |
| Gobernanza | No hay sponsor claro ni access reviews | El invitado sobrevive meses despues de terminar la necesidad de negocio |
| Acceso | El invitado cae en grupos o apps con privilegios excesivos | El riesgo no es la invitacion, sino el alcance heredado |
| Autenticacion | No hay una politica especifica para guest y external users | El acceso externo queda protegido peor que el acceso de empleados |
| Cross-tenant trust | Se confian claims de MFA o compliance sin control | Se acepta una senal emitida por otro tenant sin revisar el contexto |
Como se convierte en una ruta de ataque
Un camino de abuso real no necesita una vulnerabilidad excentrica. Basta con una combinacion de configuracion laxa y ownership difuso.
Paso 1 - El atacante consigue una identidad interna o un aprobador distraido
Puede ser un usuario normal comprometido, un owner de grupo que aprueba de memoria o un proyecto que permite invitados por costumbre. Si las External collaboration settings permiten que miembros o incluso invitados inviten a nuevos externos, el primer control ya se perdio.
Paso 2 - La cuenta invitado entra en el tenant
La identidad aparece como userType = Guest y puede heredar acceso a grupos, aplicaciones o recursos compartidos. Ese acceso suele venir dado por pertenencia a grupos, no por la cuenta guest en si. Por eso revisar solo la lista de invitados no basta: hay que revisar donde aterrizan.
Paso 3 - El invitado aprovecha politicas mas debiles que las de empleados
Microsoft permite aplicar Conditional Access especificamente a All guest and external users. Si esa poblacion no tiene una baseline propia, la organizacion termina protegiendo mejor a los empleados que a usuarios externos con acceso a los mismos datos. El problema empeora cuando se habilita confianza cross-tenant en señales de MFA o de compliance sin una decision explicita sobre que tenants y que aplicaciones la merecen.
Paso 4 - La cuenta persiste mas de lo debido
Sin access reviews, sin sponsor claro y sin revisiones de ultimo acceso, el tenant acumula guest users antiguos. Esa deuda es peligrosa porque nadie trata esas cuentas como privilegiadas, pero siguen apareciendo en grupos, apps y share links activos.
Que debe auditar primero
Empiece por controles que explican el radio de acceso, no solo el numero de invitados.
1. Quien puede invitar invitados
Revise External collaboration settings y documente si el tenant permite invitaciones desde todos los miembros, solo roles administrativos o combinaciones intermedias. Si cualquier usuario puede invitar, revise tambien donde existen aprobaciones paralelas en Teams, SharePoint o procesos de negocio.
2. Que acceso heredan los invitados
No basta con contar guests. Necesita revisar:
- grupos de Microsoft 365 con invitados
- grupos con roles administrativos o acceso a aplicaciones empresariales
- aplicaciones con asignaciones de grupo que incluyan invitados
- sitios o equipos con guest access historico pero sin sponsor activo
3. Que politica de autenticacion se aplica a guest y external users
Compruebe si existe una politica de Conditional Access separada para All guest and external users y si exige MFA, authentication strengths o restricciones de aplicacion coherentes con la sensibilidad del recurso. Si usa cross-tenant access settings, verifique que la confianza en MFA o en device claims es deliberada, no una consecuencia olvidada de una federacion o de un tenant partner antiguo.
4. Que invitados ya no deberian seguir ahi
Use signInActivity, fecha de creacion, sponsor, membership y access reviews para separar invitados activos de invitados huerfanos. Un guest que no inicia sesion desde hace meses pero sigue perteneciendo a grupos con acceso a datos no es deuda inocua; es superficie de ataque disponible.
Enumeracion operativa
Get-MgUser -Filter "userType eq 'Guest'" `
-Property Id,DisplayName,UserPrincipalName,CreatedDateTime,SignInActivity,ExternalUserState |
Select-Object DisplayName,UserPrincipalName,CreatedDateTime,
@{N='LastSignIn';E={$_.SignInActivity.LastSignInDateTime}},ExternalUserState
Ese inventario debe cruzarse con grupos, aplicaciones y owners. Un guest sin ultimo acceso reciente pero con acceso vigente a un grupo sensible merece revisarse antes que cien invitados de bajo impacto.
Deteccion y telemetria util
Busque senales de onboarding, expansion de acceso y supervivencia injustificada.
Senales clave
- invitaciones creadas por usuarios no administrativos
- guest users agregados a grupos con acceso a apps o datos sensibles
- guest sign-ins desde ubicaciones o tenants no esperados
- access reviews incompletas o sponsors inexistentes
- cuentas guest antiguas sin actividad reciente pero con memberships activas
Consulta orientativa en logs
AuditLogs
| where OperationName in ("Invite external user", "Add member to group", "Add app role assignment to user")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources
SigninLogs
| where UserType == "Guest"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessStatus, ClientAppUsed, IPAddress
Remediacion que realmente reduce riesgo
Restringa las invitaciones
Si el tenant no tiene una necesidad clara de invitaciones abiertas, limite la capacidad de invitar a roles concretos o a flujos aprobados. En tenants grandes, eso reduce mucho la probabilidad de que una cuenta interna comprometida introduzca un invitado no controlado.
Aplique Conditional Access a guest y external users
La baseline minima para acceso externo debe estar definida aparte de la poblacion interna. No asuma que una politica pensada para empleados tambien cubre a invitados. Revise MFA, authentication strength, aplicaciones incluidas, ubicaciones y exclusiones.
Revise cross-tenant access settings
Si confia en MFA o en compliance claims emitidas por otro tenant, documente que tenant, para que flujos y con que limite. La confianza no debe ser global por comodidad.
Haga access reviews y cierre el ciclo de vida
Un guest sin sponsor, sin revision periodica o sin justificacion activa debe salir. La remediacion real no es solo bloquear el sign-in, sino eliminar memberships, acceso a apps y la cuenta guest si ya no cumple ninguna funcion.
Como validar despues del cambio
- intente una nueva invitacion desde un usuario que no deberia poder invitar
- verifique que un guest nuevo cae bajo la politica de Conditional Access esperada
- confirme que los invitados antiguos sin sponsor o sin acceso vigente desaparecen de grupos y aplicaciones
- revise que los guests restantes tienen owner, uso legitimo y ultimo acceso coherente
Diferenciar invitados aislados de invitados con alcance real
No todos los guest tienen el mismo riesgo. Un invitado con acceso a un solo equipo temporal no debe tratarse igual que uno presente en grupos que asignan aplicaciones enterprise, sitios compartidos y procesos de aprobacion. Para priorizar bien, conviene separar tres niveles: guest con acceso documental acotado, guest con acceso a aplicaciones de negocio y guest con acceso indirecto a funciones administrativas o datos especialmente sensibles. Esa clasificacion ayuda a concentrar las access reviews donde el impacto real es mayor.
Cruzar sponsor, ultimo acceso y grupos efectivos
La manera mas util de revisar guests no es por numero total, sino por combinacion de señales. Un guest sin sponsor claro, sin ultimo acceso reciente y con pertenencia a grupos de alto impacto es una prioridad inmediata. En cambio, un guest con sponsor valido, uso frecuente y acceso acotado puede esperar al siguiente ciclo de revisión. Este enfoque reduce ruido y hace que la gobernanza de guest access sea operativa para equipos tecnicos, no un ejercicio de inventario infinito.
Que comprobar despues de una access review
Cerrar una access review no garantiza que el riesgo desaparezca. Despues de cada ciclo conviene validar tres cosas: que las memberships aprobadas siguen teniendo justificacion, que las memberships denegadas se eliminaron de verdad y que el owner responsable sabe volver a conceder acceso de forma controlada si el negocio lo necesita otra vez. Sin esa verificacion, muchas revisiones terminan siendo solo una firma administrativa sin efecto real sobre el acceso efectivo.
Referencias primarias
- Microsoft Learn: Configure external collaboration settings for B2B in Microsoft Entra External ID
- Microsoft Learn: Restrict guest user access permissions
- Microsoft Learn: Transition to governed collaboration with Microsoft Entra B2B collaboration
- Microsoft Learn: Conditional Access policies for guests and external users
Lecturas relacionadas
- Brechas Acceso Condicional Azure: Bypass MFA
- Endurecimiento del tenant Azure: corregir defaults inseguros
- Acceso privilegiado Azure: roles, PIM y administracion permanente
- Azure Identity Protection: politicas de riesgo
- Registros de aplicaciones Azure: riesgos de apps sobreprivilegiadas
- Identidad Azure: MFA, metodos y Security Defaults
Revise este articulo junto con las politicas de acceso externo y de MFA del tenant. Las cuentas invitado Azure solo son seguras cuando el modelo de invitacion, autenticacion, ownership y retirada de acceso se audita como una sola superficie.
