Comprendre les définitions de rôles Azure

Si vous essayez de comprendre comment un rôle Azure fonctionne, ou si vous créez votre propre rôle personnalisé Azure, il est utile de comprendre la façon dont les rôles sont définis. Cet article décrit en détail les définitions de rôles et fournit quelques exemples.

Définition de rôle

Une définition de rôle est un ensemble d’autorisations. On l’appelle parfois simplement rôle. Une définition de rôle liste les actions qui peuvent être effectuées, comme lire, écrire et supprimer. Elle permet également de répertorier les actions qui sont exclues des actions autorisées ou des actions liées aux données sous-jacentes.

L’exemple suivant illustre les propriétés d’une définition de rôle affichée avec Azure PowerShell :

Name
Id
IsCustom
Description
Actions []
NotActions []
DataActions []
NotDataActions []
AssignableScopes []
Condition
ConditionVersion

L’exemple suivant illustre les propriétés d’une définition de rôle lorsqu’elles sont affichées à l’aide de l' Azure CLI ou de l’API REST :

roleName
name
id
roleType
type
description
actions []
notActions []
dataActions []
notDataActions []
assignableScopes []
condition
conditionVersion
createdOn
updatedOn
createdBy
updatedBy

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

Format des actions

Les actions sont spécifiées à l’aide de chaînes dont le format est le suivant :

• {Company}.{ProviderName}/{resourceType}/{action}

La portion {action} d’une chaîne d’action spécifie le type d’actions que vous pouvez effectuer sur un type de ressource. Par exemple, vous verrez les sous-chaînes suivantes dans {action} :

Exemple de définition de rôle

Voici la définition de rôle Contributeur comme indiqué dans Azure PowerShell et Azure CLI. Les actions avec caractère générique (*) sous Actions indiquent que le principal affecté à ce rôle peut effectuer toutes les actions. En d’autres termes, il peut tout gérer. Cela inclut les actions qui seront définies ultérieurement, à mesure qu’Azure ajoutera de nouveaux types de ressources. Les actions sous NotActions sont soustraites de Actions. Dans le cas du rôle Contributeur, NotActions supprime la possibilité pour ce rôle de gérer l’accès aux ressources et gère également les affectations Azure Blueprints.

Rôle Contributeur affiché dans Azure PowerShell :

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/*/Delete",
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/elevateAccess/Action",
    "Microsoft.Blueprint/blueprintAssignments/write",
    "Microsoft.Blueprint/blueprintAssignments/delete",
    "Microsoft.Compute/galleries/share/action",
    "Microsoft.Purview/consents/write",
    "Microsoft.Purview/consents/delete"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Rôle Contributeur affiché dans Azure CLI :

[
  {
    "assignableScopes": [
      "/"
    ],
    "createdBy": null,
    "createdOn": "2015-02-02T21:55:09.880642+00:00",
    "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
    "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
    "permissions": [
      {
        "actions": [
          "*"
        ],
        "condition": null,
        "conditionVersion": null,
        "dataActions": [],
        "notActions": [
          "Microsoft.Authorization/*/Delete",
          "Microsoft.Authorization/*/Write",
          "Microsoft.Authorization/elevateAccess/Action",
          "Microsoft.Blueprint/blueprintAssignments/write",
          "Microsoft.Blueprint/blueprintAssignments/delete",
          "Microsoft.Compute/galleries/share/action",
          "Microsoft.Purview/consents/write",
          "Microsoft.Purview/consents/delete"
        ],
        "notDataActions": []
      }
    ],
    "roleName": "Contributor",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions",
    "updatedBy": null,
    "updatedOn": "2023-07-10T15:10:53.947865+00:00"
  }
]

Actions de contrôle et actions sur les données

Le contrôle d’accès en fonction du rôle pour les actions de plan de contrôle est spécifié dans les propriétés Actions et NotActions d’une définition de rôle. Voici quelques exemples d’actions de plan de contrôle dans Azure :

• Gérer l’accès à un compte de stockage
• Créer, mettre à jour ou supprimer un conteneur d’objets blob
• Supprimer un groupe de ressources et toutes ses ressources

L’accès au plan de contrôle n’est pas hérité de votre plan de données à condition que la méthode d’authentification du conteneur soit définie sur le Compte d’utilisateur Microsoft Entra et non sur la Clé d’accès. Cette séparation empêche des rôles avec caractères génériques (*) d’avoir un accès illimité à vos données. Par exemple, si un utilisateur a un rôle Lecteur sur un abonnement, il peut afficher le compte de stockage, mais pas les données sous-jacentes, par défaut.

Auparavant, le contrôle d’accès en fonction du rôle n’était pas utilisé pour les actions sur les données. L’autorisation pour les actions sur les données variait selon les fournisseurs de ressources. Le même modèle d’autorisation du contrôle d’accès en fonction du rôle utilisé pour les actions de plan de contrôle a été étendu aux actions de plan de données.

Pour prendre en charge les actions de plan de données, de nouvelles propriétés de données ont été ajoutées à la définition de rôle. Les actions de plan de données sont spécifiées dans les propriétés DataActions et NotDataActions. En ajoutant ces propriétés de données, la séparation entre le plan de contrôle et le plan de données est conservée. Cela empêche les attributions de rôles existantes avec des caractères génériques (*) d’accéder soudainement aux données. Voici quelques actions de plan de données qui peuvent être spécifiées dans DataActions et NotDataActions :

• Lire une liste d’objets blob dans un conteneur
• Écrire un objet blob de stockage dans un conteneur
• Supprimer un message dans une file d’attente

Voici la définition de rôle Lecteur des données blob du stockage, qui inclut des actions à la fois dans les propriétés Actions et DataActions. Ce rôle vous permet de lire le conteneur d’objets blob ainsi que les données d’objets blob sous-jacentes.

Rôle Lecteur des données blob du stockage tel qu’il est affiché dans Azure PowerShell :

{
  "Name": "Storage Blob Data Reader",
  "Id": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
  "IsCustom": false,
  "Description": "Allows for read access to Azure Storage blob containers and data",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
  ],
  "NotActions": [],
  "DataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Rôle Lecteur des données blob de stockage tel qu’il est affiché dans Azure CLI :

[
  {
    "assignableScopes": [
      "/"
    ],
    "createdBy": null,
    "createdOn": "2017-12-21T00:01:24.797231+00:00",
    "description": "Allows for read access to Azure Storage blob containers and data",
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
    "name": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
    "permissions": [
      {
        "actions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/read",
          "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
        ],
        "condition": null,
        "conditionVersion": null,
        "dataActions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
        ],
        "notActions": [],
        "notDataActions": []
      }
    ],
    "roleName": "Storage Blob Data Reader",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions",
    "updatedBy": null,
    "updatedOn": "2021-11-11T20:13:55.297507+00:00"
  }
]

Seules des actions de plan de données peuvent être ajoutées aux propriétés DataActions et NotDataActions. Les fournisseurs de ressources identifient quelles actions sont des actions sur les données en définissant la propriété isDataAction sur true. Pour afficher la liste des actions où isDataAction est true, consultez Opérations de fournisseur de ressources. Les rôles qui n’ont pas d’actions sur les données ne sont pas obligés d’avoir les propriétés DataActions et NotDataActions dans la définition de rôle.

L’autorisation pour tous les appels d’API de plan de contrôle est gérée par Azure Resource Manager. L’autorisation pour les appels d’API de plan de données est gérée par un fournisseur de ressources ou Azure Resource Manager.

Exemple d’actions sur les données

Pour mieux comprendre comment fonctionnent les actions de plan de contrôle et de plan de données, prenons un exemple spécifique. Alice a reçu le rôle Propriétaire au niveau de l’étendue de l’abonnement. Bob a reçu le rôle Contributeur aux données blob du stockage dans une étendue de compte de stockage. Le diagramme qui suit présente cet exemple.

Le rôle Propriétaire pour Alice et le rôle Contributeur aux données blob du stockage pour Bob effectuent les actions suivantes :

Owner

    Actions
    *

Contributeur aux données Blob du stockage

    Actions
    Microsoft.Storage/storageAccounts/blobServices/containers/delete
    Microsoft.Storage/storageAccounts/blobServices/containers/read
    Microsoft.Storage/storageAccounts/blobServices/containers/write
    Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
    DataActions
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Comme Alice dispose d’une action avec caractère générique (*) au niveau de l’étendue de l’abonnement, elle hérite d’autorisations lui permettant d’effectuer toutes les actions de plan de contrôle. Alice peut lire, écrire et supprimer des conteneurs. En revanche, elle ne peut pas effectuer d’actions de plan de données sans passer par des étapes supplémentaires. Par exemple, par défaut, Alice ne peut pas lire les objets blob à l’intérieur d’un conteneur. Pour cela, elle doit récupérer les clés d’accès de stockage et les utiliser pour accéder aux objets blob.

Les autorisations de Bob se limitent aux actions Actions et DataActions spécifiées dans le rôle Contributeur aux données blob du stockage. En fonction du rôle, Bob peut effectuer à la fois des actions de plan de contrôle et de plan de données. Par exemple, Bob peut lire, écrire et supprimer des conteneurs du compte de stockage spécifié, mais aussi lire, écrire et supprimer les objets blob.

Pour plus d’informations sur la sécurité des plans de contrôle et de données pour le stockage, consultez le guide de sécurité Stockage Microsoft Azure.

Quels outils permettent d’utiliser les rôles Azure pour les actions sur les données ?

Pour afficher et utiliser des actions sur les données, vous devez disposer des versions appropriées des outils ou des Kits de développement logiciel (SDK) :

Pour afficher et utiliser les actions sur les données dans l’API REST, vous devez définir le paramètre api-version sur la version suivante ou ultérieure :

• 01-07-2018

Actions

L’autorisation Actions spécifie les actions de plan de contrôle que le rôle autorise. Il s’agit d’un ensemble de chaînes qui identifient les actions sécurisables des fournisseurs de ressources Azure. Voici quelques exemples d’actions de plan de contrôle qui peuvent être utilisées dans Actions.

NotActions

L’autorisation NotActions spécifie les actions de plan de contrôle qui sont soustraites ou exclues des Actions autorisées ayant un caractère générique (*). Utilisez l’autorisation NotActions si l’ensemble des actions que vous souhaitez autoriser est plus facile à définir en soustrayant des Actions ayant un caractère générique (*). L’accès accordé par un rôle (autorisations effectives) est calculé en soustrayant les actions NotActions des actions Actions.

Actions - NotActions = Effective control plane permissions

Le tableau suivant présente deux exemples d’autorisations effectives de plan de contrôle pour une action avec caractère générique Microsoft.CostManagement :

Différences entre les NotActions et les affectations de refus

Les NotActions et les affectations de refus ne sont pas les mêmes et servent des objectifs différents. Les NotActions sont un moyen pratique de soustraire des actions spécifiques d’une action avec caractère générique (*).

Les affectations de refus empêchent les utilisateurs d’effectuer des actions particulières, même si une attribution de rôle leur accorde l’accès. Pour plus d’informations, consultez Comprendre les affectations de refus Azure.

DataActions

L’autorisation DataActions spécifie les actions de plan de données que le rôle autorise sur vos données au sein de cet objet. Par exemple, si un utilisateur dispose d’un accès en lecture aux données blob d’un compte de stockage, il peut lire les objets blob de ce compte de stockage. Voici quelques exemples d’actions sur les données qui peuvent être utilisées dans DataActions.

NotDataActions

L’autorisation NotDataActions spécifie les actions de plan de données qui sont soustraites ou exclues des DataActions autorisées ayant un caractère générique (*). Utilisez l’autorisation NotDataActions si l’ensemble des actions que vous souhaitez autoriser est plus facile à définir en soustrayant des DataActions ayant un caractère générique (*). L’accès accordé par un rôle (autorisations effectives) est calculé en soustrayant les actions NotDataActions des actions DataActions. Chaque fournisseur de ressources fournit son propre ensemble d’API pour répondre à des actions sur les données.

DataActions - NotDataActions = Effective data plane permissions

Le tableau suivant présente deux exemples d’autorisations effectives de plan de données pour une action avec caractère générique Microsoft.Storage :

AssignableScopes

La propriété AssignableScopes spécifie les scopes (racine, groupe de gestion, abonnements ou groupes de ressources) où une définition de rôle peut être attribuée. Vous pouvez rendre un rôle personnalisé disponible pour une affectation uniquement dans le groupe de gestion, les abonnements ou les groupes de ressources qui en ont besoin. Vous devez utiliser au moins un groupe de gestion, un abonnement ou un groupe de ressources.

Par exemple, si AssignableScopes elle est définie sur un abonnement, cela signifie que le rôle personnalisé est disponible pour l’attribution au niveau de l’étendue d’abonnement pour l’abonnement spécifié, l’étendue du groupe de ressources pour n’importe quel groupe de ressources de l’abonnement ou l’étendue des ressources pour n’importe quelle ressource de l’abonnement.

La chaîne AssignableScopes est définie sur l’étendue racine ("/") pour les rôles intégrés. L’étendue racine indique que le rôle est disponible pour attribution dans toutes les étendues.

Voici des exemples d’étendues assignables valides :

Vous ne pouvez définir qu’un seul groupe d’administration dans AssignableScopes pour un rôle personnalisé.

Bien qu'il soit possible de créer un rôle personnalisé avec une instance de ressource en AssignableScopes en utilisant la ligne de commande, ce n'est pas recommandé. Chaque locataire prend en charge un maximum de 5,000 rôles personnalisés. L’utilisation de cette stratégie peut potentiellement épuiser vos rôles personnalisés disponibles. En fin de compte, le niveau d'accès est déterminé par l'attribution du rôle personnalisé (portée + autorisations du rôle + principal de sécurité) et non par les AssignableScopes énumérés dans le rôle personnalisé. Ainsi, créez vos rôles personnalisés avec AssignableScopes un groupe de gestion, un abonnement ou un groupe de ressources, mais attribuez les rôles personnalisés avec une portée étroite, comme une ressource ou un groupe de ressources.

Pour plus d'informations sur AssignableScopesles rôles personnalisés, voir Rôles personnalisés Azure.

Définition de rôle d’administrateur privilégié

Les rôles d’administrateur privilégié sont des rôles qui accordent un accès d’administrateur privilégié, comme la possibilité de gérer des ressources Azure ou d’attribuer des rôles à d’autres utilisateurs. Si un rôle intégré ou personnalisé inclut l’une des actions suivantes, il est considéré comme privilégié. Pour plus d’informations, consultez Lister ou gérer des attributions de rôles d’administrateur privilégié.

Étapes suivantes

• Comprendre les attributions de rôles
• Rôles intégrés Azure
• Rôle personnalisés Azure
• Opérations de fournisseur de ressources Azure