Audite Entra ID antes de que la deriva cloud se convierta en compromiso
EtcSec ejecuta 158 detecciones en 9 categorías de Microsoft Entra ID. La cobertura se centra en los controles que los atacantes abusan primero en Microsoft 365 y Azure: brechas en Conditional Access, ausencia de MFA, administradores permanentes de riesgo, permisos de aplicaciones peligrosos, deriva guest y respuesta débil ante usuarios o sign-ins de riesgo.
La recopilación utiliza Microsoft Graph API solo con permisos de aplicación. No se requiere sesión delegada, no se instala ningún agente en endpoints y la auditoría no modifica el tenant.
La auditoría verifica si todos los usuarios y roles admin están cubiertos, si la MFA es obligatoria, si la autenticación legacy está bloqueada, si se usa device compliance o token protection y si exclusiones demasiado amplias abren huecos.
El collector observa el uso de PIM, asignaciones permanentes, cuentas de emergencia, configuración de approval y justification, duración de activación y service principals que portan roles administrativos.
El catálogo cubre consentimientos tenant-wide, política de admin consent, permisos Graph de alto privilegio, implicit grant, multi-tenant, owners ausentes, secretos caducados y credenciales con vida excesiva.
Guest admins, invitaciones sin control, cuentas guest obsoletas, MFA guest ausente, confianza cross-tenant y exposición B2B forman parte de la revisión Entra base.
Las 9 categorías se ajustan a cómo se abusa realmente de la identidad cloud
La auditoría Entra no es una puntuación cloud genérica. Es una revisión de controles organizada alrededor de Conditional Access, privilegios, consentimiento de aplicaciones, gobernanza externa y respuesta basada en riesgo.
Identity y MFA
25 detecciones que cubren políticas de registro, métodos fuertes, passwordless, cuentas de usuario obsoletas, SSPR y protección de contraseñas.
Aplicaciones y service principals
24 detecciones sobre permisos Graph peligrosos, consentimientos tenant-wide, owners de apps, implicit grant, multi-tenant e higiene de secretos.
Conditional Access
20 detecciones sobre cobertura para todos los usuarios y admins, MFA, bloqueo de legacy auth, device compliance, políticas basadas en riesgo y exclusiones.
Privileged Access y PIM
18 detecciones sobre PIM, asignaciones permanentes, cuentas de emergencia, approval, justification, MFA en activación y número de Global Admins.
Guests, grupos y configuración
39 detecciones sobre guests, confianza cross-tenant, grupos dinámicos, grupos role-assignable, configuración del tenant y exportación de logs.
Cumplimiento y Risk Protection
18 detecciones sobre licencias P2, access reviews, postura de Identity Protection, usuarios de riesgo y brechas en respuesta automatizada.
Por qué los equipos usan EtcSec para revisiones de Entra ID
La identidad cloud cambia continuamente. Una auditoría útil debe poder relanzarse tras cambios de policy, onboarding de aplicaciones, evolución de colaboración externa o revisiones de acceso privilegiado.
Flujo Graph en solo lectura
La auditoría se basa en permisos de aplicación de Graph. No hace falta sesión delegada de usuario ni mutación del tenant para producir hallazgos.
Lo bastante rápida para seguir ventanas de cambio
El tiempo típico está entre 8 y 30 segundos según el tamaño del tenant y el throttling de Graph. Eso hace realista la revisión recurrente.
Hallazgos con nombre alineados con las tareas de los operadores
Los propietarios de Conditional Access, IAM, plataforma de aplicaciones y gobernanza ven los hallazgos de su perímetro, no una única puntuación cloud mezclada.
Un collector para cloud y on-prem
El mismo ETC Collector puede auditar Active Directory y Microsoft Entra ID, algo clave en programas híbridos donde la deriva de un plano amplifica el riesgo del otro.
Lo que una auditoría seria de Entra ID debe hacer explícito
La postura cloud se reduce demasiado a menudo a “¿hay MFA?”. El catálogo publicado muestra por qué eso no basta: permisos, configuración del tenant, gobernanza guest y respuesta al riesgo interactúan entre sí.
Recopilación Graph en solo lectura y endpoints clave
La auditoría lee `/users`, `/groups`, `/applications`, `/servicePrincipals`, `/identity/conditionalAccess/policies`, `/roleManagement/directory`, `/policies/authorizationPolicy` y los endpoints relevantes de auditoría o Identity Protection. Así, los hallazgos quedan vinculados a objetos concretos y no a afirmaciones genéricas sobre la postura cloud.
El uso de permisos de aplicación hace además que el flujo se adapte bien a la automatización. Los equipos de seguridad no necesitan una sesión admin interactiva para comprobar si una policy sigue protegiendo a todos los administradores o si un onboarding de aplicaciones reintrodujo permisos excesivos.
Las 9 categorías y las preguntas operativas que responden
| Categoría | Controles | Qué aprende el operador |
|---|---|---|
| Identity | 25 | Si MFA, política de contraseñas, SSPR, registro y cuentas obsoletas resisten ataques modernos. |
| Applications | 24 | Si app registrations, service principals, consentimientos y credenciales otorgan acceso excesivo u huérfano. |
| Conditional Access | 20 | Si la cobertura es completa para todos los usuarios, admins, legacy, riesgo y sesiones. |
| Privileged Access | 18 | Si PIM se usa bien, si hay cuentas de emergencia y si los roles admin siguen siendo permanentes. |
| Guest External | 15 | Si guests, invitaciones y colaboración cross-tenant permanecen acotadas y auditables. |
| Config | 12 | Si la configuración del tenant, diagnósticos, consentimientos y app registration soportan una operación segura. |
| Groups | 12 | Si grupos dinámicos, role-assignable o manejados por externos ocultan privilegio. |
| Compliance | 8 | Si el tenant está licenciado y configurado para access reviews e Identity Protection. |
| Risk Protection | 10 | Si usuarios y sign-ins de riesgo se detectan y se tratan automáticamente. |
Las familias de detección que más a menudo desencadenan remediación
Brechas en Conditional Access
Los hallazgos clave incluyen CA_NO_MFA_REQUIREMENT, CA_NO_POLICY_ALL_USERS, CA_NO_POLICY_ADMINS, CA_NO_LEGACY_AUTH_BLOCK, CA_NO_DEVICE_COMPLIANCE, CA_NO_RISK_BASED_SIGNIN y CA_POLICY_REPORT_ONLY.
- Muestra si el tenant descansa sobre una cobertura parcial.
- Separa los controles basados en riesgo del baseline MFA.
- Hace visibles exclusiones que suelen quedar escondidas en el JSON.
Deriva de acceso privilegiado
PA_PIM_NOT_ENABLED, PA_PERMANENT_ADMIN_ASSIGNMENTS, PA_NO_EMERGENCY_ACCOUNTS, PA_GLOBAL_ADMIN_NOT_MFA, PA_TOO_MANY_GLOBAL_ADMINS y PA_SERVICE_PRINCIPAL_ADMIN describen si el privilegio sigue siendo permanente y mal protegido.
- Útil para IAM, cloud platform y gobernanza.
- Aísla el diseño de cuentas de emergencia de la higiene PIM.
- Pone el foco en los service principals porque la MFA no compensa ahí.
Riesgo de aplicaciones y consentimiento
APP_USER_CONSENT_UNRESTRICTED, APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_ROLE, APP_NO_OWNER, APP_SECRET_EXPIRED, APP_SECRET_LONG_EXPIRY y SP_HIGH_PRIVILEGE exponen las rutas de escalada y exfiltración más frecuentes.
- Combina revisión de app registrations y postura de service principals.
- Saca a la luz la higiene de credenciales, no solo los permisos.
- Ayuda a limpiar sprawl cloud tras fusiones o cambios organizativos.
Gobernanza guest y cross-tenant
GUEST_ADMIN_ROLE, GUEST_NO_MFA_REQUIRED, GUEST_INVITATION_UNRESTRICTED, B2B_CROSS_TENANT_OPEN, GUEST_STALE_90_DAYS y GUEST_NO_ACCESS_REVIEW muestran si la colaboración externa sigue controlada.
- Especialmente útil en entornos de partners o M&A.
- Separa la política de invitación de la población guest realmente obsoleta.
- Muestra dónde los guests ya están presentes en grupos sensibles.
Identity Protection y respuesta al riesgo
RISK_NO_SIGNIN_RISK_POLICY, RISK_NO_USER_RISK_POLICY, RISK_HIGH_RISK_USERS_ACTIVE, RISK_LEAKED_CREDENTIALS y RISK_USERS_NOT_REMEDIATED muestran si el tenant sabe reaccionar cuando Microsoft señala una cuenta o un sign-in de riesgo.
- Detección sin respuesta significa compromiso aún activo.
- Relaciona licencia, configuración de policy y respuesta operativa.
- Distingue telemetría simple de protección realmente aplicada.
Cómo se mapean los hallazgos a las fronteras de responsabilidad
Los propietarios de Conditional Access miran primero la categoría CA, pero sus decisiones también determinan la protección de administradores, guests y usuarios de riesgo. Los owners de plataformas de aplicaciones necesitan la categoría Applications porque los consentimientos y privilegios de service principals suelen aparecer fuera del flujo IAM central. Gobernanza se concentra en Compliance y Risk Protection, porque esas categorías revelan si PIM, Identity Protection y access reviews se utilizan de verdad.
Por eso una página Entra útil debe hacer más que prometer “auditamos Entra ID”. Debe mostrar cómo los hallazgos se conectan con modelos operativos concretos: onboarding de apps, asignación de roles admin, colaboración externa, automatización de respuesta al riesgo y supervisión híbrida.
- IAM e ingeniería cloud poseen las decisiones de Conditional Access y PIM.
- Los equipos de aplicaciones son responsables de registrations, owners y rotación de secretos.
- Gobernanza es responsable de access reviews, evidencia de cumplimiento y respuesta al riesgo.
- Los programas híbridos necesitan un flujo común cloud y on-prem.
Por qué el collector importa incluso para una revisión puramente cloud
La documentación del collector es clara: el flujo no está partido entre un producto cloud por un lado y otro on-prem por otro. El mismo collector puede consultar Graph para Entra y LDAP o SMB para Active Directory. Eso importa porque muchos problemas híbridos son compuestos. Una cuenta de servicio on-prem obsoleta y un admin cloud sin MFA suelen pertenecer a la misma narrativa de compromiso.
EtcSec añade la capa de dashboards y explotación por encima del collector. El resultado es pasar de una revisión bruta de controles cloud a remediación recurrente y seguimiento histórico, no simplemente a una exportación CSV.
Preguntas frecuentes
¿Qué cubre exactamente la auditoría de Entra ID?
El catálogo publicado lista 158 detecciones en Identity (29), Applications (28), Conditional Access (20), Privileged Access (24), Guest External (15), Config (12), Groups (12), Compliance (8) y Risk Protection (10).
¿La auditoría requiere permisos delegados o una sesión admin interactiva?
No. La revisión se basa en permisos de aplicación de Microsoft Graph y no requiere sesión delegada interactiva. Eso hace que el flujo sea compatible con la automatización.
¿Se pueden revisar Entra y Active Directory en el mismo flujo?
Sí. ETC Collector soporta Entra ID y Active Directory para que los equipos híbridos ejecuten ambas revisiones con el mismo modelo de recopilación.
¿Por qué tratar permisos de aplicaciones y gobernanza guest como temas de primer nivel?
Porque muchos incidentes de identidad cloud comienzan con consent phishing, permisos Graph excesivos, service principals obsoletos o configuraciones de colaboración externa demasiado abiertas, y no solo por una casilla de MFA ausente.
Páginas relacionadas con la seguridad de identidad
Vea el catálogo on-prem que complementa la revisión de Entra en programas de identidad híbrida.
Inspeccione las detecciones con nombre que alimentan las páginas cloud y on-prem.
Comprenda el flujo de recopilación, el modo standalone, el daemon y la superficie API.
Compare el motor de recopilación open-source con la capa SaaS para dashboards y seguimiento.
Inicie su auditoría de Microsoft Entra ID
Conéctese con permisos Graph de solo lectura, revise Conditional Access, privilegios, aplicaciones, guests y riesgo, y convierta la salida en remediación recurrente.