Les permissions Microsoft Graph à haut risque : inventaire et contrôles
Série : cinq permissions qui portent l'essentiel du risque applicatif dans un tenant M365, et les règles déclaratives pour les borner.
Pourquoi ces cinq permissions, et pas les autres
Le catalogue des permissions Microsoft Graph contient plus de 200 entrées, dont une grosse centaine en version application (lecture et écriture sans utilisateur connecté). La plupart sont étroites : DeviceManagementServiceConfig.Read.All, Reports.Read.All, Calendars.Read. Leur compromission est ennuyeuse, rarement catastrophique.
Cinq permissions sortent du lot. Elles partagent trois propriétés :
- Elles sont tenant-wide. Pas de scope par défaut, pas de sous-ensemble natif.
- Elles sont demandées par des applications légitimes. Refuser en bloc casse des intégrations que personne n'a envie de perdre.
- Leur compromission se traduit en préjudice mesurable : données clients exfiltrées, virements frauduleux, incidents de réputation, obligations de notification.
Cette série décompose chaque permission en scénario d'incident, mécanisme de non-blocage côté Microsoft, et jeu de règles déclaratives pour la borner. Le même gabarit s'applique aux cinq parce que le problème est structurellement identique, et la solution, architecturalement identique.
L'inventaire
Mail.Send
Envoi non scopé depuis n'importe quelle boîte
Une application compromise envoie 12 000 courriels de phishing en 20 minutes depuis une boîte légitime. ApplicationAccessPolicy scope les sources, rien ne contrôle les destinataires, le contenu ou le volume.
Préjudice typique : Atteinte directe à la confiance client, notification Loi 25, enquête ordinale.
Étude de cas complète et règles déclaratives →
Files.ReadWrite.All
Exfiltration SharePoint silencieuse
Lecture de toutes les bibliothèques de tous les sites du tenant. Sensitivity Labels et Purview DLP détectent après coup. Pas de scope natif équivalent à Sites.Selected.
Préjudice typique : Exfiltration massive (gigaoctets par heure) sous le radar de la détection native.
Étude de cas complète et règles déclaratives →
Sites.FullControl.All
Pivot interne par modification du plan d'accès
Contrôle complet sur tous les sites. Permet d'ajouter des invités, de modifier les permissions, d'effacer les colonnes d'audit. Le risque n'est pas l'exfiltration, c'est le pivot.
Préjudice typique : Reconfiguration silencieuse du plan d'accès SharePoint, découverte après fuite.
Étude de cas complète et règles déclaratives →
Application.ReadWrite.All
La permission qui accorde toutes les autres
Enregistrement de nouvelles apps et octroi de n'importe quelle permission Graph, sans intervention humaine. C'est la racine de la quasi-totalité des escalades tenant-wide.
Préjudice typique : Compromission totale du tenant à partir d'un seul secret d'application fuité.
Étude de cas complète et règles déclaratives →
User.Read.All
Reconnaissance silencieuse avant attaque ciblée
Lecture de tout l'annuaire avec titres, managers, départements. Invisible dans l'audit natif. Arme les campagnes de BEC et de spear-phishing contre la chaîne financière.
Préjudice typique : Fraude financière ciblée, virement détourné, calibré sur des données hiérarchiques exactes.
Étude de cas complète et règles déclaratives →Les limites partagées par les cinq
Les cinq contrôles reposent sur la même architecture. Nommer ses limites une fois évite de les répéter dans chaque article.
- Le proxy doit être sur le chemin. Une application qui conserve ses identifiants Graph en direct contourne la couche. Le modèle de confiance correct est que l'application ne détient jamais les secrets Graph réels, uniquement un identifiant de proxy inutilisable ailleurs.
- La latence ajoute 20 à 50 ms par appel. Invisible en transactionnel, à discuter pour du bulk, rarement un enjeu sur les volumes métier réels.
- Les règles demandent un inventaire. Quels sites, quels attributs, quelles apps légitimes. Ce travail n'est pas un sous-produit du déploiement, c'est souvent le premier bénéfice opérationnel.
La bascule de posture
Sans couche de gouvernance, ces cinq permissions forment la surface où la compromission d'un secret applicatif se traduit rapidement en incident mesurable. Avec, chaque appel Graph est évalué avant d'atteindre Microsoft, et le blast radius d'un secret fuité est réduit au minimum fonctionnel.
La différence n'est pas dans la détection (les outils natifs et Purview font déjà beaucoup). Elle est dans la prévention synchrone : un appel refusé ne part pas. Une fois ce principe posé, la question opérationnelle devient : quelles règles, pour quelles applications, dans quel ordre de priorité.
C'est exactement pour ça que GraphWarden existe.