m365expertise MICROSOFT SECURITY EXPERTISE
Sécurité

Exchange, SharePoint, Teams : qui détient vraiment des droits d'administration ?

m365expertise·5 août 2025·6 min·3 959 vues

Lorsqu'on inventorie les administrateurs d'un tenant, on s'arrête souvent à la liste des rôles Entra ID. C'est oublier que chaque charge de travail possède son propre modèle de permissions. Un compte absent de tout rôle d'annuaire peut ainsi disposer de droits étendus sur la messagerie ou sur des sites SharePoint.

Deux niveaux de délégation

Microsoft 365 superpose deux couches. La première est celle des rôles d'annuaire Entra ID : Administrateur général, Administrateur Exchange, Administrateur SharePoint, Administrateur Teams, etc. La seconde est propre à chaque service : groupes de rôles Exchange Online, administrateurs de collection de sites SharePoint, rôles de conformité Purview. Les rôles Entra ID sont automatiquement reflétés dans les services, mais l'inverse n'est pas vrai : un membre d'un groupe de rôles Exchange n'apparaît pas dans le portail Entra ID.

Exchange Online : un RBAC riche et souvent méconnu

Exchange Online repose sur un modèle RBAC composé de rôles de gestion (ensembles de cmdlets), d'affectations de rôles et d'étendues. Les rôles sont généralement regroupés dans des groupes de rôles :

  • Organization Management : contrôle quasi total de l'organisation Exchange ;
  • Recipient Management : création et modification de boîtes aux lettres, y compris des autorisations ;
  • Discovery Management et Compliance Management : recherche et conformité, donc accès potentiel au contenu ;
  • Help Desk, View-Only Organization Management et groupes personnalisés.

Des rôles peuvent aussi être affectés directement à un utilisateur, sans groupe, ce qui les rend encore moins visibles.

Get-RoleGroup | ForEach-Object {
    $g = $_.Name
    Get-RoleGroupMember -Identity $g | Select-Object @{n='RoleGroup';e={$g}}, Name, RecipientType
}
Get-ManagementRoleAssignment -GetEffectiveUsers | Where-Object { $_.RoleAssigneeType -eq 'User' }

Les applications aussi ont des rôles Exchange

Le RBAC pour les applications permet d'accorder à un principal de service des autorisations Exchange limitées à une étendue de gestion (par exemple un ensemble de boîtes). C'est l'alternative recommandée aux permissions Graph applicatives globales comme Mail.Read, qui donnent accès à toutes les boîtes du tenant. Encore faut-il inventorier ces affectations : Get-ServicePrincipal et Get-ManagementRoleAssignment en donnent la liste côté Exchange.

SharePoint et Teams

Côté SharePoint, le rôle Administrateur SharePoint couvre l'ensemble du service, mais chaque site possède ses propres administrateurs de collection de sites, qui ont un contrôle total sur le contenu. Ces désignations s'accumulent au fil des projets et sont rarement revues. Pour Teams, plusieurs rôles Entra ID spécialisés existent (Administrateur Teams, Administrateur des communications Teams, Administrateur des appareils Teams…), et les propriétaires d'équipe disposent de droits significatifs sur l'équipe et son site associé.

Le piège classique. Un ancien prestataire retiré de tous les rôles Entra ID mais toujours membre d'Organization Management conserve la capacité de s'octroyer l'accès à n'importe quelle boîte aux lettres.

Ce qu'un audit vérifie

  • les membres de chaque groupe de rôles Exchange, y compris les groupes personnalisés ;
  • les affectations directes de rôles de gestion à des utilisateurs ou à des applications ;
  • les principaux de service disposant de permissions Graph globales sur la messagerie ;
  • la cohérence entre les rôles Entra ID et les délégations propres aux services.
Cet article vous a-t-il été utile ?
4,3 / 5 · 325 avis