Auditer les autorisations OAuth déjà accordées dans Entra ID
Restreindre le consentement des utilisateurs protège l'avenir. Mais les autorisations accordées depuis des années, parfois par des utilisateurs qui ont quitté l'entreprise, restent valides tant que personne ne les révoque. Un audit des autorisations existantes révèle presque toujours des surprises.
Deux types d'autorisations, deux objets
Dans Entra ID, les droits accordés à une application sur une API comme Microsoft Graph prennent deux formes, stockées dans deux objets différents :
| Type | Objet | Portée |
|---|---|---|
| Autorisations déléguées | Octroi d'autorisation OAuth2 (oauth2PermissionGrant) | L'application agit au nom d'un utilisateur connecté, dans la limite des droits de celui-ci. |
| Autorisations d'application | Attribution de rôle d'application (appRoleAssignment) | L'application agit en son nom propre, sans utilisateur, souvent sur l'ensemble du locataire. |
Les autorisations d'application sont généralement les plus puissantes : Mail.Read en mode application donne accès à toutes les boîtes aux lettres de l'organisation, sauf restriction explicite côté Exchange Online.
Consentement individuel ou pour toute l'organisation
Un octroi délégué possède un type de consentement. Principal signifie qu'un utilisateur a consenti pour lui-même. AllPrincipals signifie qu'un administrateur a consenti pour tous les utilisateurs : l'application peut alors agir au nom de n'importe quel membre du locataire qui s'y connecte. Ce sont ces octrois qu'il faut examiner en priorité.
L'inventaire se fait avec Microsoft Graph PowerShell, par exemple Get-MgOauth2PermissionGrant -All pour les autorisations déléguées et Get-MgServicePrincipalAppRoleAssignment pour les autorisations d'application de chaque principal de service. Le portail affiche les mêmes informations application par application, ce qui devient vite fastidieux.
Repérer les applications à risque
Classez les résultats selon quelques critères :
- Autorisations sensibles : lecture ou écriture de courrier, de fichiers sur tout le locataire, de l'annuaire, et surtout les autorisations permettant de gérer les rôles ou d'attribuer d'autres autorisations, comme
RoleManagement.ReadWrite.DirectoryouAppRoleAssignment.ReadWrite.All; - Éditeur : application interne, éditeur vérifié ou application multilocataire inconnue ;
- Activité : une application qui ne s'est plus connectée depuis des mois n'a plus de raison de conserver ses droits ;
- Propriétaire : une application sans responsable identifié ne sera jamais revue ;
offline_access: combiné à d'autres autorisations, il permet à l'application de conserver l'accès sans nouvelle connexion de l'utilisateur.
Consentement illicite. Une application au nom trompeur, publiée par un éditeur inconnu, avec des autorisations de lecture de courrier consenties par quelques utilisateurs seulement, doit être traitée comme un incident potentiel et non comme un simple défaut d'hygiène.
Faire le ménage
La suppression brutale d'autorisations peut casser un processus métier. Une approche progressive limite ce risque :
- Identifier le propriétaire métier et confirmer l'usage de l'application.
- Pour une application douteuse, désactiver d'abord la connexion du principal de service : l'effet est réversible et révèle rapidement les dépendances.
- Supprimer les octrois ou attributions superflus, par exemple avec
Remove-MgOauth2PermissionGrant, puis ré-accorder uniquement les autorisations nécessaires. - En cas de compromission suspectée, révoquer aussi les sessions des utilisateurs concernés, car des jetons d'actualisation peuvent rester valides.
- Supprimer les applications sans usage ni propriétaire.
Éviter que le problème ne revienne
Restreignez le consentement utilisateur aux éditeurs vérifiés et aux autorisations à faible impact, ou désactivez-le, et activez le flux de demande de consentement administrateur pour que les besoins légitimes soient traités. Planifiez ensuite une revue régulière, car de nouvelles autorisations apparaissent à chaque intégration.
Ce qu'un audit vérifie
- L'inventaire complet des autorisations déléguées et d'application accordées.
- Les octrois
AllPrincipalset les autorisations d'application sensibles. - Les applications tierces inactives, sans propriétaire ou d'éditeur non vérifié.
- La configuration du consentement utilisateur et du flux de consentement administrateur.
- L'existence d'une revue périodique et d'une alerte sur les nouveaux consentements.