Comprendre les attributions de rôle Azure

  • Article

Les attributions de rôle permettent d’autoriser un principal (comme un utilisateur, un groupe, une identité managée ou un principal de service) à accéder à une ressource Azure spécifique. Cet article décrit les détails des attributions de rôle.

Attribution de rôle

L’accès à des ressources Azure est accordé en créant une attribution de rôle, et est révoqué par la suppression d’une attribution de rôle.

Une attribution de rôle comporte plusieurs composants, à savoir :

  • Principal, ou qui est titulaire du rôle.
  • Rôle attribué.
  • Étendue de l’attribution du rôle.
  • Nom de l’attribution de rôle et description qui vous aide à expliquer pourquoi le rôle a été attribué.

Par exemple, vous pouvez utiliser un RBAC Azure pour attribuer des rôles tels que :

  • L’utilisateur Sally dispose d’un accès propriétaire au compte de stockage contoso123 dans le groupe de ressources ContosoStorage.
  • Tout les membres du groupe Administrateurs de cloud dans Microsoft Entra ID disposent d’un accès lecteur à toutes les ressources du groupe de ressources ContosoStorage.
  • L’identité managée associée à une application est autorisée à redémarrer des machines virtuelles dans l’abonnement de Contoso.

L’exemple suivant illustre les propriétés d’une attribution de rôle quand elle est affichée à l’aide d’Azure PowerShell :

{
  "RoleAssignmentName": "00000000-0000-0000-0000-000000000000",
  "RoleAssignmentId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "Scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "DisplayName": "User Name",
  "SignInName": "user@contoso.com",
  "RoleDefinitionName": "Contributor",
  "RoleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "ObjectId": "22222222-2222-2222-2222-222222222222",
  "ObjectType": "User",
  "CanDelegate": false,
  "Description": null,
  "ConditionVersion": null,
  "Condition": null
}

L’exemple suivant illustre les propriétés d’une attribution de rôle quand elle est affichée à l’aide d’Azure CLI ou de l’API REST :

{
  "canDelegate": null,
  "condition": null,
  "conditionVersion": null,
  "description": null,
  "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "name": "00000000-0000-0000-0000-000000000000",
  "principalId": "22222222-2222-2222-2222-222222222222",
  "principalName": "user@contoso.com",
  "principalType": "User",
  "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "roleDefinitionName": "Contributor",
  "scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "type": "Microsoft.Authorization/roleAssignments"
}

Le tableau suivant décrit ce que signifient les propriétés d’attribution de rôle.

Propriété Description
RoleAssignmentName
name		 Nom de l’attribution de rôle, qui est un identificateur unique global (GUID).
RoleAssignmentId
id		 ID unique de l’attribution de rôle, qui inclut le nom.
Scope
scope		 Identificateur de ressource Azure auquel l’attribution de rôle est limitée.
RoleDefinitionId
roleDefinitionId		 ID unique du rôle.
RoleDefinitionName
roleDefinitionName		 Nom du rôle.
ObjectId
principalId		 Identificateur d’objet Microsoft Entra pour le principal auquel le rôle est attribué.
ObjectType
principalType		 Type d’objet Microsoft Entra que le principal représente. Les valeurs valides sont User, Group et ServicePrincipal.
DisplayName Pour les attributions de rôle pour les utilisateurs, nom d’affichage de l’utilisateur.
SignInName
principalName		 Nom de principal unique (UPN) de l’utilisateur, ou nom de l’application associée au principal de service.
Description
description		 Description de l’attribution de rôle.
Condition
condition		 Instruction de condition créée à l’aide d’une ou de plusieurs actions à partir de la définition du rôle et des attributs.
ConditionVersion
conditionVersion		 Numéro de version de la condition. La valeur par défaut est 2.0 et il s’agit de la seule version prise en charge.
CanDelegate
canDelegate		 Non implémenté.

Étendue

Lorsque vous créez une attribution de rôle, vous devez spécifier l’étendue à laquelle elle est appliquée. L’étendue représente la ressource ou l’ensemble de ressources auxquels le principal est autorisé à accéder. Vous pouvez étendre une attribution de rôle à une seule ressource, à un groupe de ressources, à un abonnement ou à un groupe d’administration.

Conseil

Utilisez la plus petite étendue dont vous avez besoin pour répondre à vos exigences.

Par exemple, si vous devez accorder à une identité managée l’accès à un seul compte de stockage, une bonne pratique de sécurité consiste à créer l’attribution de rôle dans l’étendue du compte de stockage, et non dans l’étendue du groupe de ressources ou de l’abonnement.

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

Rôle à attribuer

Une attribution de rôle est associée à une définition de rôle. La définition de rôle spécifie les autorisations dont le principal doit disposer dans l’étendue de l’attribution de rôle.

Vous pouvez attribuer une définition de rôle intégrée ou une définition de rôle personnalisée. Lorsque vous créez une attribution de rôle, certains outils nécessitent que vous utilisiez l’ID de définition de rôle tandis que d’autres outils vous permettent de fournir le nom du rôle.

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

Principal

Les principaux incluent des utilisateurs, des groupes de sécurité, des identités managées, des identités de charge de travail et des principaux de service. Les principaux sont créés et gérés dans votre locataire Microsoft Entra. Vous pouvez attribuer un rôle à tout principal. Utilisez l’ID d’objet Microsoft Entra ID pour identifier le principal auquel vous souhaitez attribuer le rôle.

Lorsque vous créez une attribution de rôle à l’aide d’Azure PowerShell, d’Azure CLI, de Bicep ou d’une autre technologie d’infrastructure en tant que code (IaC), vous spécifiez le type de principal. Les types de principaux sont User, Group et ServicePrincipal. Il est important de spécifier le type de principal correct. Sinon, vous risquez d’obtenir des erreurs de déploiement intermittentes, en particulier lorsque vous travaillez avec des principaux de service et des identités managées.

Nom

Le nom de ressource d’une attribution de rôle doit être un identificateur unique au niveau mondial (GUID).

Les noms des ressources d’attribution de rôle doivent être uniques dans le locataire Microsoft Entra, même si l’étendue de l’attribution de rôle est plus restreinte.

Conseil

Lorsque vous créez une attribution de rôle à l’aide du portail Azure, d’Azure PowerShell ou d’Azure CLI, le processus de création donne automatiquement à l’attribution de rôle un nom unique.

Si vous créez une attribution de rôle à l’aide de Bicep ou d’une autre technologie d’infrastructure en tant que code (IaC), vous devez planifier soigneusement la façon dont vous nommez vos attributions de rôle. Pour plus d’informations, consultez Créer des ressources Azure RBAC en utilisant Bicep.

Comportement de suppression des ressources

Quand vous supprimez un utilisateur, un groupe, un principal de service ou une identité managée de Microsoft Entra ID, il est recommandé de supprimer toutes les attributions de rôles. Elles ne sont pas supprimées automatiquement. Toutes les attributions de rôles qui font référence à un ID de principal supprimé ne sont plus valides.

Si vous essayez de réutiliser le nom d’une attribution de rôle pour une autre attribution de rôle, le déploiement échoue. Ce problème est plus susceptible de se produire lorsque vous utilisez Bicep ou un modèle Azure Resource Manager (modèle ARM) pour déployer vos attributions de rôle, car vous devez définir explicitement le nom de l’attribution de rôle lorsque vous utilisez ces outils. Pour contourner ce comportement, vous devez soit supprimer l’ancienne attribution de rôle avant de la recréer, soit vérifier que vous utilisez un nom unique quand vous déployez une nouvelle attribution de rôle.

Description

Vous pouvez ajouter une description textuelle à une attribution de rôle. Bien que les descriptions sont facultatives, il est recommandé de les ajouter à vos attributions de rôle. Fournissez une brève justification de la raison pour laquelle le principal a besoin du rôle attribué. Lorsque quelqu’un audite les attributions de rôle, les descriptions peuvent vous aider à comprendre pourquoi elles ont été créées et si elles sont toujours applicables.

Conditions

Certains rôles prennent en charge les conditions d’attribution de rôle en fonction des attributs dans le contexte d’actions spécifiques. Une condition d’attribution de rôle est une autre vérification que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore plus précis.

Par exemple, vous pouvez ajouter une condition qui exige qu’un objet porte une étiquette spécifique pour que l’utilisateur le lise.

En règle générale, vous générez des conditions à l’aide d’un éditeur de conditions visuelles, mais voici à quoi ressemble un exemple de condition dans le code :

((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'} AND NOT SubOperationMatches{'Blob.List'})) OR (@resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'))

La condition précédente permet aux utilisateurs de lire des blobs dont la clé de balise d’index de blob est Project et la valeur est Cascade.

Pour plus d’informations sur les conditions, consultez Qu’est-ce que le contrôle d’accès en fonction des attributs (Azure ABAC) ?

Étapes suivantes