Cross-Tenant Access en Microsoft Entra: el vector de cadena de suministro que casi nadie cierra

La pregunta que nadie hace en la junta de seguridad

Si entras hoy a Microsoft Entra > External Identities > Cross-Tenant Access Settings de tu tenant, y la sección "Default settings" dice Allow access para Inbound y Outbound, tu organización está confiando — automáticamente y sin auditoría — en cualquier otro tenant de Microsoft Entra del planeta.

Cualquiera. Sin excepciones. Sin allow-list. Sin revisión.

Es la configuración por defecto de Microsoft 365 desde 2021. Y es la razón técnica por la que los ataques que pivotaron desde un proveedor comprometido a un Banxico, un Pemex o varios retailers mexicanos en 2024-2025 no son anomalías — son la configuración pidiendo ser explotada.

Por qué este control es invisible

A diferencia de MFA o Conditional Access, los Cross-Tenant Access Settings (CTAS) no aparecen en la mayoría de los dashboards de seguridad. No están en Microsoft Secure Score con peso significativo. No salen en una auditoría superficial. Y la documentación pública es razonablemente clara — pero asume que un administrador con licenciamiento E5 ya conoce la implicación, lo cual rara vez es cierto en mid-market mexicano.

El resultado: una empresa con MFA al 100%, Conditional Access bien configurado, DLP activo, y el Defender XDR completo, todavía puede ser pivoteada en quince minutos si un partner — un proveedor de marketing, un despacho contable, una agencia de consulting — sufre un compromiso y el atacante envía una invitación de guest desde el tenant del partner.

Cómo se ve un ataque real

Reconstruido de incidentes reportados públicamente en LatAm 2024-2025:

1. Compromiso inicial en un tenant partner: phishing exitoso a un usuario administrativo del proveedor de servicios contables.

2. Pivote a CTAS confiable: el atacante ahora controla un usuario en un tenant que el target (la empresa mexicana objetivo) trata como confiable porque CTAS Default = Allow.

3. Invitación de guest aceptada automáticamente: el atacante se invita a sí mismo (como usuario del partner) al tenant target. La invitación pasa porque las CTAS Defaults de la empresa no la bloquean.

4. Bypass de MFA local: el atacante consigue que el target confíe en la claim de MFA del partner ("ya hicieron MFA en su lado, no requieran MFA aquí"). Esto es el peor scenario, pero es el default de Microsoft Entra antes de configurar trust posture explícito.

5. Acceso a recursos compartidos: el atacante (ahora guest legítimo en el tenant target) accede a SharePoint sites compartidos, canales de Teams con el partner, archivos de OneDrive expuestos. Si los sites tienen información sensible — y la mayoría la tienen porque "era para compartir con el partner" — la exfiltración es trivial.

6. Persistencia: el atacante registra dispositivos en el tenant target, configura forwarding rules, instala apps con permisos amplios. Cuando el partner detecta el compromiso original y rota credenciales, el acceso al target permanece.

Todo esto sucede porque la confianza fue concedida por default, no por decisión.

El cambio regulatorio que ya está aquí

• CNBV Circular Única de Bancos: las disposiciones sobre outsourcing y terceros (Capítulo IX) exigen que los controles de acceso sean granulares, auditables y revisables. Una CTAS Default = Allow no resiste el primer cuestionamiento del supervisor.
• NIST CSF v2.0: la función Protect, categoría AC-3, exige boundary controls explícitos entre identidades internas y externas. CTAS Default = Allow es lo opuesto a un boundary explícito.
• ISO/IEC 27001:2022 Annex A 5.20: relaciones con proveedores. Requiere acuerdos formales, scope acotado, revisión periódica. No funciona si el "acuerdo" es "todos los tenants del mundo, automáticamente".
• LFPDPPP Art. 36: las transferencias internacionales de datos personales requieren el consentimiento informado del titular o cláusulas contractuales documentadas. Un guest invitation aceptada por default a un tenant extranjero no documenta nada.

Hace 24 meses, "tenemos MFA en todos los usuarios" era la respuesta suficiente. Hoy no lo es. CTAS es la siguiente capa que cualquier auditor serio va a pedir.

Cómo cerrar la puerta sin romper operación

Paso 1: Cambiar Defaults a Block

En Microsoft Entra > External Identities > Cross-Tenant Access Settings:

• Default tenant settings · Inbound access: Block access (B2B collaboration + B2B direct connect).
• Default tenant settings · Outbound access: Block access.
• Trust settings: NO confiar en MFA claims, device compliance claims, ni Hybrid Azure AD join claims del partner por default.

Hecho. La superficie de ataque para tenants no nombrados ahora es cero.

Paso 2: Construir el allow-list real

Lista cada partner que SÍ necesita acceso. Para cada uno:

1. Tenant ID del partner (no el dominio — el GUID).

2. Contacto nombrado (la persona del partner que firma el acuerdo, no info@).

3. Justificación de negocio (por qué este partner necesita acceso B2B).

4. Scope mínimo: ¿usuarios o grupos específicos? ¿aplicaciones específicas? Nunca "todos los usuarios y todas las apps".

5. Trust posture: ¿confiamos en su MFA o requerimos MFA fresca aquí? La respuesta segura es la segunda.

6. Fecha de revisión: 6 meses como máximo. Más allá de eso, el partner puede haber cambiado de manos.

Cada entrada del allow-list es una decisión consciente, documentada, revisable. Eso es exactamente lo que NIST, ISO, CNBV e INAI llaman "control".

Paso 3: Conditional Access que asume desconfianza

Configurar una política de Conditional Access que aplique a guests/external users:

• Requiere MFA en cada login (no confiar en la claim del tenant origen).
• Bloquea el acceso desde dispositivos no compliant.
• Limita la duración de la sesión a 8 horas.
• Logs cada acceso de external user a la auditoría unificada (Purview).

Paso 4: Sweep de guests existentes

Antes de cerrar Defaults, ejecuta el playbook `audit-guest-accounts` para identificar guests ya en el tenant. Para cada uno:

• ¿Sigue siendo necesario? (Si el partner ya no trabaja con la empresa, eliminar.)
• ¿Tiene permisos excesivos? (Limpiar group memberships y app assignments.)
• ¿Está en el allow-list de CTAS? (Si no, agregar el tenant origen al allow-list o eliminar el guest.)

Las trampas comunes

Trampa 1: "Pero rompemos integraciones con partners"

Las CTAS Default = Block solo afectan tenants que NO están en el allow-list. Los partners que ya tienen relación funcionan exactamente igual — siempre y cuando estén en el allow-list. Si rompiste la integración con un partner, es porque no estaba documentado. Eso es una falla del proceso, no del control.

Trampa 2: Trust de MFA del partner

Microsoft Entra permite "trust the MFA claim from the partner tenant". Tentador para reducir fricción. Peligroso porque importa la postura de seguridad del partner directamente: si el partner tiene MFA débil (SMS, push sin number-matching) y el atacante lo bypasea, ese MFA "exitoso" se acepta en tu tenant. Default seguro: no trust. Requiere MFA fresca cada vez.

Trampa 3: Allow-list que crece sin revisión

Un allow-list creado en 2026 con 30 partners, sin revisión, en 2028 tiene partners que ya no existen, partners adquiridos por otra empresa, y partners donde el contacto nombrado ya cambió de trabajo. Cada uno es una puerta abierta sin guardian. Revisión semestral es el mínimo aceptable.

Trampa 4: Confundir Outbound con un control suave

Outbound Block = nadie en TU tenant puede ser invitado como guest a OTROS tenants. Suena draconiano hasta que recuerdas: cada vez que un empleado tuyo acepta una invitación de guest, lleva una identidad corporativa a un tenant que tú no controlas. Si el tenant remoto se compromete, esa identidad — y los recursos a los que ha tenido acceso — están comprometidos también. Outbound Default = Block es el control honesto.

Cómo medir el éxito

Tres métricas, revisadas trimestralmente:

1. Tenants en el allow-list: ¿la lista coincide con los partners reales actuales? (Cualquier delta es trabajo de limpieza.)

2. Guests activos por tenant origen: ¿cada guest se mapea a una entrada del allow-list? (Si no, son guests huérfanos — eliminar.)

3. Activaciones de Conditional Access para external users: ¿cuántas veces se aplicó MFA a un guest este trimestre? (Cero significa que el control no se está aplicando.)

Checklist de implementación

• [ ] Inventario de tenants partners actuales (con tenant ID, no dominios)
• [ ] CTAS Defaults cambiados a Block para Inbound + Outbound
• [ ] Trust de MFA claim, device claim y Hybrid AAD claim deshabilitados por default
• [ ] Allow-list construido con justificación + revisión + scope mínimo por partner
• [ ] Política de Conditional Access aplicada a external users (MFA fresca, dispositivo compliant, sesión 8h)
• [ ] Sweep de guests existentes ejecutado (vía audit-guest-accounts)
• [ ] Auditoría unificada habilitada para tracking de external user activity
• [ ] Revisión semestral del allow-list agendada (calendario corporativo)
• [ ] Alertas de acceso external de alto privilegio enviadas a CISO

Primer paso: descubre qué tenants confías hoy

Antes de cambiar Defaults, necesitas saber a qué tenants externos estás confiando hoy y qué guests tienes ya. Nuestro escaneo gratuito evalúa 192 reglas de detección — incluyendo CTAS configuration, guest accounts y Conditional Access para external users — y entrega el veredicto en minutos.

[Escanea tu tenant gratis →](/scan)

---

Fuentes citadas en este artículo:

• NIST Cybersecurity Framework v2.0 (NIST IR 8531, 2024) — función Protect, categoría PR.AC-3
• ISO/IEC 27001:2022 Annex A 5.20 — Supplier relationships; A 8.4 — Access to source code
• CNBV Circular Única de Bancos — Capítulo IX, outsourcing y servicios de terceros
• LFPDPPP (México), Art. 36 — Transferencias internacionales de datos personales
• Microsoft Entra Cross-Tenant Access Settings — documentación oficial