Activación PIM Entra: Aprobación, MFA y Justificación

Entra PIM Activación Aprobación MFA Justificación Mala Configuración Explicada

Activar Microsoft Entra Privileged Identity Management (PIM) es la parte fácil. La Entra PIM activación aprobación MFA justificación mala configuración es lo que ocurre después: PIM está desplegado, los roles son elegibles en lugar de permanentes, pero el propio paso de activación queda completamente abierto — sin aprobación requerida, sin MFA en la activación, sin justificación registrada, y con una ventana de activación de 8 horas o más. El resultado parece un acceso justo a tiempo en un panel, pero en la práctica se comporta como un acceso admin permanente: cualquiera elegible para un rol lo obtiene en el momento en que hace clic en "Activar", sin segundo factor, sin rastro de responsabilidad, y con una ventana lo bastante larga como para superar la mayoría de los ciclos de detección.

Este es un modo de fallo distinto de "PIM no está activado en absoluto". Un tenant puede superar esa primera comprobación y seguir expuesto, porque el valor de seguridad de PIM proviene casi por completo de cómo se configura la activación, no del simple hecho de que existan asignaciones elegibles. Cada uno de los cuatro controles de activación — aprobación, MFA, justificación y duración — es opcional por rol en Microsoft Entra, y ninguno es obligatorio por defecto.

⚠️

⚠️ Advertencia: los ajustes de rol de PIM son por rol e independientes entre sí. Corregir Administrador Global no corrige Administrador de Rol Privilegiado, Administrador de Seguridad, ni ningún rol de directorio personalizado — cada uno debe revisarse y configurarse por separado.

Cómo Funcionan los Controles de Activación de PIM

Microsoft Entra expone los ajustes de rol de PIM — llamados internamente policies — a través del centro de administración de Microsoft Entra (ID Governance > Privileged Identity Management > Roles de Microsoft Entra > Roles > [rol] > Ajustes de rol) o mediante el recurso de Microsoft Graph unifiedRoleManagementPolicy. Cada policy se compone de reglas independientes, y cuatro de ellas definen lo que ocurre en el momento de la activación (Configurar los ajustes de rol de Microsoft Entra en PIM, Actualizar reglas en PIM mediante Microsoft Graph):

Control	Ajuste de UI	ID de regla Graph	Qué hace
Aprobación	Require approval to activate	`Approval_EndUser_Assignment` (`isApprovalRequired`)	Envía la solicitud de activación a uno o más aprobadores designados antes de que el rol se active
MFA	On activation, require multifactor authentication	`Enablement_EndUser_Assignment` (`enabledRules: MultiFactorAuthentication`)	Fuerza un desafío MFA en el momento de la activación
Justificación	Require justification on activation	`Enablement_EndUser_Assignment` (`enabledRules: Justification`)	Fuerza una justificación de negocio en texto libre, almacenada junto con el registro de activación
Duración	Activation maximum duration	`Expiration_EndUser_Assignment` (`maximumDuration`, ISO 8601, p. ej. `PT8H`)	Limita cuánto tiempo permanece activo el rol activado, de 1 a 24 horas

Los cuatro se configuran por rol y ninguno es mutuamente excluyente — un rol bien reforzado normalmente tiene aprobación y MFA y justificación y una duración corta, no solo uno de ellos.

Por Qué "PIM Activado" No Es Lo Mismo Que "Activación Protegida"

Una comprobación relacionada, más básica, es si PIM está configurado para los roles privilegiados en absoluto — esa es una brecha distinta y más severa, que cubrimos en Acceso privilegiado Azure: roles, PIM y administracion permanente. Este artículo asume que esa comprobación ya se supera: PIM está activo, los roles son elegibles, y el tenant parece cumplir a primera vista. La brecha aquí está un nivel más profundo — es lo que ocurre dentro de PIM una vez que alguien activa un rol.

Los cuatro valores por defecto importan porque ninguno se inclina hacia la seguridad de forma predeterminada:

La aprobación está desactivada por defecto. Cualquier usuario elegible puede auto-activarse de inmediato, sin que intervenga una segunda persona.
El MFA en la activación tiene un punto ciego documentado. La propia documentación de Microsoft indica que "es posible que no se solicite a los usuarios la autenticación multifactor si se autenticaron con credenciales seguras o proporcionaron autenticación multifactor antes en la sesión" — por lo que una sesión que ya cumplió el MFA al iniciar sesión puede activar un rol privilegiado sin ningún desafío adicional. Es el mismo punto ciego de reautenticación cubierto en Identidad Azure: MFA, metodos y Security Defaults.
La justificación está desactivada por defecto, por lo que las activaciones no llevan ninguna razón de negocio registrada — lo que debilita tanto la revisión en tiempo real como la auditoría posterior.
La duración máxima de activación es de 8 horas por defecto y puede configurarse hasta 24 — tiempo suficiente para que una sesión o token secuestrado sea útil durante toda una jornada laboral.

🚨 Peligro: como el ajuste de MFA en la activación no fuerza una reautenticación cuando el MFA ya se cumplió en la sesión, un atacante que ha robado un token de sesión válido puede activar un rol privilegiado sin tocar nunca un segundo factor. La mitigación documentada por Microsoft para esta brecha específica es el contexto de autenticación de Conditional Access combinado con la frecuencia de inicio de sesión configurada en "Cada vez" — no la simple casilla de MFA en la activación.

Detección

Qué comprobar por rol

Obtenga la policy de activación actual de cada rol de directorio de Microsoft Entra y compárela con los cuatro controles anteriores. Manualmente, esto significa abrir Ajustes de rol para cada rol en el centro de administración. A escala, consúltelo mediante Graph:

GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules

O con Microsoft Graph PowerShell:

# Requiere RoleManagement.Read.Directory o RoleManagement.ReadWrite.Directory
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$policies = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole'"
foreach ($p in $policies) {
    Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $p.PolicyId |
        Where-Object { $_.Id -in @('Approval_EndUser_Assignment','Enablement_EndUser_Assignment','Expiration_EndUser_Assignment') }
}

Para cada rol, márquelo si: isApprovalRequired es false, enabledRules de la regla de enablement no incluye MultiFactorAuthentication, enabledRules no incluye Justification, o maximumDuration de la regla de expiración supera su umbral de policy (habitualmente de 1 a 4 horas para roles Tier-0). Priorice Administrador Global, Administrador de Rol Privilegiado, Administrador de Seguridad, Administrador de Acceso Condicional, y cualquier rol personalizado con permisos de escritura a nivel de todo el directorio — estos son los roles donde la brecha tiene el mayor radio de impacto.

Qué vigilar en el registro de auditoría

Microsoft Entra conserva el historial de policies y activaciones de PIM en el panel Auditoría de recursos (ID Governance > Privileged Identity Management > Roles de Microsoft Entra > Auditoría de recursos), retenido 30 días por defecto (Ver el informe del registro de auditoría de roles de Microsoft Entra en PIM) — si esa ventana por defecto es un problema para sus plazos de investigación, consulte Registro Entra ID: Retención, Diagnostic Settings, SIEM Exportación para enrutar esos registros a almacenamiento de más largo plazo. Dos tipos de actividad importan más:

Actividad	Por qué importa
`Update role setting in PIM`	Alguien cambió la policy de activación de un rol — incluyendo desactivar la aprobación, el MFA o la justificación, o alargar la ventana de activación. Esto es en sí mismo un objetivo de alto valor para un atacante que ya tiene algo de privilegio y quiere aflojar la puerta antes de activar más.
Solicitudes de activación de rol sin rastro de justificación/aprobación	Las activaciones completadas sin un aprobador registrado y sin texto de justificación son exactamente las que una policy reforzada habría bloqueado o ralentizado.

ℹ️

ℹ️ Nota: un evento Update role setting in PIM no es por sí solo prueba de un ataque — los administradores legítimos también reconfiguran las policies de PIM. Trátelo como una señal que necesita la misma revisión que cualquier otro cambio de rol privilegiado: quién lo hizo, en qué rol, y si debilitó o reforzó el control.

Remediación

💡

💡 Solución Rápida: empiece por Administrador Global y Administrador de Rol Privilegiado — los dos roles con mayor radio de impacto — y luego extiéndalo a todos los demás roles elegibles.

Enumere la policy actual de cada rol usando la consulta de Graph o PowerShell anterior, para tener una línea base antes/después en lugar de una simple estimación por rol.
Exija aprobación para activar los roles Tier-0, con al menos dos aprobadores designados configurados explícitamente. No deje la lista de aprobadores vacía: la propia documentación de Microsoft advierte que un tenant puede quedar bloqueado si todos los Administradores de Rol Privilegiado/Administradores Globales solo tienen asignaciones elegibles (no activas), se requiere aprobación, y no hay aprobadores configurados — construya cuentas de acceso de emergencia correctamente supervisadas, como asignaciones activas y permanentes, antes de activar esto.
Exija MFA en la activación, y donde el rol lo justifique, añada contexto de autenticación de Conditional Access (vea Brechas acceso condicional Entra ID: que errores dejan una exposicion real) con la frecuencia de inicio de sesión configurada en "Cada vez" — este es el ajuste que realmente fuerza la reautenticación en la activación, en lugar de aceptar silenciosamente una prueba MFA obtenida antes en la sesión.
Exija justificación en la activación (y considere exigir también información de ticket) para que cada activación lleve una razón de negocio registrada y revisable.
Reduzca la duración máxima de activación. Tanto el valor por defecto de 8 horas como el tope de 24 horas existen por comodidad, no por seguridad — la mayoría de las tareas operativas caben en 1 a 4 horas. Configúrelo con maximumDuration de la regla de expiración en formato ISO 8601 (PT2H para dos horas, PT4H para cuatro).
Aplique la misma policy a todos los roles equivalentes, no solo al que probó. Los ajustes de rol son independientes, así que un script que solo corrige Administrador Global deja sin cambios a Administrador de Rol Privilegiado, Administrador de Seguridad y los roles de directorio personalizados.
Vuelva a ejecutar la consulta de enumeración de Graph después del cambio y confirme isApprovalRequired: true, que enabledRules incluye MultiFactorAuthentication y Justification, y que maximumDuration refleja su nuevo tope — luego repita esta comprobación de forma periódica, ya que un futuro evento Update role setting in PIM puede revertirlo todo silenciosamente.

Cómo lo Detecta EtcSec

La auditoría Azure de EtcSec comprueba la policy de activación de PIM en cada escaneo, independientemente de si PIM mismo está activado.

PA_PIM_NO_APPROVAL_REQUIRED marca las asignaciones de rol elegibles donde la activación no requiere aprobación.

PA_PIM_NO_MFA_ON_ACTIVATION marca los roles donde la policy de activación no requiere autenticación multifactor.

PA_PIM_NO_JUSTIFICATION marca los roles donde la activación no requiere justificación de negocio.

PA_PIM_LONG_ACTIVATION marca los roles configurados con una duración máxima de activación lo bastante larga como para extender materialmente la exposición tras una activación comprometida.

ℹ️

ℹ️ Nota: EtcSec comprueba automáticamente esta vulnerabilidad en cada auditoría Azure. Ejecute una auditoría gratuita para verificar su entorno.

Controles Relacionados

El endurecimiento de la activación PIM es una capa del control de acceso privilegiado. Revíselo junto con Acceso privilegiado Azure: roles, PIM y administracion permanente para saber si PIM está desplegado y el número de admins permanentes está bajo control, Cuentas de Acceso de Emergencia Break Glass Entra ID: Ausentes, Sin Supervisar, Sin Excluir antes de exigir aprobación en los roles Tier-0, Identidad Azure: MFA, metodos y Security Defaults para el punto ciego de reautenticación que el MFA en la activación por sí solo no cierra, y Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica para la checklist completa de revisión de identidad en la que encaja este tema.