Microsoft Security · Acceso privilegiado

PIM en Microsoft Entra: validar activación, aprobación y caducidad de roles

Configurar PIM en Microsoft Entra no termina al convertir una asignación permanente en elegible. La prueba decisiva llega cuando un administrador necesita trabajar, otro debe aprobar y el privilegio tiene que desaparecer al concluir la ventana. Si ese ciclo no se ensaya, el proyecto puede reducir permisos sobre el papel y crear nuevas dependencias operativas.

Esta guía propone una validación operativa de Privileged Identity Management. Se centra en roles de Microsoft Entra y señala las diferencias con roles de recursos Azure. Los ejemplos de duración, pruebas y organización son criterios de diseño que debe adaptar a su empresa. No constituyen una configuración universal ni sustituyen la revisión del alcance de cada rol.

PIM Microsoft Entra: empiece por una tarea concreta

La pregunta inicial no debería ser qué administradores pasan a PIM, sino qué tareas necesitan privilegios y sobre qué objetos. Restablecer un método de autenticación, modificar una aplicación o administrar Exchange son responsabilidades diferentes. Si todo se resuelve con Global Administrator, PIM limita el tiempo de exposición, pero conserva un alcance excesivo para muchas tareas habituales.

Documente la tarea, el rol mínimo, la persona que lo necesita y el ámbito aplicable. Revise asignaciones directas y las que llegan a través de grupos u otras vías. Convertir una asignación en elegible no elimina automáticamente permisos equivalentes existentes. La prueba inicial debe comprobar que la cuenta no conserva acceso por una ruta que queda fuera del piloto.

Distinga elegibilidad, activación y asignación activa. La elegibilidad permite solicitar un rol. La activación hace que el privilegio esté disponible durante una ventana. Una asignación activa permanente mantiene el acceso sin ese ciclo. El inventario necesita indicar qué modelo corresponde a cada caso y por qué. Esa decisión determina qué pruebas son útiles y qué riesgo sigue existiendo.

Microsoft Entra y Azure no comparten todo el alcance

Un rol de directorio en Microsoft Entra y un rol sobre una suscripción o un grupo de recursos Azure protegen recursos distintos. Los ajustes de PIM para roles Azure se definen por rol y recurso. No interprete una política bien configurada en el directorio como prueba de que las suscripciones tienen el mismo control. Valide cada ámbito que forme parte del proyecto.

Si la necesidad real es acceso temporal a un grupo, revise PIM for Groups como un escenario separado. Sus efectos dependen de para qué se utiliza el grupo. Pertenecer temporalmente a un grupo que concede acceso a una aplicación requiere probar también esa aplicación y su evaluación de permisos. El nombre PIM no hace idénticos todos los modelos de autorización.

Prepare un piloto sin perder capacidad administrativa

Seleccione un rol acotado y una tarea que pueda verificarse con seguridad. Utilice una cuenta administrativa separada del usuario cotidiano y un entorno o recurso preparado para la prueba. Establezca quién supervisará la ventana y quién puede restaurar el acceso si aparece un problema. La revisión de privilegios no debe depender de una sola persona que también necesita activar el rol.

Verifique antes el licenciamiento. PIM requiere Microsoft Entra ID P2 o Microsoft Entra ID Governance en los escenarios cubiertos por estas licencias, y la cobertura debe considerar a los usuarios elegibles y los aprobadores correspondientes. No cuente únicamente a quien administra el portal. Para comparar opciones, consulte nuestra guía de Entra P1, P2 y Entra Suite.

Prepare una línea base de asignaciones. Guarde los identificadores y ámbitos necesarios, sin incluir credenciales, y señale qué cambios forman parte del piloto. Esto permite comprobar la reducción real del acceso y facilita una reversión ordenada. No mezcle la prueba de PIM con una limpieza masiva de roles, grupos y aplicaciones que impida identificar la causa de un fallo.

Revise la disponibilidad de cuentas de emergencia y su custodia. No convierta todas las cuentas capaces de recuperar la administración en elegibles con aprobaciones que nadie puede resolver. Las cuentas de emergencia tienen una finalidad específica y necesitan controles propios. La documentación oficial de Microsoft debe orientar ese diseño, incluido el seguimiento de su uso y las pruebas periódicas.

Configure cada rol con una razón operativa

Los ajustes de activación pueden incluir duración máxima, autenticación, justificación y aprobación. Defina la duración según la tarea, su impacto y la capacidad de supervisarla. Una ventana mínima que obliga a reactivar continuamente no siempre mejora la operación. Una ventana amplia por comodidad deja el privilegio disponible más tiempo del necesario. Ensaye el trabajo habitual antes de fijar el límite.

La justificación debe permitir comprender para qué se activó el rol. Evite textos repetidos como «trabajo» o «mantenimiento» cuando el objetivo es poder revisar decisiones. Proponga ejemplos concretos que indiquen tarea, recurso y referencia. El equipo no necesita redactar un informe para cada activación, pero sí dejar información que otra persona pueda interpretar después.

El campo de ticket aporta contexto, pero no equivale a una integración que comprueba automáticamente si existe o está aprobado. Si su proceso exige autorización en una herramienta de gestión, defina cómo se verificará esa relación. No presente una referencia escrita como una validación técnica que PIM no realiza por sí mismo.

Pruebe la activación con el trabajo que realmente se realiza

Empiece con la cuenta elegible sin activar el rol. Intente una operación segura que requiera ese permiso y documente el rechazo esperado. Si la operación funciona, investigue antes de continuar. Puede existir otra asignación, una pertenencia a grupo o un ámbito distinto del supuesto. Un piloto que parte de permisos mal identificados no demuestra la eficacia de PIM.

Solicite después la activación con duración y justificación conocidas. Confirme el rol y el ámbito en la solicitud antes de enviarla. Cuando intervenga una aprobación, no interprete «solicitud enviada» como «privilegio disponible». Revise su estado, espere la decisión y compruebe el acceso desde la sesión y herramienta que se utilizarán durante el trabajo real.

Una activación puede requerir renovar la sesión o esperar a que el servicio reconozca la nueva autorización. Registre el tiempo observado y la forma de recuperar el acceso correcto. No prometa una actualización instantánea en todos los portales y aplicaciones. Si el equipo termina activando un rol más amplio para evitar esa espera, el procedimiento necesita ajustes antes de ampliarse.

La aprobación debe aportar una decisión

Seleccione aprobadores que conozcan el impacto de la tarea y puedan estar disponibles. Nombrar a un directivo que nunca revisa solicitudes crea un cuello de botella. Prepare un suplente y un canal de aviso conocido. Para roles de Microsoft Entra, Microsoft documenta una ventana de aprobación de veinticuatro horas. No confunda ese plazo del servicio con el tiempo de respuesta que necesita su negocio.

La aprobación se resuelve por la primera decisión de un aprobador, y el solicitante no puede aprobar su propia petición. Por tanto, elegir varias personas no significa exigir varias aprobaciones consecutivas. Si su proceso necesita un control adicional, diseñe cómo se obtiene y conserva. Compruebe el modelo efectivo en lugar de asumir que el número de nombres refleja el número de autorizaciones requeridas.

Ensaye un rechazo con una solicitud preparada para ese fin. Confirme qué ve el usuario, cómo corrige la petición y qué registro queda. Después pruebe la ausencia del aprobador principal. El objetivo no es forzar un incidente, sino comprobar que el equipo puede continuar el proceso sin convertir una urgencia en una asignación permanente improvisada.

Compruebe la caducidad sin prometer que deshace el trabajo

Al concluir la ventana, confirme el estado del rol y repita una operación segura que requiera privilegio. Hágalo desde un contexto adecuado y documente las características del servicio utilizado. La expiración de una asignación no debe describirse como una garantía de cierre inmediato de cualquier sesión, token o proceso. La autorización efectiva necesita comprobarse en la herramienta concreta.

La caducidad tampoco revierte cambios ya realizados. Si durante la ventana se creó una cuenta, se modificó una aplicación o se concedió otro permiso, ese resultado puede persistir. PIM limita la disponibilidad del rol, pero no sustituye el control de cambios. Incluya una revisión de lo ejecutado y, cuando corresponda, una tarea separada para retirar accesos creados durante el trabajo.

Pruebe además la desactivación voluntaria al terminar antes del límite. El operador debe conocer cómo cerrar la ventana y cómo verificar el resultado. Ese hábito evita mantener privilegios disponibles por inercia. El procedimiento debería indicar también qué hacer cuando la tarea dura más de lo previsto: nueva evaluación, otra solicitud y comunicación del impacto, en lugar de ampliar la duración sin criterio.

Auditoría que permita reconstruir el ciclo

Una captura del rol activo aporta una evidencia parcial. Para reconstruir la actuación hacen falta solicitud, usuario, rol, ámbito, tiempos, justificación y decisión del aprobador cuando exista. Añada la actividad administrativa relevante en el servicio afectado. PIM explica la concesión temporal, pero no sustituye los registros que muestran qué hizo el administrador con ese privilegio.

Revise la retención disponible y el destino de los registros si necesita conservarlos más tiempo. El historial de PIM y la auditoría del servicio no deben asumirse como un archivo ilimitado. Diseñe la conservación antes de necesitar una investigación. Compruebe quién puede consultar los datos y cómo localizar un ciclo concreto sin tener que revisar manualmente todo el tenant.

Al correlacionar eventos, utilice usuario, rol, ámbito y secuencia temporal además de los identificadores disponibles. Algunas operaciones del ciclo pueden procesarse de forma asíncrona. No descarte una relación únicamente porque dos eventos no compartan un identificador. Una investigación rigurosa distingue lo demostrado, lo probable y lo que todavía falta confirmar.

Incidencias habituales y cómo diagnosticarlas

Si el usuario no ve el rol, compruebe primero cuenta, elegibilidad y ámbito. Si ve el rol pero no puede activarlo, revise requisitos, vigencia de la asignación y estado de la solicitud. Si figura activo y la tarea falla, examine autorización efectiva, sesión y permisos específicos de la aplicación. Cambiar a Global Administrator para «probar» puede ocultar el problema en lugar de resolverlo.

Cuando no llega una notificación, abra la solicitud en el portal y revise los destinatarios y la entrega del correo. La ausencia de un mensaje no demuestra que no exista una petición pendiente. Prepare una vía de consulta que no dependa exclusivamente del correo electrónico. Esto resulta especialmente importante si la tarea se relaciona con una incidencia del propio servicio de mensajería.

Las activaciones frecuentes merecen una revisión contextual. Pueden indicar una duración inadecuada, tareas fragmentadas, un rol utilizado para demasiado trabajo o una actividad que debe investigarse. No convierta automáticamente cualquier frecuencia elevada en una conclusión de ataque. Relacione el patrón con la función del operador, sus tickets y las acciones registradas.

Un ejemplo de aceptación del piloto

Imagine un equipo que modifica aplicaciones empresariales con un rol elegible. El piloto demuestra que la cuenta no puede modificar antes de activar, que la solicitud llega al suplente cuando el titular no está y que la tarea se completa dentro de la ventana. Al finalizar, se comprueba el estado del rol y se revisa el cambio efectuado. El resultado valida una operación concreta, no todos los roles del directorio.

Antes de ampliar, acuerde criterios de parada. Un aprobador inaccesible, una cuenta de recuperación que depende del mismo circuito o un permiso equivalente no identificado justifican detener la expansión. Corrija el diseño y repita únicamente las pruebas afectadas. Ampliar para cumplir una fecha puede consolidar un circuito que el equipo tendrá que evitar en la primera urgencia.

Deje un procedimiento mantenible

El cierre debe indicar quién revisa elegibilidades, quién actualiza aprobadores cuando cambia la plantilla y qué ocurre al caducar una asignación. Incluya altas y bajas del equipo técnico, cambios de responsabilidad y tareas de proveedores. Una persona que ya no necesita el rol no debería conservar elegibilidad simplemente porque sus activaciones son temporales.

Prepare una ficha por rol con alcance, tareas permitidas, condiciones de activación, responsables y referencias de evidencia. Manténgala breve y útil para el operador. Añada una revisión periódica de asignaciones permanentes y excepciones. El objetivo de PIM es que los privilegios correspondan a una necesidad concreta y verificable, también después del proyecto inicial.

Un registro de cambios que sirva para soporte

Conserve una lista de decisiones del piloto con el problema observado, su causa confirmada y la corrección aplicada. Incluya las pruebas que debieron repetirse y el responsable que aceptó el resultado. Este registro evita que un futuro administrador revierta un ajuste necesario porque desconoce su origen. También ayuda a distinguir una limitación conocida de una incidencia nueva, sin convertir el procedimiento de activación en un documento demasiado largo para utilizarlo durante el trabajo.

Documentación oficial de referencia

• Ajustes de roles Microsoft Entra
• Ajustes de roles de recursos Azure
• Flujo de aprobación
• Historial de auditoría
• Licenciamiento Microsoft Entra