Approche de test de la zone 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 peuvent souhaiter tester le déploiement, par l’accélérateur de zone d’atterrissage de plateforme, des définitions et des attributions Azure Policy, des rôles personnalisés et des attributions du contrôle d’accès basé sur les rôles (RBAC), et ainsi de suite. 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. Ces conseils fournissent une approche qui peut être utilisée pour tester les modifications et leur impact sur un déploiement d’accélérateur de zone d’atterrissage de plateforme.

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, cela peut être combiné avec les recommandations de Adopter des garde-fous pilotés par des stratégies pour connaître les techniques permettant de déployer des modifications de stratégie dans un déploiement de zone d’atterrissage de plateforme.

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 n’importe quel nom que vous jugez approprié pour votre environnement de zone 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 de zone d’atterrissage de la plateforme que votre organisation peut avoir en place qui contient les abonnements et les 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. Ils sont placés et gérés dans l’environnement de production, au sein de la hiérarchie des groupes d’administration des zones d’atterrissage Azure, ainsi que dans la gouvernance associée (RBAC et Azure Policy).

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

Cette aide concerne uniquement les tests au niveau de la plateforme et les modifications dans le contexte d’une zone d’atterrissage Azure.

Azure conseils sur les zones d’atterrissage vous aide à 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 un déploiement d’accélérateur de zone d’atterrissage de plateforme.

Diagramme de la hiérarchie du groupe d’administration avec l’approche de test de l’environnement canary.

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 l’environnement de la zone 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 identifiants de groupe de gestion doivent être uniques au sein d’un seul locataire Microsoft Entra. Le tenant considère les ID de groupe d’administration comme les identifiants de référence ; ils doivent donc être distincts dans l’ensemble du tenant. Vous pouvez faire en sorte que les noms d’affichage des groupes d’administration restent alignés sur la hiérarchie des groupes d’administration de production. Ajoutez également une distinction de nommage aux noms d’affichage, afin que les utilisateurs puissent distinguer visuellement la hiérarchie canary de la production lors de la navigation dans l’arborescence du groupe d’administration.

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.

Diagramme de l’approche de test qui utilise des bacs à sable.

Figure 2 : Hiérarchie des groupes d’administration de la zone d’atterrissage Azure mettant en évidence les environnements de test.

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 de groupes d’administration canary pour une zone d’atterrissage Azure, aux côtés d’une hiérarchie de groupes d’administration de zone d’atterrissage Azure pour un environnement de production.

Avertissement

Si vous utilisez actuellement le portail pour déployer et gérer votre environnement d'accélérateur de zone d'atterrissage de plateforme, il peut être difficile d’adopter et d’utiliser efficacement l’approche canary, car il existe un risque élevé que les environnements de production et canary se désynchronisent fréquemment et n’offrent donc pas une hiérarchie ni un environnement fidèles à ceux de la production.

Envisagez de passer à une approche de déploiement IaC (Infrastructure as Code) pour déployer votre accélérateur de zone d’atterrissage de plateforme, 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 votre zone d’atterrissage Azure.

  1. Utilisez des principaux de service Microsoft Entra (SPN) ou des identités managées (MI), qui sont des autorisations accordées sur la hiérarchie du groupe d’administration de la zone d'atterrissage Azure de l'environnement de production ou de l’environnement canary pertinent.
    • Cette aide suit le principe du privilège minimum
  2. Utilisez des dossiers distincts au sein d’un référentiel Git, des branches ou des référentiels distincts pour héberger l’IaC des déploiements de zones d’atterrissage Azure pour les environnements de production et 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.
  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 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 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 de charge de travail, 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 de tous les abonnements Azure, y compris les abonnements de l’environnement canary, vers l’espace de travail Azure Log Analytics de l’environnement de production, conformément aux recommandations de conception de la zone 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 disposez déjà d’une zone d’atterrissage Azure déployée en production et que vous envisagez maintenant d’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 pour les préfixer 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 locataire unique est conforme aux recommandations de conception de la zone d’atterrissage Azure pour les locataires Microsoft Entra.
    • Dans un seul locataire Microsoft Entra, vous pouvez utiliser les différents groupes de Microsoft Entra pour les environnements de zone d’atterrissage de production et de canari Azure avec les mêmes utilisateurs affectés à leur hiérarchie de groupe d’administration appropriée.
  • 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 les frictions et le temps nécessaire pour implémenter les modifications apportées au déploiement de zone d’atterrissage Azure.

Étapes suivantes

Une fois que vous avez un environnement canary en place, vous pouvez commencer à tester les modifications Azure Policy et RBAC avant de les déployer dans votre hiérarchie de groupe d’administration de zone d’atterrissage Azure 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 examiner les environnements sandbox que vos équipes responsables des charges de travail peuvent utiliser pour le développement et les tests de leurs charges de travail. Il s’agit d’un concept distinct de l’environnement canary, qui sert à fournir aux équipes responsables des charges de travail un environnement sûr pour développer et tester leurs charges de travail avant de les déployer en production.

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

  • Dernière mise à jour :