Por qué evaluar Microsoft 365 sin Azure es medir la mitad de la postura — y la mitad equivocada

La pregunta que casi nadie hace al comprar una "auditoría de Microsoft 365"

El folleto típico de auditoría de Microsoft 365 — del MSP local, del integrador regional o del proveedor de SaaS de cumplimiento — promete revisar Entra ID, Exchange Online, SharePoint, OneDrive, Teams, Defender for Office 365, y entregar un PDF con hallazgos priorizados. Es trabajo legítimo. También es trabajo incompleto, y la pregunta que casi nadie hace es: _¿qué pasa con Azure?_

La respuesta honesta para la mayoría de los proveedores es "no está en el alcance". La respuesta correcta para el cliente es que esa exclusión no es una decisión técnica; es una decisión comercial disfrazada de alcance. Y la diferencia importa porque la postura de seguridad de una empresa que opera Microsoft 365 y Azure no se puede medir mirando uno solo de los dos planos.

Este artículo explica por qué.

Los dos planos de control: Graph y ARM

Microsoft expone su nube empresarial a través de dos planos de control distintos:

Microsoft Graph es el plano de control de las aplicaciones SaaS: Entra ID (identidades, MFA, Conditional Access), Exchange Online (buzones, transport rules, antiphish), SharePoint y OneDrive (sitios, sharing externo), Teams (canales, políticas de mensajería), Defender for Office 365 (Safe Links, Safe Attachments, ATP), Intune (MDM), Purview (DLP, etiquetas de sensibilidad). El endpoint canónico es `graph.microsoft.com`. Está documentado en [learn.microsoft.com/graph](https://learn.microsoft.com/graph).

Azure Resource Manager es el plano de control de la infraestructura: suscripciones, resource groups, máquinas virtuales, redes virtuales (VNets), Network Security Groups, cuentas de almacenamiento, Key Vaults, bases de datos administradas, Azure Functions, Container Apps, role assignments de Azure RBAC, políticas de Azure Policy, Defender for Cloud. El endpoint canónico es `management.azure.com`. Está documentado en [learn.microsoft.com/azure/azure-resource-manager](https://learn.microsoft.com/azure/azure-resource-manager).

Los dos planos comparten la misma identidad — Entra ID es el directorio raíz de ambos — pero sus superficies de configuración son distintas, sus tokens son distintos (audiencias `https://graph.microsoft.com` vs `https://management.azure.com`), y sus benchmarks de cumplimiento son explícitamente distintos.

Esa última parte es importante: los autores de los frameworks de cumplimiento ya separaron los dos planos. CIS publica un Microsoft 365 Foundations Benchmark (v4.0.0, noviembre 2024) y, por separado, un Microsoft Azure Foundations Benchmark (v3.0.0, diciembre 2024). Microsoft publica el Microsoft Cloud Security Benchmark (MCSB v1) que mapea controles a NIST SP 800-53 Rev. 5 y separa explícitamente Azure de M365. CISA, con su proyecto SCuBA, publica baselines de M365 (AAD, EXO, SharePoint, Teams, Defender, Power Platform) y no toca Azure Resource Manager — porque ARM tiene su propia familia de baselines, dejada a CIS Azure Foundations y MCSB.

Si los frameworks formales separan los dos planos por una razón, un proveedor que solo audita uno y entrega un score consolidado está fundiendo dos categorías que los autores del estándar mantuvieron distintas. Eso es un defecto de metodología, no una elección de alcance.

Por qué el plano de Azure importa para una PyME que "solo usa Microsoft 365"

El argumento contraintuitivo del integrador local: "el cliente solo usa Microsoft 365, no tiene cargas de trabajo en Azure, ¿para qué auditar Azure?".

El argumento falla por tres razones simultáneas:

1. La PyME tiene una suscripción de Azure aunque no lo sepa

Cualquier tenant de Microsoft 365 lleva asociada al menos una suscripción de Azure — la que respalda Azure AD (ahora Entra ID), la que firma certificados, la que aloja los logs de auditoría unificada, la que registra las app registrations. Para clientes que han comprado Microsoft 365 a través de un partner CSP, hay una suscripción de tipo "Pay-As-You-Go" o "Azure plan" en el tenant que el partner administra y que el cliente raramente revisa.

Esa suscripción tiene un Global Administrator que es el mismo Global Administrator de Microsoft 365. Tiene Azure RBAC role assignments que se pueden escalar a Owner del tenant. Tiene logs de actividad que un atacante puede deshabilitar si tiene los privilegios. Y tiene un conjunto de defaults de Microsoft que — como cualquier conjunto de defaults — están optimizados para arranque, no para postura defendida.

Si la PyME tiene un tenant de Microsoft 365, tiene un plano de Azure Resource Manager. La cuestión es si está auditado.

2. La identidad cruza los dos planos sin avisar

Microsoft Digital Defense Report 2024 (publicado octubre 2024) documenta que la identidad es el vector primario de ataque contra organizaciones que operan en la nube de Microsoft, con un volumen sostenido de cientos de ataques de password por segundo a escala global y una proporción creciente de adversary-in-the-middle (AiTM) que captura tokens válidos en lugar de credenciales.

Cuando un atacante obtiene un token de identidad de Entra ID válido — por phishing AiTM, por consentimiento ilícito a una OAuth app, por un dispositivo comprometido con SSO activo — ese token puede usarse para llamar a Microsoft Graph y para llamar a Azure Resource Manager. El control de qué puede hacer el atacante con ese token no depende de cuál plano se audita: depende de cómo está configurado el conditional access, qué privilegios tiene el principal asociado, qué role assignments de Azure RBAC heredó, y si los buzones, los Key Vaults y las cuentas de almacenamiento tienen reglas de access policy que limiten la explotación.

Auditar solo Microsoft Graph significa contar puertas en una pared y declarar la casa segura sin ver el otro lado del edificio.

3. La regulación mexicana obliga a "mantener" — no a auditar parcialmente

LFPDPPP Art. 19 obliga al responsable del tratamiento de datos personales a "establecer y mantener medidas de seguridad administrativas, técnicas y físicas que permitan proteger los datos personales contra daño, pérdida, alteración, destrucción o el uso, acceso o tratamiento no autorizado". El verbo "mantener" no admite la lectura "mantener solo el plano que el proveedor quiso cotizar".

CNBV — para instituciones financieras — exige en la Circular Única de Bancos un Plan Director de Seguridad y revisiones periódicas de privilegios, con evidencia. Si la suscripción de Azure aloja el respaldo de los logs de auditoría unificada y esa suscripción no se revisa, el plan director no es revisión periódica; es revisión parcial.

NMX-I-27001 (la norma mexicana espejada de ISO/IEC 27001:2022) lista en su Anexo A controles de seguridad para "uso de la nube" (A.5.23, "Information security for use of cloud services") sin restringir el alcance a SaaS. El ISMS debe cubrir IaaS, PaaS y SaaS que el responsable utilice — y un tenant de Microsoft 365 con su suscripción adjunta de Azure utiliza los tres.

El split: 151 reglas Microsoft Graph + 46 reglas Azure Resource Manager

simiriki publica su biblioteca de detección en `lib/deepScan.ts` como un arreglo TypeScript público (parte del repositorio que la auditoría de seguridad de plataforma documenta en `/security-posture`). El conteo actual al cierre de Q2 2026 es 197 reglas con evaluadores reales de pass/fail, repartidas así:

• 151 reglas para Microsoft Graph — corren contra `graph.microsoft.com` con permisos delegados de lectura. Cubren los dominios IAM (identidad y acceso, Entra ID), EML (Exchange Online), EXO (Exchange tenant settings), DLP (Purview Data Loss Prevention), DEV (registros de aplicaciones y consentimiento), MDM (Intune / device compliance), AUD (auditoría unificada, retención de logs), APP (acceso de aplicaciones y workload identities), OPS (operaciones del tenant), TMS (Teams y mensajería), RSK (Risky users y sign-ins), PUR (políticas de Purview), PWR (Power Platform DLP).
• 46 reglas para Azure Resource Manager — corren contra `management.azure.com` con permisos de Reader en la suscripción. Cubren los dominios AZR (postura de suscripción), SEN (Sentinel y Defender for Cloud), NET (networking, NSG, Private Endpoints), CMP (compute, máquinas virtuales, disk encryption), DBS (bases de datos administradas, encriptación at-rest), GOV (gobernanza, Azure Policy, role assignments).

El conteo es verificable: `grep -c "id: " packages/scan-core/src/registry.ts` devuelve 197. No es un número de marketing.

El split 151/46 — aproximadamente 77% Graph / 23% ARM — no refleja la importancia relativa de cada plano. Refleja que la superficie técnica de Microsoft Graph es más amplia (siete aplicaciones de productividad, MDM, conmpliance suite) mientras que ARM es un solo plano de infraestructura con menos pero más profundas configuraciones críticas. Una regla de ARM mal configurada — por ejemplo un Storage Account con `allowBlobPublicAccess=true` que aloja respaldos de CFDI — tiene un impacto financiero y regulatorio mayor que muchas reglas de Graph.

Los seis dominios de ARM, en concreto

Para que el split deje de ser abstracto, los seis dominios de Azure Resource Manager que simiriki audita corresponden a controles que aparecen explícitamente en CIS Microsoft Azure Foundations Benchmark v3.0.0 y Microsoft Cloud Security Benchmark v1:

AZR (Azure subscription posture) — control 1.x de CIS: cuenta de Microsoft Entra global administrator no usada como suscripción admin, suscripciones con management group asignado, Service Principals con privilegios elevados rotados.

SEN (Sentinel + Defender for Cloud) — control 2.x de CIS: Microsoft Defender for Cloud habilitado en todas las suscripciones, auto-provisioning de Log Analytics agent, planes de Defender for Servers / Storage / Key Vault / SQL activos según el inventario.

NET (Networking) — control 6.x de CIS: NSGs con reglas de inbound restringidas, ningún recurso con `:22` o `:3389` abierto al internet, Private Endpoints en Storage Accounts y Key Vaults, DDoS Standard Protection donde aplique.

CMP (Compute) — control 7.x de CIS: VM disk encryption habilitado, sistemas operativos parchados, Just-In-Time VM Access configurado, extensiones de seguridad (`MDE.Windows`, `MDE.Linux`) presentes.

DBS (Databases) — control 4.x de CIS: Transparent Data Encryption en Azure SQL, Auditing habilitado, Advanced Threat Protection activo, firewall rules sin `0.0.0.0`.

GOV (Governance) — control 5.x de CIS: Azure Policy assignments para baseline mínimo, Role Assignments revisados, custom roles auditados, Privileged Identity Management (PIM) activo.

Cada uno de los seis dominios tiene un mapeo explícito en simiriki a CIS Azure Foundations, MCSB y — donde aplica — al artículo 19 de LFPDPPP y a los apartados de CNBV Capítulo X (Riesgos Operacionales) y Capítulo XX (Contratación de Servicios con Terceros). El mapeo está en el código, no en una hoja de cálculo aparte.

La asimetría del riesgo en una brecha real

Un caso de uso ilustrativo, construido a partir del patrón documentado en Microsoft Digital Defense Report 2024 y en los informes anuales de respuesta a incidentes de Microsoft Detection and Response Team (DART):

Un atacante envía un correo de phishing AiTM a un usuario con privilegios de Application Administrator en Entra ID. El correo lleva al usuario a un proxy que captura el token de sesión válido tras la autenticación MFA. El atacante usa el token para llamar a Microsoft Graph y crear una nueva client secret en una app registration con permisos de aplicación elevados — un patrón documentado en CISA Alert AA23-074A. Hasta aquí, una auditoría solo-Graph detectaría el patrón.

El atacante usa el mismo token de identidad para escalar al plano de Azure: solicita un token de `https://management.azure.com`, descubre que el principal de la app tiene un Role Assignment de Contributor en la suscripción de producción (porque alguien quiso simplificar el despliegue de un Function App hace dos años), y exfiltra el contenido de un Storage Account que aloja respaldos de tablas con CURPs y RFCs.

Una auditoría que solo cubrió Microsoft Graph reportará: "se detectó creación anómala de client secret, severity alta". El cliente leerá el reporte, rotará la secret, y cerrará el ticket. Una semana después descubrirá en INAI que tiene una notificación de vulneración de datos pendiente porque el Storage Account exfiltrado estaba en una suscripción que nunca se auditó.

El split no es una preferencia técnica. Es la diferencia entre una notificación de cumplimiento cerrada y una notificación de vulneración al INAI.

Cómo evaluar a un proveedor en este eje

Si su proveedor actual de auditoría de Microsoft 365 — MSP local, integrador regional o SaaS de cumplimiento — promete una postura completa, las preguntas que validan o invalidan esa promesa son específicas:

1. ¿Qué endpoint de Microsoft se llama durante el escaneo, además de `graph.microsoft.com`? Si la respuesta no incluye `management.azure.com`, el alcance es solo Graph.

2. ¿Qué permisos solicita la app de auditoría en el tenant? Permisos exclusivamente de Microsoft Graph (`Directory.Read.All`, `Policy.Read.All`, etc.) sin un Azure RBAC role assignment (`Reader` a nivel de suscripción o management group) confirman que el plano de ARM no se evalúa.

3. ¿Cuál es el conteo de reglas evaluadas, y cuál es el split por plano? Un proveedor que no puede responder por la composición de su biblioteca está vendiendo opacidad metodológica.

4. ¿Está mapeado el resultado a CIS Microsoft Azure Foundations Benchmark, no solo a CIS Microsoft 365 Foundations? Los dos benchmarks son documentos separados con IDs separados. Pedir el mapeo es trivial; entregarlo requiere haberlo hecho.

5. ¿Qué pasa con la suscripción del partner CSP? Si el tenant compró M365 a través de un Cloud Solution Provider, la suscripción que respalda Entra ID está bajo administración del partner. Una auditoría seria documenta qué se puede y qué no se puede ver desde la posición del cliente.

Las cinco preguntas son neutrales — cualquier proveedor competente las responde sin fricción. Las respuestas, no las promesas, definen si la auditoría cubre la postura completa o la mitad cómoda.

Lo que simiriki hace, para que la comparación sea simétrica

Para que este artículo no sea un argumento abstracto: simiriki ejecuta el escaneo gratuito contra los dos planos en una sola conexión OAuth. Las dos audiencias de token (`graph.microsoft.com` y `management.azure.com`) se obtienen con consentimiento explícito durante el flujo PKCE, y los 197 evaluadores corren contra los endpoints correspondientes en paralelo. El resultado entregado al correo del cliente — el Posture Brief de tres páginas — separa los hallazgos por plano y los mapea a CIS M365 Foundations, CIS Azure Foundations, MCSB y NIST CSF v2.0 con identificadores estables.

El código que lo hace es público y verificable en el repositorio:

• `apps/api/src/graph/graph-client.service.ts` — cliente rate-limited para Microsoft Graph
• `apps/api/src/connectors/azure-resource-manager.connector.ts` + `lib/armToken.ts` — adquisición de tokens y conector para Azure Resource Manager
• `packages/scan-core/src/registry.ts` — biblioteca canónica de las 197 reglas con evaluadores reales (lib/deepScan.ts la re-exporta para compatibilidad)

Ni el alcance ni los mapeos son material de marketing. Son artefactos auditables.

El siguiente paso

Si quiere ver la diferencia en su propio tenant — qué se encuentra en Graph, qué se encuentra en ARM, qué se queda sin cubrir cuando el alcance se reduce a uno solo de los dos planos — el escaneo gratuito conecta los dos planos en menos de 90 segundos y entrega el Posture Brief en minutos. Sin tarjeta de crédito, sin instalación local.

[Escanea tu Microsoft 365 + Azure gratis →](/scan)

---

Fuentes citadas en este artículo:

• Microsoft Digital Defense Report 2024 (octubre 2024) — identidad como vector primario, AiTM phishing patterns
• CIS Microsoft 365 Foundations Benchmark v4.0.0 (noviembre 2024) — controles M365
• CIS Microsoft Azure Foundations Benchmark v3.0.0 (diciembre 2024) — controles AZR/NET/CMP/DBS/GOV
• Microsoft Cloud Security Benchmark (MCSB) v1 — mapeo a NIST SP 800-53 Rev. 5
• NIST SP 800-53 Rev. 5 (septiembre 2020, release de patches 2023) — controles de seguridad federales
• CISA SCuBA Secure Configuration Baselines — scope explícito M365-only
• CISA Alert AA23-074A — patrón de app registration y client-secret abuse
• INAI · LFPDPPP Art. 19 — obligación de "establecer y mantener"
• CNBV · Circular Única de Bancos, Capítulos X y XX (última reforma 2024)
• NMX-I-27001 / ISO/IEC 27001:2022, Anexo A.5.23 — Information security for use of cloud services
• Microsoft Learn · Azure Resource Manager — [learn.microsoft.com/azure/azure-resource-manager](https://learn.microsoft.com/azure/azure-resource-manager)
• Microsoft Learn · Microsoft Graph — [learn.microsoft.com/graph](https://learn.microsoft.com/graph)

Índice completo de fuentes: [simiriki.com/sources](/sources)