Groupes d’administration
Les groupes d’administration sont essentiels à l’organisation et à la gouvernance de vos abonnements Azure. Au fur et à mesure que le nombre de vos abonnements augmente, les groupes d’administration fournissent une structure essentielle à votre environnement Azure et facilitent la gestion de vos abonnements. Utilisez les conseils suivants pour établir une hiérarchie efficace des groupes d’administration et organiser vos abonnements selon les meilleures pratiques.
Considérations relatives à la conception des groupes d’administration
Les structures de groupe d’administration dans un locataire Microsoft Entra prennent en charge le mappage organisationnel. Considérez soigneusement votre structure de groupe d’administration à mesure que votre organisation planifie son adoption d’Azure à grande échelle.
Comment votre organisation distingue-t-elle les services détenus ou exploités par des équipes spécifiques ?
Existe-t-il des fonctions spécifiques qui doivent être conservées pour des raisons professionnelles ou de conformité opérationnelle ?
Vous pouvez utiliser des groupes d’administration pour agréger des affectations de stratégie et d’initiative via Azure Policy.
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 du locataire.
Tout principal, qu’il s’agisse d’un utilisateur ou d’un principal de service, au sein d’un locataire Microsoft Entra peut créer des groupes d’administration. Cette autorisation est due au fait que l’autorisation de contrôle d’accès en fonction du rôle (RBAC) Azure pour les opérations de groupe d’administration n’est pas activée par défaut. Pour plus d’informations, consultez Comment protéger votre hiérarchie de ressources
Par défaut, tous les nouveaux abonnements sont placés sous le groupe d’administration racine des abonnés.
Consultez Groupes d’administration pour explorer leurs fonctionnalités plus en détail.
Recommandations pour les groupes d’administration
Conservez la hiérarchie de groupe d’administration raisonnablement plate, idéalement avec un maximum de trois à quatre niveaux. Cette restriction a pour effet de réduire la charge et la complexité de l’administration.
Évitez de dupliquer la structure de votre organisation dans une hiérarchie de groupe d’administration profondément imbriquée. Utilisez les groupes d’administration à des fins d’affectation de stratégie plutôt que de facturation. Cette approche requiert l’utilisation de groupes d’administration pour leur rôle prévu dans l’architecture conceptuelle de la zone d’atterrissage Azure. Cette architecture fournit des stratégies Azure pour les charges de travail qui requièrent le même type de sécurité et de conformité au niveau du même groupe d’administration.
Créez des groupes d’administration sous votre groupe d’administration de niveau racine pour représenter les types de charges de travail que vous hébergerez. Ces groupes sont basés sur la sécurité, la conformité, la connectivité et les besoins en fonctionnalités des charges de travail. Avec cette structure de regroupement, vous pouvez appliquer un ensemble de stratégies Azure au niveau du groupe d’administration. Cette structure de regroupement concerne toutes les charges de travail qui requièrent les mêmes paramètres de sécurité, de conformité, de connectivité et de fonctionnalité.
Utilisez des balises de ressources pour interroger et naviguer horizontalement dans la hiérarchie des groupes d’administration. Les balises de ressource peuvent être appliquées ou ajoutées via Azure Policy. Vous pouvez ensuite regrouper des ressources pour les besoins de recherche sans avoir à utiliser une hiérarchie de groupe d’administration complexe.
Créez un groupe d’administration bac à sable (sandbox) de niveau supérieur pour que les utilisateurs puissent conduire immédiatement une expérience avec Azure. Ils peuvent ensuite expérimenter des ressources qui ne sont pas forcément encore autorisées dans des environnements de production. Le bac à sable (sandbox) fournit une isolation de vos environnements de développement, de test et de production.
Créez un groupe d’administration de plateforme sous le groupe d’administration racine pour prendre en charge la stratégie de plateforme commune et l’attribution de rôle Azure. Cette structure de regroupement garantit que différentes stratégies peuvent être appliquées aux abonnements utilisés pour votre Fondation Azure. Elle garantit également que la facturation des ressources communes est centralisée dans un ensemble d’abonnements de base.
Limitez le nombre d’affectations Azure Policy effectuées au niveau de l’étendue du groupe d’administration racine. Cette limitation minimise le débogage des stratégies héritées dans les groupes d’administration de niveau inférieur.
Utilisez des stratégies pour appliquer les exigences de conformité au niveau du groupe d’administration ou de l’abonnement pour obtenir une gouvernance basée sur des stratégies.
Assurez-vous que seuls les utilisateurs privilégiés peuvent exécuter des groupes d’administration dans le locataire. Activez l’autorisation Azure RBAC dans les paramètres de hiérarchie des groupes d’administration pour affiner les privilèges de l’utilisateur. Par défaut, tous les utilisateurs sont autorisés à créer leurs propres groupes d’administration sous le groupe d’administration racine.
Configurez un groupe d’administration dédié par défaut pour les nouveaux abonnements. Ce groupe garantit qu’aucun abonnement n’est placé sous le groupe d’administration racine. Ce groupe s’avère particulièrement important si des utilisateurs sont éligibles aux avantages et abonnements Microsoft Developer Network (MSDN) ou Visual Studio. Un groupe d’administration de bac à sable est un bon candidat pour ce type de groupe d’administration. Pour plus d’informations, consultez Paramétrage - Groupe d’administration par défaut.
Ne créez pas de groupes d’administration pour les environnements de production, de test et de développement. Si nécessaire, séparez ces groupes en différents abonnements dans le même groupe d’administration. Pour plus d’informations sur cette rubrique, consultez :
Groupes d’administration dans l’accélérateur de zone d’atterrissage Azure et le référentiel ALZ-Bicep
Les décisions suivantes ont été prises et incluses dans l’implémentation de la structure du groupe d’administration. Ces décisions font partie de l’accélérateur de zone d’atterrissage Azure et du module groupes d’administration du référentiel ALZ-Bicep.
Notes
La hiérarchie des groupes d’administration peut être modifiée dans le module bicep de la zone d’atterrissage Azure en modifiant managementGroups.bicep.
| Groupe d’administration | Description |
|---|---|
| Groupe d’administration racine intermédiaire | Ce groupe d’administration se trouve directement sous le groupe racine du locataire. Créé avec un préfixe fourni par l’organisation, ce qui permet d’éviter l’utilisation du groupe racine afin que les organisations puissent déplacer les abonnements Azure existants dans la hiérarchie. Cela permet également des scénarios futurs. Ce groupe d’administration est un parent de tous les autres groupes d’administration créés par l’accélérateur de zone d’atterrissage Azure. |
| Plateforme | Ce groupe d’administration contient tous les groupes d’administration de la plateforme, comme la gestion, la connectivité et l’identité. |
| Gestion | Ce groupe d’administration contient un abonnement dédié à la gestion, à la surveillance et à la sécurité. Cet abonnement hébergera un espace de travail Azure Log Analytics, y compris les solutions associées et un compte Azure Automation. |
| Connectivité | Ce groupe d’administration contient un abonnement dédié pour la connectivité. Cet abonnement héberge les ressources de mise en réseau Azure requises pour la plateforme, telles que Azure Virtual WAN, le Pare-feu Azure et les zones privées Azure DNS. |
| Identité | Ce groupe d’administration contient un abonnement dédié à l’identité. Cet abonnement est un espace réservé pour les machines virtuelles Windows Server Active Directory Domain Services (AD DS) ou Microsoft Entra Domain Services. L’abonnement active également AuthN ou AuthZ pour les charges de travail dans les zones d’atterrissage. Des stratégies Azure spécifiques sont affectées pour renforcer et gérer les ressources dans l’abonnement aux identités. |
| Zones d’atterrissage | Le groupe d’administration parent pour tous les groupes d’administration enfants de la zone d’atterrissage. Les stratégies Azure indépendantes de la charge de travail seront affectées pour garantir la sécurité et la conformité des charges de travail. |
| En ligne | Le groupe d’administration dédié pour les zones d’atterrissage en ligne. Ce groupe concerne les charges de travail qui peuvent nécessiter une connectivité directe Internet entrante/sortante ou pour les charges de travail qui ne nécessitent pas de réseau virtuel. |
| Corp | Le groupe d’administration dédié pour les zones d’atterrissage de l’entreprise. Ce groupe concerne les charges de travail qui nécessitent une connectivité ou une connectivité hybride avec le réseau d’entreprise via le Hub dans l’abonnement de connectivité. |
| Bacs à sable | Le groupe d’administration dédié pour les abonnements qui seront utilisés uniquement pour les tests et l’exploration par une organisation. Ces abonnements seront déconnectés en toute sécurité des zones d’accueil d’entreprise et en ligne. Les bacs à sable disposent également d’un ensemble de stratégies moins restrictif affecté pour activer les tests, l’exploration et la configuration des services Azure. |
| Retiré | Groupe d’administration dédié pour les zones d’atterrissage en cours d’annulation. Les zones d’atterrissage annulées seront déplacées vers ce groupe d’administration avant d’être supprimées par Azure après 30 à 60 jours. |
Notes
Pour de nombreuses organisations, les groupes d’administration Corp et Online par défaut fournissent un point de départ idéal.
Certaines organisations doivent ajouter davantage d’éléments, qui ne seront pas pertinents dans d’autres organisations.
Si vous envisagez d’apporter des modifications à la hiérarchie du groupe d’administration, reportez-vous à notre aide Personnaliser l’architecture d’une zone d’atterrissage Azure pour répondre aux besoins.
Autorisations pour l’accélérateur de zone d’accueil Azure
Requiert un nom de principal du service (SPN) dédié pour exécuter les opérations du groupe d’administration, de gestion des abonnements et d’attribution de rôle. L’utilisation d’un SPN réduit le nombre d’utilisateurs disposant de droits élevés, conformément aux recommandations en matière de privilège minimum.
Requiert le rôle Administrateur de l’accès utilisateur au niveau de l’étendue du groupe d’administration racine pour accorder au SPN l’accès au niveau racine. Une fois les autorisations accordées au SPN, le rôle d’administrateur de l’accès utilisateur peut être supprimé en toute sécurité. Ainsi, seul le SPN fait partie du rôle d’administrateur de l’accès utilisateur.
Requiert le rôle Contributeur au SPN mentionné ci-dessus à l’étendue du groupe d’administration racine, qui autorise les opérations au niveau du locataire. Ce niveau d’autorisation garantit que le SPN peut être utilisé pour déployer et gérer des ressources sur n’importe quel abonnement au sein de votre organisation.
Étapes suivantes
En savoir plus sur les abonnements aux rôles quand vous planifiez une adoption Azure à grande échelle.
Commentaires
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour