Que es el acceso privilegiado Azure?
El acceso privilegiado Azure es la combinacion de roles, activaciones, excepciones y cuentas especiales que permiten administrar Microsoft Entra ID y el tenant cloud. La pregunta tecnica util no es solo cuantos Global Administrators existen. La pregunta correcta es que roles siguen activos de forma permanente, quien puede elevar privilegios bajo demanda, que controles acompañan esa activacion y que cuentas quedan fuera del modelo normal.
Microsoft documenta Privileged Identity Management (PIM) como la forma de administrar roles privilegiados con asignaciones elegibles, aprobaciones, justificacion, MFA y duraciones acotadas. Por eso el riesgo real aparece cuando un tenant sigue viviendo de asignaciones activas permanentes, de roles demasiado amplios o de cuentas de emergencia poco gobernadas.
Donde nace el riesgo de verdad
Un tenant puede tener pocos Global Admins y seguir mal protegido si conserva cualquiera de estas condiciones:
- demasiados roles activos de manera permanente
- ausencia de PIM o uso parcial solo en algunos roles
- admins sin una exigencia fuerte de MFA para activar privilegios
- cuentas break-glass mal definidas o no revisadas
- service principals o workload identities con privilegios altos fuera del mismo modelo de control
Esto importa porque el privilegio en Entra ID no es solo una cuestion de numero de cuentas. Es una cuestion de duracion, alcance, aprobacion y visibilidad.
Que revisar en una auditoria tecnica
1. Roles de directorio realmente asignados
Get-MgDirectoryRole | Select-Object DisplayName, Id
A partir de ahi hay que revisar no solo Global Administrator, sino tambien otros roles de alto impacto:
- Privileged Role Administrator
- Authentication Administrator
- Application Administrator o Cloud Application Administrator
- Security Administrator
- Exchange, SharePoint o Intune Admins con mucho alcance operativo
2. Diferenciar asignaciones activas y elegibles
PIM existe precisamente para reducir standing privilege. La revision correcta debe responder:
- que roles siguen activos permanentemente
- que roles son elegibles y requieren activacion
- si la activacion exige MFA, justificacion y/o aprobacion
- cuanto dura la activacion y quien la valida
3. Revisar cuentas de emergencia
Microsoft recomienda cuentas de emergencia separadas para evitar lockout total. Pero esas cuentas no pueden convertirse en una via paralela de administracion cotidiana. Deben ser pocas, estar documentadas, probadas y vigiladas.
4. Revisar identidades no humanas con privilegios altos
Los service principals y otras workload identities pueden concentrar privilegios equivalentes o cercanos a los de un admin humano. Si no entran en la misma conversacion de riesgo, el tenant solo esta protegiendo una parte del problema.
Detection
La deteccion util en acceso privilegiado se apoya en:
- nuevos miembros anadidos a roles de alto impacto
- cambios de asignacion activa a elegible o viceversa
- activaciones PIM fuera de horario o desde ubicaciones no esperadas
- roles con demasiados miembros activos
- cuentas de emergencia usadas fuera de una prueba o incidente real
- workload identities con permisos amplios y secretos prolongados
El objetivo no es solo registrar cambios. Es poder contestar rapidamente a preguntas como:
- quien podia elevar privilegios en una fecha concreta
- quien aprobo esa elevacion
- si la activacion estaba justificada
- si habia una alternativa menos potente
Remediacion
1. Reducir roles activos permanentes
El primer paso es convertir el privilegio permanente en privilegio elegible siempre que la operacion lo permita. Un rol privilegiado activo por costumbre es una deuda, no una comodidad.
2. Usar PIM como control operativo real
Microsoft documenta que PIM permite:
- requerir MFA para activar
- exigir approval
- pedir justification
- limitar la duracion de la activacion
Esto es exactamente lo que hace que un rol privilegiado deje de ser un standing access permanente y pase a ser una elevacion controlada.
3. Separar cuentas de emergencia del trabajo diario
Los break-glass accounts no deberian participar en administracion rutinaria. Su finalidad es resiliencia del tenant, no comodidad operativa.
4. Revisar el alcance de roles distintos de Global Admin
Muchos equipos reducen Global Admins y olvidan otros roles potentes. Una auditoria seria no se queda en el nombre del rol mas famoso; revisa el conjunto de permisos efectivos disponibles para operar identidades, aplicaciones, politicas y workloads.
5. Incluir service principals en la conversacion
El acceso privilegiado Azure no termina en los usuarios interactivos. Si una aplicacion o automation principal mantiene permisos altos y secretos estaticos, el riesgo administrativo sigue ahi con otro nombre.
6. Alinear PIM con Conditional Access y cuentas de emergencia
PIM por si solo no arregla una postura de identidad debil. La elevacion debe convivir con:
- MFA fuerte para administradores
- cuentas de emergencia separadas y testadas
- reduccion de secretos estaticos en identidades no humanas
- revisiones periodicas del motivo por el que un rol sigue siendo necesario
Sin este contexto, es facil acabar con un tenant que "tiene PIM" pero mantiene el mismo riesgo operativo con otra interfaz.
Validacion
La validacion correcta debe demostrar que:
- los roles de alto impacto tienen pocos miembros activos permanentes
- PIM esta habilitado donde debe estarlo
- la activacion exige controles proporcionales al riesgo
- las cuentas de emergencia estan separadas del uso diario
- las identidades no humanas privilegiadas estan inventariadas y gobernadas
Una tabla bonita de roles no basta. Lo que importa es si la ruta desde "usuario comprometido" hasta "privilegio global" se ha vuelto realmente mas costosa y mas visible. Tambien conviene validar periodicamente que las activaciones siguen teniendo sentido operativo y que ningun rol se mantiene elegible o activo solo por costumbre historica.
Revisar settings de activacion, no solo membresias
Un error habitual es limitar la revision a "cuantos admins permanentes hay" y no mirar como se activa el privilegio cuando PIM ya esta implantado. Los settings de cada rol importan tanto como la elegibilidad misma. Duracion maxima, MFA obligatoria, necesidad de justificante, aprobacion, notificaciones y alcance del reviewer determinan si la elevacion es realmente controlada o solo cosmetica.
Cuentas de emergencia: controladas, separadas y comprobadas
Las cuentas de emergencia necesitan un tratamiento distinto al de los admins diarios, pero eso no significa que deban quedar fuera del gobierno. Un programa serio de acceso privilegiado revisa que existan pocas, que no participen en administracion ordinaria, que tengan procedimientos de uso muy claros y que sus credenciales, metodos y alertas se prueben en ventanas controladas. El riesgo no es solo que existan, sino que se conviertan en el atajo favorito para saltarse PIM, MFA fuerte o aprobaciones.
Workload identities con privilegios altos
Tambien conviene revisar si el tenant esta trasladando privilegios desde usuarios humanos hacia service principals sin aplicar el mismo rigor. Una workload identity con permisos amplios sobre aplicaciones, roles o automatizacion puede neutralizar parte del valor de PIM si usa secretos largos, certificados sin rotacion o owners difusos. Para cerrar bien el tema, el inventario de acceso privilegiado debe incluir tanto personas como aplicaciones con capacidad real de cambiar configuracion critica.
Matriz minima de comprobacion
Despues de ajustar PIM o la asignacion de roles, una validacion tecnica minima deberia confirmar:
- que un admin habitual necesita activacion y cumple MFA fuerte
- que la activacion deja trazabilidad suficiente en logs y aprobaciones
- que una cuenta de emergencia no puede usarse como sustituto operativo diario
- que los service principals privilegiados siguen inventariados y con ownership claro
Sin esa comprobacion cruzada, muchos tenants creen haber reducido privilegio permanente cuando solo han cambiado el lugar donde se define.
Aprobacion y justificacion: donde se ve la madurez real
En muchos tenants la diferencia entre un modelo maduro y uno cosmetico se ve en dos campos muy simples: quien aprueba y como se justifica la activacion. Si la aprobacion recae siempre en el mismo equipo operativo sin separacion real o si las justificaciones son texto libre sin criterio, el control pierde valor rapido. Lo util es poder reconstruir despues por que una elevacion existio, quien la autorizo y que tarea concreta la motivaba.
Que revisar cada semana
Una rutina corta pero efectiva suele incluir:
- roles con mas miembros activos de los previstos
- activaciones fuera de horario o desde contextos anormales
- cuentas de emergencia usadas desde la ultima revision
- workload identities con secretos a punto de expirar o con permisos demasiado amplios
- roles elegibles que nadie revisa desde hace meses
Ese seguimiento semanal evita que PIM quede bien configurado una vez y mal gobernado despues.
Fuentes primarias
- What is Microsoft Entra Privileged Identity Management?
- Discover resources to manage in PIM
- Configure role settings in PIM
- Manage emergency access accounts in Microsoft Entra ID
Como EtcSec detecta esto
EtcSec cubre este tema con varios hallazgos relacionados:
- PA_TOO_MANY_GLOBAL_ADMINS
- PA_PERMANENT_ADMIN_ASSIGNMENTS
- PA_PIM_NOT_ENABLED
- PA_GLOBAL_ADMIN_NOT_MFA
La pregunta util no es cuantos admins hay en una hoja de calculo. La pregunta util es si el tenant ha reducido de verdad el privilegio permanente y si cada elevacion deja evidencia, aprobacion y contexto suficiente.
