Personnaliser l’architecture d’une zone d’atterrissage Azure pour répondre aux besoins
Dans le cadre des recommandations relatives à la zone d’atterrissage Azure, plusieurs options d’implémentation de référence sont disponibles :
- Zone d’atterrissage Azure avec Azure Virtual WAN
- Zone d’atterrissage Azure avec hub-and-spoke traditionnel
- Base de la zone d’atterrissage Azure
- Zone d’atterrissage Azure pour les petites entreprises
Ces options peuvent aider votre organisation à démarrer rapidement, grâce à des configurations qui fournissent l’architecture conceptuelle 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 issues de l’engagement des clients et des partenaires. Cette connaissance représente le « 80 » % de la règle 80/20. Les différentes implémentations adoptent des positions sur les décisions techniques qui font partie du processus de conception de l’architecture.
Comme tous les cas d’usage ne sont pas identiques, toutes les organisations ne peuvent pas nécessairement utiliser une approche d’implémentation de la façon exacte prévue. Vous devez comprendre les points à prendre en compte lorsqu’une exigence de personnalisation 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 attendues en matière d’environnement et de conformité à une étendue spécifique. Voici quelques exemples :
- Affectations Azure Policy.
- Affectations de contrôle d’accès en fonction du rôle (RBAC).
- Ressources managées de manière centralisée, comme la mise en réseau, notamment.
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 y 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 contraire, il fait partie de l’infrastructure utilisée pour implémenter chacun des archétypes de zone d’atterrissage dans votre environnement.
Vous pouvez voir cette relation dans l’architecture conceptuelle de la zone d’atterrissage Azure. Les affectations de stratégies sont créées au niveau du groupe d’administration racine intermédiaire, par exemple Contoso, pour les paramètres qui doivent s’appliquer à toutes les charges de travail. D’autres affectations de stratégies sont créées à des niveaux inférieurs de la hiérarchie pour des besoins plus spécifiques.
La sélection élective de l’abonnement dans la hiérarchie des groupes d’administration détermine les résultats des affectations Azure Policy et de contrôle d’accès (IAM) héritées et appliquées à cette zone d’atterrissage particulière (abonnement Azure).
Des processus et des outils supplémentaires peuvent être nécessaires pour s’assurer qu’une zone d’atterrissage dispose des ressources managées de manière centralisée requises. 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 le 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 contre le déni de service distribué (DDoS).
Notes
Dans les implémentations de référence de zone d’atterrissage Azure, les stratégies Azure avec les effets DeployIfNotExists et 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 basée sur une stratégie.
Pour plus d’informations, consultez Adoption de garde-fous pilotés par la stratégie.
Archétypes intégrés pour l’architecture conceptuelle d’une 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 en ligne. Ces archétypes peuvent s’appliquer à votre organisation et répondre à vos besoins. Vous pouvez modifier ces archétypes ou en créer. Votre décision dépend des besoins et des exigences de votre organisation.
Conseil
Pour examiner les archétypes de zone d’atterrissage dans l’accélérateur de zone d’atterrissage Azure, consultez Groupes d’administration dans l’accélérateur de zone d’atterrissage Azure.
Vous pouvez également créer des modifications ailleurs dans la hiérarchie des ressources. Lorsque vous planifiez la hiérarchie de votre implémentation de 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 | Le groupe d’administration dédié pour les zones d’atterrissage de l’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 | Le 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é directe Internet entrante/sortante ou pour les charges de travail qui ne nécessitent pas de réseau virtuel. |
| Bac à sable | Le groupe d’administration dédié pour les abonnements qui seront utilisés uniquement pour les tests et l’exploration par une organisation. Ces abonnements seront déconnectés en toute sécurité des zones d’accueil d’entreprise et en ligne. Les bacs à sable disposent également d’un ensemble de stratégies moins restrictif affecté pour activer les tests, l’exploration et la configuration des services Azure. |
Scénarios où une personnalisation peut être requise
Comme mentionné, nous fournissons des archétypes de zone d’atterrissage courants dans Architecture conceptuelle d’une zone 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 personnaliser les archétypes de zone d’atterrissage en fonction de vos besoins et de vos 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 illustre la hiérarchie par défaut de l’architecture conceptuelle de la zone d’atterrissage Azure.
Deux zones de la hiérarchie sont mises en surbrillance. L’une se trouve sous Zones d’atterrissage, et l’autre se trouve sous Plateforme.
Personnaliser des archétypes de zone d’atterrissage d’application
Remarquez la zone mise en surbrillance en bleu sous le groupe d’administration Zones d’atterrissage. C’est l’emplacement le plus courant et le plus sûr de la hiérarchie pour ajouter des archétypes supplémentaires afin de répondre à des exigences nouvelles ou plus nombreuses qui ne peuvent pas être ajoutées en tant qu’affectations de stratégies supplémentaires à un archétype existant en utilisant 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 d’être appliquée à 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 stratégie 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.
Maintenant, vous pouvez 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, formant ainsi le nouvel archétype.
Un autre exemple est Microsoft Cloud for Sovereignty, qui ajoute des groupes d’administration pour le calcul confidentiel et est conçu pour une utilisation dans des secteurs d'activité réglementés. Microsoft Cloud for Sovereignty fournit des outils, des conseils et des garde-fous pour l’adoption du cloud public avec des contrôles de souveraineté appropriés.
Conseil
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 par rapport au contrôle d’accès en fonction du rôle (RBAC) et à Azure Policy. Pour plus d’informations, consultez l’article Migrer des environnements Azure existants vers l’architecture conceptuelle de la zone d’atterrissage Azure.
Personnaliser des archétypes de zone d’atterrissage de plateforme
Vous pouvez également souhaiter de personnaliser la zone mise en surbrillance en orange, sous le groupe d’administration Plateforme. Ces zones sont appelées zones d’atterrissage de plateforme.
Par exemple, vous pouvez avoir une équipe SOC dédiée qui a besoin de son propre archétype pour héberger ses charges de travail. Ces charges de travail doivent répondre à es 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.
Maintenant, vous pouvez 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, formant ainsi le nouvel archétype.
Exemple d’une 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 d’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 la hiérarchie par défaut que nous fournissons conviennent à la plupart des scénarios.
Ne recréez pas votre hiérarchie d’organisation, vos équipes ou vos services dans les archétypes.
Essayez toujours de vous baser sur les archétypes et la hiérarchie existants pour répondre aux nouvelles exigences.
Créez uniquement de nouveaux archétypes si nécessaire.
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 d’être appliquée à toutes les charges de travail.
Créez uniquement de nouveaux archétypes dans les zones mises en surbrillance dans les diagrammes précédents.
Évitez d’aller au-delà de quatre couches de profondeur de hiérarchie pour éviter la complexité et les exclusions inutiles. Développez des archétypes horizontalement plutôt que verticalement dans la hiérarchie.
Ne créez pas d’archétypes pour les environnements tels que les environnements de développement, de test et de production.
Pour plus d’information, 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 de gestion 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