Architecture de référence des machines virtuelles Azure dans une zone d’atterrissage Azure

L’architecture présentée dans cet article s’appuie sur l’architecture de référence de la machine virtuelle pour répondre aux changements et aux attentes lorsque vous la déployez dans une zone d’atterrissage Azure.

L’exemple fourni dans cet article décrit une organisation qui veut qu’une charge de travail basée sur des machines virtuelles utilise des ressources fédérées gérées de manière centralisée par une équipe de plateforme. Ces ressources incluent des ressources réseau pour la connectivité intersite, la gestion des identités et des accès, et les stratégies. Cet exemple part du principe que l’organisation adopte des zones d’atterrissage Azure pour mettre en œuvre une gouvernance cohérente et un rapport coût-efficacité sur plusieurs charges de travail.

En tant que propriétaire d’une charge de travail, vous pouvez déléguer la gestion des ressources partagées à des équipes centrales, afin de vous concentrer sur les efforts de développement de la charge de travail. Cet article présente le point de vue de l’équipe chargée de la charge de travail. Les recommandations destinées à l’équipe chargée de la plateforme sont détaillées.

Disposition de l’article

Architecture	Décision de conception	L’approche Azure Well-Architected Framework
▪ Diagramme d’architecture ▪ Ressources de charge de travail ▪ Ressources fédérées	▪ Paramétrage de l’abonnement ▪ Exigences réseau ▪ Modifications de la conception du réseau à partir de la base de référence ▪ Monitoring ▪ Conformité des correctifs ▪ Gouvernance organisationnelle ▪ Gestion des changements	▪ Fiabilité ▪ Sécurité ▪ Optimisation des coûts

Architecture

Téléchargez un fichier Visio de cette architecture.

Composants

Toutes les architectures de zones d’atterrissage Azure comportent une séparation de propriété entre l’équipe de la plateforme et l’équipe de la charge de travail. Les architectes d’applications et les équipes DevOps doivent avoir une connaissance approfondie de ce partage des responsabilités afin de comprendre ce qui relève de leur influence ou de leur contrôle direct et ce qui n’en relève pas.

Ressources appartenant à l’équipe chargée de la charge de travail

Les ressources suivantes ne changent pratiquement pas par rapport à l’architecture de référence.

• La plateforme d’application est Machines virtuelles Azure. Les ressources de calcul sont distribuées entre les zones de disponibilité.

• Azure Load Balancer est utilisé pour équilibrer en privé la charge du trafic depuis les machines virtuelles front-end vers les machines virtuelles back-end. L’équilibreur de charge distribue le trafic vers les machines virtuelles dans les différentes zones.

• Azure Application Gateway fait office de proxy inverse pour acheminer les demandes des utilisateurs vers les machines virtuelles front-end. La référence SKU sélectionnée est également utilisée pour héberger Azure Web Application Firewall pour protéger les machines virtuelles front-end contre le trafic potentiellement malveillant.

• Azure Key Vault permet de stocker tous les secrets et certificats de l’application.

• Azure Monitor, Log Analytics et Application Insights permettent de collecter, de stocker et de visualiser les données d’observabilité.

• Azure Policy est utilisé pour appliquer des stratégies spécifiques à la charge de travail.

L’équipe responsable de la charge de travail gère et assume les ressources et responsabilités suivantes.

• Sous-réseaux du réseau virtuel Spoke et les groupes de sécurité réseau (NSG) qui sont placés sur ces sous-réseaux pour maintenir la segmentation et contrôler le flux de trafic.

• Points de terminaison privés pour sécuriser la connectivité aux solutions PaaS (Platform as a Service) et aux zones DNS privées requises pour ces points de terminaison.

• Les disques managés Azure stockent les fichiers journaux sur les serveurs de back-end, et les données sont conservées même lorsque les machines virtuelles redémarrent. Les serveurs de front-end possèdent des disques attachés que vous pouvez utiliser pour déployer votre application sans état.

Les ressources de la plate-forme appartenant à l’équipe

L’équipe de plateforme possède et gère ces ressources centralisées. Cette architecture suppose que ces ressources sont pré-approvisionnées et les considère comme des dépendances.

• Le pare-feu Azure dans le réseau hub est utilisé pour inspecter et restreindre le trafic de sortie. Ce composant remplace l’équilibreur de charge standard dans l’architecture de référence, qui ne prévoit pas de restrictions sur le trafic sortant vers Internet.

• Azure Bastion dans le réseau hub fournit un accès opérationnel sécurisé aux machines virtuelles de charge de travail. Dans l’architecture de référence, l’équipe de charge de travail possède ce composant.

• Le réseau virtuel Spoke est l’emplacement où la charge de travail est déployée.

• Les routes définies par l’utilisateur sont utilisées pour forcer le tunneling vers le réseau hub.

• Les contraintes de gouvernance basées sur Azure Policy et les stratégies DeployIfNotExists (DINE) font partie de l’abonnement de la charge de travail.

Paramétrage de l’abonnement

Dans un contexte de zone d’atterrissage, votre équipe responsable de la charge de travail doit informer l’équipe de plateforme de ses exigences spécifiques.

Votre équipe responsable de la charge de travail doit inclure des informations détaillées sur l’espace de mise en réseau dont votre charge de travail a besoin, afin que l’équipe de plateforme lui alloue les ressources nécessaires. Votre équipe détermine les exigences, et l’équipe de plateforme détermine les adresses IP à attribuer dans le réseau virtuel et le groupe d’administration auquel l’abonnement est attribué.

L’équipe de plateforme affecte un groupe d’administration approprié en fonction du niveau de criticité pour l’entreprise et des exigences techniques de la charge de travail, par exemple si elle est exposée sur Internet. L’organisation détermine la configuration de ces groupes d’administration et l’équipe de plateforme les implémente.

Par exemple, les groupes d’administration des scénarios d’application de l’architecture de référence sont pris en compte :

• Les applications privées, notamment des applications métier internes ou des solutions logicielles commerciales (COTS), qui sont souvent situées dans le groupe d’administration de l’entreprise des zones d’atterrissage Azure.

• Les applications publiques, notamment dans les applications accessibles sur Internet, qui sont souvent situées dans le groupe d’administration de l’entreprise ou en ligne.

L’équipe de la plate-forme est également chargée de configurer un abonnement ou un groupe d’abonnements pour le déploiement de la charge de travail.

Les sections suivantes fournissent des conseils sur la configuration initiale de l’abonnement. Toutefois, l’équipe de plateforme apporte généralement des modifications aux services centralisés pour répondre à des besoins non satisfaits ou modifiés. Les changements apportés à la plate-forme affectent plus largement toutes les équipes responsables de la charge de travail.

Par conséquent, l’équipe de plateforme doit s’assurer que toutes les charges de travail de machines virtuelles sont capables de faire face aux changements, et elle doit connaître le cycle de vie de la solution basée sur une machine virtuelle et le cycle de tests. Pour plus d’informations, consultez Gestion des modifications au fil du temps.

Exigences et exécution de la charge de travail

L’équipe responsable de la charge de travail et les équipes de plateforme assument deux responsabilités majeures : l’affectation des groupes d’administration et la configuration de la mise en réseau. Pour cette architecture, il faut tenir compte des exigences suivantes liées à la mise en réseau, qui doivent être communiquées à l’équipe de plateforme. Ces points vous serviront d’exemples pour comprendre la discussion et la négociation entre les deux équipes lors de l’implémentation d’une architecture similaire.

• Nombre de réseaux virtuels spoke : cette architecture requiert un seul réseau spoke dédié. Il est inutile d’étendre les ressources déployées sur plusieurs réseaux, elles sont colocalisées au sein d’un seul réseau virtuel.

• La taille du réseau spoke : prenez en compte les exigences opérationnelles et la croissance attendue de la charge de travail. Par exemple, si vous envisagez d’implémenter des mises à jour bleu/vert ou de contrôle de validité, la taille maximale doit tenir compte de l’espace requis par vos déploiements côte à côte.

  Les modifications ultérieures peuvent nécessiter davantage d’espace IP, ce qui pourrait entraîner un décalage par rapport à l’attribution actuelle. L’intégration de ces espaces peut accroître la complexité. Soyez proactif et demandez suffisamment de ressources réseau pour vous assurer que l’espace attribué peut prendre en charge l’expansion future.

• La région de déploiement : il est important de spécifier les régions où la charge de travail sera déployée. L’équipe de plateforme peut utiliser ces informations pour vous assurer que les réseaux virtuels en étoile sont approvisionnés dans la même région. Les réseaux couvrant différentes régions peuvent entraîner des problèmes de latence dus au fait que le trafic traverse les frontières régionales et peuvent également entraîner des coûts supplémentaires en termes de bande passante.

• Les caractéristiques de la charge de travail et les choix de conception : communiquez vos choix en matière de conception, de composants et les caractéristiques à votre équipe de plateforme. Par exemple, si vous estimez que votre charge de travail générera un grand nombre de connexions simultanées à Internet (bavardages), l’équipe de plate-forme doit veiller à ce qu’il y ait suffisamment de ports disponibles pour éviter la saturation. Ils peuvent ajouter des adresses IP au pare-feu centralisé pour prendre en charge le trafic ou configurer une passerelle de traduction d’adresses réseau (NAT) pour acheminer le trafic via un autre chemin.

  À l’inverse, si vous vous attendez à ce que votre charge de travail génère un trafic réseau minimal (bruit de fond), l’équipe de plateforme doit utiliser les ressources de manière efficace dans l’ensemble de l’organisation.

  L’équipe de plateforme doit disposer d’une compréhension claire des dépendances. Par exemple, votre charge de travail peut avoir besoin d’accéder à une base de données appartenant à une autre équipe, ou elle peut présenter un trafic intersite. Votre charge de travail a-t-elle des dépendances à l’extérieur d’Azure ? Ces informations sont importantes pour l’équipe de plateforme.

• La configuration du pare-feu : l’équipe de plateforme doit connaître le trafic qui quitte le réseau spoke et qui est tunnélisé vers le réseau hub. Le pare-feu dans le hub ne peut pas bloquer ce trafic.

  Par exemple, si votre charge de travail doit accéder aux mises à jour de Windows pour rester à jour, un pare-feu ne doit pas bloquer ces mises à jour. De même, si des agents de surveillance accèdent à des points de terminaison spécifiques, un pare-feu ne doit pas bloquer ce trafic, car il pourrait perturber les données de surveillance de votre charge de travail. L’application peut nécessiter l’accès à des points de terminaison tiers. Dans tous les cas, utilisez un pare-feu centralisé pour faire la différence entre le trafic attendu et celui injustifié.

• Accès de l’opérateur : s’il existe des groupes de sécurité Microsoft Entra ID utilisés par les opérateurs pour accéder aux machines virtuelles via Azure Bastion, informez l’équipe de plateforme. En général, Azure Bastion est une ressource centrale. Il est essentiel de s’assurer que les groupes de sécurité et les machines virtuelles prennent en charge le protocole sécurisé.

  Informez également l’équipe de plateforme des plages d’adresses IP qui contiennent les machines virtuelles. Ces informations sont nécessaires pour configurer les groupes de sécurité réseau autour d’Azure Bastion dans le réseau hub.

• Adresses IP publiques : communiquez à l’équipe de la plateforme le profil de trafic d’entrée, y compris les adresses IP publiques attendues. Dans cette architecture, seul le trafic provenant d’Internet cible l’IP publique sur Application Gateway. L’équipe de plateforme doit indiquer à l’équipe responsable de la charge de travail si ces adresses IP font l’objet d’un plan Azure DDoS Protection ou si c’est la responsabilité de l’équipe responsable de la charge de travail.

  Dans cette architecture, il existe une autre adresse IP publique pour l’accès opérationnel via Azure Bastion. L’équipe de plateforme est propriétaire de cette adresse IP publique et elle est inscrite dans un service, comme DDoS Protection, également géré par l’équipe de plateforme.

Choix de conception de machine virtuelle

La référence SKU de machine virtuelle et les sélections de disques sont les mêmes que dans l’architecture de référence.

Une organisation peut imposer à l’équipe responsable de la charge de travail des exigences de conformité qui requièrent l’utilisation d’images de machines virtuelles spécifiques. En fonction de ces exigences, l’équipe de plateforme peut gérer un ensemble d’images standardisées, souvent appelées images de référence, qui sont créées pour leur utilisation dans l’ensemble de l’organisation.

L’équipe de plateforme peut utiliser une offre managée telle qu’Azure Compute Gallery ou un dépôt privé pour stocker des images de système d’exploitation approuvées ou des artefacts de la charge de travail. Lorsque vous choisissez une image de système d’exploitation pour des machines virtuelles, consultez votre équipe de plateforme pour connaître les sources des images, la fréquence des mises à jour et les attentes en matière d’utilisation. Veillez également à ce que les images puissent répondre aux exigences métier que respecte la charge de travail.

Mise en réseau

Dans l’architecture de référence, la charge de travail est provisionnée dans un seul réseau virtuel. L’équipe responsable de la charge de travail gère le réseau virtuel.

Dans cette architecture, l’équipe de la plate-forme détermine la topologie du réseau. Nous partons du principe que cette architecture utilise la topologie hub-and-spoke.

Téléchargez un fichier Visio de cette architecture.

• Réseau virtuel hub : un hub régional contient des services centralisés qui communiquent avec les ressources de charge de travail dans la même région. Pour plus d’informations, consultez Ressources appartenant à l’équipe de plateforme. Nous vous recommandons de placer le hub dans l’abonnement de connectivité.

• Réseau virtuel spoke : dans cette architecture, le réseau virtuel unique de l’architecture de référence est le réseau spoke. Il est appairé au réseau hub, qui contient les services centralisés. La propriétaire et l’administratrice de ce réseau spoke est l’équipe de plateforme. Ce réseau contient les ressources de charge de travail. L’équipe responsable de la charge de travail possède les ressources de ce réseau, y compris ses sous-réseaux.

Assurez-vous que vous communiquez les exigences en matière de charge de travail à l’équipe de plateforme et révisez-les régulièrement.

Sous-réseaux du réseau virtuel

Dans le réseau virtuel spoke, l’équipe responsable de la charge de travail crée et alloue les sous-réseaux. La mise en place de contrôles pour limiter le trafic entrant et sortant des sous-réseaux contribue à la segmentation. Cette architecture utilise la même topologie de sous-réseau que l’architecture de référence, qui a des sous-réseaux dédiés pour Application Gateway, les machines virtuelles de front-end, l’équilibreur de charge, les machines virtuelles de back-end et les points de terminaison privés.

Lorsque vous déployez votre charge de travail dans une zone d’atterrissage Azure, vous devez encore appliquer des contrôles de réseau. Les organisations peuvent imposer des restrictions pour se prémunir contre l’exfiltration de données et garantir la visibilité pour le centre des opérations de sécurité (SOC) central et l’équipe du réseau informatique.

Avec cette approche, l’équipe de plateforme peut optimiser les dépenses globales de l’organisation grâce à des services centralisés, plutôt que de déployer des contrôles de sécurité redondants pour chaque charge de travail au sein de l’organisation. Dans cette architecture, le pare-feu Azure est un exemple de service central. La gestion par chaque équipe de la charge de travail de sa propre instance de pare-feu n’est ni rentable ni pratique. Nous vous recommandons d’adopter une approche centralisée de la gestion du pare-feu.

Trafic d’entrée

Le flux de trafic d’entrée est le même que celui de l’architecture de référence.

Le propriétaire de la charge de travail est responsable des ressources liées à l’entrée de l’Internet public dans votre charge de travail. Par exemple, dans cette architecture, Application Gateway et son adresse IP publique sont placés dans le réseau spoke et non dans le réseau hub. Certaines organisations peuvent placer des ressources avec le trafic d’entrée dans un abonnement de connectivité à l’aide de l’implémentation d’une zone démilitarisée (DMZ) centralisée. L’intégration à cette topologie spécifique n’est pas couverte dans cet article.

Trafic de sortie

Dans l’architecture de référence, des groupes de machines virtuelles identiques de charge de travail accèdent à l’Internet public via Azure Load Balancer, mais ce trafic n’est pas restreint.

Cette conception est différente dans cette architecture. Tout le trafic qui quitte le réseau virtuel spoke est acheminé via le réseau hub appairé à travers un pare-feu de sortie. Une route est attachée à tous les sous-réseaux possibles du réseau en étoile qui dirige tout le trafic pour les IP qui ne se trouvent pas dans le réseau virtuel local (0.0.0.0/0) vers le pare-feu Azure du hub.

Téléchargez un fichier Visio de cette architecture.

La communication de la charge de travail vers le point de terminaison privé pour l’accès Key Vault est le même que celui de l’architecture de référence. Par souci de concision, ce chemin est omis dans le diagramme précédent.

L’équipe responsable de la charge de travail doit identifier, documenter et communiquer tous les flux de trafic sortant nécessaires aux opérations d’infrastructure et de charge de travail. L’équipe de plateforme autorise le trafic requis, et tout le trafic de sortie non communiqué est susceptible d’être refusé.

Le contrôle du trafic sortant ne consiste pas seulement à s’assurer que le trafic attendu est autorisé. Il faut également s’assurer que seul le trafic attendu est autorisé. Le trafic de sortie non communiqué est généralement refusé par défaut, mais il est dans l’intérêt de la charge de travail de s’assurer que le trafic est correctement acheminé.

Communiquez les exigences de trafic de sortie uniques à l’équipe de plateforme. Par exemple, si votre charge de travail établit de nombreuses connexions simultanées avec des points de terminaison de réseau externe, informez-en l’équipe de plateforme. Celle-ci peut alors soit fournir une implémentation appropriée d’Azure NAT Gateway, soit ajouter davantage d’IP publiques sur le pare-feu régional pour atténuer les risques.

Les exigences de votre organisation peuvent décourager l’utilisation de modèles d’architecture, qui utilisent des adresses IP publiques appartenant à la charge de travail pour la sortie. Dans ce cas, vous pouvez utiliser Azure Policy pour refuser les IP publiques sur les cartes d’interface réseau (NIC) des machines virtuelles et toutes les autres IP publiques, autres que vos points d’entrée bien connus.

Zones DNS privées

Pour fonctionner avec le fournisseur DNS, les architectures qui utilisent des points de terminaison privés requièrent des zones DNS privées. L’équipe responsable de la charge de travail doit avoir une compréhension claire des exigences et de la gestion des zones DNS privées dans l’abonnement fourni par l’équipe de plateforme. Les zones DNS privées sont généralement gérées à grande échelle avec des stratégies DINE. Ainsi, Azure Firewall peut fonctionner comme un proxy DNS fiable et prendre en charge les règles de réseau des noms de domaines complets (FQDN).

Dans cette architecture, l’équipe de la plateforme assure la résolution DNS privée fiable pour les points de terminaison de la liaison privée. Collaborez avec votre équipe de plateforme pour comprendre leurs attentes.

Test de la connectivité

Pour les architectures basées sur des machines virtuelles, il existe différents outils de test qui permettent de déterminer les problèmes de visibilité du réseau, de routage et de DNS. Vous pouvez utiliser des outils de dépannage traditionnels, tels que netstat, nslookup ou tcping. En outre, vous pouvez examiner les paramètres DHCP (Dynamic Host Configuration Protocol) et DNS de l’adaptateur réseau. S’il y a des cartes d’interface réseau, les possibilités de dépannage sont plus nombreuses et vous permettent d’effectuer des contrôles de connectivité à l’aide d’Azure Network Watcher.

Accès opérateur

Tout comme l’architecture de référence, cette architecture prend en charge l’accès opérationnel via Azure Bastion.

Toutefois, l’architecture de référence déploie Azure Bastion dans le cadre de la charge de travail. Une organisation classique qui adopte les zones d’atterrissage Azure déploie Azure Bastion en tant que ressource centrale pour chaque région. Azure Bastion appartient à l’équipe de plateforme, qui en assure la maintenance, et toutes les charges de travail de l’organisation le partagent. Pour illustrer ce cas d’utilisation dans cette architecture, Azure Bastion se trouve dans le réseau hub de l’abonnement de connectivité.

Opérateur d’identité

Cette architecture utilise la même extension d’authentification que l’architecture de référence.

Commencez toujours par le principe des privilèges minimum et de l’accès granulaire à une tâche au lieu d’un accès à long terme. Dans le contexte de la zone d’atterrissage, tirez parti de la prise en charge juste-à-temps (JIT) gérée par l’équipe de plateforme.

Conformité des correctifs et mises à niveau du système d’exploitation

L’architecture de référence décrit une approche autonome de la mise à jour corrective et des mises à niveau. Lorsque la charge de travail est intégrée aux zones d’atterrissage, cette approche peut changer. L’équipe de plate-forme peut déterminer les opérations de correction afin que toutes les charges de travail soient conformes aux exigences de l’organisation.

Veillez à ce que le processus de mise à jour corrective inclue tous les composants que vous ajoutez à l’architecture. Par exemple, si vous choisissez d’ajouter des machines virtuelles de l’agent de build pour automatiser le déploiement, la mise à l’échelle et la gestion des applications, ces machines virtuelles doivent respecter les exigences de la plateforme.

Surveillance

La plateforme de zone d’atterrissage Azure fournit des ressources d’observabilité partagées dans le cadre des abonnements de gestion. Nous vous recommandons toutefois de provisionner vos propres ressources de surveillance afin de faciliter l’appropriation des responsabilités de la charge de travail. Cette approche est cohérente avec l’architecture de référence.

L’équipe responsable de la charge de travail provisionne les ressources de surveillance, ce qui inclut :

• Application Insights en tant que service de surveillance des performances des applications (APM) pour l’équipe responsable de la charge de travail.

• L’espace de travail Log Analytics en tant que récepteur unifié pour l’ensemble des journaux et des métriques collectés à partir des ressources Azure appartenant à la charge de travail et du code de l’application.

Téléchargez un fichier Visio de cette architecture.

Comme pour la base de référence, toutes les ressources sont configurées pour envoyer des journaux de diagnostic Azure à l’espace de travail Log Analytics que l’équipe responsable de la charge de travail provisionne dans le cadre du déploiement de l’infrastructure en tant que code (IaC) des ressources. Vous devrez peut-être également envoyer des journaux à un espace de travail Log Analytics central. Dans les zones d’atterrissage Azure, cet espace de travail se trouve dans l’abonnement de gestion.

L’équipe de plate-forme peut également utiliser des stratégies DINE pour configurer Diagnostics de manière à ce qu’il envoie des journaux à ses abonnements de gestion centralisée. Il est important de s’assurer que votre implémentation ne limite pas les flux de journaux supplémentaires.

Mise en corrélation des données issues de plusieurs récepteurs

Les journaux et les métriques de la charge de travail ainsi que les composants de son infrastructure sont stockés dans l’espace de travail Log Analytics de la charge de travail. Néanmoins, les journaux et les métriques générés par des services centralisés, notamment Azure Firewall, Microsoft Entra ID et Azure Bastion, sont stockés dans un espace de travail Log Analytics central. La corrélation des données issues de plusieurs récepteurs peut être une tâche complexe.

Les données corrélées sont souvent utilisées lors de la réponse aux incidents. En cas de problème de corrélation des données issues de plusieurs récepteurs, veillez à ce que le runbook de triage de cette architecture en tienne compte et inclue les points de contact de l’organisation si le problème s’étend au-delà des ressources de la charge de travail. Les administrateurs de la charge de travail peuvent avoir besoin de l’aide des administrateurs de plateforme pour corréler les entrées de journal provenant des services de réseau d’entreprise, de sécurité ou d’autres services de la plateforme.

Azure Policy

L’équipe de plateforme applique probablement des stratégies qui affectent le déploiement de la charge de travail. Ils appliquent souvent des stratégies DINE pour gérer les déploiements automatisés dans un abonnement de zone d’atterrissage d’application. Les stratégies DINE peuvent modifier les ressources de la charge de travail ou en ajouter à votre déploiement, ce qui peut entraîner un écart entre les ressources déployées de façon déclarative à l’aide du modèle de charge de travail et les ressources que les demandes de traitement utilisent réellement. La solution habituelle consiste à corriger ces changements à l’aide d’approches impératives, ce qui n’est pas idéal.

Pour éviter cet écart, incorporez et testez de manière préventive les changements initiés par la plateforme dans vos modèles IaC. Si l’équipe de plateforme utilise des stratégies Azure qui sont en conflit avec les exigences de l’application, vous pouvez négocier une résolution avec l’équipe de plateforme.

Gestion des changements au fil du temps

Dans cette architecture, les services et les opérations fournis par la plateforme sont considérés comme des dépendances externes. L’équipe de plateforme continue d’appliquer des modifications, d’intégrer des utilisateurs et de contrôler les coûts. L’équipe de la plateforme, au service de l’organisation, peut ne pas donner la priorité à des charges de travail individuelles. Les modifications apportées à ces dépendances, qu’il s’agisse de changements d’images de référence, de modifications de pare-feu, de mises à jour correctives automatisées ou de changements de règles, peuvent affecter plusieurs charges de travail.

Par conséquent, les équipes responsables de la charge de travail et de la plateforme doivent communiquer efficacement et en temps voulu pour gérer toutes les dépendances externes. Il est important de tester les changements pour éviter qu’ils n’affectent négativement les charges de travail.

Changements au niveau de la plate-forme qui affectent la charge de travail

Dans cette architecture, l’équipe de plateforme gère les ressources suivantes. Les modifications apportées à ces ressources sont susceptibles d’affecter la fiabilité, la sécurité, les opérations et les objectifs de performance de la charge de travail. Il est important d’évaluer ces changements avant que l’équipe de plateforme ne les mette en œuvre, en vue de déterminer la façon dont ils affectent la charge de travail.

• Stratégies Azure : les changements apportées aux stratégies Azure peuvent affecter les ressources de charge de travail et leurs dépendances. Par exemple, il peut se produire des changements directs de politique ou un déplacement de la zone d’atterrissage dans une nouvelle hiérarchie de groupes de gestion. Ces changements peuvent passer inaperçus avant le prochain déploiement, c’est pourquoi il est important de les tester de manière approfondie.

• Règles de pare-feu : les changements apportés aux règles de pare-feu peuvent affecter le réseau virtuel de la charge de travail ou les règles qui s’appliquent à l’ensemble du trafic. Ces changements peuvent entraîner un blocage du trafic et même des défaillances de processus silencieux, comme l’échec de l’application des correctifs du système d’exploitation. Ces problèmes potentiels s’appliquent aussi bien au pare-feu Azure de sortie qu’aux règles du groupe de sécurité réseau appliquées par Azure Virtual Network Manager.

• Ressources partagées : les modifications apportées à la référence SKU ou aux fonctionnalités sur des ressources partagées peuvent affecter la charge de travail.

• Routage dans le réseau hub : Les modifications de la nature transitive du routage dans le hub sont susceptibles d’affecter la fonctionnalité de la charge de travail si celle-ci dépend du routage vers d’autres réseaux virtuels.

• Hôte Azure Bastion : les modifications apportées à la disponibilité ou à la configuration de l’hôte Azure Bastion peuvent affecter les opérations de la charge de travail. Veiller à ce que les modifications du modèle d’accès au serveur de rebond soient efficaces pour les accès de routine, ad hoc et d’urgence.

• Changements de propriétaire : communiquez à l’équipe responsable de la charge de travail tous les changements de propriétaires et de points de contact, car ils peuvent avoir une incidence sur la gestion et les demandes de support de la charge de travail.

Changements au niveau de la charge de travail qui affectent la plateforme

Les exemples suivants présentent des modifications de charges de travail dans cette architecture que vous devez communiquer à l’équipe de plateforme. Il est important que l’équipe de la plateforme valide la fiabilité, la sécurité, les opérations et les objectifs de performances du service de plateforme au regard des nouveaux changements apportés par l’équipe de la charge de travail avant qu’ils n’entrent en vigueur.

• Sortie réseau : surveillez toute augmentation significative de la sortie réseau afin d’éviter que la charge de travail ne devienne un voisin bruyant pour les périphériques du réseau. Ce problème peut affecter les cibles de performances ou de fiabilité d’autres charges de travail.

• Accès public : les modifications apportées à l’accès public aux composants de la charge de travail peuvent nécessiter des tests supplémentaires. L’équipe de plateforme peut déplacer la charge de travail vers un autre groupe d’administration.

• Évaluation de la criticité pour l’entreprise : si des modifications sont apportées aux accords de niveau de service (SLA) de la charge de travail, vous pourriez avoir besoin d’une nouvelle approche collaborative entre les équipes de plateforme et de charge de travail.

• Changements de propriétaire : communiquez à l’équipe de plateforme tous les changements de propriétaire et de points de contact.

Changements des exigences de l’entreprise concernant la charge de travail

Pour maintenir les objectifs de niveau de service (SLO) de la charge de travail, l’équipe de la plate-forme peut être amenée à participer aux modifications apportées à l’architecture de cette dernière. Ces modifications peuvent nécessiter une gestion du changement de la part de l’équipe de plate-forme ou la validation du fait que la gouvernance existante prend en charge les exigences modifiées.

Par exemple, communiquez les modifications apportées à tout flux de sortie précédemment interdit, pour que l’équipe de plateforme puisse ajouter ce flux dans le pare-feu, le gestionnaire de réseau virtuel ou d’autres composants pour prendre en charge le trafic requis. À l’inverse, si un flux de sortie précédemment autorisé n’est plus nécessaire, l’équipe de plateforme doit le bloquer pour assurer la sécurité de la charge de travail. Communiquez également les modifications apportées au routage vers d’autres réseaux virtuels ou points de terminaison intersite, ou les modifications apportées aux composants de l’architecture. Chaque ressource est soumise à des politiques et éventuellement à un contrôle du pare-feu de sortie.

Fiabilité

Cette architecture est conforme aux garanties de fiabilité de l’architecture de référence.

Objectifs de fiabilité

Le SLO composite maximal possible est inférieur au SLO composite de référence en raison de composants tels que le contrôle réseau de sortie. Ces composants, courants dans les environnements de zone d’atterrissage, ne sont pas uniques à cette architecture. Le SLO est également réduit si l’équipe responsable de la charge de travail contrôle directement ces services Azure.

Malgré un SLO maximal inférieur, l’aspect clé de la fiabilité est la répartition des éléments de la charge de travail entre les équipes fonctionnelles. Avec cette méthode, l’équipe chargée de la charge de travail bénéficie d’une équipe spécialisée qui se concentre sur l’exploitation de l’infrastructure critique que cette charge de travail et d’autres charges de travail utilisent.

Pour plus d’informations, consultez Recommandations pour définir des objectifs de fiabilité.

Dépendances critiques

Affichez toutes les fonctionnalités exécutées par la charge de travail dans la zone d’atterrissage de la plate-forme et de l’application en tant que dépendances. Dans le cadre des plans de réponse aux incidents, l’équipe responsable de la charge de travail doit connaître le point et la méthode de contact pour ces dépendances. Incluez également ces dépendances dans l’analyse du mode d’échec (FMA) de la charge de travail.

Pour cette architecture, tenez compte des dépendances suivantes :

• Pare-feu de sortie : le pare-feu de sortie centralisé, partagé par plusieurs charges de travail, subit des modifications sans rapport avec la charge de travail.

• Épuisement du port réseau : les pics d’utilisation de toutes les charges de travail qui partagent le périphérique réseau peuvent entraîner une saturation du réseau ou un épuisement des ports sur le pare-feu de sortie.

• Stratégies DINE : les stratégies DINE pour les zones DNS privées Azure DNS (ou toute autre dépendance fournie par la plateforme) sont les meilleures possibles, sans contrat SLA lors de l’exécution. Un retard dans la configuration DNS peut entraîner des retards dans la préparation d’une application pour gérer le trafic.

• Stratégies de groupes d’administration : des stratégies cohérentes entre les environnements sont essentielles pour la fiabilité. Assurez-vous que les environnements de préproduction sont similaires aux environnements de production pour fournir des tests précis et éviter les écarts spécifiques à l’environnement susceptibles de bloquer un déploiement ou une mise à l’échelle. Pour plus d’informations, consultez la section Gérer les environnements de développement d’applications dans les zones d’atterrissage Azure.

Bon nombre de ces considérations seraient possibles sans les zones d’atterrissage Azure, mais les équipes responsables de la charge de travail et de la plateforme doivent collaborer pour résoudre ces problèmes afin de garantir la satisfaction des besoins.

Pour plus d’informations, consultez Recommandations pour effectuer une analyse du mode d’échec.

Sécurité

Les considérations de sécurité relatives à cette architecture sont les mêmes que pour l’architecture de référence. Les recommandations fournies dans les sections suivantes sont basées sur la liste de contrôle sur la conception de la sécurité dans Well-Architected Framework.

Contrôles de réseau

Configurez correctement les contrôles réseau pour vous assurer que votre charge de travail est sécurisée.

Trafic d’entrée

Vous pouvez isoler votre charge de travail d’autres spokes de charge de travail au sein de votre organisation à l’aide de groupes de sécurité réseau sur vos sous-réseaux, ou de la nature ou des contrôles non transitifs dans le hub régional. Construisez des groupes de sécurité réseau complets qui autorisent uniquement les exigences du réseau entrant de votre application et de son infrastructure. Nous vous recommandons de ne pas compter uniquement sur la nature non transitive du réseau du hub pour assurer votre sécurité.

L’L’équipe de plateforme met probablement en œuvre des politiques Azure pour s’assurer que la passerelle d’application dispose d’un pare-feu d’application Web réglé sur le mode de refus pour restreindre le nombre d’IP publiques disponibles pour votre abonnement, et d’autres contrôles. En plus de ces stratégies, l’équipe responsable de la charge de travail devrait assumer la responsabilité du déploiement de politiques centrées sur la charge de travail qui renforcent la posture de sécurité à l’entrée.

Le tableau suivant présente des exemples de contrôles d’entrée dans cette architecture.

Source	Objectif	Contrôle de la charge de travail	Contrôle de la plateforme
Internet	Flux de trafic utilisateur	Achemine toutes les demandes à travers un groupe de sécurité réseau, un pare-feu d’application Web et des règles de routage avant d’autoriser la transition du trafic public vers le trafic privé qui entre dans les machines virtuelles de front-end.	Aucun
Azure Bastion	Accès des opérateurs aux machines virtuelles	Groupe de sécurité réseau sur des sous-réseaux de machines virtuelles qui bloque tout le trafic vers les ports d’accès distant, à moins qu’il ne provienne du sous-réseau Azure Bastion désigné de la plateforme.	Aucun
Autres spokes	Aucun	Bloqué via des règles de groupe de sécurité réseau	Routage non transitif ou règles de pare-feu Azure dans le cas d’un hub sécurisé Azure Virtual WAN

Trafic de sortie

Applique des règles de groupe de sécurité réseau qui expriment les exigences de connectivité sortante requises de votre solution et refuse tout le reste. Ne vous reposez pas uniquement sur les contrôles réseau hub. En tant qu’opérateur de charge de travail, il vous incombe d’arrêter le trafic de sortie non souhaité aussi près de la source que possible.

Sachez que, bien que vous soyez propriétaire de votre sous-réseau au sein du réseau virtuel, l’équipe de plateforme a probablement créé des règles de pare-feu pour représenter spécifiquement vos besoins capturés dans le cadre de votre processus de distributeur d’abonnements. Veillez à ce que les modifications apportées aux sous-réseaux et à l’emplacement des ressources au cours de la durée de vie de votre architecture soient toujours compatibles avec votre demande initiale. Vous pouvez également travailler avec votre équipe réseau pour garantir la continuité du contrôle de sortie par accès minimal.

Le tableau suivant présente des exemples de contrôles de sortie dans cette architecture.

Point de terminaison	Objectif	Contrôle de la charge de travail (NSG)	Contrôle de plateforme (hub)
ntp.ubuntu.com	Protocole NTP (Network Time Protocol) pour les machines virtuelles Linux	UDP/123 vers Internet sur le sous-réseau de la machine virtuelle de front-end (le pare-feu de sortie réduit cette large ouverture).	Autorisation pour la règle réseau du pare-feu identique à celle du contrôle de la charge de travail
Points de terminaison Windows Update	Fonctionnalités de Windows Update à partir de serveurs Microsoft	TCP/443 et TCP/80 vers Internet sur le sous-réseau de machine virtuelle back-end (le pare-feu de sortie réduit cette large ouverture)	Autorisation de la règle du pare-feu avec la balise FQDN de WindowsUpdate
Surveiller les points de terminaison de l’agent	Trafic requis pour l’extension Monitor sur des machines virtuelles	TCP/443 vers Internet sur les deux sous-réseaux de machines virtuelles (le pare-feu de sortie réduit cette large ouverture)	Autorisations nécessaires pour les règles d’application du pare-feu pour tous les FQDN spécifiques sur TCP/443
nginx.org	Pour installer Nginx (un exemple de composant d’application) directement à partir du fournisseur	TCP/443 vers Internet sur le sous-réseau de la machine virtuelle de front-end (le pare-feu de sortie réduit cette large ouverture).	Autorisation nécessaire de la règle d’application du pare-feu pour nginx.org sur TCP/443
Key Vault	Importer des certificats TLS (Transport Layer Security) dans la passerelle d’applications et les machines virtuelles	- TCP/443 vers un sous-réseau de point de terminaison privé à partir des deux sous-réseaux de machines virtuelles vers un sous-réseau de point de terminaison privé - TCP/443 vers un sous-réseau de point de terminaison privé à partir d’un sous-réseau Application Gateway - TCP/443 à partir de machines virtuelles identifiées avec une désignation de groupe de sécurité d’application (ASG) requise et un sous-réseau Application Gateway	Aucun

Protection DDOS

Déterminez qui est responsable de l’application du plan de protection DDoS qui couvre toutes les adresses IP publiques de votre solution. L’équipe de plateforme peut utiliser des plans de protection IP ou encore utiliser Azure Policy pour appliquer des plans de protection de réseau virtuel. Cette architecture devrait être couverte parce qu’elle fait appel à une adresse IP publique pour l’accès à Internet.

Pour plus d’informations, consultez Recommandations pour la mise en réseau et la connectivité.

Gestion des secrets

Pour la gestion des secrets, cette architecture est conforme à l’architecture de référence.

En tant qu’équipe responsable de la charge de travail, continuez à conserver vos secrets dans votre instance Key Vault. Déployez davantage d’instances si nécessaire pour prendre en charge vos opérations d’application et d’infrastructure.

Pour plus d’informations, consultez Recommandations pour protéger les secrets d’application.

Optimisation des coûts

Pour les ressources de charge de travail, les stratégies d’optimisation des coûts de l’architecture de référence s’appliquent également à cette architecture.

Cette architecture bénéficie grandement des ressources de la plateforme de zone d’atterrissage Azure. Même si vous utilisez ces ressources dans le cadre d’un modèle de rétrofacturation, la sécurité accrue et la connectivité entre sites sont plus rentables que l’autogestion de ces ressources.

Dans cette architecture, l’équipe de plateforme gère les ressources suivantes. Ces dernières sont souvent basées sur la consommation (rétrofacturation) ou potentiellement gratuites pour l’équipe responsable de la charge de travail.

• Pare-feu Azure
• Informations et événements gestion des événements (SIEM)
• Hôtes Azure Bastion
• Connectivité intersite, notamment ExpressRoute

Tirez parti d’autres offres centralisées de votre équipe responsable de la plate-forme pour étendre ces avantages à votre charge de travail sans compromettre son SLO, son objectif de délai de récupération (RTO) ou son objectif de point de récupération (RPO).

Pour plus d’informations, consultez Recommandations pour collecter et examiner les données de coût.

Déployer ce scénario

Un déploiement pour cette architecture de référence est disponible sur GitHub.

Étape suivante

Passez en revue les détails techniques et collaboratifs partagés entre une équipe responsable de la charge de travail et des équipes de plateforme.

Distributeur d’abonnements