Auditar el consentimiento de apps OAuth en Microsoft Entra ID

En un tenant de Microsoft Entra ID con la configuración por defecto, cualquier usuario puede aprobar una aplicación de terceros que lea su buzón, y nadie de TI recibe una consulta al respecto. Si nunca ha revisado este ajuste, dé por hecho que ya existen algunas concesiones y audítelas antes de cambiar la política.

Qué permite la configuración por defecto

Un usuario puede dar su consentimiento para que una aplicación lea su propio buzón. No puede conceder a una aplicación acceso sin restricciones de lectura y escritura a todos los archivos de la organización, porque eso requiere un administrador. Microsoft recomienda permitir el consentimiento de usuario únicamente para aplicaciones de un publicador verificado, con el fin de reducir el riesgo de que aplicaciones maliciosas engañen a los usuarios para que concedan acceso.

Además, una concesión no es una contraseña. Con OAuth 2.0 (RFC 6749), la aplicación recibe un token de acceso con un alcance y una vigencia definidos, emitido en lugar de las credenciales del usuario. La concesión es un objeto independiente, y usted tiene que localizarlo y eliminarlo.

Listar lo que se ha concedido

Necesita, como mínimo, el rol Cloud Application Administrator o Application Administrator. En el centro de administración de Microsoft Entra, vaya a Entra ID > Aplicaciones empresariales > Todas las aplicaciones, seleccione la aplicación y abra Permisos. La pestaña Consentimiento del administrador muestra los permisos concedidos para toda la organización. La pestaña Consentimiento del usuario muestra lo que concedieron usuarios o grupos concretos.

El portal funciona aplicación por aplicación, así que para obtener una vista de todo el tenant hace falta un bucle. Los endpoints de Graph de la guía de revocación de Microsoft se limitan cada uno a un único service principal: oauth2PermissionGrants devuelve los permisos delegados y appRoleAssignments devuelve los permisos de aplicación. El siguiente script usa los cmdlets equivalentes y resuelve los ID a nombres, incluidos los roles de aplicación como Mail.Read:

Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

$sps  = Get-MgServicePrincipal -All
$name = @{}
$role = @{}
foreach ($s in $sps) {
  $name[$s.Id] = $s.DisplayName
  foreach ($r in $s.AppRoles) { $role["$($s.Id)|$($r.Id)"] = $r.Value }
}

$rows = @()
foreach ($g in Get-MgOauth2PermissionGrant -All) {
  $rows += [pscustomobject]@{ App=$name[$g.ClientId]; Type="Delegated"
    Resource=$name[$g.ResourceId]; Detail=$g.Scope }
}
foreach ($sp in $sps) {
  $assigned = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All |
    Where-Object { $_.PrincipalType -eq "ServicePrincipal" }
  foreach ($a in $assigned) {
    $rows += [pscustomobject]@{ App=$sp.DisplayName; Type="Application"
      Resource=$name[$a.ResourceId]; Detail=$role["$($a.ResourceId)|$($a.AppRoleId)"] }
  }
}
$rows | Export-Csv consent-audit.csv -NoTypeInformation

Estos scopes proceden de los ejemplos de revocación de Microsoft e incluyen acceso de escritura, que una auditoría de solo lectura no necesita. Solicite scopes más acotados si su tenant lo permite y pruebe el script primero con un conjunto reducido.

Orden de triaje

Este orden es nuestro, no una recomendación de Microsoft. Empiece por las concesiones delegadas cuyos scopes leen o envían correo o leen archivos. Filtre la columna Detail por Mail y Files. Después, revise todos los permisos de aplicación.

Una concesión maliciosa tiene un aspecto normal en el portal, con un nombre verosímil y unos pocos scopes. El patrón que hay que buscar es el de varios usuarios que dan su consentimiento a la misma aplicación desconocida, de un publicador que usted no puede verificar. Si encuentra uno, trátelo como un incidente e involucre a nuestro equipo de respuesta a incidentes o al suyo propio.

Eliminar las concesiones de riesgo

Para los permisos concedidos por administradores, abra la pestaña Consentimiento del administrador, seleccione el control ... junto al permiso y elija Revocar permiso. En el portal no puede revocar nada desde la pestaña Consentimiento del usuario. Para eso necesita Graph o PowerShell.

En Graph, elimine una concesión delegada por su ID, o quite un permiso de aplicación por el ID de su asignación:

DELETE https://graph.microsoft.com/v1.0/oAuth2PermissionGrants/{id}
DELETE https://graph.microsoft.com/v1.0/servicePrincipals/{resource-servicePrincipal-id}/appRoleAssignedTo/{appRoleAssignment-id}

La página de revocación incluye también scripts de PowerShell que eliminan todos los permisos delegados y de aplicación de una aplicación. Léalos antes de ejecutarlos, porque borran todo lo asociado a ese service principal.

Revocar no impide que un usuario vuelva a aprobar la misma aplicación. Microsoft menciona dos remedios: impedir que la aplicación solicite los permisos mediante consentimiento dinámico, o bloquear por completo el consentimiento de usuario. En el caso de las aplicaciones de terceros no puede cambiar lo que solicitan, así que, en nuestra opinión, el bloqueo es el control que está en sus manos.

Restringir el consentimiento de usuario

Necesita el rol Privileged Role Administrator. El rol Global Administrator solo es necesario si usa el centro de administración, donde el ajuste está en Identidad > Aplicaciones > Aplicaciones empresariales > Consentimiento y permisos > Configuración del consentimiento del usuario.

Entra incluye dos políticas integradas para esto:

La política low depende de que usted clasifique los permisos, que es la forma de elegir qué pueden aprobar los usuarios. Hágalo primero y pruebe después con una cuenta de usuario normal.

Antes de cambiar nada en PowerShell o Graph, obtenga la authorizationPolicy actual. Es posible que su tenant tenga asignadas políticas ManagePermissionGrantsForOwnedResource.*, como la que permite a los desarrolladores gestionar el consentimiento de las aplicaciones que poseen. Manténgalas en la colección o las eliminará. Así se deshabilita el consentimiento de usuario con Graph PowerShell:

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$body = @{
  "permissionGrantPolicyIdsAssignedToDefaultUserRole" = @(
    "managePermissionGrantsForOwnedResource.{other-current-policies}"
  )
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $body

Para permitir en su lugar el consentimiento bajo la política de bajo impacto, añada managePermissionGrantsForSelf.microsoft-user-default-low al PATCH de Graph sobre defaultUserRolePermissions.permissionGrantPoliciesAssigned. Un cambio de política solo afecta a los consentimientos futuros, por lo que las concesiones existentes siguen vigentes hasta que usted las elimine.

Ofrezca a los usuarios una vía para pedir aprobación

Si bloquea el consentimiento sin ofrecer una alternativa, los usuarios buscarán atajos. El flujo de consentimiento de administrador (admin consent workflow) les permite solicitar la aprobación. Un Global Administrator lo activa en Entra ID > Aplicaciones empresariales > Consentimiento y permisos > Configuración del consentimiento del administrador. Establezca "Los usuarios pueden solicitar el consentimiento del administrador para las aplicaciones a las que no pueden dar su consentimiento" en Sí y elija después:

• Revisores: usuarios, grupos o roles. Ser revisor no eleva sus privilegios, así que cada uno debe tener ya los permisos necesarios para conceder el consentimiento a la aplicación solicitada. Solo los Global Administrators pueden aprobar aplicaciones que solicitan roles de aplicación de Microsoft Graph (permisos de aplicación).
• Notificaciones por correo electrónico: si las deshabilita para los revisores, también se deshabilitan las notificaciones a los solicitantes.
• Vigencia de las solicitudes y recordatorios de caducidad: la vigencia es el número de días que una solicitud sigue siendo válida. El primer recordatorio llega aproximadamente a la mitad del plazo, es decir, el día dos en una solicitud de tres días.

Guarde los cambios y espere hasta una hora a que el flujo surta efecto. Un revisor eliminado conserva el acceso a las solicitudes realizadas mientras tuvo el rol. Los nuevos revisores no pueden actuar sobre las solicitudes creadas antes de que se les añadiera.

Los roles integrados de Entra, el RBAC de Exchange y el consentimiento específico de recurso (resource-specific consent) de Teams también pueden conceder acceso, así que inclúyalos en una revisión más amplia.

Por dónde empezar

1. Ejecute el script de inventario y revise por separado las concesiones delegadas y los permisos de aplicación. Marque las aplicaciones que nadie sepa justificar.
2. Revoque las concesiones de riesgo: las consentidas por administradores, en el portal; las consentidas por usuarios, mediante Graph o PowerShell.
3. Lea la authorizationPolicy actual y establezca después el consentimiento de usuario en microsoft-user-default-low con los permisos clasificados, o deshabilítelo, manteniendo las entradas ManagePermissionGrantsForOwnedResource.*.
4. Active el flujo de consentimiento de administrador. Designe revisores cuyos roles puedan conceder el consentimiento a lo que van a pedir los usuarios y mantenga entre ellos a un Global Administrator, porque solo ese rol aprueba los permisos de aplicación de Microsoft Graph.
5. Repita la revisión de forma periódica. Si le falta tiempo, nuestro equipo de consultoría puede llevarla a cabo como una evaluación, y nuestro servicio gestionado de seguridad puede encargarse de la monitorización.