Utilisateurs, groupes et attributions de rôles

Azure Role-Based Access Control (RBAC) est le système d’autorisation qui contrôle qui peut faire quoi sur les ressources Azure. Au lieu d’attribuer directement des autorisations à des personnes, vous attribuez des rôles à des principaux de sécurité (utilisateurs, groupes, principaux de service ou identités managées) dans une étendue donnée. Cette séparation facilite la gestion des autorisations à mesure que votre organisation se développe.

Chaque attribution RBAC comprend trois composants. Un principal de sécurité est l’entité qui reçoit l’accès (utilisateur, groupe ou identité managée). Une définition de rôle indique les actions autorisées (par exemple, lire des VMs ou écrire dans le stockage). Une étendue indique où l’accès s’applique — de la plus large à la plus restreinte : groupe d’administration, abonnement, groupe de ressources ou ressource individuelle. L’accès est hérité vers les niveaux inférieurs de la hiérarchie des étendues.

Azure fournit des centaines de rôles intégrés. Les quatre rôles les plus utilisés pour tous les types de ressources sont les suivants : Propriétaire — accès complet, y compris la possibilité d’attribuer des rôles à d’autres personnes ; Contributor — accès complet pour créer et gérer des ressources, mais impossibilité d’accorder l’accès à d’autres personnes ; Reader — accès en lecture seule ; et Administrateur des accès utilisateur — possibilité de gérer les attributions de rôles sans gérer lui-même les ressources.

Une attribution de rôle accorde au principal de sécurité indiqué les autorisations définies dans la définition de rôle, au niveau de l’étendue indiquée. Les attributions de rôles se propagent à toutes les étendues enfants : attribuer Contributor au niveau du groupe de ressources donne un accès Contributor à chaque ressource de ce groupe. Une attribution au niveau de l’abonnement donne un accès Contributor dans tous les groupes de ressources de cet abonnement.

Le principe du moindre privilège stipule que chaque identité ne doit disposer que des autorisations minimales nécessaires à l’exercice de ses fonctions. Dans Azure RBAC, cela signifie qu’il faut préférer Reader à Contributor lorsqu’aucune écriture n’est nécessaire, privilégier l’étendue d’un groupe de ressources à celle d’un abonnement et utiliser, lorsque cela est possible, des rôles spécifiques au niveau des ressources (par exemple, Contributeur aux données d’objets blob du stockage) plutôt que le rôle Contributor, plus large.

Lorsqu’aucun rôle intégré ne correspond exactement à vos besoins, vous pouvez créer un rôle personnalisé. Une définition de rôle personnalisée spécifie un ensemble d’Actions (opérations du plan de contrôle autorisées), de NotActions (opérations exclues de l’ensemble autorisé), de DataActions (opérations du plan de données sur les ressources, comme la lecture du contenu d’un objet blob) et d’AssignableScopes (abonnements ou groupes d’administration auxquels le rôle peut être attribué).

Attribuer des rôles à des groupes plutôt qu’à des utilisateurs individuels est une bonne pratique. Lorsqu’un nouveau développeur rejoint DevTeam, vous l’ajoutez au groupe de sécurité DevTeam dans Entra ID : il hérite automatiquement de toutes les attributions de rôles détenues par le groupe, sans aucune modification d’Azure RBAC. Ce point de gestion unique évite les attributions individuelles dispersées, qui deviennent difficiles à auditer ou à révoquer lors du départ d’un employé.

Un principal de service est une identité utilisée par des applications, des scripts et des outils d’automatisation pour s’authentifier auprès d’Azure et accéder aux ressources. Contrairement à une identité utilisateur, un principal de service ne peut pas se connecter de manière interactive. Vous les créez à partir des inscriptions d’applications dans Entra ID, puis vous leur attribuez des rôles RBAC au niveau de l’étendue appropriée — par exemple, en accordant à un pipeline d’intégration et de déploiement continus un accès Contributor à un seul groupe de ressources pour déployer l’infrastructure.

Les attributions de refus bloquent certaines actions pour les principaux de sécurité, même si une attribution de rôle les autoriserait autrement. Contrairement aux attributions de rôles, les attributions de refus ne peuvent pas être créées directement par les administrateurs : Azure Blueprints ou les applications managées les associent afin d’empêcher les utilisateurs de modifier des ressources protégées. Une attribution de refus est prioritaire sur toute attribution de rôle correspondante.

Privileged Identity Management (PIM) est une fonctionnalité d’Entra ID P2 qui fournit un accès privilégié au moment opportun. Au lieu d’attribuer en permanence un rôle de propriétaire ou d’administrateur général, vous rendez les utilisateurs éligibles à ce rôle. Lorsqu’ils en ont besoin, ils activent l’attribution pendant une durée limitée (par exemple, de 1 à 8 heures), avec éventuellement une procédure d’approbation et une justification obligatoires. Cela réduit considérablement la surface d’attaque permanente liée aux comptes dotés de privilèges excessifs.

Les révisions des accès (Entra ID P2) sont des révisions automatisées périodiques qui demandent aux propriétaires des ressources ou aux responsables de confirmer que les membres de leur équipe ont toujours besoin de leurs attributions de rôles actuelles. Les réviseurs approuvent ou refusent la poursuite de l’accès directement depuis l’interface de révision. Cela permet de détecter les autorisations obsolètes laissées par des changements de rôle, la fin de projets ou le départ d’employés — une exigence essentielle des programmes de conformité réglementaire.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris qu’Azure RBAC attribue des rôles à des principaux de sécurité dans une étendue donnée, que le principe du moindre privilège consiste à accorder uniquement les autorisations minimales nécessaires et que PIM fournit une activation au moment opportun pour les rôles hautement privilégiés au lieu d’une attribution permanente. Nous allons maintenant aborder l’authentification multifacteur et l’accès conditionnel dans Entra ID.