Zones d’atterrissage Azure - Considérations relatives à la conception des modules Bicep

Cet article contient des considérations relatives à la conception de la solution modularisée Zones d’atterrissage Azure (ALZ) - Bicep que vous pouvez utiliser pour déployer et gérer les fonctionnalités de plateforme de base de l’architecture conceptuelle de zone d’atterrissage Azure, comme décrit dans le Cloud Adoption Framework (CAF).

Bicep est un langage spécifique à un domaine (DSL) qui utilise la syntaxe déclarative pour déployer des ressources Azure. Il fournit une syntaxe concise, une cohérence des types fiable et une prise en charge de la réutilisation du code.

Une implémentation de cette architecture est disponible sur GitHub: Azure Landing Zones (ALZ) - Bicep Implementation. Vous pouvez l’utiliser comme point de départ et la configurer en fonction de vos besoins.

Notes

Il existe des implémentations pour plusieurs technologies de déploiement, notamment des modèles ARM et des modules Terraform basés sur le portail. Le choix de la technologie de déploiement ne devrait pas influencer le déploiement des zones d’atterrissage Azure.

Accélérateur ALZ Bicep

Vous trouverez des instructions pas à pas sur l’implémentation, l’automatisation et la maintenance de votre module ALZ Bicep avec l’accélérateur ALZ Bicep.

L’infrastructure de l’accélérateur ALZ Bicep a été développée pour fournir aux utilisateurs finaux la prise en charge de l’intégration et du déploiement d’ALZ Bicep à l’aide de pipelines CI/CD à part entière, la prise en charge des pipelines GitHub Actions et Azure DevOps, l’infrastructure dédiée pour rester synchronisé avec les nouvelles versions d’ALZ Bicep et modifier ou ajouter des modules personnalisés, ainsi que des conseils de stratégie de branchement et des pipelines de demande de tirage pour le linting et la validation des modules Bicep.

Concevoir

L’architecture tire parti de la nature modulaire d’Azure Bicep, et est composée de plusieurs modules. Chaque module encapsule une fonctionnalité de base de l’architecture conceptuelle des Zones d’atterrissage Azure. Les modules peuvent être déployés individuellement, mais il existe des dépendances à prendre en compte.

L’architecture propose l’inclusion de modules orchestrateurs pour simplifier l’expérience de déploiement. Les modules orchestrateurs peuvent être utilisés pour automatiser le déploiement des modules, et encapsuler différentes topologies de déploiement.

Modules

Un concept de base dans Bicep est l’utilisation de modules. Les modules vous permettent d’organiser les déploiements en regroupements logiques. Les modules permettent d’améliorer la lisibilité de vos fichiers Bicep en encapsulant les détails complexes de votre déploiement. Vous pouvez également facilement réutiliser des modules pour différents déploiements.

La possibilité de réutiliser les modules offre un avantage réel lors de la définition et du déploiement de zones d’atterrissage. Elle permet d’utiliser des environnements reproductibles et cohérents dans le code, tout en réduisant l’effort nécessaire au déploiement à grande échelle.

Couches et étapes

En plus des modules, l’architecture de zone d’atterrissage Bicep est structurée à l’aide d’un concept de couches. Les couches sont des groupes de modules Bicep destinés à être déployés ensemble. Ces groupes constituent des étapes logiques de l’implémentation.

Un avantage de cette approche par couches réside dans la possibilité d’étoffer votre environnement de façon incrémentielle au fil du temps. Par exemple, vous pouvez commencer par un petit nombre de couches. Vous pourrez ajouter les couches restantes à une étape ultérieure lorsque vous serez prêt.

Descriptions de module

Cette section fournit une vue d’ensemble générale des modules de base de cette architecture.

Couche	Module	Description	Liens utiles
Core	Groupes d'administration	Les groupes d’administration sont les ressources du plus haut niveau dans un locataire Azure. Les groupes d’administration vous permettent de gérer plus facilement vos ressources. Vous pouvez appliquer une stratégie au niveau d’un groupe d’administration, dont hériteront les ressources de niveau inférieur. Plus précisément, vous pouvez appliquer les éléments suivants au niveau d’un groupe d’administration, dont hériteront les abonnements sous celui-ci : Stratégies Azure Attributions de rôles de contrôle d’accès en fonction du rôle (RBAC) Azure Contrôle des coûts Ce module déploie la hiérarchie de groupes d’administration définie dans l’architecture conceptuelle de zone d’atterrissage Azure.	Groupes d’administration - documentation Cloud Adoption Framework (CAF) Module : Groupes d’administration - Implémentation de référence
Core	Définitions de stratégies personnalisées	DeployIfNotExists (DINE) ou Modifier des stratégies permettent de s’assurer que les abonnements et ressources composant des zones d’atterrissage sont conformes. Les stratégies facilitent également la gestion des zones d’atterrissage. Ce module déploie des définitions de stratégies personnalisées sur des groupes d’administration. Certains clients ne peuvent pas utiliser DINE ou Modifier des stratégies. Si vous êtes dans ce cas, consultez les Conseils du CAF sur les stratégies personnalisées.	Adopter des garde-garde-fous pilotés par les stratégies- Documentation CAF Module : Définitions de stratégies personnalisées - Implémentation de référence Définitions de stratégies personnalisées déployées dans des implémentations de référence
Core	Définitions de rôles personnalisés	Le contrôle d’accès en fonction du rôle (RBAC) simplifie la gestion des droits utilisateur au sein d’un système. Au lieu de gérer les droits des utilisateurs individuels, vous déterminez les droits requis pour différents rôles dans votre système. Un RBAC Azure comprend plusieurs rôles intégrés. Des définitions de rôles personnalisés vous permettent de créer des rôles personnalisés pour votre environnement. Ce module déploie des définitions de rôles personnalisés. Le module devrait suivre les Conseils du CAF sur le contrôle d’accès en fonction du rôle Azure.	Contrôle d’accès en fonction du rôle Azure - Documentation CAF Définitions de rôles personnalisés déployées dans une implémentation de référence
Gestion	Journalisation, Automation et Sentinel	Azure Monitor, Azure Automation et Microsoft Sentinel vous permettent de surveiller et de gérer votre infrastructure et vos charges de travail. Azure Monitor est une solution qui vous permet de collecter, d’analyser et de manipuler la télémétrie de votre environnement. Microsoft Sentinel est une solution SIEM (Gestion des informations et des événements de sécurité) native Cloud. Vous pouvez ainsi : Collecter - Collecter des données dans votre infrastructure toute entière Détecter - Détecter des menaces non détectées précédemment Répondre - Répondre à des menaces légitimes avec une orchestration intégrée Examiner - Examiner des menaces à l’aide de l’intelligence artificielle Azure Automation est un système d’automatisation basé sur le cloud. Il inclut : Gestion de la configuration - Inventaire et suivi des modifications pour les machines virtuelles Linux et Windows, et gestion de la configuration d’état souhaitée Gestion des mises à jour - Évaluation de la conformité du système Windows et Linux, et création de déploiements planifiés pour respecter la conformité Automatisation des processus - Automatisation des tâches de gestion Ce module déploie les outils nécessaires pour surveiller, gérer et consulter les menaces pour votre environnement. Ces outils doivent inclure Azure Monitor, Azure Automation et Microsoft Sentinel.	Gestion et surveillance de charge de travail - Documentation CAF Module : Jurnalisation, Automation et Sentinel – Implémentation de référence
Connectivité	Mise en réseau	La topologie réseau est une considération clé dans les déploiements de zones d’atterrissage Azure. CAF se concentre sur 2 approches de base de la mise en réseau : Topologies basées sur Azure Virtual WAN Topologies traditionnelles Ces modules déploient la topologie réseau que vous choisissez.	Définir une topologie de réseau Azure - Documentation CAF Modules : Déploiement de topologie réseau - Implémentation de référence
Identité	Affectations de rôles	La gestion des identités et des accès (IAM) est la principale limite de sécurité dans le cloud public. Le contrôle d’accès en fonction du rôle (RBAC) Azure vous permet d’effectuer des attributions de rôles intégrés ou des définitions de rôles personnalisés pour des principaux de sécurité. Ce module déploie des attributions de rôles sur des principaux de service, des identités gérées ou des groupes de sécurité dans des groupes d’administration et des abonnements. Le module doit suivre les Conseils du CAF sur la gestion des identités et des accès Azure.	Zone de conception de la gestion des identités et des accès Azure - Documentation CAF Module : Attributions de rôles pour des groupes d’administration et des abonnements – Implémentation de référence
Core	Placement d’abonnement	Les abonnements affectés à un groupe d’administration héritent de ce qui suit : Stratégies Azure Attributions de rôles de contrôle d’accès en fonction du rôle (RBAC) Azure Contrôle des coûts Ce module déplace les abonnements sous le groupe d’administration approprié.	Groupes d’administration - documentation Cloud Adoption Framework (CAF) Module : Placement d’abonnement
Core	Affectations de stratégies intégrées et personnalisées	Ce module déploie les affectations Azure Policy de zone d’atterrissage Azure par défaut sur des groupes d’administration. Il crée également des attributions de rôles pour des identités gérées affectées par le système créées par des stratégies.	Adopter des garde-garde-fous pilotés par les stratégies- Documentation CAF Module : Attributions de stratégie par défaut ALZ
Gestion	Modules orchestrateurs	Les modules orchestrateurs peuvent considérablement améliorer l’expérience de déploiement. Ces modules encapsulent le déploiement de plusieurs modules dans un seul. Cela masque la complexité à l’utilisateur final.	Module : Orchestration – hubPeeredSpoke – Réseau Spoke, y compris peering vers Hub (Hub Spoke ou Virtual WAN)

Personnalisation de l’implémentation Bicep

Les implémentations de zone d’atterrissage Azure fournies dans le cadre du Cloud Adoption Framework répondent à un vaste éventail d’exigences et de cas d’usage. Toutefois, il existe souvent des scénarios où une personnalisation est requise en réponse à des besoins métier spécifiques.

Conseil

Pour plus d’informations, consultez Personnaliser l’architecture d’une zone d’atterrissage Azure pour répondre aux besoins.

Une fois la zone d’atterrissage de la plateforme implémentée, l’étape suivante consiste à déployer des zones d’atterrissage d’application qui permettent aux équipes d’application sous le groupe d’administration landing zones avec les garde-fous requis par les administrateurs informatiques centraux ou PlatformOps. Le groupe d’administration corp concerne les applications connectées à l’entreprise, tandis que le groupe d’administration online est destiné aux applications qui sont principalement accessibles publiquement, mais qui peuvent toujours se connecter aux applications d’entreprise via des réseaux hub dans certains scénarios.

Vous pouvez utiliser l’implémentation Bicep de zone d’atterrissage Azure comme base pour votre déploiement personnalisé. Cela vous permet d’accélérer votre implémentation en éliminant la nécessité de partir de zéro en raison d’une modification requise spécifique excluant une option prête à l’emploi.

Les informations sur la personnalisation des modules sont disponibles dans le wiki de dépôt GitHub GitHub: Azure Landing Zones (ALZ) Bicep - Wiki- Consumer Guide. Vous pouvez l’utiliser comme point de départ et la configurer en fonction de vos besoins.