Présentation des groupes d’administration Azure

Si votre organisation dispose de plusieurs abonnements Azure, vous pouvez avoir besoin d’un moyen de gérer efficacement l’accès, les stratégies et la conformité de ces abonnements. Les groupes d’administration fournissent une étendue de gouvernance au-delà des abonnements. Lorsque vous organisez les abonnements en groupes d’administration, et les conditions de gouvernance que vous appliquez s’appliquent en cascade par héritage à tous les abonnements associés.

Les groupes d’administration autorisent une gestion de qualité professionnelle à grande échelle quel que soit le type de vos abonnements. Toutefois, tous les abonnements au sein d’un même groupe d’administration doivent approuver le même locataire Microsoft Entra ID.

Par exemple, vous pouvez appliquer une stratégie à un groupe d’administration afin de limiter les régions disponibles pour la création de machines virtuelles. Cette stratégie serait appliquée à tous les groupes d’administration, abonnements et ressources imbriqués pour permettre la création de machines virtuelles uniquement dans les régions autorisées.

Hiérarchie des groupes d’administration et des abonnements

Vous pouvez créer une structure flexible de groupes d’administration et d’abonnements pour organiser vos ressources dans une hiérarchie à des fins de stratégie unifiée et de gestion de l’accès. Le diagramme suivant montre un exemple de création d’une hiérarchie pour la gouvernance à l’aide des groupes d’administration.

Vous pouvez créer une hiérarchie qui applique une stratégie, par exemple, qui limite les emplacements de machines virtuelles à la région USA Ouest dans le groupe de gestion appelé Corp. Cette stratégie hérite de tous les abonnements Accord Entreprise (EA) de ce groupe d’administration et s’applique à toutes les machines virtuelles sous ces abonnements. Le propriétaire de la ressource ou de l’abonnement ne peut pas modifier cette stratégie de sécurité pour permettre une gouvernance améliorée.

Un autre scénario où vous pouvez utiliser les groupes d’administration consiste à fournir un accès utilisateur à plusieurs abonnements. En déplaçant plusieurs abonnements sous un groupe d’administration, vous pouvez créer une attribution de rôle Azure sur le groupe d’administration. Le rôle hérite de cet accès à tous les abonnements. Une affectation sur le groupe d’administration peut autoriser les utilisateurs à accéder à tout ce dont ils ont besoin, au lieu de créer un script Azure de contrôle d’accès en fonction du groupe (RBAC) sur différents abonnements.

Faits importants sur les groupes d’administration

• Un seul annuaire peut prendre en charge 10 000 groupes d’administration.

• Une arborescence de groupes d’administration peut prendre en charge jusqu’à six niveaux de profondeur.

  Cette limite n’inclut pas le niveau Racine ni le niveau de l’abonnement.

• Chaque groupe d’administration et chaque abonnement ne peut avoir qu’un seul parent.

• Chaque groupe d’administration peut avoir de nombreux enfants.

• Dans chaque annuaire, tous les abonnements et groupes d’administration sont dans une même hiérarchie. Pour plus d’informations, consultez Informations importantes sur le groupe d’administration racine plus loin dans cet article.

Groupe d’administration racine pour chaque annuaire

Chaque répertoire a un groupe d’administration de niveau supérieur unique appelé groupe d’administration racine. Le groupe d’administration racine est intégré à la hiérarchie et contient tous les groupes d’administration et abonnements.

Le groupe d'administration racine permet d’appliquer des stratégies globales et des affectations de rôles Azure au niveau de l’annuaire. Initialement, le Élever l’accès pour gérer tous les abonnements et groupes d’administration Azure au rôle Administrateur(-trice) de l’accès utilisateur(-trice) de ce groupe racine. Une fois que l’administrateur client a élevé l’accès, l’administrateur peut attribuer n’importe quel rôle Azure à d’autres utilisateurs ou groupes d’annuaires pour gérer la hiérarchie. En tant qu’administrateur, vous pouvez attribuer votre compte comme propriétaire du groupe d’administration racine.

Faits importants sur le groupe d’administration racine

• Par défaut, le nom d’affichage du groupe d’administration racine est le groupe racine du locataire et il fonctionne lui-même en tant que groupe d’administration. L’ID est la même valeur que l’ID de locataire Microsoft Entra.
• Pour changer le nom d’affichage, votre compte doit avoir le rôle Propriétaire ou Contributeur sur le groupe d’administration racine. Pour plus d’informations, consultez Modifier le nom d’un groupe d'administration.
• Le groupe d’administration racine ne peut pas être déplacé ni supprimé, contrairement aux autres groupes d’administration.
• Tous les abonnements et groupes d’administration sont contenus dans le groupe d’administration racine de l’annuaire.
  • Toutes les ressources de l’annuaire sont contenues dans le groupe d’administration racine à des fins de gestion globale.
  • Lors de leur création, les nouveaux abonnements sont attribués par défaut au groupe d’administration racine.
• Tous les clients Azure peuvent voir le groupe d’administration racine, mais tous ne peuvent pas le gérer.
  • Toute personne ayant accès à un abonnement peut voir où celui-ci se trouve dans la hiérarchie.
  • Personne n’a par défaut l’accès au groupe d’administration racine. Les administrateurs généraux Microsoft Entra sont les seuls utilisateurs à pouvoir élever leurs privilèges pour obtenir l’accès. Une fois qu’ils ont accès au groupe d’administration racine, ils peuvent attribuer un rôle Azure aux autres utilisateurs pour gérer le groupe.

Configuration initiale des groupes d’administration

Lorsqu’un utilisateur commence à utiliser les groupes d’administration, un processus de configuration initiale est lancé. La première étape est la création du groupe d’administration racine dans l’annuaire. Tous les abonnements existants du répertoire deviennent des enfants du groupe d’administration racine.

Ce processus permet de faire en sorte que l’annuaire ne contienne qu’une seule hiérarchie de groupes gestion. Le fait de n’avoir qu’une seule hiérarchie par annuaire permet aux administrateurs d’appliquer un accès global et des stratégies que les autres utilisateurs de l’annuaire ne peuvent pas contourner.

Tout ce qui est attribué à la racine s’applique à l’ensemble de la hiérarchie. Autrement dit, elle s’applique à tous les groupes d’administration, abonnements, groupes de ressources et ressources au sein de ce locataire Microsoft Entra.

Accès aux groupes d’administration

Les groupes d’administration Azure prennent en charge le RBAC Azure pour tous les accès aux ressources et toutes les définitions de rôles. Les ressources enfants qui existent dans la hiérarchie héritent de ces autorisations. Tout rôle Azure peut être affecté à un groupe d’administration qui hérite de la hiérarchie vers les ressources.

Par exemple, vous pouvez attribuer le contributeur de machine virtuelle avec un rôle Azure à un groupe d’administration. Ce rôle n’a aucune action sur le groupe d’administration, mais hérite de toutes les machines virtuelles sous ce groupe d’administration.

Le graphique suivant montre la liste des rôles, ainsi que les actions prises en charge par les groupes d’administration.

* : Ces rôles permettent aux utilisateurs d’effectuer les actions spécifiées uniquement sur l’étendue du groupe d’administration.

** : Les attributions de rôles sur le groupe d’administration racine ne sont pas nécessaires pour déplacer un abonnement ou un groupe d’administration.

Déplacement d’abonnements et de groupes d’administration

Le déplacement d’abonnements et de groupes d’administration nécessite l’application de différentes attributions de rôles. Pour déplacer un abonnement enfant ou un groupe d’administration, les autorisations suivantes sont nécessaires :

• Abonnement enfant ou groupe d’administration déplacé
  • Microsoft.management/managementgroups/write
  • Microsoft.management/managementgroups/subscriptions/write (uniquement pour les abonnements)
  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.Authorization/roleAssignments/delete
  • Microsoft.Management/register/action
• Groupe d’administration parent cible
  • Microsoft.management/managementgroups/write
• Groupe d’administration parent actuel
  • Microsoft.management/managementgroups/write

Pour plus d’informations sur le déplacement d’éléments dans la hiérarchie, consultez Gérer vos ressources avec des groupes d’administration.

Définition et attribution d’un rôle personnalisé Azure

Vous pouvez définir un groupe d’administration en tant qu’étendue attribuable dans une définition de rôle personnalisé Azure. Le rôle personnalisé Azure est attribuable dans ce groupe d’administration, ainsi que tout groupe d’administration, abonnement, groupe de ressources ou ressource dont il est parent. Le rôle personnalisé hérite ensuite de la hiérarchie comme n’importe quel rôle intégré.

Pour plus d’informations sur les limitations des rôles personnalisés et des groupes d’administration, consultez Limitations plus tard dans cet article.

Exemple de définition

Le processus de définition et création d’un rôle personnalisé ne change pas avec l’inclusion de groupes d’administration. Utilisez le chemin d’accès complet pour définir le groupe d’administration : /providers/Microsoft.Management/managementgroups/{_groupId_}.

Utilisez l’ID du groupe d’administration et non le nom d’affichage du groupe d’administration. Cette erreur courante se produit car il s’agit de deux champs personnalisés définis au moment de la création d’un groupe d’administration.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementGroups/delete",
    "Microsoft.Management/managementGroups/read",
    "Microsoft.Management/managementGroups/write",
    "Microsoft.Management/managementGroups/subscriptions/delete",
    "Microsoft.Management/managementGroups/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Problèmes de chemin rompu entre la définition de rôle et l’attribution de rôle

Les étendues attribuables aux définitions de rôles peuvent être n’importe où dans la hiérarchie d’un groupe d’administration. Une définition de rôle peut être sur un groupe d’administration parent alors que l’attribution de rôle réelle existe sur l’abonnement enfant. Étant donné qu’il existe une relation entre les deux éléments, un message d’erreur s’affiche si vous essayez de séparer l’affectation de sa définition.

Par exemple, considérez l’exemple suivant de la petite section d’une hiérarchie.

Supposons qu’un rôle personnalisé soit défini sur le groupe d’administration bac à sable. Ce rôle personnalisé est ensuite attribué dans les deux abonnements bac à sable.

Si vous tentez de déplacer l’un de ces abonnements pour qu’il devienne enfant du groupe d’administration Corp, cette action rompt le chemin entre l’attribution à la définition du rôle pour le groupe d’administration bac à sable. Dans ce scénario, une erreur est reçue indiquant que le déplacement n’est pas autorisé, car il interrompt cette relation.

Pour résoudre ce scénario, vous disposez de ces options :

• Supprimez l’attribution de rôle de l’abonnement avant de déplacer ce dernier vers un autre groupe d’administration parent.
• Ajoutez l’abonnement dans l’étendue attribuable de la définition de rôle.
• Changez l’étendue attribuable dans la définition de rôle. Dans cet exemple, vous pouvez changer les étendues attribuables du groupe d'administration bac à sable vers le groupe d’administration racine, afin que les deux branches de la hiérarchie puissent atteindre la définition.
• Créer un autre rôle personnalisé est défini dans l’autre branche. Ce nouveau rôle vous oblige également à modifier le rôle sur l’abonnement.

Limites

Certaines limitations s’appliquent quand vous utilisez des rôles personnalisés dans des groupes d’administration :

• Vous pouvez définir un seul groupe d’administration dans les étendues attribuables d’un nouveau rôle. Cette limitation vise à réduire le nombre de situations où la relation entre les définitions de rôles et les attributions de rôles est rompue. Ce type de situation se produit quand un abonnement ou un groupe d’administration comportant une attribution de rôle est déplacé vers un autre parent dépourvu de la définition de rôle.
• Les rôles personnalisés avec DataActions ne peuvent pas être attribués au niveau de l’étendue du groupe d’administration. Pour plus d’informations, consultez limites de rôle personnalisées.
• Azure Resource Manager ne valide pas le groupe d’administration existant dans l’étendue attribuable de la définition de rôle. Même si vous avez fait une faute de frappe ou indiqué un ID de groupe d’administration incorrect, la définition de rôle est créée.

Déplacement des groupes d’administration et des abonnements

Pour déplacer un groupe d’administration ou un abonnement de sorte qu’il devienne l’enfant d’un autre groupe d’administration, il faut que :

• Les autorisations en écriture pour le groupe d’administration et l’attribution de rôle dans l’abonnement ou le groupe d’administration enfant.
  • Exemple de rôle intégré : Propriétaire
• L’accès en écriture au groupe d’administration dans le groupe d’administration parent cible.
  • Un rôle intégré, par exemple, Propriétaire, Contributeur, Contributeur du groupe d’administration
• L’accès en écriture au groupe d’administration dans le groupe d’administration parent existant.
  • Un rôle intégré, par exemple, Propriétaire, Contributeur, Contributeur du groupe d’administration

Il y a une exception : si le groupe d'administration parent cible ou existant correspond au groupe d'administration racine, les exigences en matière d'autorisations ne s'appliquent pas. Étant donné que le groupe d’administration racine correspondant à l'emplacement de destination de tous les nouveaux groupes d’administration et abonnements, vous ne devez pas disposer d'autorisations sur ce dernier pour déplacer un élément.

Si le rôle Propriétaire de l'abonnement est hérité du groupe d’administration actuel, vos cibles de déplacement sont limitées. Vous pouvez déplacer l’abonnement uniquement vers un autre groupe d’administration pour lequel vous détenez le rôle Propriétaire. Vous ne pouvez pas le déplacer vers un groupe d’administration pour lequel vous détenez seulement un rôle Contributeur, car vous perdriez la propriété de l’abonnement. Si vous vous voyez affecter directement le rôle Propriétaire de l’abonnement, vous pouvez le déplacer dans un groupe d’administration au sein duquel vous avez le rôle Contributeur.

Auditer les groupes d’administration en utilisant les journaux d’activité

Les groupes d’administration sont pris en charge dans Journaux d’activité Azure Monitor. Vous pouvez interroger tous les événements qui se produisent dans un groupe d’administration au même emplacement central, tout comme d’autres ressources Azure. Par exemple, vous pouvez voir tous les changements d’attributions de rôles ou de stratégie apportés à un groupe d’administration spécifique.

Lorsque vous souhaitez interroger des groupes d’administration en dehors du portail Azure, l’étendue cible des groupes d’administration ressemble à "/providers/Microsoft.Management/managementGroups/{management-group-id}".

Contenu connexe

Pour en savoir plus sur les groupes d’administration, consultez :

• Créer des groupes d’administration pour organiser les ressources Azure
• Changer, supprimer ou gérer vos groupes d’administration
• Protéger la hiérarchie de vos ressources