Utiliser des rôles pour contrôler l’accès aux ressources
Rôles intégrés pour les ressources Azure (utilisation de PowerShell)
Azure fournit plusieurs rôles intégrés qui couvrent les scénarios de sécurité les plus courants. Pour comprendre le fonctionnement des rôles, examinons trois rôles applicables à tous les types de ressources :
- Propriétaire : dispose d’un accès total à toutes les ressources, ainsi que le droit de déléguer l’accès à d’autres personnes.
- Contributeur : peut créer et gérer tous les types de ressource Azure, mais ne peut pas octroyer l’accès à d’autres utilisateurs.
- Lecteur : peut voir les ressources Azure existantes.
Définitions de rôles
Chaque rôle est un ensemble de propriétés définies dans un fichier JSON (JavaScript Object Notation). Cette définition de rôle comprend un nom, un identificateur et une description. Elle inclut également les autorisations accordées (Actions), les autorisations refusées (NotActions) et l’étendue (par exemple, l’accès en lecture) pour le rôle.
Pour le rôle Propriétaire, toutes les actions sont autorisées, ce qui est indiqué par un astérisque (*), aucune action n’est refusée, et toutes les étendues sont incluses, ce qui est indiqué par une barre oblique (/).
Vous pouvez obtenir ces informations à l’aide de l’applet de commande PowerShell Get-AzRoleDefinition Owner.
Get-AzRoleDefinition Owner
Ce code doit normalement produire la sortie suivante :
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Répétez cette opération pour les rôles Contributeur et Lecteur afin de voir quelles actions sont autorisées ou refusées.
Rôles intégrés
Pour un examen approfondi des rôles RBAC et des rôles d’utilisateur dans Microsoft Entra ID, consultez Examiner les rôles RBAC et utilisateur dans Microsoft Entra ID.
Qu’est-ce qu’une définition de rôle ?
Une définition de rôle est un ensemble d’autorisations. Une définition de rôle répertorie les opérations que le rôle peut effectuer, par exemple, lecture, écriture et suppression. Elle peut également lister les opérations refusées ou les opérations liées aux données sous-jacentes.
Comme cela a été décrit précédemment, une définition de rôle présente la structure suivante :
| Nom | Description |
|---|---|
Id |
Identificateur unique attribué au rôle par Azure |
IsCustom |
True (Vrai) s’il s’agit d’un rôle personnalisé ; False (Faux) si c’est un rôle intégré |
Description |
Description lisible du rôle |
Actions [] |
Autorisations accordées ; * indique qu’elles sont toutes accordées |
NotActions [] |
Autorisations refusées |
DataActions [] |
Autorisations accordées spécifiques appliquées aux données, par exemple Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read |
NotDataActions [] |
Autorisations refusées spécifiques appliquées aux données. |
AssignableScopes [] |
Étendues où ce rôle s’applique ; / indique une étendue globale, mais possibilité d’accéder à une arborescence hiérarchique |
Cette structure est représentée au format JSON quand elle est utilisée dans le contrôle d’accès en fonction du rôle (RBAC) ou à partir de l’API sous-jacente. Par exemple, voici la définition du rôle Contributeur au format JSON.
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Éléments Actions et NotActions
Vous pouvez personnaliser les propriétés Actions et NotActions pour accorder ou refuser des autorisations de manière précise. Ces propriétés ont toujours le format suivant : {Company}.{ProviderName}/{resourceType}/{action}.
À titre d’exemple, voici les actions pour les trois rôles que nous avons examinés précédemment :
| Rôle intégré | Actions | NotActions |
|---|---|---|
| Propriétaire (autoriser toutes les actions) | * |
- |
| Contributeur (autoriser toutes les actions, sauf l’ajout ou la suppression d’attributions de rôles) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
| Lecteur (autoriser toutes les actions de lecture) | */read |
- |
L’opération avec caractère générique (*) sous Actions indique que le principal attribué à ce rôle est autorisé à effectuer toutes les actions ; autrement dit, ce rôle peut tout gérer, y compris les actions définies ultérieurement à mesure que de nouveaux types de ressources sont ajoutés à Azure. Avec le rôle Lecteur, seule l’action read est autorisée.
Les opérations sous NotActions sont soustraites de Actions. Avec le rôle Contributeur, NotActions supprime la possibilité pour ce rôle de gérer l’accès aux ressources, mais aussi d’en autoriser l’accès.
Éléments DataActions et NotDataActions
Les opérations sur les données sont spécifiées dans les propriétés DataActions et NotDataActions. Vous pouvez spécifier des opérations sur les données séparément des opérations de gestion. Cela empêche les attributions de rôles qui ont des caractères génériques (*) d’accéder soudainement aux données. Voici quelques opérations de données que vous pouvez spécifier 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
Vous pouvez uniquement ajouter des opérations sur les données aux propriétés DataActions et NotDataActions. Les fournisseurs de ressources identifient quelles opérations sont des opérations sur les données en définissant la propriété isDataAction sur true. Pour les rôles n’ayant aucune opération sur les données, ces propriétés peuvent être omises de la définition de rôle.
Ces actions fonctionnent exactement comme les actions de gestion. Vous pouvez spécifier les actions que vous souhaitez autoriser (ou * pour toutes les actions), puis fournir une liste d’actions spécifiques à supprimer dans la collection NotDataActions. Voici quelques exemples. Vous trouverez la liste complète des actions et des actions sur les données dans la documentation du fournisseur de ressources :
| Opération sur des données | Description |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
Supprimer des données d’objet blob |
Microsoft.Compute/virtualMachines/login/action |
Se connecter à une machine virtuelle en tant qu’utilisateur standard |
Microsoft.EventHub/namespaces/messages/send/action |
Envoyer des messages sur un hub d’événements |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
Retourner un fichier/dossier ou une liste de fichiers/dossiers |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Lire un message dans une file d’attente |
Rôles attribuables
Définir les propriétés Actions et NotActions n’est pas suffisant pour implémenter entièrement un rôle. Vous devez en plus définir l’étendue appropriée pour le rôle.
La propriété AssignableScopes du rôle spécifie les étendues (abonnements, groupes de ressources ou ressources) au sein desquelles le rôle peut être attribué. Vous pouvez rendre le rôle personnalisé disponible pour l’attribution seulement dans les abonnements ou groupes de ressources qui en ont besoin. Vous évitez ainsi de surcharger l’expérience utilisateur pour les autres abonnements ou groupes de ressources.
Voici quelques exemples :
| À | Utiliser l’étendue |
|---|---|
| Limiter à un abonnement | "/subscriptions/{sub-id}" |
| Limiter à un groupe de ressources spécifique sur un abonnement spécifique | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
| Limiter à une ressource spécifique | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
| Rendre un rôle disponible pour l’attribution dans deux abonnements | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
Créer les rôles
Microsoft Entra ID est fourni avec des rôles intégrés susceptibles de couvrir 99 % de ce que vous voulez faire. Il est préférable d’utiliser un rôle intégré quand c’est possible. Vous pouvez cependant créer des rôles personnalisés si c’est nécessaire.
Remarque
La création d’un rôle personnalisé nécessite Microsoft Entra ID P1 ou P2. Vous ne pouvez pas créer des rôles personnalisés dans le niveau Gratuit.
Vous pouvez créer un rôle par le biais de plusieurs mécanismes :
Centre d’administration Microsoft Entra : Vous pouvez utiliser le Centre d’administration Microsoft Entra pour créer un rôle personnalisé en sélectionnant Rôles et administrateurs sous Rôles et administrateurs dans le menu de gauche, puis en sélectionnant Nouveau rôle personnalisé.
Portail Azure : Vous pouvez utiliser le Portail Azure pour créer un rôle personnalisé en sélectionnant Microsoft Entra ID>Rôles et administrateurs>Nouveau rôle personnalisé.
Azure PowerShell : vous pouvez utiliser la cmdlet
New-AzRoleDefinitionpour définir un nouveau rôle.API Graph Azure : vous pouvez effectuer un appel REST à l’API Graph pour créer un rôle programmatiquement.
La section Résumé de ce module contient un lien vers la documentation relative à ces approches.