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.
Propriété | Description |
---|---|
Name roleName |
Nom d’affichage du rôle. |
Id name |
ID unique du rôle. Les rôles intégrés ont le même ID de rôle dans tous les clouds. |
id |
ID unique complet du rôle. Même si un rôle est renommé, l’ID de rôle ne change pas. Nous vous recommandons d’utiliser l’ID de rôle dans vos scripts. |
IsCustom roleType |
Indique s’il s’agit d’un rôle personnalisé. À définir sur true ou CustomRole pour les rôles personnalisés. À définir sur false ou BuiltInRole pour les rôles intégrés. |
type |
Type d'objet. Réglez sur Microsoft.Authorization/roleDefinitions . |
Description description |
Description du rôle |
Actions actions |
Tableau de chaînes qui spécifie les actions du plan de contrôle que le rôle permet d’effectuer. |
NotActions notActions |
Tableau de chaînes qui spécifie les actions du plan de contrôle qui sont exclues des Actions autorisées. |
DataActions dataActions |
Tableau de chaînes qui spécifie les actions du plan de données que le rôle autorise sur vos données au sein de cet objet. |
NotDataActions notDataActions |
Tableau de chaînes qui spécifie les actions du plan de données exclues des DataActions autorisées. |
AssignableScopes assignableScopes |
Tableau de chaînes qui spécifie les étendues pour lesquelles le rôle est disponible à des fins d’attribution. |
Condition condition |
Pour les rôles intégrés, instruction de condition basée sur une ou plusieurs actions dans la définition de rôle. |
ConditionVersion conditionVersion |
Numéro de version de condition. La valeur par défaut est 2.0 et il s’agit de la seule version prise en charge. |
createdOn |
Le rôle de date et d’heure a été créé. |
updatedOn |
Le rôle de date et d’heure a été mis à jour pour la dernière fois. |
createdBy |
Pour les rôles personnalisés, principal qui a créé un rôle. |
updatedBy |
Pour les rôles personnalisés, principal qui a mis à jour le 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}
:
Sous-chaîne d’action | Description |
---|---|
* |
Le caractère générique donne accès à toutes les actions qui correspondent à la chaîne. |
read |
Permet les actions de lecture (GET). |
write |
Permet les actions d’écriture (PUT ou PATCH). |
action |
Permet des actions personnalisées, telles que le redémarrage de machines virtuelles (POST). |
delete |
Permet les actions de suppression (DELETE). |
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) :
Outil | Version |
---|---|
Azure PowerShell | 1.1.0 ou ultérieure |
Azure CLI | 2.0.30 ou version ultérieure |
Azure pour .NET | 2.8.0-preview ou version ultérieure |
Kit de développement logiciel (SDK) Azure pour Go | 15.0.0 ou version ultérieure |
Azure pour Java | 1.9.0 ou version ultérieure |
Azure pour Python | 0.40.0 ou version ultérieure |
Kit de développement logiciel (SDK) Azure pour Ruby | 0.17.1 ou version ultérieure |
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
.
Chaîne d’action | Description |
---|---|
*/read |
Accorde l’accès aux actions de lecture pour tous les types de ressources de l’ensemble des fournisseurs de ressources Azure. |
Microsoft.Compute/* |
Accorde l’accès à l’ensemble des actions pour tous les types de ressources dans le fournisseur de ressources Microsoft.Compute. |
Microsoft.Network/*/read |
Accorde l’accès aux actions de lecture pour tous les types de ressources dans le fournisseur de ressources Microsoft.Network. |
Microsoft.Compute/virtualMachines/* |
Accorde l’accès à toutes les actions des machines virtuelles et à leurs types de ressources enfants. |
microsoft.web/sites/restart/Action |
Accorde l’accès au redémarrage d’une application web. |
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 :
Actions | NotActions | Autorisations effectives de plan de contrôle |
---|---|---|
Microsoft.CostManagement/exports/* |
aucune | Microsoft.CostManagement/exports/action Microsoft.CostManagement/exports/read Microsoft.CostManagement/exports/write Microsoft.CostManagement/exports/delete Microsoft.CostManagement/exports/run/action |
Microsoft.CostManagement/exports/* |
Microsoft.CostManagement/exports/delete |
Microsoft.CostManagement/exports/action Microsoft.CostManagement/exports/read Microsoft.CostManagement/exports/write Microsoft.CostManagement/exports/run/action |
Remarque
Si un utilisateur se voit attribuer un rôle qui exclut une action dans NotActions
, et un second rôle qui accorde l’accès à cette même action, il est autorisé à effectuer celle-ci. NotActions
n’est pas une règle de refus : il s’agit simplement d’un moyen pratique de créer un ensemble d’actions autorisées lorsque des actions spécifiques doivent être exclues.
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
.
Chaîne d’action sur les données | Description |
---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read |
Retourne un objet blob ou une liste d'objets blob. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write |
Retourne le résultat de l'écriture d'un objet blob. |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Retourne un message. |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/* |
Retourne un message ou le résultat de l’écriture ou de la suppression d’un message. |
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 :
DataActions | NotDataActions | Autorisations effectives de plan de données |
---|---|---|
Microsoft.Storage/storageAccounts/queueServices/queues/messages/* |
aucune | Microsoft.Storage/storageAccounts/queueServices/queues/messages/read Microsoft.Storage/storageAccounts/queueServices/queues/messages/write Microsoft.Storage/storageAccounts/queueServices/queues/messages/delete Microsoft.Storage/storageAccounts/queueServices/queues/messages/add/action Microsoft.Storage/storageAccounts/queueServices/queues/messages/process/action |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/* |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/delete |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read Microsoft.Storage/storageAccounts/queueServices/queues/messages/write Microsoft.Storage/storageAccounts/queueServices/queues/messages/add/action Microsoft.Storage/storageAccounts/queueServices/queues/messages/process/action |
Remarque
Si un utilisateur se voit attribuer un rôle qui exclut une action sur les données dans NotDataActions
, et un second rôle qui accorde l’accès à cette même action, il est autorisé à effectuer celle-ci. NotDataActions
n’est pas une règle de refus : il s’agit simplement d’un moyen pratique de créer un ensemble d’actions sur les données autorisées lorsque des actions sur les données spécifiques doivent être exclues.
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 :
Le rôle est disponible à l’attribution | Exemple |
---|---|
Abonnement unique | "/subscriptions/{subscriptionId1}" |
Deux abonnements | "/subscriptions/{subscriptionId1}", "/subscriptions/{subscriptionId2}" |
Groupe de ressources réseau | "/subscriptions/{subscriptionId1}/resourceGroups/Network" |
Un seul groupe d’administration | "/providers/Microsoft.Management/managementGroups/{groupId1}" |
Groupe d’administration et abonnement | "/providers/Microsoft.Management/managementGroups/{groupId1}", "/subscriptions/{subscriptionId1}", |
Toutes les étendues (applicable uniquement aux rôles intégrés) | "/" |
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 AssignableScopes
les 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é.
Chaîne d’action | Description |
---|---|
* |
Créer et gérer les ressources de tous les types. |
*/delete |
Supprimez les ressources de tous les types. |
*/write |
Écrire des ressources de tous les types. |
Microsoft.Authorization/denyAssignments/delete |
Supprime un refus d’affectation dans l’étendue spécifiée. |
Microsoft.Authorization/denyAssignments/write |
Crée un refus d’affectation dans l’étendue spécifiée. |
Microsoft.Authorization/roleAssignments/delete |
Supprimez une affectation de rôle au niveau de la portée spécifiée. |
Microsoft.Authorization/roleAssignments/write |
Créez une affectation de rôle au niveau de la portée spécifiée. |
Microsoft.Authorization/roleDefinitions/delete |
Supprimez la définition de rôle personnalisé spécifiée. |
Microsoft.Authorization/roleDefinitions/write |
Créez ou mettez à jour une définition de rôle personnalisé avec des autorisations spécifiées et des portées pouvant être affectées. |