Approche de test pour les zones d'atterrissage Azure

Remarque

Cet article s’applique uniquement à Microsoft Azure et non à d’autres offres Microsoft Cloud telles que Microsoft 365 ou Microsoft Dynamics 365.

Certaines organisations veulent tester le déploiement de leur plateforme de zones d’atterrissage Azure relativement aux définitions et aux affectations Azure Policy, aux rôles personnalisés de contrôle d’accès en fonction du rôle (RBAC) et aux attributions, etc. Les tests peuvent être effectués via l’automatisation à l’aide de modèles Azure Resource Manager (modèles ARM), Terraform, Bicepou manuellement via le portail Azure. Ce guide fournit une approche qui peut être utilisée pour tester les modifications et leur impact sur un déploiement de plateforme de zones d’atterrissage Azure.

Vous pouvez également utiliser cet article conjointement avec les conseils de la zone de conception critique pour l’automation de plateforme et le DevOps qui traite des équipes et des tâches de fonctions PlatformOps et centrales. En outre, il peut être combiné avec les instructions de Adopter des garde-fous pilotés par les stratégies pour les techniques de déploiement des modifications de stratégie dans un déploiement de zones d’atterrissage Azure.

Ces conseils sont les plus adaptés aux organisations avec des processus de gestion des changements robustes qui régissent les modifications apportées à la hiérarchie des groupes d’administration de production. La hiérarchie du groupe d’administration canary peut être utilisée de manière indépendante pour créer et tester des déploiements avant de les effectuer dans l’environnement de production.

Remarque

Le terme canary est utilisé pour éviter toute confusion avec les environnements de développement ou de test. Il est utilisé à titre de simple illustration. Vous pouvez définir le nom de votre choix pour votre environnement de zones d’atterrissage d’atterrissage Azure Canary.

De même, le terme environnement de production/hiérarchie est utilisé dans ce guide pour faire référence à la hiérarchie des groupes d’administration des zones d’atterrissage Azure que votre organisation peut avoir en place qui contient les abonnements et ressources Azure pour vos charges de travail.

Définition de la plateforme

Important

Ces conseils ne concernent pas les environnements de développement ou les environnements de test qui seront utilisés par les propriétaires d’applications ou de services appelés zones d’atterrissage, charges de travail, applications ou services. Ces environnements sont placés et gérés au sein de la hiérarchie du groupe d’administration de l’environnement des zones d’atterrissage Azure de production et de la gouvernance associée (RBAC et Azure Policy).

Pour obtenir des conseils sur le développement, les tests, les tests d’acceptation des utilisateurs (UAT) et les environnements de production pour les charges de travail d’application et les équipes, consultez Gérer les environnements de développement d’applications dans les zones d’atterrissage Azure.

Ces directives concernent seulement les tests au niveau de la plateforme ainsi que les modifications dans le contexte des zones d’atterrissage Azure.

Les zones d’atterrissage Azure vous aident à concevoir et déployer les composants de plateforme Azure requis pour vous permettre de construire et d’opérationnaliser des zones d’atterrissage à grande échelle.

Les ressources de plateforme visées dans cet article et cette approche de test sont les suivantes :

Produit ou service	Fournisseur et type de ressource
Groupes d’administration	Microsoft.Management/managementGroups
Association d’abonnement aux groupes d’administration	Microsoft.Management/managementGroups/subscriptions
Définitions de stratégies	Microsoft.Authorization/policyDefinitions
Définitions d’initiatives de stratégie ou de jeux de stratégies	Microsoft.Authorization/policySetDefinitions
Attributions de stratégies	Microsoft.Authorization/policyAssignments
Définitions de rôles RBAC	Microsoft.Authorization/roleDefinitions
Attributions de rôles RBAC	Microsoft.Authorization/roleAssignments
Abonnements	Microsoft.Subscription/aliases

Exemples de scénarios et de résultats

Un exemple de ce scénario est celui d’une organisation désireuse de tester l’impact et le résultat d’une nouvelle stratégie Azure pour régir des ressources et des paramètres dans toutes les zones d’atterrissage, conformément au principe de conception de gouvernance pilotée par une stratégie. Elle ne souhaite pas apporter cette modification directement à l’environnement de production, car elle s’inquiète de son impact éventuel.

L’utilisation de l’environnement canary pour tester cette modification de plateforme permet à l’organisation d’implémenter et d’examiner l’impact et le résultat du changement de stratégie Azure. Ce processus permet à l’organisation de s’assurer que la stratégie Azure est conforme à ses exigences avant de l’implémenter dans son environnement de production.

Un scénario similaire pourrait être une modification des attributions de rôle RBAC Azure et des appartenances aux groupes Microsoft Entra. Il pourrait nécessiter une forme de test avant l’implémentation des modifications dans l’environnement de production.

Important

Il ne s’agit pas d’une approche de déploiement ou d’un modèle commun pour la plupart des clients. Il n’est pas obligatoire pour les déploiements de zones d’atterrissage Azure.

Figure 1 : hiérarchie du groupe d’administration canary.

Comme le montre le diagramme, la totalité de la hiérarchie du groupe d’administration de production des zones d’atterrissage Azure est dupliquée sous Tenant Root Group. Le nom canary est ajouté aux noms d’affichage et ID du groupe d’administration. Les ID doivent être uniques au sein d’un tenant Microsoft Entra.

Remarque

Les noms d'affichage des groupes de gestion canary peuvent être identiques à ceux des groupes de gestion de production. Cela peut entraîner une confusion pour les utilisateurs. C’est pourquoi nous recommandons d’ajouter le mot « canary » aux noms d’affichage, ainsi qu’à leur ID.

La hiérarchie des groupes d’administration canary est ensuite utilisée pour simplifier le test des types de ressources suivants :

• Groupes d’administration
  • Placement de l’abonnement
• RBAC
  • Rôles (intégrés et personnalisés)
  • Attributions
• Azure Policy
  • Définitions (intégrées et personnalisées)
  • Initiatives, également appelées définitions fixées
  • Attributions

Que se passe-t-il si vous ne souhaitez pas déployer la hiérarchie du groupe d’administration canary ?

Si vous ne souhaitez pas déployer la hiérarchie du groupe d’administration canary, vous pouvez tester les ressources de la plateforme dans la hiérarchie de l’environnement de production en utilisant des abonnements de bac à sable, comme illustré dans le diagramme.

Figure 2 : Hiérarchie des groupes d’administration des zones d’atterrissage Azure mettant en évidence les bacs à sable (sandbox).

Pour tester la stratégie Azure et le contrôle d’accès en fonction du rôle (RBAC) dans ce scénario, vous avez besoin d’un seul abonnement Azure avec le rôle RBAC Propriétaire attribué à l’identité sous laquelle vous souhaitez conduire le test, par exemple, l’identité du compte d’utilisateur, du principal ou du service géré. Cette configuration vous permet de créer, d’affecter et de corriger les définitions et affectations de politiques Azure uniquement dans le cadre de l’abonnement sandbox.

Cette approche du bac à sable permet également de tester le RBAC au sein de l’abonnement, par exemple, si vous développez un nouveau rôle RBAC personnalisé afin d’accorder des autorisations pour un cas d’usage particulier. Vous pouvez effectuer ce test entièrement dans l’abonnement de bac à sable avant de créer et d’attribuer des rôles plus haut dans la hiérarchie.

L’avantage de cette approche est que vous pouvez utiliser les abonnements de test aussi longtemps que nécessaire, et ensuite les supprimer de l’environnement.

Toutefois, cette approche ne vous permet pas de tester avec l’héritage du RBAC et des stratégies Azure à partir de la hiérarchie du groupe d’administration.

Conseils d’implémentation

Vous trouverez ci-dessous des conseils sur la façon d’implémenter et d’utiliser la hiérarchie du groupe d’administration Canary pour les zones d’atterrissage Azure, en même temps qu’une hiérarchie de groupe d’administration d’environnement de production des zones d’atterrissage Azure.

Avertissement

Si vous utilisez le portail pour déployer et gérer votre environnement de zones d’atterrissage Azure aujourd’hui, il peut être difficile d’adopter et d’utiliser efficacement l’approche Canary en raison d’un risque élevé de désynchronisation fréquente des environnements de production et des environnements Canary, qui ne fournissent donc pas de hiérarchie et d’environnement de production de type réplica.

Envisagez de passer à une approche de déploiement d’Infrastructure as Code (IaC) pour les zones d’atterrissage Azure, comme indiqué ci-dessus, si vous êtes dans ce scénario. Découvrez aussi les risques potentiels de dérive des configurations entre Canary et la production, et procédez donc avec précaution. Pour plus d’informations, consultez Utiliser IaC pour mettre à jour les zones d’atterrissage Azure.

1. Utilisez des noms de principal du service (SPN) ou des identités managées Microsoft Entra distincts, qui sont des autorisations accordées sur la hiérarchie du groupe d’administration des zones d’atterrissage Azure de l’environnement de production ou de l’environnement de contrôle de validité.
   • Cette aide suit le principe du privilège minimum
2. Utilisez des dossiers distincts au sein d’un dépôt Git, des branches ou des dépôts pour contenir l’infrastructure en tant que code pour les déploiements de zones d’atterrissage Azure de l’environnement de production et de l’environnement Canary.
   • Utilisation de principaux de service (SPN) ou d’identités managées Microsoft Entra appropriés dans le cadre des pipelines de CI/CD, en fonction de la hiérarchie en cours de déploiement.
3. Implémentez des stratégies ou une sécurité de branche Git pour l’environnement canary comme celles que vous avez mises en place pour l’environnement de production.
   • Envisagez de réduire le nombre d’approbateurs et de vérifications pour l’environnement canary afin de provoquer une interruption immédiate (fail-fast).
4. Utilisez les mêmes Azure Pipelines ou GitHub Actions qui utilisent des variables d'environnement pour changer quelle hiérarchie est déployée. Une autre option consiste à cloner les pipelines et à modifier les paramètres codés en dur afin de définir la hiérarchie déployée.
   • L’utilisation de modèles DevOps Azure Pipelines ou de modèles de flux de travail GitHub Actions vous aidera à respecter le principe Don’t Repeat Yourself (DRY).
5. Disposez d’un ensemble d’abonnements canary sous un compte de facturation distinct, par exemple un compte Contrat Entreprise (EA) ou une section de facture MCA (Contrat client Microsoft), qui peut être déplacée autour de la hiérarchie des groupes d’administration canary en fonction des besoins.
   • Il peut être utile d’avoir un ensemble de ressources toujours déployées dans les abonnements à l’environnement canary pour accélérer le test et la validation des modifications apportées à l’environnement canary.
6. Disposez d’un ensemble d’exemples d’architectures de charge de travail d’application que vous pouvez déployer dans les abonnements canary dans l’environnement canary pour tester les modifications Azure Policy et RBAC. Cela vous permet de valider les modifications avant de déployer et de promouvoir les modifications en production.
   • Ces exemples de charges de travail peuvent être déployés à l’aide des mêmes modèles IaC que ceux utilisés pour déployer les charges de travail d’application de production. Cela vous aidera à vous assurer que l’environnement canary est synchronisé avec l’environnement de production et que les modifications que vous testez sont valides et applicables à l’environnement de production.
   • Vous devez examiner et mettre à jour en continu les exemples de charges de travail pour vous assurer qu’elles sont pertinentes et à jour avec les derniers modèles d’architecture et de conception de votre organisation.
   • Si vous fournissez des architectures de référence à vos équipes d’applications, envisagez également de les déployer dans l’environnement canary. Cela vous permet de valider les modifications par rapport aux architectures de référence et de s’assurer qu’elles sont applicables à l’environnement de production.
7. Envoyez tous les journaux d’activité Azure pour tous les abonnements Azure, y compris les abonnements de l’environnement Canary, à l’espace de travail Azure Log Analytics conformément aux recommandations de conception des zones d’atterrissage Azure.
   • Cela permet à vos équipes de sécurité et d’exploitation de surveiller l’environnement canary pour les modifications ou problèmes susceptibles de survenir à partir du test d’Azure Policy et des modifications RBAC apportées à l’environnement de production.

Conseil

Si vous avez déjà des zones d’atterrissage Azure déployées en production et que vous cherchez maintenant à ajouter un environnement Canary. Envisagez de cloner votre déploiement actuel de la hiérarchie de l’environnement de production et de modifier les noms des ressources en les préfixant avec votre schéma de nommage Canary.

Ceci est destiné à garantir que ce que vous déployez pour activer l’environnement Canary est synchronisé avec la production depuis le début. Cette opération est facilement obtenue lors de l’utilisation d’un outil IaC en même temps qu’un dépôt Git.

Utilisation d’un seul locataire Microsoft Entra

Les considérations à prendre en compte lorsque vous utilisez un seul locataire Microsoft Entra sont les suivantes :

• L’utilisation d’un seul locataire suit les recommandations de conception des zones d’atterrissage Azure pour les locataires Microsoft Entra.
  • Dans un locataire Microsoft Entra unique, vous pouvez utiliser les différents groupes Microsoft Entra tant pour les environnements de production que pour les environnements de zones d’atterrissage Azure de contrôle de validité, avec les mêmes utilisateurs attribués à leur hiérarchie de groupe d’administration pertinente.
• Augmentation ou duplication des coûts de licence Microsoft Entra ID en raison d’identités multiples dans différents locataires Microsoft Entra. Cela s’applique particulièrement aux clients qui utilisent des fonctionnalités Microsoft Entra ID P1 ou P2.
• Les modifications de RBAC sont plus complexes dans des environnements de contrôle de validité et de production, car il est improbable que les utilisateurs et les groupes soient identiques dans les deux locataires Microsoft Entra.
  • Considérez que les ID d’utilisateurs et de groupes ne seront pas les mêmes dans les locataires Microsoft Entra, car ils sont globalement uniques.
• Réduit la complexité et la surcharge qu’entraîne la gestion de plusieurs locataires Microsoft Entra.
  • Les utilisateurs privilégiés qui doivent conserver l’accès et se connecter à des locataires distincts pour effectuer des tests peuvent apporter des modifications accidentelles à l’environnement de production au lieu de l’environnement canary, par exemple.
• Réduit la probabilité d'une dérive de configuration et d'échecs de déploiement.
• Un locataire Azure AD unique ne nécessite pas de créer des processus supplémentaires de sécurité et d’accès d’urgence ou de secours.
• Réduit la friction et le temps nécessaires pour implémenter des modifications du déploiement de zones d’atterrissage Azure.

Étapes suivantes

Une fois que vous disposez d’un environnement canary, vous pouvez commencer à tester les modifications Azure Policy et RBAC avant de les déployer dans votre hiérarchie de groupe d’administration des zones d’atterrissage Azure de production.

Lorsque vous avez testé les modifications apportées aux stratégies Azure dans l’environnement canary, vous pouvez ensuite les promouvoir vers l’environnement de production en suivant la même approche que celle décrite dans les conseils d’adoption des garde-fous pilotés par la stratégie. Pour ce faire, utilisez la fonctionnalité de mode d’application des affectations de stratégie. L’utilisation de l’approche décrite dans cette aide vous permet de passer à une phase de test supplémentaire avant d’appliquer Azure Policy dans l’environnement de production dans son effet souhaité, ce qui vous aidera à renforcer la confiance dans les modifications apportées à Azure Policy que vous apportez.

Vous pouvez également passer en revue les environnements de bac à sable à utiliser par vos équipes d'applications pour développer et tester leurs charges de travail. Il s'agit d'un concept distinct de l'environnement canary et il est utilisé pour fournir un environnement sécurisé dans lequel les équipes d'applications peuvent développer et tester leurs charges de travail avant leur déploiement en production.

Implémenter des environnements de bac à sable de la zone d’atterrissage