Azure AD Premium P2: PIM, Identity Protection y Revisiones de Acceso que Nadie Activó

Azure AD Premium P2: PIM, Identity Protection y Revisiones de Acceso que Nadie Activó

Las funciones de Azure AD Premium P2 — Privileged Identity Management (PIM), Identity Protection y Access Reviews — están bloqueadas detrás de la licencia premium de segundo nivel de Microsoft, pero que se asigne una licencia P2 a un usuario no significa que ninguna de las tres esté realmente configurada en el tenant. Microsoft Entra ID P2 (el nombre actual de Azure AD Premium P2) se sitúa por encima de P1 y está incluido en Microsoft 365 E5, E7, y Enterprise Mobility + Security E5. Como producto independiente, tiene un precio de 10 $/usuario/mes (precios de Microsoft Entra). Sobre el papel, es el nivel que todo tenant preocupado por la seguridad debería tener. En la práctica, muchos tenants la tienen asignada a algunos o a todos sus usuarios y no usan casi nada de lo que realmente ofrece.

Esa brecha importa porque estas tres capacidades no son simples extras visuales. Son exactamente lo que Microsoft bloquea detrás del SKU P2 (Microsoft Entra ID Governance puede sustituir a algunas de ellas, pero P2 es el camino más habitual). Si estás pagando la licencia y ninguna de las tres está configurada, estás pagando por una capacidad que no usas, mientras tu postura real de acceso privilegiado y riesgo sigue siendo idéntica a la de un tenant P1 — consulta cómo auditar la seguridad de Microsoft Entra ID para la base completa en la que encajan las comprobaciones de este artículo.

Según la propia referencia de licencias de Microsoft, tres capacidades concretas requieren P2 (o Entra ID Governance) y simplemente no están disponibles — no degradadas, no disponibles — por debajo de ese nivel: las políticas de Acceso Condicional basadas en riesgo (riesgo de inicio de sesión y riesgo de usuario), Privileged Identity Management tanto para roles de Entra como para roles de recursos de Azure, y la generación actual de Access Reviews (Licencias de Microsoft Entra — Microsoft Learn). Este artículo repasa cómo funciona cada una, qué aspecto tiene "configurado" sobre el papel frente a la realidad del tenant, y cómo detectar y cerrar la brecha.

Cómo funciona realmente cada función de P2

Privileged Identity Management (PIM)

El modelo de PIM distingue entre asignación de rol "elegible" y "activa". Un usuario que se hace elegible para un rol — Global Administrator, por ejemplo — no tiene ningún privilegio permanente. Para usar el rol, debe solicitar una activación, que puede requerir MFA, una justificación o la aprobación de un aprobador designado, y la asignación activa resultante está limitada en el tiempo y expira automáticamente (Microsoft Entra ID Governance — Qué es PIM). Este es el modelo justo a tiempo que elimina el acceso admin permanente como superficie de ataque — consulta Acceso Privilegiado en Azure: Demasiados Administradores Globales para ver lo que realmente cuesta el acceso permanente sin PIM. Las cuentas de emergencia break-glass son la excepción intencionada a este modelo y deben quedar fuera de PIM — consulta Cuentas de Acceso de Emergencia Break-Glass en Entra ID para saber cómo diseñarlas correctamente.

PIM también cubre los roles de recursos de Azure (Owner, Contributor, etc. en cualquier ámbito) y PIM para grupos, donde la elegibilidad para la pertenencia o propiedad de un grupo requiere en sí misma una licencia P2 (o Entra ID Governance) para cada miembro, propietario, aprobador y revisor elegible — no solo para los administradores. Los escenarios de ejemplo de Microsoft hacen concreto el cálculo de licencias: un tenant con 42 administradores gestionados a través de PIM, más 5 aprobadores y 6 revisores implicados en revisiones de privilegios mensuales, necesita 53 licencias, no 42 (Licencias de Microsoft Entra — sección PIM). Los equipos que solo presupuestan P2 para las cuentas admin suelen sublicenciar este punto y acaban con aprobadores o revisores bloqueados silenciosamente.

Identity Protection

Identity Protection puntúa el riesgo de los inicios de sesión y de los usuarios usando detecciones tanto en tiempo real como fuera de línea (post-autenticación) — credenciales filtradas, direcciones IP anónimas, viajes imposibles, propiedades de inicio de sesión inusuales y compromiso confirmado por inteligencia de amenazas, entre otras (Tipos y niveles de detección de riesgo — Microsoft Learn). Las detecciones de riesgo bajo caducan automáticamente a los seis meses; las de riesgo medio y alto persisten hasta que un administrador las corrige o las descarta. La puntuación de riesgo solo se vuelve accionable cuando está conectada a una política de Acceso Condicional de riesgo de inicio de sesión o de riesgo de usuario — sin esa política, Identity Protection genera un informe que nadie mira en lugar de un control automatizado. Consulta Azure Identity Protection: Automatizar la Respuesta a Credenciales Filtradas para ver cómo construir esa política.

Access Reviews

Access Reviews permite que revisores designados (un manager, un propietario de recursos, o los propios usuarios) recertifiquen periódicamente la pertenencia a grupos, el acceso a aplicaciones, las asignaciones de roles elegibles de PIM y el acceso de invitados, en lugar de depender de que alguien recuerde retirar un acceso que ya no se necesita. El nivel de capacidad "anteriormente disponible con carácter general en Microsoft Entra ID P2" es lo que tienen disponible hoy la mayoría de los tenants P2 (Licencias de Microsoft Entra — Access reviews). La licencia sigue a la población revisada, no solo al revisor: la revisión de un grupo de 500 miembros con tres propietarios de grupo como revisores requiere 503 licencias en el ejemplo trabajado por Microsoft — los miembros revisados también necesitan cobertura, no solo las personas que hacen la revisión.

Detección: ¿estás usando realmente lo que pagas?

La asignación de licencias y la configuración de la función son dos preguntas distintas, y el centro de administración de Entra facilita confirmar la primera sin comprobar nunca la segunda. Esto es lo que hay que revisar en cada caso.

Get-MgRoleManagementDirectoryRoleEligibilitySchedule (Microsoft Graph PowerShell SDK) devuelve todas las asignaciones elegibles de PIM en el tenant, por separado de Get-MgRoleManagementDirectoryRoleAssignmentSchedule para las activas/permanentes — comparar ambas listas es la forma más rápida de ver cuántos roles privilegiados pasan realmente por PIM frente a los que siguen siendo concesiones permanentes (Referencia de Microsoft Graph PowerShell).

Remediación: activar lo que ya tienes

1. Migrar las asignaciones privilegiadas permanentes a PIM elegible. En ID Governance → Privileged Identity Management → Roles de Microsoft Entra, revisa cada asignación activa. Para los roles que no necesitan acceso permanente, retira la asignación permanente y crea una elegible con una duración de activación, un requisito de MFA, y (para Global Administrator y roles igualmente sensibles) una aprobación.
2. Activar el Acceso Condicional basado en riesgo. Crea una política de riesgo de inicio de sesión (por ejemplo, exigir MFA en riesgo medio) y una política de riesgo de usuario (por ejemplo, exigir un cambio de contraseña seguro en riesgo alto) en Protection → Acceso Condicional. Sin este paso, Identity Protection sigue siendo un panel, no un control.
3. Activar notificaciones para usuarios de riesgo. Configura el resumen semanal y las alertas de usuarios en riesgo en la configuración de Identity Protection para que el riesgo no sea algo que un administrador tenga que acordarse de revisar.
4. Poner en marcha revisiones de acceso empezando por los ámbitos de mayor valor: las asignaciones de roles elegibles de PIM, los grupos anidados en roles privilegiados y el acceso de invitados — consulta Cuentas de Invitado de Azure: la Superficie de Ataque Olvidada para entender por qué las cuentas de invitado obsoletas suelen ser las peores infractoras. Define una cadencia recurrente (trimestral es un valor por defecto razonable) y asigna propietarios de recursos o managers como revisores en lugar de un único administrador central que no tendrá contexto sobre cada grupo.
5. Revisar el cálculo de licencias antes de escalar. PIM para grupos y Access Reviews requieren ambos una licencia P2 (o Governance) para cada miembro, aprobador y revisor elegible — no solo para los administradores objetivo. Sublicenciar este punto hace que la herramienta deje de cubrir silenciosamente a personas a las que debería cubrir.
6. Verificar frente a un estándar de referencia. Las recomendaciones del CIS Microsoft 365 Foundations Benchmark para PIM y las revisiones de acceso ofrecen un listón concreto y auditable — útil tanto para confirmar que has cerrado la brecha como para justificar el gasto en P2 ante quien lo aprobó.

🚨 Peligro: si una licencia P2 (o Governance) caduca o se retira, PIM no se limita a dejar de aplicar los controles — Microsoft documenta explícitamente que las asignaciones de roles Entra elegibles se eliminan, que cualquier revisión de acceso en curso sobre roles Entra finaliza, y que la configuración de PIM se elimina (Licencias de Microsoft Entra — expiración de licencia de PIM). Las asignaciones de roles permanentes no se ven afectadas por esto, lo que explica exactamente por qué confiar en PIM sin mantener actualizada la cobertura de licencias da una falsa sensación de seguridad.

Cómo lo detecta EtcSec

La auditoría de Azure de EtcSec comprueba AZ_NO_P2_LICENSE (P2 presente en el tenant pero sin usar sus funciones distintivas), AZ_P2_NOT_FULLY_UTILIZED, PA_PIM_NOT_ENABLED y PA_PERMANENT_ADMIN_ASSIGNMENTS para señalar roles privilegiados mantenidos fuera de PIM, RISK_NO_SIGNIN_RISK_POLICY para detectar Identity Protection funcionando sin una política de Acceso Condicional que lo aplique, y AZ_ACCESS_REVIEWS_NOT_CONFIGURED para señalar tenants sin cobertura de revisión de acceso recurrente en roles privilegiados o acceso de invitados.