Adapter l’architecture de la zone d’atterrissage Azure pour répondre aux exigences

Dans le cadre des conseils de zone d’atterrissage Azure, plusieurs options d’implémentation de référence sont disponibles.

Ces options peuvent aider votre organisation à démarrer rapidement en utilisant des configurations qui fournissent l’architecture de référence de la zone d’atterrissage Azure et les meilleures pratiques dans les domaines de conception.

Les implémentations de référence sont basées sur les meilleures pratiques et les apprentissages des équipes Microsoft à partir d’engagements avec les clients et les partenaires. Cette connaissance représente le côté « 80 » de la règle 80/20. Les différentes implémentations prennent des positions sur les décisions techniques qui font partie du processus de conception d’architecture.

Étant donné que tous les cas d’usage ne sont pas les mêmes, toutes les organisations ne peuvent pas utiliser une approche d’implémentation exacte de la façon prévue. Vous devez comprendre les considérations à prendre en compte lorsqu’une exigence d’adaptation est identifiée.

Qu’est-ce qu’un archétype de zone d’atterrissage dans les zones d’atterrissage Azure ?

Un archétype de zone d’atterrissage décrit ce qui doit être vrai pour garantir qu’une zone d’atterrissage (abonnement Azure) répond aux exigences d’environnement et de conformité attendues dans une étendue spécifique. Voici quelques exemples :

• Affectations Azure Policy.
• Attributions de contrôle d’accès en fonction du rôle (RBAC).
• Ressources gérées de manière centralisée, telles que la mise en réseau.

Considérez que chaque groupe d’administration dans la hiérarchie des ressources contribue au résultat de l’archétype de zone d’atterrissage finale en raison de la façon dont l’héritage de stratégie fonctionne dans Azure. Réfléchissez à ce qui est appliqué aux niveaux supérieurs de la hiérarchie des ressources lorsque vous concevez les niveaux inférieurs.

Il existe une relation étroite entre les groupes d’administration et les archétypes de zone d’atterrissage, mais un groupe d’administration seul n’est pas un archétype de zone d’atterrissage. Au lieu de cela, il fait partie du framework utilisé pour implémenter chacun des archétypes de zone d’atterrissage dans votre environnement.

Vous pouvez voir cette relation dans l’architecture de référence de la zone d’atterrissage Azure. Les affectations de politique sont établies au niveau du groupe de gestion racine intermédiaire, tel que Contoso, pour les paramètres qui doivent s'appliquer à l'ensemble des charges de travail. D’autres attributions de stratégie sont créées à des niveaux inférieurs de la hiérarchie pour des exigences plus spécifiques.

Le positionnement de l’abonnement dans la hiérarchie du groupe d’administration détermine l’ensemble des stratégies Azure et des affectations de contrôle d’accès (IAM) qui sont héritées, appliquées et imposées à cette zone d’atterrissage spécifique (abonnement Azure).

D’autres processus et outils peuvent être nécessaires pour s’assurer qu’une zone d’atterrissage dispose des ressources gérées de manière centralisée. Voici quelques exemples :

• Paramètres de diagnostic pour envoyer des données de journal d’activité à un espace de travail Log Analytics.
• Paramètres d’exportation continue pour Microsoft Defender pour cloud.
• Réseau virtuel avec des espaces d’adressage IP managés pour les charges de travail d’application.
• Liaison de réseaux virtuels à une protection réseau par déni de service distribué (DDoS).

Remarque

Dans les implémentations de référence de zone d’atterrissage Azure, les stratégies Azure avec DeployIfNotExists et les Modify sont utilisées pour réussir le déploiement de certaines des ressources citées ci-dessus. Ils suivent le principe de conception de la gouvernance orientée par les politiques.

Pour plus d’informations, consultez Adoptez des garde-fous pilotés par des politiques.

Archétypes intégrés pour l’architecture de référence de la zone d’atterrissage Azure

L’architecture conceptuelle inclut des exemples d’archétypes de zone d’atterrissage pour les charges de travail d’application telles que corp et online. Ces archétypes peuvent s’appliquer à votre organisation et répondre à vos besoins. Vous souhaiterez peut-être apporter des modifications à ces archétypes ou en créer de nouvelles. Votre décision dépend des besoins et des exigences de votre organisation.

Conseil / Astuce

Pour passer en revue les archétypes de zone d’atterrissage dans l’architecture de référence de la zone d’atterrissage Azure, consultez les groupes d’administration dans l’architecture de référence de la zone d’atterrissage Azure.

Vous pouvez également créer des modifications ailleurs dans la hiérarchie des ressources. Lorsque vous planifiez la hiérarchie pour votre implémentation des zones d’atterrissage Azure pour votre organisation, suivez les instructions dans les zones de conception.

Les exemples d’archétypes de zone d’atterrissage suivants de l’architecture conceptuelle vous aident à comprendre leur objectif et leur utilisation prévue :

Archétype de zone d’atterrissage (groupe d’administration)	Objectif ou utilisation
Corp	Groupe d’administration dédié pour les zones d’atterrissage d’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é.
En ligne	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é entrante/sortante Internet directe ou pour les charges de travail qui ne nécessitent pas de réseau virtuel.
Bac à sable	Groupe d’administration dédié pour les abonnements qui ne seront utilisés que pour les tests et l’exploration par une organisation. Ces abonnements seront déconnectés de manière sécurisée des zones d’atterrissage d’entreprise et en ligne. Les bacs à sable ont également un ensemble moins restrictif de stratégies affectées pour activer les tests, l’exploration et la configuration des services Azure.

Scénarios où la personnalisation peut être nécessaire

Comme mentionné, nous fournissons des archétypes de zone d’atterrissage courants dans l’architecture de référence des zones d’atterrissage Azure. Il s’agit des archétypes corp et en ligne. Ces archétypes ne sont pas fixes et ne sont pas les seuls archétypes de zone d’atterrissage autorisés pour les charges de travail d’application. Vous devrez peut-être adapter les archétypes de zone d’atterrissage en fonction de vos besoins et exigences.

Avant de personnaliser les archétypes de zone d’atterrissage, il est important de comprendre les concepts et de visualiser également la zone de la hiérarchie que nous vous suggérons de personnaliser. Le diagramme suivant montre la hiérarchie par défaut de l’architecture de référence de la zone d’atterrissage Azure.

Deux zones de la hiérarchie sont mises en surbrillance. L’une se trouve sous les zones d’atterrissage, et l’autre se trouve sous la plateforme.

Adapter les archétypes de zone cible d'application

Remarquez la zone mise en surbrillance en vert sous le groupe d’administration Zones d’atterrissage. Il s’agit de la place la plus courante et la plus sûre dans la hiérarchie pour ajouter d’autres archétypes pour répondre à de nouvelles exigences ou plus qui ne peuvent pas être ajoutées en tant qu’affectations de stratégie supplémentaires à un archétype existant à l’aide de la hiérarchie existante.

Par exemple, vous pouvez avoir une nouvelle exigence pour héberger un ensemble de charges de travail d’application qui doivent répondre aux exigences de conformité du secteur des cartes de paiement (PCI). Toutefois, cette nouvelle exigence n’a pas besoin de s’appliquer à toutes les charges de travail dans l’ensemble de votre patrimoine.

Il existe un moyen simple et sûr de répondre à cette nouvelle exigence. Créez un groupe d’administration appelé PCI sous le groupe d’administration Zones d’atterrissage dans la hiérarchie. Vous pouvez affecter d'autres stratégies comme l'initiative de conformité réglementaire Microsoft Defender pour le Cloud pour PCI v3.2.1:2018 au nouveau groupe d'administration PCI. Cette action forme un nouvel archétype.

Vous pouvez maintenant placer de nouveaux abonnements Azure ou déplacer des abonnements Azure existants dans le nouveau groupe d’administration PCI pour qu’il hérite des stratégies requises et forme le nouvel archétype.

Un autre exemple est Microsoft Sovereign Cloud, qui ajoute des groupes d’administration pour le calcul confidentiel et est aligné pour une utilisation dans les secteurs réglementés. Microsoft Sovereign Cloud fournit des outils, des conseils et des garde-fous pour l’adoption du cloud public avec des contrôles de souveraineté appropriés.

Conseil / Astuce

Vous devez savoir ce qu’il faut prendre en compte et ce qui se passe lorsque vous déplacez des abonnements Azure entre des groupes d’administration en relation avec RBAC et Azure Policy. Pour plus d’informations, consultez Transition d’environnements Azure existants vers l’architecture de référence de la zone d’atterrissage Azure.

Personnaliser les archétypes de zone d’atterrissage de la plateforme

Remarque

Le scénario détaillé dans cette section fait désormais partie de l’architecture de la zone d’atterrissage Azure par défaut. Vous pouvez toujours adapter les archétypes de zone d’atterrissage de la plateforme pour répondre à vos besoins en suivant l’exemple de scénario.

Vous pouvez également personnaliser la zone mise en surbrillance en orange sous le groupe d’administration Plateforme . Les zones de cette zone sont appelées zones d’atterrissage de plateforme.

Par exemple, vous pouvez avoir une équipe SOC dédiée qui nécessite son propre archétype pour héberger ses charges de travail. Ces charges de travail doivent répondre aux exigences d’affectation Azure Policy et RBAC différentes de celles du groupe d’administration.

Créez un groupe d’administration de sécurité sous le groupe d’administration Plateforme dans la hiérarchie. Vous pouvez lui attribuer les affectations Azure Policy et RBAC requises.

Vous pouvez maintenant placer de nouveaux abonnements Azure ou déplacer des abonnements Azure existants dans le nouveau groupe d’administration de sécurité pour qu’il hérite des stratégies requises et forme le nouvel archétype.

Exemple de hiérarchie de zone d’atterrissage Azure personnalisée

Le diagramme suivant montre une hiérarchie de zone d’atterrissage Azure personnalisée. Il utilise des exemples du diagramme précédent.

Éléments à prendre en considération

Tenez compte des points suivants lorsque vous envisagez de personnaliser votre implémentation des archétypes de zone d’atterrissage Azure dans la hiérarchie :

• La personnalisation de la hiérarchie n’est pas obligatoire. Les archétypes et hiérarchies par défaut que nous fournissons conviennent à la plupart des scénarios.

• Ne recréez pas votre hiérarchie organisationnelle, vos équipes ou vos services dans les archétypes.

• Essayez toujours de vous appuyer sur les archétypes et la hiérarchie existants pour répondre aux nouvelles exigences.

• Créez uniquement de nouveaux archétypes quand ils sont vraiment nécessaires.

  Par exemple, une nouvelle exigence de conformité telle que PCI est requise pour un sous-ensemble de charges de travail d’application et n’a pas besoin de s’appliquer à toutes les charges de travail.

• Créez uniquement de nouveaux archétypes dans les zones mises en surbrillance indiquées dans les diagrammes précédents.

• Évitez d’aller au-delà d’une profondeur hiérarchique de quatre couches pour éviter la complexité et les exclusions inutiles. Développez les archétypes horizontalement au lieu de verticalement dans la hiérarchie.

• Ne créez pas d’archétypes pour des environnements tels que le développement, le test et la production.

  Pour plus d’informations, consultez Comment gérer les zones d’atterrissage de charge de travail dev/test/production dans l’architecture conceptuelle des zones d’atterrissage Azure ?

• Si vous venez d’un environnement en friche ou si vous cherchez une approche pour héberger des abonnements dans le groupe d’administration des zones d’atterrissage avec des politiques en mode d’application « audit uniquement », évaluez le scénario : Transition d’un environnement en dupliquant un groupe d’administration des zones d’atterrissage