Comprendre les attributions de rôle Azure

Article
08/30/2024

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) ?

Intégration à Privileged Identity Management (préversion)

Important

L’intégration de l’attribution de rôle Azure à Privileged Identity Management est actuellement en PRÉVERSION. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Si vous disposez d’une licence Microsoft Entra ID P2 ou Microsoft Entra ID Governance, Microsoft Entra Privileged Identity Management (PIM) est intégré aux étapes d’attribution de rôle. Par exemple, vous pouvez attribuer des rôles à des utilisateurs pendant une période limitée. Vous pouvez également rendre les utilisateurs éligibles pour les attributions de rôles afin qu’ils doivent s’activer pour utiliser le rôle, par exemple demander l’approbation. Les attributions de rôles éligibles fournissent un accès juste-à-temps à un rôle pendant une période limitée. Vous ne pouvez pas créer d’attributions de rôles éligibles pour les applications, les principaux de service ou les identités managées, car ils ne peuvent pas effectuer les étapes d’activation. Vous pouvez créer des attributions de rôles éligibles au niveau du groupe d’administration, de l’abonnement et de l’étendue du groupe de ressources, mais pas au niveau du groupe de ressources. Cette fonctionnalité étant déployée en plusieurs phases, il est possible qu’elle ne soit pas encore disponible dans votre locataire ou que votre interface soit différente.

Les options du type d’attribution disponibles peuvent varier en fonction de votre stratégie PIM. Par exemple, la stratégie PIM détermine si des attributions permanentes peuvent être créées, la durée maximale des attributions liées au temps, des exigences d’activation des rôles (approbation, authentification multifacteur ou contexte d’authentification de l’accès conditionnel) et d’autres paramètres. Pour plus d’informations, consultez l’article Configurer les paramètres des rôles de ressource Azure dans Privileged Identity Management.

Si vous ne souhaitez pas utiliser la fonctionnalité PIM, sélectionnez le type d’affectation actif et les options de durée d’affectation permanentes. Ces paramètres créent une attribution de rôle où le principal dispose toujours d’autorisations dans le rôle.

Pour mieux comprendre PIM, vous devez connaître les termes suivants.

Terme ou concept	Catégorie d’attribution de rôle	Description
Éligible	Type	Attribution de rôle qui oblige l’utilisateur à effectuer une ou plusieurs actions pour utiliser ce rôle. Lorsqu’un utilisateur devient éligible pour un rôle, il peut l’activer pour réaliser des tâches privilégiées. Il n’existe aucune différence entre un accès accordé de façon permanente à un utilisateur et l’affectation d’un rôle éligible. La seule différence réside dans le fait que certaines personnes n’ont pas besoin d’un accès permanent.
active	Type	Attribution de rôle qui n’exige aucune action de la part de l’utilisateur pour être utilisée. Les utilisateurs actifs disposent des privilèges affectés au rôle.
Activer		Processus dans lequel une ou plusieurs actions sont exécutées dans le but d’utiliser un rôle pour lequel un utilisateur est éligible. Il peut s’agir de procéder à une vérification de l’authentification multifacteur (MFA), de fournir une justification professionnelle ou de demander une approbation aux approbateurs désignés.
Éligibilité permanente	Duration	Attribution de rôle qui permet à un utilisateur d’être toujours éligible à l’activation du rôle.
Active en permanence	Duration	Attribution de rôle qui permet à un utilisateur de toujours utiliser un rôle sans effectuer aucune action.
éligible avec limitation dans le temps	Duration	Attribution de rôle qui permet à un utilisateur d’être éligible à l’activation d’un rôle uniquement pendant une période.
actif avec limitation dans le temps	Duration	Attribution de rôle qui permet à un utilisateur d’utiliser un rôle uniquement pendant une période.
Accès juste-à-temps (JIT)		Modèle où les utilisateurs reçoivent des autorisations temporaires pour effectuer des tâches privilégiées. De cette façon, les utilisateurs malveillants ou non autorisés ne peuvent pas accéder aux ressources une fois que les autorisations ont expiré. L’accès est accordé uniquement au moment où les utilisateurs en ont besoin.
Principe des privilèges d’accès minimum		Pratique de sécurité recommandée qui consiste à accorder à chaque utilisateur les privilèges minimaux dont il a besoin pour accomplir les tâches qu’il est autorisé à effectuer. Cette pratique réduit le nombre d’administrateurs généraux et utilise à la place des rôles d’administrateur spécifiques pour certains scénarios.

Pour plus d’informations, consultez l’article Qu’est-ce que Microsoft Entra Privileged Identity Management ?.

Partager via