Rôles personnalisés Entra ID : le moindre privilège quand les rôles intégrés sont trop larges
Pour permettre à un service de gérer quelques applications, on lui attribue souvent Administrateur d'application, voire Administrateur général « pour que ça marche ». Les rôles personnalisés permettent de faire beaucoup plus fin. Encore faut-il savoir quelles autorisations sont réellement sensibles.
Quand les rôles intégrés ne suffisent plus
Entra ID propose plusieurs dizaines de rôles intégrés. Ils couvrent la plupart des besoins, mais souvent de manière trop large. Administrateur d'application, par exemple, permet de gérer toutes les inscriptions d'applications et applications d'entreprise du locataire, y compris leurs secrets et certificats. Pour une équipe qui ne gère qu'un portail métier, c'est disproportionné.
Un rôle personnalisé se justifie lorsque :
- le besoin ne porte que sur quelques actions précises, par exemple mettre à jour les propriétés d'une application sans toucher à ses informations d'identification ;
- le périmètre est limité à un ensemble d'objets identifiable ;
- le rôle intégré le plus proche donne accès à des actions dangereuses sans rapport avec le besoin.
Concevoir le rôle
Un rôle personnalisé est un ensemble d'autorisations de la forme microsoft.directory/applications/basic/update. Toutes les autorisations d'annuaire ne sont pas disponibles pour les rôles personnalisés : la liste prise en charge couvre notamment les applications, les utilisateurs, les groupes et les appareils, et elle évolue. Consultez la documentation Microsoft pour connaître l'état actuel.
La méthode que nous recommandons :
- Décrire les tâches réelles, en termes métier, avec l'équipe concernée.
- Traduire chaque tâche en autorisations, en partant de zéro et non d'un rôle intégré copié.
- Écarter systématiquement les autorisations sensibles qui ne sont pas indispensables.
- Tester le rôle sur un compte dédié avant de l'attribuer.
Les autorisations qui mènent plus loin. Modifier les informations d'identification d'une application (microsoft.directory/applications/credentials/update) ou ses propriétaires permet de s'authentifier en tant qu'elle. Si cette application détient des autorisations Microsoft Graph élevées, le rôle personnalisé devient un chemin d'élévation de privilèges. Ces autorisations doivent être réservées à des périmètres maîtrisés.
Limiter l'étendue
Un rôle, intégré ou personnalisé, s'attribue à une étendue. Trois niveaux existent :
| Étendue | Usage |
|---|---|
| Locataire | L'autorisation s'applique à tous les objets concernés. À réserver aux besoins réellement transverses. |
| Unité administrative | L'autorisation ne porte que sur les utilisateurs, groupes ou appareils membres de l'unité, par exemple une filiale ou un pays. |
| Ressource | L'autorisation ne porte que sur une application précise : inscription d'application ou application d'entreprise. |
L'étendue à la ressource est souvent la bonne réponse pour les équipes applicatives : un rôle personnalisé de gestion d'application, attribué sur la seule application concernée, remplace avantageusement un rôle global. Pour les objets sensibles, les unités administratives à gestion restreinte empêchent même les administrateurs du locataire de les modifier, sauf rôle attribué sur l'unité elle-même.
Licences et gouvernance
La création et l'attribution de rôles personnalisés nécessitent Microsoft Entra ID P1 au minimum ; vérifiez les conditions de licence actuelles. Une fois créés, ces rôles doivent être gouvernés comme les autres :
- attribution via PIM, en mode éligible, lorsque le rôle comporte des autorisations sensibles ;
- description claire de l'objet du rôle et de son propriétaire ;
- revue périodique des autorisations, car un rôle a tendance à s'enrichir au fil des demandes ;
- attribution à des groupes assignables à des rôles plutôt qu'à des utilisateurs individuels, lorsque l'équipe est stable.
Ce qu'un audit vérifie
- La liste des rôles personnalisés, leurs autorisations et leur justification.
- La présence d'autorisations sur les informations d'identification ou les propriétaires d'applications, et les applications concernées.
- Les étendues d'attribution : locataire, unité administrative ou ressource.
- Les attributions permanentes hors PIM.
- Les rôles intégrés larges qui pourraient être remplacés par un rôle personnalisé.