Qué vas a conseguir
Que nadie del equipo de IT de la sede tenga privilegios de administración encendidos todo el día, y que aun así puedan resolver una incidencia antes de la apertura de mercado. En una entidad regulada, la pregunta de auditoría no es solo quién puede administrar, sino quién lo hizo, cuándo, por qué y con qué ticket. PIM responde a las cuatro si lo configuras pensando en cómo trabaja la sede, no solo en el tenant.
La configuración del tenant, los administradores globales y las cuentas de emergencia están en la guía de Microsoft 365: Global Admin y PIM. Aquí va el ángulo de la sede: el técnico local, el horario de mercado y la evidencia que se entrega cada trimestre.
Antes de empezar
- Licencias Microsoft Entra ID P2 o Microsoft Entra ID Governance para los usuarios que van a tener roles elegibles y para los revisores.
- Cuentas de administración separadas de las de uso diario (por ejemplo
adm-javier.ruiz), con MFA resistente a phishing. - Acordado con seguridad y cumplimiento quién aprueba qué, y un responsable de guardia que pueda aprobar fuera de horario.
1. De roles permanentes a roles elegibles
El punto de partida suele ser un técnico de la sede con Intune Administrator, User Administrator y Exchange Administrator activos desde hace años. Pásalos a elegibles: el rol existe, pero hay que activarlo cuando se necesita.
| Rol | Uso en la sede | Duración máxima | Al activar |
|---|---|---|---|
| Helpdesk Administrator | Resetear contraseñas, sesiones | 8 h | MFA, justificación |
| Authentication Administrator | Resetear métodos de MFA | 4 h | MFA, ticket |
| Intune Administrator | Equipos, aplicaciones, perfiles | 4 h | MFA, ticket |
| Exchange Administrator | Buzones compartidos, reglas | 2 h | MFA, ticket, aprobación |
| Security Administrator | Solo con incidente abierto | 2 h | MFA, ticket, aprobación |
- Asigna los roles con unidades administrativas cuando sea posible: el técnico de Madrid administra los usuarios y equipos de Madrid, no los de toda la organización.
- Las asignaciones elegibles caducan (por ejemplo a los 12 meses) y se renuevan en la revisión. Una asignación permanente es la que nadie vuelve a mirar.
2. La activación: ticket, justificación y aprobación
En ID Governance › Privileged Identity Management › Microsoft Entra roles › Settings, cada rol tiene su configuración. Para la sede, lo útil es:
- Ticket obligatorio: el campo es informativo (PIM no lo valida contra tu herramienta), pero queda en el registro de auditoría junto a la activación. El revisor puede cruzar cada activación con su ticket.
- Contexto de autenticación en lugar de solo MFA: así exiges que la activación se haga desde un equipo conforme y con un método fuerte, aunque el técnico ya hubiera hecho MFA al iniciar sesión.
- Aprobación solo donde tiene sentido. Si todo requiere aprobación, a las 7:30 nadie trabaja. Con al menos dos aprobadores por rol, y uno de ellos el responsable de guardia.
3. PIM para grupos: servidores y aplicaciones de la sede
Muchos permisos de la sede no son roles de Entra: administrador de los servidores locales, acceso a la consola de una aplicación de negocio, permisos de soporte en la plataforma de trading. Para eso está PIM para grupos.
- Crea grupos de seguridad en la nube con nombre claro, por ejemplo
PIM-MAD-ServerAdminsoPIM-APP-SoporteTrading. Los grupos sincronizados desde AD no se pueden gestionar con PIM para grupos. - Actívalos en Privileged Identity Management › Groups y añade a los técnicos como miembros elegibles.
- Para aplicaciones con SSO en Entra, asigna el grupo a la aplicación: solo quien ha activado la pertenencia entra con permisos de soporte.
- Para servidores en AD, el grupo se aprovisiona a AD (Entra Cloud Sync, aprovisionamiento de grupos a AD) y ese grupo de AD es el que tiene permisos en los servidores.
Hay retraso: la pertenencia tarda lo que tarde el ciclo de sincronización en llegar a AD, y el técnico tiene que cerrar sesión o renovar su ticket Kerberos para que cuente. Explícalo antes de que alguien abra un ticket diciendo que PIM no funciona.
4. El ticket: "no puedo activar mi rol durante una incidencia a las 7:30"
Martes, 7:30. Un grupo de puestos de la sala no recibe una configuración de Intune y el mercado abre a las 9:00. Javier, técnico de la sede, intenta activar Intune Administrator y no puede.
- ¿Qué ve exactamente? No es lo mismo "no me aparece el rol" que "está pendiente de aprobación" o "me pide verificación y falla".
- El rol no aparece en My roles: la asignación elegible ha caducado. Compruébalo:
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"$u = Get-MgUser -Filter "displayName eq 'adm-javier.ruiz'"Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -Filter "principalId eq '$($u.Id)'" -ExpandProperty RoleDefinition | Select-Object @{n='Role';e={$_.RoleDefinition.DisplayName}}, StartDateTime, EndDateTimeRole StartDateTime EndDateTime---- ------------- -----------Helpdesk Administrator 01/11/2025 09:00:00 01/11/2026 09:00:00Authentication Administrator 01/11/2025 09:00:00 01/11/2026 09:00:00Intune Administrator no está: venció la semana pasada y nadie la renovó. Un administrador con rol suficiente (Privileged Role Administrator, activado) crea de nuevo la asignación elegible, con el ticket de la incidencia como justificación.
- Pendiente de aprobación: los aprobadores están en otra zona horaria o aún no han empezado. Por eso el responsable de guardia está en la lista de aprobadores; si no lo está, se le añade después, no ahora.
- Falla la verificación: el contexto de autenticación exige un equipo conforme y Javier está en un portátil que ha dejado de serlo. Que active desde su equipo habitual.
- Activado, pero el portal no le deja: el portal guarda la sesión anterior. Cerrar sesión y volver a entrar, o esperar unos minutos.
Después de la incidencia, revisa por qué venció una asignación sin aviso: la renovación tiene que estar en el calendario de revisiones, no en la memoria de alguien.
5. Revisiones trimestrales como evidencia de auditoría
En ID Governance › Privileged Identity Management › Microsoft Entra roles › Access reviews (y lo mismo para grupos), crea una revisión recurrente:
- Frecuencia: trimestral, alineada con el calendario de controles que revisa auditoría interna.
- Alcance: asignaciones elegibles y activas de los roles y grupos de la sede.
- Revisores: el responsable de IT de la sede, o el responsable de cada técnico. Nunca el propio técnico revisándose a sí mismo.
- Al terminar: aplicar resultados automáticamente y, si el revisor no responde, quitar el acceso.
Al cerrar cada revisión, descarga los resultados y guárdalos junto al registro de activaciones del trimestre (Privileged Identity Management › Microsoft Entra roles › Resource audit). Eso es lo que se entrega: quién tenía qué, quién lo revisó, qué se quitó y cada activación con su ticket.
6. Lo que revisas cada mes
- Asignaciones activas permanentes que hayan aparecido fuera de PIM: deberían ser solo las de emergencia.
- Asignaciones elegibles que vencen en los próximos 30 días.
- Activaciones sin ticket o con justificaciones vacías del tipo "soporte".
Siguientes pasos
- La guía de Microsoft 365: Global Admin y PIM cubre la configuración del tenant, los administradores globales y las cuentas de emergencia.
- La guía de Entra ID: Conditional Access explica cómo crear el contexto de autenticación que se exige al activar.
- La guía de ISO 27001/NIS2/RGPD en IT ayuda a encajar estas revisiones en el sistema de controles.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.
Apúntate y llévate las 33 ideas →