Auditer les consentements OAuth dans Microsoft Entra ID

Dans un tenant Microsoft Entra ID configuré par défaut, n'importe quel utilisateur peut approuver une application tierce qui lit sa boîte mail, sans que personne à l'IT ne soit sollicité. Si vous n'avez jamais passé ce paramètre en revue, partez du principe que des autorisations existent déjà et auditez-les avant de modifier la politique.

Ce que permet la configuration par défaut

Un utilisateur peut consentir à ce qu'une application lise sa propre boîte mail. Il ne peut pas donner à une application un accès illimité en lecture et en écriture à tous les fichiers de l'organisation, car cela exige un administrateur. Microsoft recommande de n'autoriser le consentement utilisateur que pour les applications issues d'un éditeur vérifié (verified publisher), afin de réduire le risque que des applications malveillantes piègent des utilisateurs pour obtenir un accès.

Une autorisation (grant) n'est pas non plus un mot de passe. Avec OAuth 2.0 (RFC 6749), l'application reçoit un jeton d'accès avec un périmètre (scope) et une durée de vie définis, émis à la place des identifiants de l'utilisateur. L'autorisation est un objet à part entière, que vous devez trouver et supprimer.

Lister ce qui a été accordé

Vous avez besoin au minimum du rôle Cloud Application Administrator ou Application Administrator. Dans le centre d'administration Microsoft Entra, allez dans Entra ID > Enterprise apps > All applications, sélectionnez l'application et ouvrez Permissions. L'onglet Admin consent affiche les permissions accordées pour toute l'organisation. L'onglet User consent affiche ce que des utilisateurs ou des groupes précis ont accordé.

Le portail fonctionne application par application : pour obtenir une vue sur l'ensemble du tenant, il faut donc une boucle. Les endpoints Graph décrits dans le guide de révocation de Microsoft sont limités chacun à un seul service principal : oauth2PermissionGrants renvoie les permissions déléguées et appRoleAssignments renvoie les permissions d'application. Le script ci-dessous utilise les cmdlets équivalentes et résout les ID en noms, y compris pour les rôles d'application comme 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

Ces scopes proviennent des exemples de révocation de Microsoft et incluent un accès en écriture, dont un audit en lecture seule n'a pas besoin. Demandez des scopes plus restreints si votre tenant le permet, et testez d'abord le script sur un petit échantillon.

Ordre de tri

Cet ordre est le nôtre, il ne vient pas de Microsoft. Commencez par les autorisations déléguées dont les scopes lisent ou envoient des e-mails, ou lisent des fichiers. Filtrez la colonne Detail sur Mail et Files. Passez ensuite en revue toutes les permissions d'application.

Une autorisation malveillante a l'air ordinaire dans le portail : un nom plausible et quelques scopes. Le schéma à repérer est celui de plusieurs utilisateurs qui consentent à la même application inconnue, issue d'un éditeur que vous ne pouvez pas vérifier. Si vous en trouvez une, traitez-la comme un incident et impliquez notre équipe de réponse à incident ou la vôtre.

Supprimer les autorisations risquées

Pour les permissions accordées par des administrateurs, ouvrez l'onglet Admin consent, sélectionnez le contrôle ... à côté de la permission et choisissez Revoke permission. Il est impossible de révoquer quoi que ce soit depuis l'onglet User consent dans le portail. Pour cela, il faut passer par Graph ou PowerShell.

Dans Graph, supprimez une autorisation déléguée par son ID, ou retirez une permission d'application par l'ID de son affectation :

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

La page sur la révocation propose aussi des scripts PowerShell qui suppriment toutes les permissions déléguées et d'application d'une application. Lisez-les avant de les exécuter, car ils retirent tout ce qui est associé à ce service principal.

Révoquer n'empêche pas un utilisateur d'approuver à nouveau la même application. Microsoft cite deux remèdes : empêcher l'application de demander les permissions par consentement dynamique, ou bloquer entièrement le consentement utilisateur. Pour les applications tierces, vous ne pouvez pas modifier ce qu'elles demandent ; à notre avis, le blocage est donc le contrôle que vous maîtrisez.

Restreindre le consentement utilisateur

Vous avez besoin du rôle Privileged Role Administrator. Le rôle Global Administrator n'est requis que si vous passez par le centre d'administration, où le paramètre se trouve sous Identity > Applications > Enterprise apps > Consent and permissions > User consent settings.

Entra fournit deux politiques intégrées pour cela :

La politique low dépend de la classification que vous faites des permissions : c'est ainsi que vous choisissez ce que les utilisateurs peuvent approuver. Faites-le en premier, puis testez avec un compte utilisateur ordinaire.

Avant de modifier quoi que ce soit en PowerShell ou via Graph, récupérez l'authorizationPolicy actuelle. Votre tenant peut avoir des politiques ManagePermissionGrantsForOwnedResource.* affectées, comme celle qui permet aux développeurs de gérer le consentement des applications dont ils sont propriétaires. Conservez-les dans la collection, sinon vous les supprimerez. Voici comment désactiver le consentement utilisateur avec Graph PowerShell :

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

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

Pour autoriser plutôt le consentement sous la politique à faible impact, ajoutez managePermissionGrantsForSelf.microsoft-user-default-low au PATCH Graph de defaultUserRolePermissions.permissionGrantPoliciesAssigned. Un changement de politique n'affecte que les consentements futurs : les autorisations existantes restent en place tant que vous ne les supprimez pas.

Offrir aux utilisateurs un moyen de demander

Si vous bloquez le consentement sans alternative, les utilisateurs chercheront des contournements. Le workflow de consentement administrateur (admin consent workflow) leur permet de demander une approbation à la place. Un Global Administrator l'active sous Entra ID > Enterprise apps > Consent and permissions > Admin consent settings. Réglez « Users can request admin consent to apps they are unable to consent to » sur Yes, puis choisissez :

• Reviewers : des utilisateurs, des groupes ou des rôles. Être reviewer n'élève pas leurs privilèges : chacun doit déjà détenir les permissions nécessaires pour accorder le consentement à l'application demandée. Seuls les Global Administrators peuvent approuver les applications qui demandent des rôles d'application Microsoft Graph (permissions d'application).
• Notifications par e-mail : si vous les désactivez pour les reviewers, les notifications aux demandeurs sont désactivées aussi.
• Durée de vie des demandes et rappels d'expiration : la durée de vie correspond au nombre de jours pendant lesquels une demande reste valide. Le premier rappel arrive à peu près à mi-parcours, soit le deuxième jour pour une demande de trois jours.

Enregistrez, puis comptez jusqu'à une heure pour que le workflow prenne effet. Un reviewer retiré conserve l'accès aux demandes effectuées pendant qu'il détenait le rôle. Les nouveaux reviewers ne peuvent pas traiter les demandes créées avant leur ajout.

Les rôles intégrés d'Entra, Exchange RBAC et le consentement spécifique aux ressources de Teams (resource-specific consent) peuvent aussi donner accès : incluez-les dans une revue plus large.

Par où commencer

1. Exécutez le script d'inventaire et passez en revue séparément les autorisations déléguées et les permissions d'application. Marquez les applications que personne ne sait justifier.
2. Révoquez les autorisations risquées : celles accordées par un administrateur dans le portail, celles accordées par les utilisateurs via Graph ou PowerShell.
3. Lisez l'authorizationPolicy actuelle, puis réglez le consentement utilisateur sur microsoft-user-default-low avec des permissions classées, ou désactivez-le, en conservant les entrées ManagePermissionGrantsForOwnedResource.*.
4. Activez le workflow de consentement administrateur. Désignez des reviewers dont les rôles peuvent accorder le consentement pour ce que les utilisateurs demanderont, et gardez parmi eux un Global Administrator, car seul ce rôle approuve les permissions d'application Microsoft Graph.
5. Répétez la revue à intervalles réguliers. Si le temps vous manque, notre équipe de conseil peut la réaliser sous forme d'évaluation, et notre service de sécurité managée peut assurer la surveillance.