Microsoft 365: los roles de administración, PIM y las cuentas de emergencia

Qué vas a conseguir

Un tenant donde nadie es administrador global por costumbre. Cada técnico tiene el rol justo para su trabajo, lo activa cuando lo necesita durante un tiempo limitado y dejando rastro, y solo dos cuentas de emergencia tienen el rol de forma permanente. Si roban la contraseña de un técnico un martes cualquiera, el atacante no se lleva el tenant.

Antes de empezar

• Licencias Microsoft Entra ID P2 (incluidas en Microsoft 365 E5 o en Entra ID Governance) para los usuarios que usarán PIM.
• El rol Privileged Role Administrator para configurar PIM (y, al principio, un Global Administrator a mano).
• El módulo Microsoft Graph PowerShell (guía de Graph del Nivel 3).
• Una conversación previa con el equipo: va a cambiar cómo trabajan. Explicar el porqué ahorra muchas quejas.

1. Quién es administrador hoy

›Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"›Get-MgDirectoryRole | ForEach-Object { $r = $_; Get-MgDirectoryRoleMember -DirectoryRoleId $r.Id | ForEach-Object { [pscustomobject]@{ Rol = $r.DisplayName; Miembro = $_.AdditionalProperties.userPrincipalName } } } | Sort-Object Rol | Format-TableRol                          Miembro---                          -------Exchange Administrator       a.vidal@contoso.comGlobal Administrator         admin@contoso.onmicrosoft.comGlobal Administrator         j.serrano@contoso.comGlobal Administrator         m.ortega@contoso.comGlobal Administrator         p.ruiz@contoso.comGlobal Administrator         proveedor.soporte@contoso.comGlobal Administrator         s.navas@contoso.comUser Administrator           l.prado@contoso.com

Seis administradores globales, uno de ellos la cuenta de un proveedor y otro la cuenta con la que se creó el tenant. Es lo normal en un tenant de unos años, y es lo que vas a cambiar.

2. Cada tarea a su rol mínimo

Con esta tabla, casi nadie necesita Global Administrator para su día a día. El proveedor tampoco: se le da un rol concreto mediante GDAP (relaciones de administración delegada con permisos granulares y caducidad) en lugar de una cuenta dentro del tenant.

3. Las dos cuentas de emergencia

• Dos cuentas solo en la nube con el dominio onmicrosoft.com (brk-admin-01, brk-admin-02), sin licencia, sin buzón, sin dependencia de AD local ni de un proveedor de identidad federado.
• Son las únicas con Global Administrator permanente (activo).
• Excluidas de todas las políticas de Conditional Access (guía de Conditional Access del Nivel 3), salvo de una propia que exija su método de autenticación.
• Microsoft exige MFA para entrar en los portales de administración, también a estas cuentas: cada una tiene una llave FIDO2 (passkey) guardada en una caja fuerte, distinta para cada cuenta, y la contraseña larga en un sobre en otra ubicación.
• Cada inicio de sesión con ellas genera una alerta inmediata (guía de Microsoft Sentinel). Se prueban cada tres meses, con un cambio registrado, para saber que funcionan.

4. PIM: elegible en lugar de permanente

Se configuran así los roles más sensibles (Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator). Para roles de menos impacto (Helpdesk, License) basta con MFA y justificación, sin aprobación: si cada reseteo de contraseña espera a un aprobador, la gente buscará atajos.

Después, en Asignaciones › Agregar asignaciones › Elegible, cada técnico recibe sus roles como elegibles y se retiran las asignaciones activas que tenía.

El técnico activa el rol desde Mis roles cuando lo necesita, o con PowerShell:

›$me = (Get-MgUser -UserId "m.ortega@contoso.com").Id›$rol = (Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Exchange Administrator'").Id›$params = @{ Action = "selfActivate"; PrincipalId = $me; RoleDefinitionId = $rol; DirectoryScopeId = "/"; Justification = "CHG-1042 regla de transporte"; ScheduleInfo = @{ StartDateTime = (Get-Date); Expiration = @{ Type = "AfterDuration"; Duration = "PT2H" } } }›New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params | Format-List Status, ActionStatus : ProvisionedAction : selfActivate

Consejo: el contexto de autenticación de Conditional Access (en "Al activar, requerir") es más fuerte que el simple "MFA de Azure": exige que la activación se haga con una llave FIDO2 o Windows Hello, no con un SMS que se puede interceptar.

5. El ticket: "no me deja activar el rol"

6. Revisiones y alertas

• Revisiones de acceso trimestrales de los roles privilegiados (PIM › Revisiones de acceso): cada técnico confirma que sigue necesitando sus roles, o su responsable lo decide; si nadie responde, se retira el acceso.
• Alertas de PIM que revisas cada semana: Demasiados administradores globales, Se asignan roles fuera de Privileged Identity Management, Los administradores no usan sus roles privilegiados.
• Historial de auditoría de PIM: quién activó qué, cuándo, con qué justificación y qué ticket. Es lo que te pedirá un auditor de ISO 27001.

7. Lo que revisas cada mes

• Número de Global Administrator activos: dos (las de emergencia). Si hay más, alguien se asignó el rol fuera de PIM.
• Activaciones sin número de ticket válido o con justificaciones vacías ("necesario", "trabajo").
• Las cuentas de emergencia: sin inicios de sesión salvo las pruebas, llaves en su sitio.
• Las relaciones GDAP de los proveedores: roles concedidos y fecha de caducidad.

Siguientes pasos

• PIM para grupos: grupos con acceso a recursos (por ejemplo, propietarios de una suscripción) que también se activan bajo demanda.
• PIM para recursos de Azure: los roles de suscripción y grupo de recursos con el mismo modelo.
• Unidades administrativas: un técnico de una sede administra solo los usuarios de su sede.
• Estaciones de trabajo con acceso privilegiado (PAW) para las tareas de Global Administrator.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.