PIM en Microsoft 365: por qué los administradores permanentes son tu mayor brecha

La brecha que casi nadie audita

Hay un control de seguridad que rara vez aparece en una RFP, casi nunca en una propuesta de un integrador, y prácticamente nunca en una auditoría de PyME mexicana. Y sin embargo, es el primer hallazgo que cualquier auditor serio de CNBV, INAI o SAT marca cuando entra a un tenant de Microsoft 365:

El administrador permanente.

La cuenta del Global Administrator que está asignada hace 18 meses, que ya nadie revisa, que sigue activa 24/7, que tiene MFA pero no JIT (Just-In-Time), y que un atacante con un solo phishing exitoso puede usar para borrar toda la organización en menos de cinco minutos.

No es una brecha hipotética. Es la configuración por defecto. Y es lo que NIST CSF v2.0 (función PR — Protect, categoría AC-4) y la familia ISO/IEC 27001:2022 Annex A 8.2 ahora explícitamente clasifican como "no aceptable" para cualquier organización que maneje datos sensibles.

Por qué esto cambió en los últimos 24 meses

Hasta hace poco, "tener MFA en el Global Admin" era considerado suficiente. Ya no.

El detonador regulatorio

• NIST CSF v2.0 (publicado febrero 2024): la función "Protect" ahora exige separar identidad de privilegio. La autorización debe ser temporal, justificada y auditada — no permanente.
• ISO/IEC 27001:2022 Annex A 8.2: derechos de acceso privilegiado. Requiere asignación bajo demanda con revisión periódica documentada. La revisión "anual" del listado de admins ya no califica.
• Circular Única de Bancos (CNBV): para instituciones financieras mexicanas, la segregación de funciones privilegiadas es obligatoria. Un Global Admin permanente es por definición segregación incompleta.
• LFPDPPP Art. 19 + reforma de habeas data 2024: las medidas de seguridad para datos personales deben ser "razonables" — concepto que INAI ya está calibrando con el estándar internacional. Un admin permanente con acceso a buzones de empleados no resiste el test de razonabilidad.

La otra mitad: la realidad operativa

No es solo regulatorio. Las víctimas reales de los ataques que llegan a portada — desde Lapsus$ hasta los ransomware de doble extorsión que golpearon a empresas mexicanas en 2024-2025 — tenían en común que el atacante consiguió un Global Admin token y lo usó como llave maestra. En cada uno de esos casos, si el admin hubiera sido elegible (PIM-eligible) en lugar de activo permanente, la cadena de ataque se habría detenido en la activación.

Cómo funciona Privileged Identity Management

Microsoft Entra Privileged Identity Management (PIM) cambia el modelo de "rol asignado" a "rol elegible":

1. Asignación elegible: el usuario está autorizado a ASUMIR el rol, pero no lo tiene activo.

2. Activación bajo demanda: el usuario solicita el rol cuando lo necesita. La solicitud puede requerir MFA, justificación escrita, ticket asociado, y aprobación de otro admin.

3. Duración acotada: la activación dura un periodo definido — típicamente 1 a 8 horas, después del cual el rol se desactiva automáticamente.

4. Auditoría completa: cada activación queda registrada con timestamp, justificación, IP, dispositivo y session ID.

El resultado: el atacante que roba credenciales de un Global Admin elegible no obtiene poder. Obtiene la capacidad de SOLICITAR poder, lo cual dispara MFA, justificación y posible aprobación — y en el camino, dispara también las alertas de detección.

Los 7 roles que no deberían estar activos hoy

No todos los roles administrativos requieren el mismo tratamiento. Estos son los siete que merecen conversión a elegible inmediata:

1. Global Administrator — control total del tenant. Acceso permanente nunca se justifica.

2. Privileged Role Administrator — puede asignar otros roles privilegiados. Permanente equivale a una llave que multiplica las llaves.

3. Security Administrator — gestiona políticas de seguridad. Si está comprometido, puede deshabilitar la detección que detectaría su propio compromiso.

4. Exchange Administrator — acceso completo a buzones. Acceso permanente significa exfiltración silenciosa indetectable.

5. SharePoint Administrator — acceso completo a documentos. Mismo riesgo, diferente repositorio.

6. User Administrator — puede crear, modificar y deshabilitar cuentas. Permanente significa creación silenciosa de backdoors.

7. Conditional Access Administrator — define las reglas de MFA y dispositivos. Permanente significa que la persona que vigila la puerta puede abrirla a su gusto.

Las cuentas break-glass: la excepción que sí defiendes

Hay un caso legítimo de admin permanente: la cuenta de emergencia (break-glass). Si PIM, MFA o el directorio fallan, alguien tiene que poder entrar al tenant para restaurar el servicio. Esta cuenta:

• Es exclusivamente cloud-only (no sincronizada con AD on-premises).
• Tiene credenciales largas, almacenadas físicamente en una caja fuerte.
• Está excluida de la política de Conditional Access que exige MFA, porque el escenario para el que existe es justamente cuando MFA no funciona.
• Genera una alerta automática a CISO + CEO cada vez que se usa.
• Se rota semestralmente.

Mantener dos cuentas break-glass por tenant es la práctica estándar. Documentarlas explícitamente en el risk register es la diferencia entre una excepción auditada y un admin olvidado.

Implementación en 30 días sin romper la operación

Convertir 8-15 admins permanentes a elegibles parece riesgoso. Hecho con orden, no lo es:

Semana 1: descubrimiento

• Listar todos los assignments activos en PIM > Microsoft Entra roles.
• Identificar quién usa cada rol semanalmente vs. mensualmente vs. nunca.
• Documentar las cuentas break-glass actuales (típicamente las hay, sin etiqueta formal).

Semana 2: configuración del modelo

• Configurar role settings: máximo de 8 horas de activación, MFA obligatorio, justificación obligatoria, aprobación requerida para Global Admin.
• Crear el grupo de aprobadores (mínimo 2 personas, idealmente CISO + CEO o CISO + responsable de TI).
• Habilitar notificaciones a los aprobadores y al equipo de seguridad para cada activación de rol crítico.

Semana 3: piloto

• Convertir 2-3 admins de bajo impacto (User Administrator, SharePoint Administrator) a elegibles.
• Recolectar feedback operativo durante 5 días hábiles.
• Ajustar duración máxima si la operación lo justifica.

Semana 4: corte general

• Convertir los 7 roles críticos a elegibles para todos los usuarios excepto las 2 break-glass.
• Comunicar el cambio con 72h de anticipación al equipo de TI.
• Hacer un dry-run con cada admin: que active el rol, ejecute una tarea típica, y desactive.

A día 30 ya tienes el modelo en producción.

Las trampas comunes

Privilege creep

Después de 3-6 meses, alguien aprueba activaciones permanentes "para no interrumpir." En 12 meses estás de vuelta donde empezaste. La revisión trimestral de assignments elegibles es obligatoria, no opcional.

Cuentas de servicio

Algunos integradores resuelven necesidades de automatización con un Global Admin de servicio "porque no se puede activar PIM en una cuenta no humana". Eso es falso: usa Managed Identities o service principals con least-privilege, nunca una identidad humana de servicio.

MFA bypass por excepciones

Si la política de Conditional Access excluye al rango de IPs corporativas de MFA, la activación de PIM desde la oficina no requerirá MFA. El atacante que entra por VPN está dentro del rango. Conditional Access debe exigir MFA en cada activación, sin excepciones por red.

Reportería falsa

Los reportes "everything is fine" en algunos dashboards de seguridad muestran solo si los roles tienen MFA, no si están elegibles vs activos. Si tu reporte de cumplimiento dice "100% MFA" y tienes admins permanentes, el reporte está midiendo lo que no importa.

Cómo medir el éxito

Tres métricas, revisadas mensualmente:

1. Activaciones elegibles vs activos permanentes: meta = 0 permanentes (excepto break-glass documentadas).

2. Tiempo promedio de activación: si el promedio es más de 4 horas, el modelo está siendo usado para evadir el control. Investiga.

3. Activaciones sin justificación documentada: meta = 0. Si el campo de justificación está vacío en una activación, esa cuenta no debería tener el rol elegible.

Checklist de implementación

• [ ] Listado de admins permanentes documentado (incluye los olvidados)
• [ ] Modelo de PIM configurado con MFA + justificación obligatoria
• [ ] Aprobadores asignados y entrenados (mínimo 2 personas)
• [ ] 2 cuentas break-glass formalmente etiquetadas y rotadas
• [ ] Los 7 roles críticos convertidos a elegibles para todos los usuarios humanos
• [ ] Service principals con least-privilege para automatizaciones (no admins humanos)
• [ ] Conditional Access exige MFA en cada activación, sin excepciones de red
• [ ] Revisión trimestral de assignments elegibles agendada en calendario
• [ ] Alertas de activación de Global Admin enviadas a CISO + CEO
• [ ] Métricas mensuales de activación reportadas al comité de seguridad

Primer paso: conoce tu brecha

Antes de instalar nada, necesitas saber cuántos admins permanentes tienes hoy y qué roles están en riesgo. Nuestro escaneo gratuito evalúa 192 reglas de detección — incluyendo cuentas privilegiadas, configuración de PIM, y políticas de Conditional Access — y entrega el veredicto en minutos.

[Escanea tu tenant gratis →](/scan)

---

Fuentes citadas en este artículo:

• NIST Cybersecurity Framework v2.0 (NIST IR 8531, 2024) — función Protect, categoría PR.AC-4
• ISO/IEC 27001:2022 Annex A 8.2 — Privileged access rights
• CNBV Circular Única de Bancos — Capítulo IV, segregación de funciones
• LFPDPPP (México), Art. 19 — Medidas de seguridad para datos personales
• Microsoft Entra Privileged Identity Management — documentación oficial