Partager via


Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (RBAC Azure) ?

Il est vital pour toute organisation qui utilise le cloud de pouvoir gérer les accès aux ressources situées dans cloud. Le contrôle d’accès basé sur un rôle Azure (RBAC Azure) permet de gérer les utilisateurs ayant accès aux ressources Azure, les modes d’utilisation des ressources par ces derniers et les zones auxquelles ils ont accès.

Le contrôle RBAC Azure est un système d’autorisation basé sur Azure Resource Manager qui permet une gestion affinée de l’accès aux ressources Azure.

Cette vidéo fournit une vue d’ensemble rapide du RBAC Azure.

Comment utiliser le contrôle RBAC Azure ?

Voici quelques exemples de ce que vous pouvez faire avec le contrôle RBAC Azure :

  • Autoriser un utilisateur à gérer des machines virtuelles dans un abonnement et un autre utilisateur à gérer des réseaux virtuels
  • Permettre à un groupe d’administrateurs de base de données de gérer des bases de données SQL dans un abonnement
  • Permettre à un utilisateur à gérer toutes les ressources dans un groupe de ressources, telles que des machines virtuelles, des sites Web et des sous-réseaux
  • Permettre à une application d’accéder à toutes les ressources d’un groupe de ressources

Fonctionnement du contrôle RBAC Azure

Les attributions de rôles Azure vous permettent de contrôler l’accès aux ressources avec RBAC Azure. Il s’agit d’un concept clé dont la compréhension est essentielle, à savoir la façon dont les autorisations sont appliquées. Une attribution de rôle se compose de trois éléments : un principal de sécurité, une définition de rôle et une étendue.

Principal de sécurité

Un principal de sécurité est un objet qui représente un utilisateur, un groupe, un principal de service ou une identité managée demandant l’accès à des ressources Azure. Vous pouvez attribuer un rôle à l’un de ces principaux de sécurité.

Diagram showing the security principal types for a role assignment.

Définition de rôle

Une définition de rôle est une collection d’autorisations. Elle est généralement simplement appelée rôle. Une définition de rôle liste les actions qui peuvent être effectuées, comme lire, écrire et supprimer. Les rôles peuvent être de haut niveau, comme propriétaire, ou spécifiques, comme lecteur de machines virtuelles.

Diagram showing role definition example for a role assignment

Azure inclut plusieurs rôles intégrés que vous pouvez utiliser. Par exemple, le rôle de contributeur de machine virtuelle permet à l’utilisateur de créer et gérer des machines virtuelles. Si les rôles intégrés ne répondent pas aux besoins spécifiques de votre organisation, vous pouvez créer vos propres rôles personnalisés Azure.

Cette vidéo fournit une vue d’ensemble rapide des rôles intégrés et des rôles personnalisés.

Azure propose des actions de données qui vous permettent d’accorder l’accès aux données au sein d’un objet. Par exemple, si un utilisateur dispose d’un accès en lecture aux données d’un compte de stockage, il peut lire les objets blob ou les messages de ce compte de stockage.

Pour plus d’informations, consultez Comprendre les définitions de rôle Azure.

Étendue

Étendue représente l’ensemble des ressources auxquelles l’accès s’applique. Lorsque vous attribuez un rôle, vous pouvez restreindre les actions autorisées en définissant une étendue. Cette possibilité s’avère utile si vous voulez par exemple attribuer le rôle de contributeur de site web à quelqu’un, mais seulement pour un groupe de ressources.

Dans Azure, vous pouvez spécifier une étendue à quatre niveaux : groupe d’administration, abonnement, groupe de ressources ou ressource. Les étendues sont structurées dans une relation parent-enfant. Vous pouvez attribuer des rôles à n’importe de ces niveaux d’étendue.

Diagram showing scope levels for a role assignment.

Pour plus d’informations sur l’étendue, consultez Comprendre l’étendue.

Affectations de rôles

Une attribution de rôle est le processus d’attachement d’une définition de rôle à un utilisateur, un groupe, un principal de service ou une identité managée au niveau d’une étendue spécifique pour accorder des accès. La création d’une attribution de rôle permet d’accorder un accès, qui peut être révoqué par la suppression d’une attribution de rôle.

Le diagramme suivant montre un exemple d’attribution de rôle. Dans cet exemple, le rôle de contributeur a été attribué au groupe Marketing pour le groupe de ressources pharma-sales. Cela signifie que les utilisateurs du groupe Marketing peuvent créer ou gérer n’importe quelle ressource Azure dans le groupe de ressources pharma-sales. Les utilisateurs marketing n’ont pas accès aux ressources en dehors du groupe de ressources pharma-sales, sauf s’ils font partie d’une autre attribution de rôle.

Diagram showing how security principal, role definition, and scope create a role assignment.

Vous pouvez attribuer des rôles en utilisant le portail Azure, Azure PowerShell, Azure CLI, des SDK Azure ou des API REST.

Pour plus d’informations, consultez Étapes pour attribuer un rôle Azure.

Groupes

Les attributions de rôles sont transitives pour les groupes, ce qui signifie que si un utilisateur est membre d’un groupe et que ce groupe est membre d’un autre groupe disposant d’une attribution de rôle, l’utilisateur dispose des autorisations dans l’attribution de rôle.

Diagram showing how role assignments are transitive for groups.

Attributions de rôles multiples

Que se passe-t-il si plusieurs attributions de rôles se chevauchent ? Le contrôle RBAC Azure étant un modèle additif, vos autorisations effectives correspondent à la somme de vos attributions de rôles. Prenons l’exemple suivant où un utilisateur reçoit le rôle Contributeur pour l’étendue de l’abonnement et le rôle Lecteur pour un groupe de ressources. La somme des autorisations du rôle Contributeur et des autorisations du rôle Lecteur correspond effectivement au rôle Contributeur pour l’abonnement. Ainsi, dans ce cas, l’attribution du rôle Lecteur n’a aucun impact.

Diagram showing how multiple role assignments overlap.

Comment le contrôle RBAC Azure détermine si un utilisateur a accès à une ressource

Voici les principales étapes suivies par le contrôle RBAC Azure pour déterminer si vous avez accès à une ressource. Ces étapes s’appliquent aux services Azure Resource Manager ou de plan de données intégrés à Azure RBAC. Cela est utile pour comprendre si vous essayez de résoudre un problème d’accès.

  1. Un utilisateur (ou principal de service) se procure un jeton pour Azure Resource Manager.

    Le jeton inclut les appartenances de l’utilisateur à des groupes (notamment les appartenances à des groupes transitifs).

  2. L’utilisateur effectue un appel d’API REST vers Azure Resource Manager avec le jeton joint.

  3. Azure Resource Manager récupère toutes les attributions de rôle et les affectations de refus qui s’appliquent à la ressource sur laquelle l’action est entreprise.

  4. Si c’est le cas, l’accès est bloqué. Dans le cas contraire, l’évaluation se poursuit.

  5. Azure Resource Manager restreint les attributions de rôles qui s’appliquent à cet utilisateur ou à son groupe, et détermine les rôles dont l’utilisateur dispose pour cette ressource.

  6. Azure Resource Manager détermine si l’action contenue dans l’appel d’API est incluse dans les rôles dont l’utilisateur dispose pour cette ressource. Si les rôles incluent Actions un caractère générique (*), les autorisations effectives sont calculées en soustrayant NotActions de l’autorisation Actions. De même, la même soustraction est effectuée pour toutes les actions de données.

    Actions - NotActions = Effective management permissions

    DataActions - NotDataActions = Effective data permissions

  7. Si l’utilisateur n’a pas de rôle avec l’action à l’étendue demandée, l’accès n’est pas autorisé. Dans le cas contraire, toutes les conditions sont évaluées.

  8. Si l’attribution de rôle inclut des conditions, elles sont évaluées. Sinon, l’accès est accordé.

  9. Si les conditions sont remplies, l’accès est autorisé. Sinon, l’accès n’est pas autorisé.

Le schéma suivant est un résumé de la logique d’évaluation.

Evaluation logic flowchart for determining access to a resource.

Où sont stockées les données RBAC Azure ?

Les définitions de rôle, les attributions de rôle et les attributions de refus sont stockées globalement (dans le monde entier) afin de garantir l’accès à vos ressources, quelle que soit la région dans laquelle vous avez créé la ressource.

Quand vous supprimez une attribution de rôle ou des données RBAC Azure, les données sont supprimées dans toutes les localisations. Les principaux qui accédaient à une ressource avec les données RBAC Azure perdent leur accès.

Pourquoi les données RBAC Azure sont dans le monde entier ?

Les données RBAC Azure sont globales pour s’assurer que les clients peuvent accéder rapidement aux ressources, quel que soit l’endroit où ils accèdent. RBAC Azure est appliqué par Azure Resource Manager, qui a un point de terminaison global, et les demandes sont routées vers la région la plus proche pour assurer vitesse et résilience. Par conséquent, RBAC Azure doit être appliqué dans toutes les régions, et les données sont répliquées dans toutes les régions. Pour plus d’informations, consultez Résilience d’Azure Resource Manager.

Considérez l'exemple suivant. Arina crée une machine virtuelle dans la région Asie Est. Bob, qui est membre de l’équipe d’Arina, travaille aux États-Unis. Bob doit accéder à la machine virtuelle qui a été créée dans la région Asie Est. Pour accorder à Bob un accès rapide à la machine virtuelle, Azure doit répliquer globalement l’attribution de rôle qui accorde à Bob l’accès à la machine virtuelle où qu’il se trouve.

Diagram showing Azure RBAC data in multiple regions.

Conditions de licence :

L'utilisation de cette fonctionnalité est gratuite et incluse dans votre abonnement Azure.

Étapes suivantes