Partager via

FAQ sur la zone d’atterrissage Azure

  • Article

Cet article répond aux questions fréquemment posées sur l'architecture des zones d'atterrissage Azure.

Pour accéder aux FAQ relatifs à l’architecture de la zone d'atterrissage Azure, consultez FAQ sur l'implémentation du modèle à l'échelle de l'entreprise.

Qu'est-ce que l'accélérateur de zone d'atterrissage Azure ?

L’accélérateur de zone d’atterrissage Azure est une expérience de déploiement basée sur le portail Azure. Il déploie une implémentation bien cadrée basée sur l'architecture conceptuelle de la zone d'atterrissage Azure.

Microsoft développe et gère activement les accélérateurs et les implémentations de plateforme et d’application en alignement avec les principes de conception de la zone d’atterrissage Azure et les conseils sur la zone de conception .

Consultez les instructions déployer des zones d’atterrissage Azure pour en savoir plus sur les zones d’atterrissage de plateforme et d’application recommandées.

Pour savoir comment personnaliser votre déploiement de zones d’atterrissage Azure en fonction de vos besoins, consultez Personnaliser l’architecture de zone d’atterrissage Azure pour répondre aux exigences

Conseil

Pour demander un ajout à la liste de l’accélérateur et de l’implémentation, soulevez un problème GitHub sur le dépôt ALZ.

Qu'est-ce que l'architecture conceptuelle de la zone d'atterrissage Azure ?

L’architecture conceptuelle de la zone d’atterrissage Azure représente les décisions de mise à l’échelle et de maturité. Elle s'appuie sur les enseignements tirés et les commentaires des clients qui ont adopté Azure au sein de leur patrimoine numérique. Cette architecture conceptuelle peut aider votre organisation à définir une orientation pour la conception et l'implémentation d'une zone d'atterrissage.

À quoi correspond une zone d’atterrissage dans Azure dans le contexte d’une architecture de zone d'atterrissage Azure ?

Du point de vue de la zone d'atterrissage Azure, les zones d'atterrissage sont des abonnements Azure individuels.

Qu'est-ce que la gouvernance basée sur une stratégie et comment fonctionne-t-elle ?

La gouvernance basée sur une stratégie est l'un des principes de conception clés de l'architecture à l'échelle de l'entreprise.

La gouvernance basée sur une stratégie consiste à utiliser Azure Policy pour réduire le temps nécessaire à l'exécution de tâches opérationnelles courantes et répétées dans votre locataire Azure. Utilisez de nombreux effets d'Azure Policy, comme Append, Deny, DeployIfNotExists et Modify, pour prévenir les problèmes de non-conformité en empêchant la création ou la mise à jour de ressources non conformes (telles que définies par la définition de la stratégie), en déployant des ressources ou en modifiant les paramètres d'une demande de création ou de mise à jour de ressources pour les rendre conformes. Certains effets, tels que Audit, Disabled et AuditIfNotExists n'assurent aucune prévention ou action ; ils se contentent de vérifier et de signaler les problèmes de non-conformité.

Voici quelques exemples de gouvernance basée sur une stratégie :

  • Effet Deny : empêche la création ou la mise à jour de sous-réseaux auxquels aucun groupe de sécurité réseau n'est associé.

  • DeployIfNotExistsEffet : un nouvel abonnement (zone d'atterrissage) est créé et placé dans un groupe d'administration au sein de votre déploiement de zone d'atterrissage Azure. Azure Policy garantit que Microsoft Defender pour le cloud (anciennement appelé Azure Security Center) est activé sur l’abonnement. Il configure également les paramètres de diagnostic du journal d’activité pour envoyer les journaux à l’espace de travail Log Analytics dans l’abonnement de gestion.

    Au lieu de répéter du code ou des activités manuelles lors de la création d'un nouvel abonnement, la définition de stratégie DeployIfNotExists les déploie et les configure automatiquement pour vous.

Que se passe-t-il si nous ne pouvons pas utiliser des stratégies DeployIfNotExists (DINE) ou que nous ne sommes pas prêts à les utiliser ?

Nous avons une page dédiée qui décrit les différentes phases et options que vous avez pour « désactiver » les stratégies DINE ou pour utiliser notre approche en trois phases afin de les adopter au fil du temps dans votre environnement.

Consultez les conseils de Adoption de garde-fous pilotés par les stratégies

Devons-nous utiliser Azure Policy pour déployer des charges de travail ?

En bref, non. Utilisez Azure Policy pour contrôler, gérer et maintenir la conformité de vos charges de travail et zones d’atterrissage. Il n’est pas conçu pour déployer des charges de travail entières et d’autres outils. Utilisez le portail Azure ou les offres d'infrastructure-as-code (modèles Resource Manager, Bicep, Terraform) pour déployer et gérer votre charge de travail et bénéficier de l’autonomie dont vous avez besoin.

Que sont les zones d’atterrissage Cloud Adoption Framework pour Terraform (aztfmod) ?

Le projet open source (OSS) (aussi appelé aztfmod) de zones d’atterrissage Cloud Adoption Framework est un projet communautaire détenu et géré en dehors de l’équipe principale des zones d’atterrissage Azure et de l’organisation Azure GitHub. Si votre organisation choisit d’utiliser ce projet OSS, vous devez prendre en compte le support disponible, car il repose sur les efforts de la communauté via GitHub.

Que se passe-t-il si nous avons déjà des ressources dans nos zones d’atterrissage et que nous attribuons ultérieurement une définition Azure Policy qui inclut celles-ci dans son étendue ?

Consultez les sections suivantes de la documentation :

Comment gérer les zones d’atterrissage de charge de travail « dev/test/production » dans l’architecture des zones d’atterrissage Azure ?

Pour plus d'informations, consultez la section Gérer les environnements de développement d'applications dans les zones d'atterrissage Azure.

Pourquoi nous demande-t-on de spécifier des régions Azure lors du déploiement de l'accélérateur de zone d'atterrissage Azure et à quoi servent-elles ?

Lorsque vous déployez une architecture de zone d'atterrissage Azure à l’aide de l’accélérateur de zone d’atterrissage Azure basé sur le portail, sélectionnez une région Azure dans laquelle effectuer le déploiement. Le premier onglet, Emplacement du déploiement, détermine l'emplacement où les données de déploiement sont stockées. Pour plus d'informations, consultez Déploiements de locataires avec des modèles Resource Manager. Certaines parties d’une zone d’atterrissage sont déployées globalement, mais leurs métadonnées de déploiement sont suivies dans un magasin de métadonnées régional. Les métadonnées relatives à leur déploiement sont stockées dans la région sélectionnée dans l'onglet Emplacement du déploiement.

Le sélecteur de région de l’onglet Emplacement de déploiement est également utilisé pour sélectionner la région Azure où les ressources spécifiques à une région doivent être stockées, comme un espace de travail Log Analytics et un compte Automation, si nécessaire.

Si vous déployez une topologie de réseau sous l’onglet Topologie et connectivité du réseau, vous devez sélectionner une région Azure où déployer les ressources réseau. Cette région peut être différente de la région sélectionnée dans l’onglet Emplacement de déploiement.

Pour plus d’informations sur les régions utilisées par les ressources de la zone d’atterrissage, consultez Régions de zone d’atterrissage.

Comment activer davantage de régions Azure lorsque nous utilisons une architecture de zone d'atterrissage Azure ?

Pour comprendre comment ajouter de nouvelles régions à une zone d’atterrissage ou comment déplacer des ressources de zone d’atterrissage vers une autre région, consultez Régions de zone d’atterrissage.

Doit-on créer un abonnement Azure chaque fois ou peut-on réutiliser les abonnements Azure ?

Qu’est-ce que la réutilisation des abonnements ?

La réutilisation des abonnements est le processus de réattribution d’un abonnement existant à un nouveau propriétaire. Il doit y avoir un processus de réinitialisation de l’abonnement à un état propre connu, puis sa réattribution à un nouveau propriétaire.

Pourquoi réutiliser des abonnements ?

En général, nous recommandons aux clients d’adopter le principe de conception de démocratisation des abonnements. Toutefois, dans certaines circonstances la réutilisation de l’abonnement n’est pas possible ni recommandée.

Conseil

Regardez la vidéo YouTube sur le principe de conception de démocratisation des abonnements ici : Azure Landing Zones - How many subscriptions should I use in Azure?

Vous devez réfléchir à la réutilisation des abonnements si vous rencontrez l’une des circonstances suivantes :

  • Vous avez un Contrat Entreprise (EA) et prévoyez de créer plus de 5 000 abonnements sur un seul compte de propriétaire du compte EA (compte de facturation), y compris les abonnements supprimés.
  • Vous avez un Contrat client Microsoft (MCA) ou un Contrat Partenaire Microsoft (MPA) et vous prévoyez d’avoir plus de 5 000 abonnements actifs. Pour en savoir plus sur les limites de l'abonnement, consultez Comptes et étendues de facturation dans le portail Azure.
  • Vous êtes un client du paiement à l’utilisation.
  • Vous utilisez Microsoft Azure Sponsorship.
  • Vous créez généralement :
    1. Des environnements lab ou de bac à sable éphémères
    2. Des environnements de démo pour les preuves de concept ou les produits minimum viables (MVP), y compris les éditeurs de logiciels indépendants (ISV) pour l’accès des clients à la démo/l’essai
    3. Des environnements de formation, comme les environnements d’apprenants MSP/ du formateur

Comment réutiliser les abonnements ?

Si vous êtes en présence d’un des scénarios ou considérations ci-dessus, vous devez peut-être réutiliser les abonnements désactivés ou inutilisés existants, et les réattribuer à un nouveau propriétaire avec un nouvel objectif.

Nettoyer l’ancien abonnement

Vous devez d’abord nettoyer l’ancien abonnement pour le réutiliser. Vous devez effectuer les actions suivantes sur un abonnement pour qu’il soit réutilisable :

  • Supprimer les groupes de ressources et les ressources qu’il contiennent.
  • Supprimer les attributions de rôle, y compris les attributions de rôle Privileged Identity Management (PIM), dans l’étendue de l’abonnement.
  • Supprimer les définitions personnalisées du contrôle d’accès en fonction du rôle (RBAC) dans l’étendue de l’abonnement.
  • Supprimer les définitions, initiatives, attributions et exemptions de stratégie dans l’étendue de l’abonnement.
  • Supprimer les déploiements dans l’étendue de l’abonnement.
  • Supprimer les étiquettes dans l’étendue de l’abonnement.
  • Supprimer les verrous de ressource dans l’étendue de l’abonnement.
  • Supprimer les budgets Microsoft Cost Management dans l’étendue de l’abonnement.
  • Réinitialiser les plans Microsoft Defender pour le cloud sur les niveaux gratuits, sauf si les exigences de l’organisation imposent que ces journaux soient définis sur les niveaux payants. Vous appliquez normalement ces exigences via Azure Policy.
  • Supprimer le transfert des journaux d’activité d’abonnement (paramètres de diagnostic) vers les espaces de travail Log Analytics, Event Hubs, un compte de stockage ou toute autre destination prise en charge, sauf si les exigences de l’organisation imposent le transfert de ces journaux tant que l’abonnement est actif.
  • Supprimer toutes les délégations Azure Lighthouse dans l’étendue de l’abonnement.
  • Supprimer les ressources masquées de l’abonnement.

Conseil

L’utilisation de Get-AzResource ou az resource list -o table ciblée sur l’étendue de l’abonnement vous permet de trouver les ressources masquées ou restantes que vous devez supprimer avant la réattribution.

Réattribuer l’abonnement

Vous pouvez réattribuer l’abonnement après l’avoir nettoyé. Voici quelques activités courantes que vous pouvez effectuer dans le cadre du processus de réattribution :

  • Ajouter de nouvelles étiquettes et définir leurs valeurs sur l’abonnement.
  • Ajouter de nouvelles attributions de rôle, ou attributions de rôle Privileged Identity Management (PIM), dans l’étendue de l’abonnement pour les nouveaux propriétaires. En règle générale, ces attributions s’adressent à des groupes Microsoft Entra plutôt qu’à des individus.
  • Placer l’abonnement dans le groupe d’administration souhaité en fonction de ses exigences de gouvernance.
  • Créer des budgets Microsoft Cost Management et définir des alertes pour les nouveaux propriétaires quand les seuils sont atteints.
  • Définir des plans Microsoft Defender pour le cloud sur les niveaux souhaités. Vous devez appliquer ce paramètre via Azure Policy une fois dans le groupe d’administration approprié.
  • Configurer le transfert des journaux d’activité d’abonnement (paramètres de diagnostic) vers les espaces de travail Log Analytics, Event Hubs, un compte de stockage ou toute autre destination prise en charge. Vous devez appliquer ce paramètre via Azure Policy une fois dans le groupe d’administration approprié.

La zone d’atterrissage souveraine est un composant de Microsoft Cloud for Sovereignty destiné aux clients du secteur public qui ont besoin de contrôles de souveraineté avancés. En tant que version personnalisée de l’architecture conceptuelle de la zone d’atterrissage Azure, la zone d’atterrissage souveraine aligne les fonctionnalités Azure telles que la résidence des services, les clés gérées par le client, Azure Private Link et l’informatique confidentielle. Grâce à cet alignement, la zone d’atterrissage souveraine crée une architecture cloud où les données et charges de travail offrent le chiffrement et la protection contre les menaces par défaut.

Remarque

Microsoft Cloud for Sovereignty est orienté vers les organisations gouvernementales ayant des besoins de souveraineté. Vous devez soigneusement déterminer si vous avez besoin des fonctionnalités de Microsoft Cloud for Sovereignty, puis envisager uniquement d’adopter l’architecture de la zone d’atterrissage souveraine.

Pour plus d’informations sur la zone d’atterrissage souveraine, consultez Considérations relatives à la souveraineté des zones d’atterrissage Azure.