Les rôles Entra ID dangereux que personne ne surveille

Dans chaque audit M365, on vérifie le nombre de Global Admins. C'est devenu le réflexe standard — Microsoft le recommande, les frameworks de sécurité le mentionnent, tout le monde le sait.

Le problème : pendant qu'on surveille les Global Admins, personne ne regarde les vingt autres rôles qui permettent de faire à peu près autant de dégâts.

L'obsession Global Admin

Avoir trop de Global Admins est effectivement un problème. Ce rôle donne un accès total à tout le tenant — utilisateurs, données, configuration, facturation. Recommandation Microsoft : 2 maximum, idéalement avec un compte dédié sans boîte mail.

Mais le Global Admin n'est pas le seul rôle dangereux. Entra ID dispose de plus de 60 rôles intégrés. La plupart sont inoffensifs. Certains permettent de compromettre l'ensemble du tenant sans jamais toucher au compte Global Admin.

Les rôles vraiment dangereux

Privileged Role Administrator. C'est le plus critique après Global Admin. Ce rôle permet d'attribuer n'importe quel rôle à n'importe quel utilisateur — y compris Global Admin. Un attaquant qui prend le contrôle d'un Privileged Role Admin peut s'élever au niveau Global Admin en quelques clics.

Application Administrator. Ce rôle permet de créer et modifier des app registrations et des applications d'entreprise. Concrètement : créer une application OAuth malveillante, lui accorder des permissions étendues (lecture de tous les mails, accès aux fichiers), et faire consentir un utilisateur ou un admin. Résultat : une backdoor persistante dans le tenant.

Exchange Administrator. Accès complet à Exchange Online — toutes les boîtes mail, toutes les règles de transport, tous les connecteurs. Ce rôle permet de lire, modifier ou supprimer n'importe quel email de n'importe quel utilisateur du tenant.

Authentication Administrator. Ce rôle permet de modifier les méthodes d'authentification des utilisateurs non-admins : réinitialiser les mots de passe, supprimer les méthodes MFA enregistrées, enregistrer de nouveaux appareils. Un attaquant avec ce rôle peut prendre le contrôle de n'importe quel compte utilisateur sans déclencher d'alerte liée au Global Admin.

Conditional Access Administrator. Peut créer, modifier ou supprimer les politiques d'accès conditionnel. Autrement dit : désactiver le MFA obligatoire, ouvrir l'accès depuis n'importe quel pays, exclure des comptes des politiques de sécurité.

Helpdesk Administrator. Limité aux utilisateurs non-admins, mais peut réinitialiser leurs mots de passe et leurs méthodes MFA. Dans une PME où les comptes "utilisateurs" ont souvent des accès larges à SharePoint et Teams, c'est un vecteur d'escalade réel.

Les identifier

Entra ID n'affiche pas par défaut une vue consolidée de tous les rôles attribués. Il faut naviguer rôle par rôle.

Via le portail Entra :

Pour chaque rôle à risque, vérifier : qui a ce rôle, est-ce une attribution permanente ou éligible (PIM), est-ce un compte avec MFA, est-ce un compte encore actif.

Les rôles à vérifier en priorité :

• Privileged Role Administrator
• Application Administrator
• Exchange Administrator
• Authentication Administrator
• Conditional Access Administrator
• Security Administrator
• User Administrator
• Helpdesk Administrator

Que faire

Inventorier tous les rôles attribués. Pas seulement Global Admin. Pour chaque rôle sensible, lister les détenteurs, vérifier leur légitimité, vérifier leur statut MFA.

Supprimer les attributions inutiles. Si un compte n'a plus besoin d'un rôle, retirer l'attribution. La règle est simple : le moindre privilège, toujours.

Passer en attributions éligibles via PIM. Avec Azure AD P2, le Privileged Identity Management (PIM) permet de convertir les attributions permanentes en attributions à la demande, temporaires et auditées. L'utilisateur active son rôle quand il en a besoin, pour une durée limitée, avec justification.

Appliquer le MFA sur les comptes avec rôles. Un compte avec Exchange Admin ou Application Admin sans MFA est une cible prioritaire. Si les Security Defaults sont actifs, les admins sont forcés au MFA à chaque connexion — vérifier que c'est bien le cas ou qu'une politique CA couvre ces comptes.

Utiliser des comptes dédiés. Les rôles sensibles ne devraient pas être attribués aux comptes du quotidien. Un compte dédié, sans boîte mail, utilisé uniquement pour les tâches d'administration — c'est la bonne pratique, pas seulement pour Global Admin.