Qué es la gestión del acceso privilegiado en Azure?
El acceso privilegiado Azure es el conjunto de identidades, roles, políticas y flujos de trabajo que controlan el poder administrativo en Microsoft Entra ID, Microsoft 365, Azure y los servicios conectados. En Microsoft Entra ID, roles como Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Security Administrator y Application Administrator pueden cambiar la configuración de seguridad, asignar privilegios, gestionar aplicaciones o crear rutas de acceso duraderas.
Esto convierte el acceso privilegiado en un problema del plano de control del tenant. Una identidad privilegiada comprometida puede cambiar políticas de Acceso Condicional, añadir o modificar asignaciones de roles, registrar aplicaciones, alterar métodos de autenticación y debilitar los controles en los que confían los equipos de respuesta.
Privileged Identity Management (PIM) reduce la exposición permanente al permitir que los administradores usen asignaciones elegibles y activación limitada en el tiempo en lugar de mantener roles poderosos activos todo el tiempo. PIM no es solo una función de interfaz. Es un modelo de control: activar solo cuando sea necesario, exigir autenticación más fuerte o aprobación cuando corresponda, registrar el motivo, y revisar el rol después de su uso.
Cómo falla el acceso privilegiado Azure
Los mismos fallos de acceso privilegiado aparecen repetidamente en tenants reales:
- demasiados Global Administrators
- asignaciones de rol permanentes donde bastarían asignaciones elegibles
- cuentas admin sin cobertura de autenticación fuerte
- cuentas de emergencia que existen pero no se supervisan ni se prueban
- service principals y aplicaciones privilegiadas excluidas de las revisiones de administradores humanos
- PIM desplegado para algunos roles pero no para los roles que interesan a los atacantes
- exclusiones de Acceso Condicional que sacan cuentas admin de la ruta de control prevista
El riesgo no depende solo del número de administradores. Un tenant con pocos Global Admins puede seguir expuesto si esas identidades son permanentes, susceptibles de phishing, reutilizadas para el trabajo diario, o excluidas de las políticas. Un tenant con muchos administradores con alcance limitado puede ser más seguro si cada rol está justificado, es elegible, se supervisa y está protegido con autenticación fuerte.
Por qué Global Administrator es diferente
Microsoft documenta Global Administrator como un rol altamente privilegiado que puede leer y modificar casi toda la configuración administrativa en Microsoft Entra ID, con pocas excepciones, y que también puede leer y modificar casi toda la configuración administrativa de Microsoft 365. Global Administrator también puede elevar el acceso en algunos escenarios. Esto lo distingue de un rol operativo restringido como User Administrator o Reports Reader.
Use el rol de menor privilegio capaz de completar la tarea. Si el trabajo es consentimiento de aplicaciones, cambios de Acceso Condicional, administración de Exchange o investigación de seguridad, asigne el rol que corresponde a la tarea en lugar de recurrir por defecto a Global Administrator. Esto reduce el radio de impacto cuando falla una cuenta, una sesión o un flujo de aprobación.
La cadena de ataque
Paso 1 - Enumerar el acceso privilegiado
Un atacante con visibilidad de lectura sobre el directorio suele empezar enumerando roles de directorio, miembros de roles, grupos privilegiados, aplicaciones y service principals. Busca cuentas con poder permanente, autenticación débil, o propietarios inactivos.
Paso 2 - Apuntar a la ruta admin más débil
El objetivo más fácil puede no ser el Global Administrator evidente. Puede ser un Privileged Role Administrator obsoleto, un propietario de aplicación con permisos amplios, una cuenta de emergencia con poca supervisión, o una cuenta admin excluida del Acceso Condicional por una interrupción pasada.
Paso 3 - Convertir el acceso en persistencia
Una vez que existe el acceso privilegiado, el atacante puede intentar añadir otra asignación de rol, cambiar métodos de autenticación, debilitar una política, crear una credencial de aplicación, o añadir una ruta de permisos de service principal. La ruta de persistencia depende de los roles que tiene la identidad comprometida.
Paso 4 - Esconderse en la administración legítima
Los cambios privilegiados suelen ser poco frecuentes pero legítimos. Los atacantes se benefician cuando el tenant no tiene una línea base de quién activa PIM, quién aprueba las solicitudes, qué cuentas deberían ser permanentes, y qué aplicaciones tienen permitido mantener privilegio alto.
Detección
Eventos del log de auditoría de Entra ID
Supervise los cambios administrativos que alteran el plano de control del tenant:
| Área de operación | Qué revisar |
|---|---|
| Asignaciones de roles | Nuevos miembros añadidos a roles privilegiados, especialmente Global Administrator y Privileged Role Administrator |
| Actividad PIM | Activaciones, aprobaciones, solicitudes denegadas, y cambios en la configuración del rol |
| Métodos de autenticación | Cambios en los métodos de autenticación de usuarios privilegiados |
| Acceso Condicional | Creación, actualización, eliminación de políticas, o cambios de exclusión |
| Aplicaciones | Nuevos registros de aplicación, nuevas credenciales, nuevos propietarios, y consentimiento de alto privilegio |
| Cuentas de emergencia | Cualquier inicio de sesión, cambio de credencial, o cambio de rol |
Señales de actividad PIM
PIM debería hacer el privilegio más observable. Revise:
- activación fuera del horario laboral o de las ventanas de mantenimiento habituales
- activación de roles que el usuario no usa normalmente
- activación sin una justificación útil donde se requiere justificación
- aprobación por un aprobador inesperado
- activación repetida por cuentas que también muestran riesgo de inicio de sesión
- asignaciones permanentes creadas después de un despliegue de PIM
Advertencias sobre la detección
No trate un solo evento de auditoría como prueba de compromiso. Una asignación de rol puede formar parte de un proyecto legítimo. La alerta debe incluir contexto: actor, objetivo, rol, tipo de asignación, duración de la activación, ruta de aprobación, dispositivo, ubicación, nivel de riesgo, y si el usuario normalmente desempeña ese rol.
Remediación
El objetivo no es eliminar toda la administración. El objetivo es eliminar el privilegio permanente innecesario y hacer que el acceso privilegiado sea explícito, limitado en el tiempo, con autenticación fuerte y revisable.
1. Reducir el número de Global Administrators
Liste todas las asignaciones de Global Administrator y clasifique cada cuenta:
- administrador humano normal
- cuenta de acceso de emergencia
- cuenta de servicio o identidad de automatización
- cuenta obsoleta
- identidad externa o invitada
- propietario desconocido
Los administradores humanos normales normalmente no deberían necesitar Global Administrator activo de forma permanente. Conviértalos a roles más limitados o asignaciones elegibles mediante PIM cuando la licencia y las operaciones lo permitan. Mantenga la excepción de acceso de emergencia separada en lugar de tratarla como un modelo de administración rutinario.
2. Configurar la configuración de rol de PIM
Para los roles de alto valor, configure los ajustes de PIM de forma deliberada:
- asignación elegible en lugar de permanente activa para administradores normales
- duración de activación adecuada al rol
- contexto de autenticación MFA o Acceso Condicional en la activación cuando se requiera
- aprobación para roles especialmente sensibles
- justificación de negocio e información de ticket donde el proceso necesite auditabilidad
- notificaciones al equipo propietario del rol
- revisiones de acceso periódicas para asignaciones permanentes y elegibles
Los ajustes de rol de PIM de Microsoft admiten controles como aprobación, justificación, información de ticket, y duración de la asignación. La información de ticket es un campo informativo, no una validación automática contra un sistema de tickets, así que no asuma que por sí sola prueba la autorización del cambio.
3. Proteger correctamente las cuentas de acceso de emergencia
Las cuentas de acceso de emergencia son intencionalmente diferentes. Microsoft recomienda dos o más cuentas de acceso de emergencia solo en la nube para escenarios de break-glass, y la guía de Microsoft indica que esas asignaciones de Global Administrator deberían ser activas permanentes en lugar de elegibles en PIM. Eso evita que una dependencia de PIM bloquee el tenant durante una interrupción.
Esa excepción no significa controles débiles. Las cuentas de emergencia deben ser solo en la nube, protegidas con autenticación resistente a phishing cuando sea posible, almacenadas de forma segura, supervisadas en cada inicio de sesión, y validadas regularmente. No deben usarse para la administración rutinaria.
4. Exigir autenticación fuerte para usuarios privilegiados
Exija autenticación fuerte para usuarios y roles privilegiados. Para los roles de mayor valor, prefiera métodos resistentes a phishing cuando la licencia, el soporte de dispositivos y las operaciones lo permitan. Verifique también que los administradores no estén evitando la política mediante ubicaciones de confianza, grupos excluidos, cuentas de prueba obsoletas, o flujos de trabajo heredados.
5. Incluir aplicaciones y service principals
El acceso privilegiado no es solo humano. Revise los service principals, registros de aplicación, credenciales, propietarios, y permisos de aplicación. Un tenant puede tener una lista limpia de Global Administrators y aun así tener una ruta de aplicación que puede leer datos del directorio, modificar objetos, o mantener persistencia.
Frecuencia de revisión y ownership
El acceso privilegiado debe tener un propietario y una frecuencia de revisión. PIM reduce el acceso permanente, pero no prueba automáticamente que cada asignación elegible siga estando justificada. Al menos una vez por ciclo de revisión, compare cada asignación de rol privilegiado con el modelo operativo actual: quién es el propietario del rol, qué tarea lo requiere, si la asignación debería seguir siendo elegible, si la configuración de activación sigue siendo suficientemente estricta, y si el usuario sigue perteneciendo a la población admin.
Revise también los cambios después de migraciones, fusiones, respuesta a incidentes, uso de acceso de emergencia, y incorporaciones SaaS importantes. Esos son los momentos en que las rutas admin temporales suelen volverse permanentes.
Validación tras el despliegue de PIM
Después de la limpieza, valide la seguridad efectiva en lugar de la existencia de la política:
- confirme que los administradores normales son elegibles, no activos permanentemente, para roles de alto valor
- confirme que las cuentas de emergencia son las únicas excepciones intencionales de Global Administrator permanente
- realice una activación controlada y confirme que el MFA, la aprobación, la duración y el registro se comportan como se espera
- revise los logs de auditoría en busca de nuevas asignaciones de rol después de la limpieza
- verifique que el Acceso Condicional no excluye cuentas privilegiadas de forma no intencionada
- revise los service principals y registros de aplicación en busca de privilegio equivalente a roles admin
- confirme que las alertas se disparan con el inicio de sesión de una cuenta de emergencia y con la asignación de un rol privilegiado
Una buena prueba de validación pregunta: si esta contraseña o sesión admin se roba hoy, ¿qué privilegio obtiene el atacante de inmediato, y qué controles adicionales debe superar antes de ejercer más privilegio?
Cómo EtcSec detecta esto
EtcSec audita la configuración del acceso privilegiado Azure en cada escaneo y se centra en las condiciones que convierten una cuenta comprometida en control total del tenant.
PA_TOO_MANY_GLOBAL_ADMINS identifica tenants con un número excesivo de Global Administrators.
PA_PERMANENT_ADMIN_ASSIGNMENTS señala asignaciones privilegiadas permanentes que deberían revisarse para su conversión a acceso elegible.
PA_PIM_NOT_ENABLED identifica tenants donde el control de acceso privilegiado justo a tiempo está ausente o es ineficaz.
PA_GLOBAL_ADMIN_NOT_MFA identifica cuentas Global Administrator sin cobertura de autenticación fuerte.
Controles relacionados
Revise el acceso privilegiado junto con Identidad Azure: por qué el MFA solo no es suficiente, Azure Identity Protection: bloqueo de credenciales filtradas, Acceso Condicional Azure: bypass de MFA con contraseñas robadas, Cuentas invitado Azure: la superficie de ataque olvidada de su tenant, y Registros de aplicaciones Azure: apps del tenant sobreprivilegiadas. El privilegio admin permanente rara vez es el único problema de un tenant.
Fuentes primarias
Explore las páginas de identidad que apoyan este tema