Gérer les environnements de développement d'applications dans les zones d'atterrissage Azure
Cet article explique comment les équipes de plateforme cloud peuvent implémenter des garde-fous pour gérer les environnements d'application dans les zones d'atterrissage Azure. Il explique également comment aligner différents environnements de développement d'applications avec leur infrastructure. Un aspect clé de la création de l'environnement approprié consiste à placer des abonnements dans les groupes d'administration appropriés.
Poser les bases
Les équipes de développement ont besoin de pouvoir itérer rapidement, et les équipes de gouvernance cloud et de plateforme doivent gérer les risques organisationnels, la conformité et la sécurité à grande échelle. Vous pouvez gérer correctement les environnements d'application en mettant l'accent sur deux principes de conception de zone d'atterrissage Azure clés : la gouvernance pilotée par les stratégies et la démocratisation des abonnements. Ces principes fournissent des garde-fous fondamentaux et décrivent comment déléguer des contrôles aux équipes d'application. Les équipes d'applications utilisent des Aides Azure Well-Architected Framework pour concevoir leur charge de travail. Elles déploient et gèrent leurs propres ressources de zone d'atterrissage, et l'équipe de plateforme contrôle les ressources en affectant des stratégies Azure.
Il est important de fournir des ressources de bac à sable pour les ressources semi-régies, afin que les équipes d'applications puissent expérimenter des technologies et des fonctionnalités.
Lorsque les propriétaires d'applications utilisent distributeur d'abonnements ou d'autres processus de création d'abonnement, ils doivent savoir comment demander des abonnements pour plusieurs environnements de développement.
Cet article décrit la zone d'atterrissage Azure, y compris les groupes d'administration, les stratégies et l'architecture de plateforme partagée, ainsi que la charge de travail ou la zone d'atterrissage de l'application.
Remarque
Les conseils de cet article concernent uniquement les zones d'atterrissage de charge de travail ou d'application. Pour tester et séparer l'environnement pour la plateforme de zone d'atterrissage Azure elle-même, consultez Approche de test des zones d'atterrissage Azure, qui décrit l'approche de contrôle de validité.
Dans la pratique, vous pouvez utiliser n'importe quel nombre et type d'environnement par phases. Cet article fait référence aux environnements par phases suivants.
| Environment | Description | Groupe d’administration |
|---|---|---|
| Sandbox | Environnement utilisé pour l'innovation rapide des prototypes, mais pas pour les configurations liées à la production | Groupe d'administration de bac à sable |
| Développement | Environnement utilisé pour générer des candidats potentiels à la version finale (RC) | Groupe d'administration Archétype, tel que corp ou online |
| Test | Environnement utilisé pour effectuer des tests, notamment des tests unitaires, des tests d'acceptation utilisateur et des tests d'assurance qualité | Groupe d'administration Archétype, tel que corp ou online |
| Production | Environnement utilisé pour apporter de la valeur aux clients | Groupe d'administration Archétype, tel que corp ou online |
Pour plus d'informations, consultez les vidéos Gestion des environnements de développement, de test et de production pour les charges de travail d'application et Combien d'abonnements dois-je utiliser dans Azure ?
Environnements, abonnements et groupes de gestion
Avant d'aller dans cette section, consultez Zone de conception de l'organisation des ressources.
Vous devez organiser correctement vos abonnements lorsque vous adoptez des pratiques de zone d'atterrissage Azure. Dans l'idéal, chaque environnement d'application doit avoir son propre abonnement. Cette méthode fournit des contrôles de sécurité et de stratégie qui conservent les environnements isolés. Elle contient des problèmes potentiels pour un environnement.
Les abonnements distincts ont les mêmes stratégies au niveau de l'archétype. Si nécessaire, les propriétaires d'applications peuvent attribuer des stratégies spécifiques à l'abonnement pour appliquer le comportement propre à l'application et à l'environnement.
Pour certaines architectures d'application, les services doivent être partagés entre les environnements. Si c'est le cas, vous pouvez utiliser un abonnement unique pour plusieurs environnements. Nous recommandons aux propriétaires de charge de travail de travailler avec les équipes de plateforme cloud pour déterminer si un abonnement unique pour plusieurs environnements est nécessaire.
Utilisez un abonnement unique pour plusieurs environnements d'application dans les cas suivants :
Les environnements ne peuvent pas être isolés dans leurs propres abonnements.
Les environnements ont les mêmes équipes affectées aux rôles fonctionnels, tels que les opérateurs réseau.
Les environnements peuvent utiliser les mêmes stratégies.
Si une charge de travail d'application ou de service doit se trouver dans un abonnement unique et que vous devez modifier des stratégies qui s'appliquent à chaque environnement, vous pouvez :
créer un groupe d'administration aligné sur les archétypes sous le groupe d'administration des zones d'atterrissage. Pour plus d'informations, consultez Hiérarchie des groupes d'administration dans cet article.
Utilisez des abonnements de type « bac à sable » pour les activités de développement. Les bacs à sable disposent d'un ensemble de stratégies moins restrictives.
Utilisez des stratégies appliquées au niveau de l'abonnement au lieu du niveau du groupe d'administration. Utilisez des balises dans vos définitions de stratégie pour les filtrer et les appliquer à l'environnement approprié. Vous pouvez également affecter des stratégies à des groupes de ressources spécifiques ou les exclure.
Vous pouvez affecter des stratégies pendant le processus de création d'abonnement dans le cadre du distributeur d'abonnements.
Pour les stratégies que vous implémentez pour contrôler les coûts, appliquez la définition de stratégie au niveau d'un abonnement, le cas échéant. Vous pouvez également rendre le propriétaire de la zone d'atterrissage responsable des coûts, ce qui offre une véritable autonomie. Pour plus d’informations, consultez Automatisation de la plateforme et DevOps.
Avertissement
Contrairement aux stratégies et contrôles au niveau du groupe d'administration, les stratégies et balises basées sur l'abonnement peuvent être modifiées par des personnes disposant d'autorisations élevées pour l'abonnement. Les administrateurs disposant de rôles appropriés peuvent contourner ces contrôles en excluant les stratégies, en modifiant des stratégies ou en modifiant les balises sur les ressources.
Par conséquent, vous ne devez pas appliquer de balises dans les définitions des stratégies axées sur la sécurité. En outre, n'attribuez pas d'autorisations comme toujours actives pour les actions suivantes :
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Vous pouvez contrôler ces actions à l'aide de Privileged Identity Management (PIM).
Hiérarchie de groupe d’administration
Évitez les hiérarchies de groupe d'administration complexes. Elles peuvent nécessiter une modification fréquente, une mise à l'échelle inefficace et une valeur insuffisante. Pour éviter ces problèmes potentiels, les groupes d'administration des zones d'atterrissage Azure sont alignés sur l'archétype de charge de travail. Pour plus d’informations, consultez Groupe d’administration et organisation d’abonnement.
Alignés sur les archétypes signifie que les groupes d'administration ne sont créés que pour des archétypes de charge de travail spécifiques. Par exemple, dans l'architecture conceptuelle, le groupe d'administration « Zones d'atterrissage » comporte les groupes d'administration enfants « Corp » et « Online ». Ces groupes d'administration enfants s'alignent sur des modèles archétype distincts pour les charges de travail qu'ils contiennent. Les groupes d'administration enfants se concentrent sur les exigences de connectivité hybride (VPN/Azure ExpressRoute), notamment les applications et services internes uniquement et accessibles au public.
À l'exception des environnements de bac à sable, différents environnements d'application doivent utiliser le même archétype pour le déploiement. Même si les environnements sont divisés entre plusieurs abonnements, ils sont détenus dans le même groupe d'administration unique (corp ou online), en fonction du archétype du groupe d'administration et des exigences.
Vous pouvez utiliser des abonnements bac à sable pour le développement non structuré, comme les laboratoires personnels ou pour une charge de travail qui n'a pas d'archétype. Une équipe de charge de travail d'application ou de service utilise un groupe d'administration de bac à sable pour tester différents services Azure afin de déterminer celui qui convient le mieux à ses besoins. Après avoir décidé des services, elle peut approvisionner une zone d'atterrissage (dans le bon groupe de gestion aligné sur l'archétype de charge de travail dans la hiérarchie des groupes d'administration des zones d'atterrissage) pour l'équipe.
Les environnements de bac à sable peuvent être utilisés pour des applications spécifiques, ou une équipe de charge de travail peut les utiliser pour l'expérimentation.
Pour plus d’informations, consultez l’article suivant :
- Groupes d'administration
- Domaine de conception de l'organisation des ressources
- Personnalisez l'architecture d'une zone d'atterrissage Azure pour répondre aux besoins.
Défis liés au groupe d'administration basé sur l'environnement
Les groupes d'administration pour les environnements au sein des archétypes peuvent ajouter une surcharge de gestion et fournir une valeur minimale.
Le groupe d'administration des zones d'atterrissage doit avoir des stratégies universelles qui mettent en œuvre des garde-fous pour les groupes d'administration enfant corp et online. Corp et online ont des stratégies uniques qui appliquent les directives de l'organisation relatives aux charges de travail publiques et privées.
De nombreuses organisations créent des groupes d'administration distincts pour les environnements de cycle de vie du développement logiciel de charge de travail (SDLC) pour affecter des stratégies et des contrôles environnementaux. Dans la pratique, cette méthode crée plus de défis pour les équipes de charge de travail qu'elle n'en résout. Les environnements SDLC ne doivent pas avoir de stratégies différentes. Nous vous déconseillons donc de recommander de groupes d'administration distincts.
Les propriétaires d'applications peuvent modifier la topologie ou la configuration des ressources d'une charge de travail pour s'aligner sur les stratégies dans plusieurs environnements SDLC qu'il a promus. Cette méthode augmente le risque. Les règles spécifiques à chaque environnement peuvent entraîner une expérience de développement médiocre pour les équipes de développement et d'assurance qualité. Des problèmes peuvent également survenir si une application a un ensemble de stratégies de garde-fou qui fonctionnent dans un environnement, et que l'application est exposée à un autre ensemble de stratégies ultérieurement dans son cycle de promotion. Vous devrez peut-être apporter des ajustements à une application si les contrôles changent.
Pour éviter ce travail supplémentaire, créez des stratégies cohérentes tout au long de la promotion du code dans les environnements SDLC. Vous ne devez pas créer de stratégies pour chaque environnement, mais fournir un ensemble cohérent pour tous les environnements de développement, à l'exclusion des environnements de bac à sable.
Par exemple, imaginez qu'une organisation définit une stratégie qui exige que les comptes de stockage soient configurés avec des règles de pare-feu spécifiques pour empêcher l'entrée des réseaux publics. Au lieu de cela, les comptes de stockage utilisent des points de terminaison privés à l'intérieur des réseaux de zone d'atterrissage Azure pour la communication. Si l'environnement de développement n'a pas de stratégie de ce type, le test de la charge de travail ne trouve pas de mauvaise configuration du compte de stockage qui autorise l'accès public. Les déploiements de test fonctionnent dans l'environnement de développement et sont itérés. Lorsque la solution est promue vers un autre environnement doté de la stratégie de compte de stockage, le déploiement échoue en raison de la stratégie appliquée.
Par conséquent, l'équipe de développement d'applications doit retravailler son déploiement et son architecture, après avoir déjà investi beaucoup d'efforts. Cet exemple montre comment différentes stratégies dans différents environnements peuvent créer des problèmes.
Remarque
L'équation suivante montre pourquoi un groupe de gestion distinct pour chaque environnement ou charge de travail n'est pas adapté : N charges de travail x Z groupes d'administration = Nombre total de groupes d'administration.
Si une organisation a 30 charges de travail qui nécessitent chacune un groupe d'administration et un groupe d'administration enfant pour le développement, les tests et les environnements de production, l'organisation a ceci au final :
N = Nombre de charges de travail/applications = 30
Z = Nombre de groupes de gestion pour la charge de travail et les environnements (1 pour la charge de travail + 3 pour les environnements) = 4
N (30) x Z (4) = 120 groupes d’administration totaux
Les propriétaires d'applications peuvent avoir besoin de stratégies pour s'appliquer différemment à plusieurs environnements. Par exemple, les propriétaires d'applications peuvent nécessiter des configurations de sauvegarde pour les environnements de production, mais pas pour d'autres environnements.
Certaines stratégies peuvent être activées en tant que stratégies d'audit au niveau du groupe d'administration. Les équipes d'application déterminent comment implémenter le contrôle. Cette méthode n'empêche pas les déploiements, mais elle permet aux équipes d'applications de gérer leurs besoins uniques. Elles peuvent ensuite créer des stratégies de niveau inférieur ou incorporer ces exigences dans leurs modules de déploiement de l'infrastructure en tant que code (IaC).
Dans ce modèle de responsabilité partagée, l'équipe de plateforme audite les pratiques et l'équipe d'application gère l'implémentation. Ce modèle peut améliorer l'agilité des déploiements.
Les opérateurs de la plateforme doivent travailler avec l'équipe chargée de la charge de travail de chaque application ou service (propriétaires de la zone d'atterrissage) pour comprendre leurs besoins. Les opérateurs de plateforme peuvent fournir des abonnements en fonction des exigences et des plans de l'application. Les opérateurs de plateforme peuvent également décider de désigner des gamme de produits pour différents types de charges de travail afin de pouvoir mettre en place des processus de création d'abonnements et des outils basés sur les exigences communes des équipes chargées des charges de travail des applications ou des services.
Scénario : charges de travail basées sur des machines virtuelles
Les premières charges de travail dans les zones d'atterrissage Azure sont souvent composées de machines virtuelles Azure. Vous pouvez déployer ces charges de travail dans Azure ou les migrer à partir de centres de données existants.
Au lieu de déployer des machines virtuelles sur plusieurs environnements dans un abonnement unique, vous pouvez :
Établissez des abonnements pour chaque environnement d'application et placez-les tous dans le même groupe d'administration archétype.
Déployez un réseau virtuel pour chaque environnement d'application dans l'abonnement approprié. Vous pouvez déterminer la taille du réseau virtuel en fonction de la taille de l'environnement d'application.
Déployez les machines virtuelles sur leur abonnement approprié. Les machines virtuelles peuvent utiliser différentes références SKU et différentes configurations de disponibilité pour chaque environnement, le cas échéant.
Différentes ressources d'environnement d'application sont protégées par différents contrôles d'accès. Par conséquent, lorsque les développeurs d'applications configurent des pipelines de déploiement, l'identité de chaque pipeline peut être limitée à l'environnement. Cette configuration permet de protéger les environnements contre les déploiements accidentels.
Scénario : Azure App Service.
Une charge de travail avec des abonnements environnementaux qui utilisent App Service peut créer des défis. Pour les développeurs d'applications, l'une des meilleures pratiques d'App Service consiste à utiliser des emplacements de déploiement pour faciliter la gestion des changements et des mises à jour d'une application web.
Toutefois, cette fonction ne peut être utilisée qu'avec l'application qui fait partie du plan App Service, qui ne peut être utilisé que dans le cadre d'un abonnement unique. Si les opérateurs de plateforme imposent que les propriétaires d'applications utilisent des abonnements distincts pour les environnements de développement, de test et de production, le cycle de vie du déploiement d'application peut être plus difficile à gérer.
Pour cet exemple, la meilleure option est un abonnement unique pour la charge de travail d'application ou de service. Les propriétaires d'applications peuvent utiliser le contrôle d'accès en fonction du rôle Azure (RBAC) avec PIM au niveau du groupe de ressources pour renforcer la sécurité.