Déléguer la gestion de l’accès Azure à d’autres personnes

Dans le contrôle d’accès en fonction du rôle Azure (Azure RBAC), pour accorder l’accès aux ressources Azure, vous attribuez des rôles Azure. Par exemple, si un utilisateur doit créer et gérer des sites web dans un abonnement, vous attribuez le rôle Contributeur de site web.

L’attribution de rôles Azure pour accorder l’accès aux ressources Azure est une tâche courante. En tant qu’administrateur, vous pouvez obtenir plusieurs demandes d’octroi d’accès que vous souhaitez déléguer à quelqu’un d’autre. Toutefois, vous souhaitez vous assurer que le délégué dispose uniquement des autorisations dont il a besoin pour effectuer son travail. Cet article décrit un moyen plus sécurisé de déléguer la gestion des attributions de rôle à d’autres utilisateurs de votre organisation.

Pourquoi déléguer la gestion des attributions de rôle ?

Voici quelques raisons pour lesquelles vous pouvez déléguer la gestion des attributions de rôle à d’autres personnes :

• Vous recevez plusieurs demandes d’attribution de rôles dans votre organisation.
• Des utilisateurs sont en attente de l’attribution de rôle dont ils ont besoin.
• Au sein de leur service, équipe ou projet respectif, les utilisateurs sont bien informés des personnes qui ont besoin d’un accès.
• Les utilisateurs disposent des autorisations nécessaires pour créer des ressources Azure, mais ont besoin d’une attribution de rôle supplémentaire pour utiliser intégralement cette ressource. Par exemple :
  • Les utilisateurs autorisés à créer des machines virtuelles ne peuvent pas se connecter immédiatement à la machine virtuelle sans le rôle Connexion de l’administrateur aux machines virtuelles ou Connexion de l’utilisateur aux machines virtuelles. Au lieu de demander à un administrateur d’attribuer un rôle de connexion, il est plus efficace que l’utilisateur puisse attribuer le rôle de connexion lui-même.
  • Un développeur dispose des autorisations nécessaires pour créer un cluster Azure Kubernetes Service (AKS) et une instance Azure Container Registry (ACR), mais doit attribuer le rôle AcrPull à une identité managée afin qu’elle puisse extraire des images à partir de l’instance ACR. Au lieu de demander à un administrateur d’attribuer le rôle AcrPull, il est plus efficace que le développeur puisse attribuer le rôle lui-même.

Comment déléguer actuellement la gestion des attributions de rôle

Les rôles Propriétaire et Administrateur de l’accès utilisateur sont des rôles intégrés qui permettent aux utilisateurs de créer des attributions de rôle. Les membres de ces rôles peuvent décider qui peut disposer des autorisations d’écriture, de lecture et de suppression pour n’importe quelle ressource d’un abonnement. Pour déléguer la gestion des attributions de rôle à un autre utilisateur, vous pouvez attribuer le rôle Propriétaire ou Administrateur de l’accès utilisateur à un utilisateur.

Le diagramme suivant montre comment Alice peut déléguer des responsabilités d’attribution de rôle à Dara. Pour obtenir les étapes particulières, consultez l’article Attribuer à un utilisateur le rôle d’administrateur d’un abonnement Azure.

1. Alice à Dara attribue le rôle Administrateur de l’accès utilisateur.
2. Dara peut désormais attribuer n’importe quel rôle à un utilisateur, un groupe ou un principal de service dans la même étendue.

Quels sont les problèmes liés à la méthode de délégation actuelle ?

Vous trouverez ci-dessous les principaux problèmes liés à la méthode actuelle de délégation de la gestion des attributions de rôle à d’autres membres de votre organisation.

• Le délégué dispose d’un accès illimité à l’étendue d’attribution de rôle. Cela enfreint le principe du privilège minimum et vous expose à une surface d’attaque plus importante.
• Le délégué peut attribuer n’importe quel rôle à n’importe quel utilisateur dans son étendue, y compris lui-même.
• Le délégué peut attribuer le rôle Propriétaire ou Administrateur de l’accès utilisateur à un autre utilisateur, qui peut ensuite attribuer des rôles à d’autres utilisateurs.

Au lieu d’attribuer le rôle Propriétaire ou Administrateur de l’accès utilisateur, une méthode plus sécurisée consiste à limiter la capacité d’un délégué à créer des attributions de rôle.

Une méthode plus sécurisée : Déléguer la gestion des attributions de rôle avec des conditions

La délégation de la gestion des attributions de rôles avec des conditions permet de restreindre les attributions de rôle qu’un utilisateur peut créer. Dans l’exemple précédent, Alice peut autoriser Dara à créer des attributions de rôle en son nom, mais pas toutes les attributions de rôle. Par exemple, Alice peut limiter les rôles que Dara peut attribuer et limiter les principaux auxquels Dara peut attribuer des rôles. Cette délégation avec des conditions est parfois appelée délégation contrainte et est implémentée à l’aide de conditions de contrôle d’accès en fonction des attributs Azure (Azure ABAC).

Cette vidéo fournit une vue d’ensemble de la délégation de la gestion des attributions de rôle avec des conditions.

Pourquoi déléguer la gestion des attributions de rôle avec des conditions ?

Voici quelques raisons pour lesquelles la délégation de la gestion des attributions de rôle à d’autres personnes avec des conditions est plus sécurisée :

• Vous pouvez restreindre les attributions de rôle que le délégué est autorisé à créer.
• Vous pouvez empêcher un délégué d’autoriser un autre utilisateur à attribuer des rôles.
• Vous pouvez appliquer la conformité des stratégies de privilège minimum de votre organisation.
• Vous pouvez automatiser la gestion des ressources Azure sans avoir à accorder des autorisations complètes à un compte de service.

Exemple de conditions

Prenons un exemple où Alice est une administratrice disposant du rôle Administrateur de l’accès utilisateur pour un abonnement. Alice souhaite accorder à Dara la possibilité d’attribuer des rôles spécifiques pour des groupes particuliers. Alice ne souhaite pas que Dara dispose d’autres autorisations d’attribution de rôle. Le diagramme suivant montre comment Alice peut déléguer des responsabilités d’attribution de rôle à Dara avec des conditions.

1. Alice attribue le rôle Administrateur de contrôle d’accès en fonction du rôle à Dara. Alice ajoute des conditions pour que Dara puisse uniquement attribuer le rôle Contributeur de sauvegarde ou Lecteur de sauvegarde aux groupes Marketing et Ventes.
2. Dara peut désormais attribuer le rôle Contributeur de sauvegarde ou Lecteur de sauvegarde aux groupes Marketing et Ventes.
3. Si Dara essaie d’attribuer d’autres rôles ou d’attribuer un rôle à un autre principal (par exemple, un utilisateur ou une identité managée), l’attribution de rôle échoue.

Rôle Administrateur de contrôle d’accès en fonction du rôle

Le rôle Administrateur de contrôle d’accès en fonction du rôle est un rôle intégré conçu pour déléguer la gestion des attributions de rôle à d’autres personnes. Il dispose de moins d’autorisations que le rôle Administrateur de l’accès utilisateur, ce qui suit les meilleures pratiques en matière de privilège minimum. Le rôle Administrateur de contrôle d’accès en fonction du rôle dispose des autorisations suivantes :

• Créer une attribution de rôle au niveau de l’étendue spécifiée
• Supprimer une attribution de rôle au niveau de l’étendue spécifiée
• Lire les ressources de tous les types, à l’exception des secrets
• Créer et mettre à jour un ticket de support

Façons de limiter les attributions de rôle

Voici les façons dont les attributions de rôle peuvent être contraintes avec des conditions. Vous pouvez également combiner ces conditions en fonction de votre scénario.

• Contraindre les rôles qui peuvent être attribués

  

• Contraindre les rôles et les types de principaux (utilisateurs, groupes ou principaux de service) qui peuvent être attribués aux rôles

  

• Contraindre les rôles et des principaux spécifiques qui peuvent être attribués aux rôles

  

• Spécifier des conditions différentes pour les actions d’ajout et de suppression d’attribution de rôle

  

Comment déléguer la gestion des attributions de rôle avec des conditions

Pour déléguer la gestion des attributions de rôles avec des conditions, vous attribuez des rôles comme vous le faites actuellement, mais vous ajoutez également une condition à l’attribution de rôle.

1. Déterminez les autorisations dont le délégué a besoin

   • Quels rôles le délégué peut-il attribuer ?
   • À quels types de principaux le délégué peut-il attribuer des rôles ?
   • À quels principaux le délégué peut-il attribuer des rôles ?
   • Le délégué peut-il supprimer des attributions de rôle ?

2. Démarrez une nouvelle attribution de rôle

3. Sélectionnez le rôle Administrateur de contrôle d’accès en fonction du rôle

   Vous pouvez sélectionner n’importe quel rôle qui inclut l’action Microsoft.Authorization/roleAssignments/write, mais l’administrateur de contrôle d’accès en fonction du rôle dispose d’autorisations moins nombreuses.

4. Sélectionnez le délégué souhaité

   Sélectionnez l’utilisateur auquel vous souhaitez déléguer la gestion des attributions de rôle.

5. Ajouter une condition

   Il existe plusieurs façons d’ajouter une condition. Par exemple, vous pouvez utiliser un modèle de condition dans le portail Azure, l’éditeur de conditions avancé dans le portail Azure, Azure PowerShell, Azure CLI, Bicep ou l’API REST.

   Modèle

   Choisissez un modèle de condition dans la liste correspondante. Sélectionnez Configurer pour spécifier les rôles, les types de principaux ou les principaux.

   Pour plus d’informations, consultez Déléguer la gestion des attributions de rôles Azure à d’autres personnes avec des conditions.

   

   Éditeur de conditions

   Si les modèles de condition ne fonctionnent pas pour votre scénario ou si vous souhaitez un plus grand contrôle, vous pouvez utiliser l’éditeur de conditions.

   Pour obtenir des exemples, consultez Exemples pour déléguer la gestion des attributions de rôles Azure avec des conditions.

   

   Azure PowerShell

   New-AzRoleAssignment

   $roleDefinitionId = "f58310d9-a9f6-439a-9e8d-f62e7b41a168"
   $principalId = "<principalId>"
   $scope = "/subscriptions/<subscriptionId>"
   $condition = "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
   $conditionVersion = "2.0"
   New-AzRoleAssignment -ObjectId $principalId -Scope $scope -RoleDefinitionId $roleDefinitionId -Condition $condition -ConditionVersion $conditionVersion
   

   Azure CLI

   az role assignment create

   set roleDefinitionId="f58310d9-a9f6-439a-9e8d-f62e7b41a168"
   set principalId="{principalId}"
   set principalType="User"
   set scope="/subscriptions/{subscriptionId}"
   set condition="((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
   set conditionVersion="2.0"
   az role assignment create --assignee-object-id %principalId% --assignee-principal-type %principalType% --scope %scope% --role %roleDefinitionId% --condition %condition% --condition-version %conditionVersion%
   

   Bicep

   param roleDefinitionResourceId string
   param principalId string
   param condition string
   
   targetScope = 'subscription'
   
   resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
     name: guid(subscription().id, principalId, roleDefinitionResourceId)
     properties: {
       roleDefinitionId: roleDefinitionResourceId
       principalId: principalId
       principalType: 'User'
       condition: condition
       conditionVersion:'2.0'
     }
   }
   

   {
     "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
     "contentVersion": "1.0.0.0",
     "parameters": {
       "roleDefinitionResourceId": {
         "value": "providers/Microsoft.Authorization/roleDefinitions/f58310d9-a9f6-439a-9e8d-f62e7b41a168"
       },
       "principalId": {
         "value": "{principalId}"
       },
       "condition": {
         "value": "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
       }
     }
   }
   

   REST API

   Attributions de rôle – Créer

   PUT https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleAssignments/f58310d9-a9f6-439a-9e8d-f62e7b41a168?api-version=2020-04-01-Preview
   
   {
     "properties": {
       "roleDefinitionId": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/f58310d9-a9f6-439a-9e8d-f62e7b41a168",
       "principalId": "{principalId}",
       "condition": "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))",
       "conditionVersion": "2.0"
     }
   }
   

6. Attribuez le rôle avec condition au délégué

   Une fois que vous avez spécifié votre condition, effectuez l’attribution de rôle.

7. Contactez le délégué concerné

   Informez le délégué qu’il peut désormais attribuer des rôles avec des conditions.

Rôles intégrés avec des conditions

Les rôles Key Vault Data Access Administration istrator et Virtual Machine Data Access Administration istrator (préversion) ont déjà une condition intégrée pour limiter les attributions de rôles.

Le rôle d’accès aux données key Vault Administration istrator vous permet de gérer l’accès aux secrets, certificats et clés Key Vault. Il est exclusivement axé sur le contrôle d’accès sans avoir la possibilité d’attribuer des rôles privilégiés tels que les rôles Propriétaire et Administrateur de l’accès utilisateur. Il permet une meilleure séparation des tâches pour des scénarios tels que la gestion du chiffrement au repos entre les services de données afin de respecter davantage le principe de privilège minimum. La condition limite les attributions de rôle aux rôles Azure Key Vault suivants :

• Administrateur Key Vault
• Agent des certificats Key Vault
• Agent de chiffrement Key Vault
• Utilisateur du service de chiffrement de Key Vault
• Utilisateur de chiffrement Key Vault
• Lecteur Key Vault
• Agent des secrets Key Vault
• Utilisateur des secrets Key Vault

Si vous souhaitez limiter davantage l’attribution de rôle Administrateur de l’accès aux données Key Vault, vous pouvez ajouter votre propre condition pour contraindre les types de principaux (utilisateurs, groupes ou principaux de service) ou les principaux spécifiques qui peuvent être attribues aux rôles Key Vault.

Problèmes connus

Voici les problèmes connus liés à la délégation de la gestion des attributions de rôle avec des conditions :

• Vous ne pouvez pas déléguer la gestion des attributions de rôle avec des conditions à l’aide de Privileged Identity Management.
• Vous ne pouvez pas avoir une attribution de rôle avec une action de données Microsoft.Storage et une condition ABAC qui utilise un opérateur de comparaison GUID. Pour plus d’informations, consultez Résoudre les problèmes liés à RBAC Azure.

Conditions de licence :

L'utilisation de cette fonctionnalité est gratuite et incluse dans votre abonnement Azure.

Étapes suivantes

• Déléguer la gestion des attributions de rôles Azure à d’autres personnes avec des conditions
• Qu’est-ce que le contrôle d’accès en fonction des attributs Azure (Azure ABAC) ?
• Exemples de délégation de gestion des attributions de rôle Azure avec des conditions