Pour auditer les applications tierces Microsoft 365, listez dans Entra ID chaque application d’entreprise qui détient des autorisations sur votre tenant, puis supprimez celles que personne n’utilise et réduisez les droits des autres. Comptez une demi-journée pour une PME : c’est le seul moyen de savoir qui peut lire vos e-mails sans jamais passer par un mot de passe ni par la double authentification.
La question n’est pas théorique. Mi-octobre 2026, un attaquant a utilisé le secret d’une application de sauvegarde Microsoft 365 largement déployée par les infogérants, ConnectWise Cloud Backup (ex-SkyKick), pour se connecter directement à des tenants clients. Huntress a recensé au moins 162 tenants compromis dans son seul périmètre, et Todyl rappelle que ces connexions, faites par script au nom de l’application, échappaient totalement à la MFA. Un administrateur a même reçu une alerte pour une application qu’il n’utilisait plus depuis des années.
Pourquoi une application tierce échappe à vos protections
Quand vous connectez un outil de sauvegarde, d’archivage, de signature ou de CRM à Microsoft 365, vous créez dans votre tenant un principal de service : une identité propre à l’application, avec ses propres autorisations (lire tous les e-mails, écrire dans SharePoint, gérer l’annuaire…). Cette identité s’authentifie avec un secret ou un certificat détenu par l’éditeur, pas avec le compte d’un collaborateur.
Conséquence directe : si l’éditeur se fait voler ce secret, l’attaquant hérite de toutes les autorisations que vous avez accordées un jour, sans phishing, sans MFA et sans alerte de connexion utilisateur. Et ces autorisations ne disparaissent pas quand vous résiliez le service : l’application reste dans votre tenant tant que vous ne la supprimez pas.
Le tutoriel : auditer vos applications tierces Microsoft 365 en 7 étapes
Étape 1 : listez toutes les applications d’entreprise
Dans le centre d’administration Microsoft Entra, ouvrez Applications d’entreprise, puis retirez le filtre par défaut et choisissez le type « Toutes les applications ». Exportez la liste en CSV. Vous obtenez chaque application, son éditeur et sa date de création. Dans une PME de 50 personnes, il n’est pas rare d’en découvrir plusieurs dizaines, dont une bonne partie installée par un ancien prestataire ou par un collaborateur parti.
Étape 2 : repérez les autorisations les plus dangereuses
Pour chaque application, ouvrez l’onglet Autorisations. Distinguez les autorisations « déléguées » (l’application agit au nom d’un utilisateur connecté) des autorisations « d’application » (elle agit seule, sur tout le tenant). Ce sont ces dernières qu’il faut traquer en priorité, en particulier :
- Mail.ReadWrite ou Mail.Read : accès à toutes les boîtes aux lettres ;
- Files.ReadWrite.All et Sites.ReadWrite.All : tout OneDrive et tout SharePoint ;
- Directory.ReadWrite.All et RoleManagement.ReadWrite.Directory : la capacité de modifier l’annuaire et de s’attribuer des rôles d’administration.
Selon BleepingComputer, qui cite Microsoft Threat Intelligence, l’attaquant a vraisemblablement abusé de Directory.ReadWrite.All pour que des applications s’attribuent le rôle d’administrateur Exchange, voire d’administrateur général dans un cas.
Étape 3 : vérifiez qui utilise encore chaque application
Dans Journaux de connexion, ouvrez l’onglet « Connexions de principal de service ». Filtrez sur chaque application de votre liste : une application à hauts privilèges qui ne s’est pas connectée depuis 90 jours est une candidate évidente à la suppression. Croisez avec vos contrats : un service résilié ne doit plus avoir aucune identité dans votre tenant. La documentation Microsoft sur les journaux de connexion détaille les quatre types de connexions disponibles.
Étape 4 : désactivez, puis supprimez les applications inutiles
Procédez en deux temps pour éviter de casser un flux métier oublié. D’abord, dans les Propriétés de l’application, passez « Activé pour la connexion des utilisateurs ? » sur Non : l’application ne peut plus obtenir de jeton. Attendez une à deux semaines. Si personne ne se plaint, supprimez-la. Microsoft documente les deux opérations : désactiver la connexion et supprimer l’application.
Étape 5 : réduisez les droits des applications que vous gardez
Pour chaque application conservée, demandez à l’éditeur la liste minimale des autorisations nécessaires. Un outil de signature électronique n’a pas besoin de lire toutes les boîtes aux lettres ; un CRM n’a pas besoin de modifier l’annuaire. Quand l’éditeur le permet, limitez l’accès à une partie des boîtes (stratégies d’accès aux applications Exchange) ou à certains sites SharePoint plutôt qu’à l’ensemble du tenant. Notez dans un registre, pour chaque application : propriétaire interne, éditeur, autorisations, date de la dernière revue.
Étape 6 : fermez la porte aux nouvelles autorisations non validées
Dans Consentement et autorisations, interdisez aux utilisateurs d’accorder eux-mêmes des droits à des applications, ou limitez-les aux éditeurs vérifiés et aux autorisations à faible impact. Activez ensuite le flux de demande de consentement administrateur : un collaborateur qui veut connecter un outil fait une demande, un administrateur la valide. Les deux réglages sont décrits dans la documentation Microsoft sur le consentement des utilisateurs.
Étape 7 : surveillez ce que font vos applications
L’audit est une photo ; il faut aussi un film. Configurez des alertes sur trois événements : l’ajout d’un secret ou d’un certificat à une application, l’attribution d’un rôle d’administration à un principal de service, et toute connexion d’application depuis une adresse IP inhabituelle. C’est exactement ce qui a permis à certains administrateurs de repérer l’attaque ConnectWise le jour même : une notification Privileged Identity Management signalant qu’une application s’attribuait un rôle Exchange. Planifiez enfin une revue complète tous les six mois.
Le cas particulier des outils de votre infogérant
Les applications les plus puissantes de votre tenant sont souvent celles de votre prestataire informatique : sauvegarde, supervision, RMM, outil de gestion multi-clients. Elles sont aussi les plus attractives pour un attaquant, puisqu’un seul secret volé ouvre des centaines de tenants. Demandez à votre infogérant la liste des applications et des accès qu’il a installés chez vous, les autorisations de chacune, et la façon dont il protège leurs secrets. Côté accès humains, exigez des relations d’administration déléguée granulaires (GDAP), limitées dans le temps et aux seuls rôles utiles, plutôt qu’un accès d’administrateur général permanent.
Ces contrôles prolongent la démarche décrite dans notre article sur l’encadrement des accès de vos prestataires, et complètent la protection contre le phishing par consentement, détaillée dans notre guide sur le consentement OAuth.
Une application qui s’attribue un rôle d’administrateur un vendredi soir ne se remarque que si quelqu’un regarde les journaux en continu : c’est le rôle de notre SOC managé 24/7 pour PME et ETI, qui surveille aussi les identités cloud de votre tenant Microsoft 365.
Ce qu’il faut retenir
- Une application tierce Microsoft 365 s’authentifie avec son propre secret : la MFA de vos utilisateurs ne la protège pas.
- Les autorisations d’application (Mail, Files, Directory) donnent accès à tout le tenant, sans utilisateur connecté.
- Un service résilié laisse son application et ses droits dans votre tenant tant que vous ne la supprimez pas.
- Désactivez avant de supprimer, puis bloquez le consentement des utilisateurs et activez la demande d’approbation.
- Surveillez l’ajout de secrets et l’attribution de rôles aux applications, et revoyez la liste tous les six mois.
Sources
- Huntress — Vendor credential enables unauthorized access
- Todyl — Investigation : accès non autorisé via l’application ConnectWise Cloud Backup
- ConnectWise — Avis de sécurité
- Microsoft Learn — Configurer le consentement des utilisateurs aux applications
- Microsoft Learn — Examiner les applications OAuth à risque