Azure Entra ID como Tier 0. Post 2/3

Blog

Estimados amigos de Inseguros !!!

En el post anterior ya empezamos a hablar de Tier 0 en Entra ID y de una idea que para mí es clave: no debemos quedarnos solo con los Global Administrator. Eso sería demasiado simple, somos SeguridadSi xD xD xD

Decíamos que Tier 0 no va solo de nombres llamativos, sino de capacidad real para alterar identidad, privilegios, acceso, autenticación o confianza dentro del tenant. Y por eso hoy quiero empezar a bajar el tema a tierra con algo mucho más práctico. Vamos a ver roles.

Empiezo por uno evidente.

Global Administrator

¿Qué puede hacer?

Es el rol más potente de todo Entra ID. Tiene control completo sobre la administración del tenant, puede gestionar usuarios, grupos, configuraciones de seguridad, dominios, licencias, integración con servicios de Microsoft 365 y, en muchos casos, elevar su control sobre otros componentes relacionados.

Dicho sin adornos: es el rol con las llaves del reino.

Problemas de seguridad

Si un atacante compromete una cuenta con este rol, ya no hablamos de un incidente pequeño ni de una cuenta administrativa más. Hablamos de control completo del tenant.

Puede resetear contraseñas, modificar controles de seguridad, crear nuevas cuentas privilegiadas, tocar configuraciones críticas y dejar persistencia. Además, en muchos entornos sigue existiendo el problema clásico: demasiados administradores globales y, peor aún, usados para tareas del día a día.

Eso multiplica muchísimo el riesgo.

Medidas de seguridad

Aquí no hay inventos raros. Hay que reducir el número al mínimo imprescindible, usar PIM siempre que se pueda, separar cuentas administrativas de cuentas normales, exigir MFA fuerte resistente a phishing, usar estaciones de administración dedicadas y revisar de forma periódica quién tiene este rol y por qué.

Un Global Administrator no debería vivir una vida normal de usuario.

Application Administrator

¿Qué puede hacer?

Este rol puede crear y gestionar registros de aplicaciones, aplicaciones empresariales, credenciales de aplicaciones como secretos y certificados, y conceder consentimientos o gestionar elementos críticos relacionados con identidades de aplicación.

En un tenant moderno, eso da muchísimo poder.

Problemas de seguridad

Aquí hay un error muy habitual: pensar que esto “solo toca aplicaciones”.

No. Tocar aplicaciones en Entra ID puede significar crear persistencia, robar tokens, acceder a datos empresariales, montar accesos no interactivos difíciles de detectar o conceder permisos excesivos a una aplicación controlada por un atacante.

En la práctica, una cuenta comprometida con este rol puede convertirse en una puerta trasera perfecta.

Medidas de seguridad

Este rol debe estar muy limitado, muy justificado y muy auditado. Nada de asignaciones amplias por comodidad. Conviene vigilar creación de aplicaciones, cambios en secretos y certificados, concesión de permisos privilegiados y consentimientos administrativos. Y, por supuesto, aplicar PIM, MFA fuerte y revisión periódica de uso real.

Cloud Application Administrator

¿Qué puede hacer?

Es muy similar al Application Administrator, aunque con algunas diferencias puntuales. Sigue teniendo una enorme capacidad sobre las aplicaciones cloud del entorno y sobre su configuración operativa.

En tenants muy orientados a SaaS y nube, esto puede ser casi igual de delicado.

Problemas de seguridad

El riesgo es prácticamente el mismo en muchos escenarios: control de aplicaciones, manipulación de credenciales, permisos indebidos, persistencia silenciosa y capacidad para usar el plano de aplicaciones como vector de ataque.

Muchas veces este rol no genera tanto respeto como debería, y eso lo convierte en un candidato perfecto para ser subestimado.

Medidas de seguridad

Las mismas ideas: mínimo número de asignaciones, justificación real, activación temporal, monitorización de cambios, revisión de permisos concedidos a aplicaciones y un proceso muy serio para cualquier modificación en identidades de aplicación.

Conditional Access Administrator

¿Qué puede hacer?

Puede crear, modificar y eliminar políticas de Conditional Access. Es decir, puede tocar una de las capas más importantes de defensa del tenant: cuándo entra un usuario, desde dónde, con qué requisitos y bajo qué condiciones.

Problemas de seguridad

Este rol es peligrosísimo porque puede cambiar la postura de seguridad del entorno en minutos.

Un atacante podría deshabilitar requisitos de MFA, crear exclusiones para sus cuentas, permitir accesos desde ubicaciones no deseadas o bloquear a administradores legítimos mientras se deja una vía libre para operar.

Es decir, no solo puede abrir la puerta. También puede decidir a quién se la cierra.

Medidas de seguridad

Este rol debe tratarse como extremadamente sensible. Debe usar PIM, MFA fuerte y cuentas separadas. Las políticas de acceso condicional deben auditarse, versionarse y revisarse con cuidado. Además, cualquier cambio debería generar alertas y, si es posible, requerir control adicional o revisión.

No puede ser un rol “operativo” sin vigilancia.

Hybrid Identity Administrator

¿Qué puede hacer?

Gestiona elementos críticos de la identidad híbrida, como sincronización, federación, autenticación pass-through y otros componentes que conectan el mundo on-premise con la nube.

Y eso, como ya os imaginaréis, no es precisamente poca cosa.

Problemas de seguridad

Cuando un rol controla el puente entre el entorno local y Entra ID, el riesgo es enorme. Puede modificar reglas de sincronización, afectar a la federación, introducir cambios peligrosos en la confianza y, en determinados escenarios, facilitar ataques de impacto muy alto.

La identidad híbrida es uno de esos terrenos donde un pequeño cambio puede tener consecuencias muy grandes.

Medidas de seguridad

Este rol tiene que estar hipercontrolado. Pocas cuentas, muy justificadas, segregación clara, revisiones periódicas, endurecimiento de los sistemas implicados y mucho cuidado con cualquier cambio en sincronización o federación. Aquí no vale improvisar.

Privileged Authentication Administrator

¿Qué puede hacer?

Puede ver, configurar y resetear métodos de autenticación de usuarios, incluidos usuarios altamente privilegiados. Puede forzar re-registros, modificar información de autenticación y, en la práctica, tocar una parte muy delicada del proceso de acceso.

Problemas de seguridad

Este rol es una barbaridad si cae en malas manos.

Porque no hablamos solo de “administrar MFA”. Hablamos de la posibilidad de intervenir sobre los mecanismos de autenticación de cuentas críticas. Un atacante podría resetear los factores de un administrador privilegiado, registrar sus propios métodos y usar eso como trampolín para secuestrar la cuenta.

Es un camino indirecto hacia el control total.

Medidas de seguridad

Muy pocas cuentas, PIM obligatorio, MFA fuerte, cuentas administrativas separadas, alertado fino sobre cambios en métodos de autenticación y una revisión constante de asignaciones. Este rol no puede regalarse ni dejarse permanente.

Privileged Role Administrator

¿Qué puede hacer?

Gestiona la asignación de roles administrativos dentro de Entra ID. Puede añadir o quitar miembros de roles privilegiados y tocar elementos muy sensibles del modelo de privilegios.

Problemas de seguridad

Aquí el riesgo es evidente. Si puedo asignar roles privilegiados, puedo convertirme en alguien mucho más poderoso. Por ejemplo, puedo añadirme a Global Administrator o modificar cómo se gestiona el privilegio dentro del tenant.

En entornos con PIM, además, el impacto puede ser todavía mayor si se tocan activaciones, duraciones, requisitos o reglas.

Medidas de seguridad

Este rol es puro Tier 0. Debe estar muy restringido, activarse solo temporalmente, requerir controles adicionales y vigilarse de cerca. Además, conviene revisar cualquier cambio en roles privilegiados como si fuera un evento de máxima sensibilidad.

Security Administrator

¿Qué puede hacer?

Puede leer y gestionar mucha información de seguridad del tenant, modificar políticas y trabajar con elementos muy sensibles de la postura defensiva.

Problemas de seguridad

A veces este rol no se mete en la conversación de Tier 0, y creo que es un error. Porque un atacante con esta visibilidad puede entender cómo le detectas, qué alertas se generan, qué políticas existen y, en algunos casos, intervenir sobre ciertos mecanismos defensivos.

No siempre le dará control total instantáneo, pero sí puede darle una ventaja brutal para moverse con menos ruido y más conocimiento.

Medidas de seguridad

Este rol también debe limitarse mucho, auditarse bien y separarse del uso cotidiano. Hay que vigilar cambios en políticas, revisiones de alertas, operaciones delicadas y cualquier actividad anómala relacionada con la visibilidad o administración de la seguridad del tenant.

Como veis, el patrón se repite. No estamos hablando solo de quién manda más en el portal. Estamos hablando de quién puede cambiar las reglas de identidad, acceso, privilegio y defensa en el tenant.

En el post anterior empezamos con la idea general. Hoy ya hemos bajado un poco más a tierra. En el siguiente, si queréis, podemos meternos en la parte más fea y más útil: qué escenarios de ataque reales se abren cuando cae una de estas cuentas y cómo revisaría yo un tenant para detectar este tipo de problemas.

Si queréis aprender ciberseguridad Microsoft, identidades, hardening, defensa y cómo auditar este tipo de entornos de forma práctica, podéis echar un vistazo a los cursos de la academia:

https://www.seguridadsi.com/todos-cursos

Gracias por leerme !!!

Autor

Profesor y consultor de ciberseguridad. Microsoft MVP.

+ 25 años de experiencia

Compartir artículo :

Otros artículos

calendly
×
Hola 👋, bienvenido a SeguridadSI
Reserva una llamada de 15 minutos para resolver cualquier consulta
Scroll al inicio