Présentation des groupes d’administration Azure

Article
04/20/2023

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. 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. Cependant, tous les abonnements au sein d’un même groupe d’administration doivent approuver le même locataire Azure Active Directory (Azure AD).

Par exemple, vous pouvez appliquer des stratégies à 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, et permettrait 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.

Schéma d’un exemple de hiérarchie de 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 est héritée par tous les abonnements Contrat Entreprise descendants de ce groupe d’administration et s’applique à toutes les machines virtuelles dans ces abonnements. Cette stratégie de sécurité ne peut pas être modifiée par le propriétaire de ressources ou d’abonnement permettant une gouvernance améliorée.

Notes

Les groupes d’administration ne sont actuellement pas pris en charge dans les fonctionnalités Cost Management pour les abonnements de Contrat client Microsoft (MCA).

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 ce groupe d’administration, vous pouvez créer une attribution de rôle Azure sur le groupe d’administration, qui héritera 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 RBAC sur différents abonnements.

Faits importants sur les groupes d’administration

10 000 groupes d’administration peuvent être pris en charge dans un seul annuaire.
Une arborescence de groupes d’administration peut prendre en charge jusqu’à six niveaux de profondeur.
- Cette limite n’inclut ni le niveau racine ni le niveau d’abonnement.
Chaque groupe d’administration et chaque abonnement ne prennent en charge 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. Consultez Faits importants sur le groupe d’administration racine.

Groupe d’administration racine pour chaque annuaire

Chaque annuaire reçoit 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. Il permet d’appliquer des stratégies globales et des affectations de rôles Azure au niveau de l’annuaire. L’administrateur général d’Azure AD doit élever ses privilèges au rôle Administrateur d’accès utilisateur de ce groupe racine au départ. Une fois l’accès obtenu, l’administrateur peut attribuer un rôle Azure à d’autres utilisateurs ou groupes de l’annuaire 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 complet du groupe d’administration racine est le groupe racine du locataire et fonctionne lui-même en tant que groupe d’administration. L’ID est la même valeur que l’ID de locataire Azure Active Directory (Azure AD).
Pour changer le nom d’affichage, votre compte doit avoir le rôle Propriétaire ou Contributeur sur le groupe d’administration racine. Pour savoir comment mettre à jour le nom du groupe d’administration, consultez Changer 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 ne reçoit par défaut l’accès au groupe d’administration racine. Les administrateurs généraux Azure AD 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, les administrateurs généraux peuvent attribuer un rôle Azure aux autres utilisateurs pour le gérer.

Important

Les attributions d’accès utilisateur et de stratégies effectuées au niveau du groupe d’administration racine s’appliquent à toutes les ressources de l’annuaire. Pour cette raison, tous les utilisateurs doivent évaluer la nécessité de définir des ressources dans cette étendue. Les attributions d’accès utilisateur et de stratégies ne doivent être obligatoires que pour cette étendue.

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. Une fois le groupe créé, tous les abonnements existants de l’annuaire 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 élément attribué au niveau racine est appliqué à toute la hiérarchie, qui comprend tous les groupes d’administration, les abonnements, les groupes de ressources et les ressources de ce locataire Azure AD.

Accès aux groupes d’administration

Les groupes d’administration Azure prennent en charge le contrôle d’accès en fonction du rôle Azure (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. Vous pouvez attribuer n’importe quel rôle Azure à un groupe d’administration, qui héritera ensuite de la hiérarchie des ressources. Par exemple, un contributeur de machine virtuelle avec un rôle Azure peut être affecté à un groupe d’administration. Ce rôle n’a aucun effet sur le groupe d’administration, mais il hérite de toutes les machines virtuelles situées 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.

Nom du rôle Azure	Créer	Renommer	Déplacer**	DELETE	Attribuer l’accès	Attribuer la stratégie	Lire
Propriétaire	X	X	X	X	X	X	X
Contributeur	X	X	X	X			X
Contributeur MG*	X	X	X	X			X
Lecteur							X
Lecteur MG*							X
Contributeur de la stratégie de ressource						X
Administrateur de l'accès utilisateur					X	X

*: Les rôles Contributeur du groupe d’administration et Lecteur de groupe d’administration permettent aux utilisateurs d’effectuer ces actions 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.

Consultez Gérer vos ressources avec des groupes d’administration pour des détails sur le déplacement d’éléments dans la hiérarchie.

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 alors 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.

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. Spécifiez le chemin 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 est due au fait qu’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/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/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

L’étendue attribuable aux définitions de rôles peut être n’importe où dans la hiérarchie d’un groupe d’administration. Une définition de rôle peut être définie sur un groupe d’administration parent alors que l’attribution de rôle réelle existe sur l’abonnement enfant. Comme ces deux éléments sont liés, une erreur se produit si vous tentez de séparer l’attribution de sa définition.

Par exemple, examinons une petite section d’une hiérarchie pour un visuel.

Diagramme d’un sous-ensemble de l’exemple de hiérarchie de groupes d’administration.

Prenons l’exemple d’un rôle personnalisé défini sur le groupe d’administration Bac à sable. Ce rôle personnalisé est ensuite attribué dans les deux abonnements Bac à sable.

Si nous tentons de déplacer l’un de ces abonnements pour qu’il devienne enfant du groupe d’administration Corp, ce déplacement rompt le chemin entre l’attribution de rôle de l’abonnement et la définition de rôle du groupe d’administration Bac à sable. Dans ce scénario, vous recevez une erreur indiquant que le déplacement n’est pas autorisé, car il rompt cette relation.

Il existe plusieurs solutions pour corriger ce scénario :

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 l’exemple ci-dessus, vous pouvez changer les étendues attribuables du bac à sable vers le groupe d’administration racine afin que la définition soit disponible dans les deux branches de la hiérarchie.
Créez un autre rôle personnalisé défini dans l’autre branche. Pour ce nouveau rôle, vous devez également changer l’attribution de rôle dans 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. Cette 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.
Il n’est pas possible de définir les actions du plan de données du fournisseur de ressources dans des rôles personnalisés de groupe d’administration. Cette restriction s’explique par un problème de latence avec la mise à jour des fournisseurs de ressources du plan de données. Nous travaillons actuellement sur ce problème de latence ; ces actions seront désactivées de la définition de rôle pour réduire les risques.
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, trois règles doivent être remplies.

Pour effectuer le déplacement, vous devez avoir :

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

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. 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 uniquement déplacer l’abonnement 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 un rôle Contributeur si vous perdez la propriété de l’abonnement. Si vous vous voyez attribuer directement le rôle Propriétaire de l'abonnement (non hérité du groupe d’administration), vous pouvez le déplacer vers un groupe d’administration au sein duquel vous détenez un rôle Contributeur.

Important

Azure Resource Manager met en cache les détails de hiérarchie de groupe d’administration pendant 30 minutes maximum. Par conséquent, il est possible que le déplacement d’un groupe d’administration ne soit pas visible immédiatement dans le portail Azure.

Auditer les groupes d’administration à l’aide des journaux d’activité

Les groupes d’administration sont pris en charge dans le journal d’activité Azure. Vous pouvez rechercher dans 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.

Capture d’écran du journal d’activité et des opérations associées au groupe d’administration sélectionné.

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