Architecture de base des machines virtuelles Azure dans une zone d’atterrissage Azure

L’architecture de cet article s’étend sur l’architecture de base des machines virtuelles pour répondre aux modifications et aux attentes lorsque vous le déployez dans une zone d’atterrissage Azure.

Dans l’exemple de cet article, une organisation souhaite qu’une charge de travail basée sur une machine virtuelle utilise des ressources fédérées qu’une équipe de plateforme gère de manière centralisée. Ces ressources incluent des ressources réseau pour la connectivité intersite, la gestion des accès aux identités et les stratégies. Cet exemple suppose que l’organisation adopte des zones d’atterrissage Azure pour appliquer une gouvernance cohérente et une efficacité des coûts sur plusieurs charges de travail.

En tant que propriétaire de charge de travail, vous pouvez décharger la gestion des ressources partagées aux équipes centrales, afin de vous concentrer sur les efforts de développement de charge de travail. Cet article présente la perspective de l’équipe de charge de travail. Les recommandations qui sont destinées à l’équipe de plateforme sont spécifiées.

Disposition de l’article

Architecture	Décision de conception	Approche d’Azure Well-Architected Framework
▪ diagramme d’architecture ▪ ressources de charge de travail ▪ ressources fédérées	▪ configuration de l’abonnement ▪ configuration réseau requise ▪ modifications de conception réseau de la base de référence ▪ de surveillance ▪ de conformité des correctifs ▪ de gouvernance organisationnelle ▪ de gestion des modifications	▪ fiabilité ▪ sécurité ▪ d’optimisation des coûts

Architecture

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

Composants

Toutes les architectures de zone d’atterrissage Azure ont une séparation de propriété entre l’équipe de plateforme et l’équipe de charge de travail. Les architectes d’applications et les équipes DevOps doivent avoir une bonne compréhension de cette responsabilité afin de comprendre ce qui est sous leur influence directe ou leur contrôle et ce qui n’est pas le cas.

Ressources appartenant à l’équipe de charge de travail

Les ressources suivantes restent essentiellement inchangées par rapport à l’architecture de base de référence .

• machines virtuelles Azure est la plateforme d’applications. Les ressources de calcul sont distribuées entre les zones de disponibilité.

• Azure Load Balancer est utilisé pour équilibrer la charge privée du trafic des machines virtuelles frontales vers les machines virtuelles principales. L’équilibreur de charge distribue le trafic vers les machines virtuelles entre les zones.

• Azure Application Gateway est utilisé comme proxy inverse pour acheminer les requêtes utilisateur vers les machines virtuelles frontales. La référence SKU sélectionnée est également utilisée pour héberger le pare-feu d’applications web Azure pour protéger les machines virtuelles frontales contre le trafic potentiellement malveillant.

• azure Key Vault est utilisé pour stocker des secrets et des certificats d’application.

• azure Monitor, Log Analytics et Application Insights sont utilisés pour collecter, stocker et visualiser les données d’observabilité.

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

L’équipe de charge de travail gère et répond aux ressources et responsabilités suivantes.

• sous-réseaux de 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.

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

• Disques managés Azure stocke les fichiers journaux sur les serveurs principaux, et les données sont conservées même lorsque les machines virtuelles redémarrent. Les serveurs frontaux ont des disques attachés que vous pouvez utiliser pour déployer votre application sans état.

Ressources appartenant à l’équipe de plateforme

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

• 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 base, qui ne fournit 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 base, 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.

• itinéraires définis par l’utilisateur (UDR) sont utilisés pour forcer le tunneling vers le réseau hub.

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

Configuration de l’abonnement

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

Votre équipe de charge de travail doit inclure des informations détaillées sur l’espace réseau dont votre charge de travail a besoin, afin que l’équipe de plateforme puisse allouer 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 de la criticité métier et des exigences techniques de la charge de travail, par exemple si une charge de travail est exposée à 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 dans les scénarios d’application pour l’architecture de base de référence sont pris en compte :

• applications privées, telles que des applications métier internes ou des solutions commerciales hors-plateau (COTS), qui sont souvent situées sous le groupe d’administration Corp des zones d’atterrissage Azure.

• applications publiques, comme dans les applications accessibles sur Internet, qui sont souvent sous le groupe d’administration Corp ou Online.

L’équipe de plateforme est également responsable de la configuration d’un abonnement ou d’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 aux exigences manquées ou modifiées. Les modifications de plateforme ont un effet plus large sur toutes les équipes de charge de travail.

Par conséquent, l’équipe de plateforme doit s’assurer que toutes les charges de travail de machine virtuelle sont préparées pour toutes les modifications, et qu’elles doivent connaître le cycle de vie de la solution basée sur la machine virtuelle et le cycle de test. Pour plus d’informations, consultez Gestion des modifications au fil du temps.

Exigences et traitement des charges de travail

L’équipe de charge de travail et les équipes de plateforme partagent deux responsabilités principales : l’attribution de groupe d’administration et la configuration réseau. Pour cette architecture, tenez compte des exigences de mise en réseau suivantes que vous devez communiquer à l’équipe de plateforme. Utilisez ces points comme exemples pour comprendre la discussion et la négociation entre les deux équipes lorsque vous implémentez une architecture similaire.

• Le nombre de réseaux virtuels spoke: dans cette architecture, un seul spoke dédié est requis. Les ressources déployées n’ont pas besoin d’être réparties sur plusieurs réseaux et sont colocalisées au sein d’un même 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 canary, la taille maximale doit tenir compte de l’espace requis par vos déploiements côte à côte.

  Les modifications futures peuvent nécessiter davantage d’espace IP, ce qui peut égarer avec l’allocation actuelle. L’intégration de ces espaces peut introduire une complexité supplémentaire. Soyez proactif et demandez suffisamment de ressources réseau pour vous assurer que l’espace alloué 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 spoke-and-hub sont approvisionnés dans la même région. Les réseaux entre différentes régions peuvent entraîner des problèmes de latence en raison du trafic franchissant les limites régionales et peuvent également entraîner des coûts de bande passante supplémentaires.

• Les caractéristiques de la charge de travail et les choix de conception: communiquez vos choix de conception, vos composants et vos caractéristiques à votre équipe de plateforme. Par exemple, si vous attendez que votre charge de travail génère un nombre élevé de connexions simultanées à Internet (chatte), l’équipe de plateforme doit s’assurer qu’il existe suffisamment de ports disponibles pour empêcher l’épuisement. Ils peuvent ajouter des adresses IP au pare-feu centralisé pour prendre en charge le trafic ou configurer une passerelle NAT (Network Address Translation) pour acheminer le trafic via un autre chemin.

  À l’inverse, si vous attendez que votre charge de travail génère un trafic réseau minimal (bruit d’arrière-plan), l’équipe de plateforme doit utiliser efficacement des ressources au sein de l’organisation.

  L’équipe de plateforme doit comprendre clairement les dépendances. Par exemple, votre charge de travail peut avoir besoin d’accéder à une base de données propriétaire d’une autre équipe, ou votre charge de travail peut avoir du trafic intersite. Votre charge de travail a-t-elle des dépendances en dehors d’Azure ? Ces informations sont importantes pour que l’équipe de plateforme sache.

• La configuration du pare-feu: l’équipe de plateforme doit connaître le trafic qui quitte le réseau spoke et est tunnelisé 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 Windows pour rester corrigé, un pare-feu ne doit pas bloquer ces mises à jour. De même, s’il existe des agents Monitor, qui accèdent à des points de terminaison spécifiques, un pare-feu ne doit pas bloquer ce trafic, car il peut perturber les données de surveillance de votre charge de travail. L’application peut nécessiter l’accès aux points de terminaison tiers. Quoi qu’il en soit, utilisez un pare-feu centralisé pour faire la distinction entre le trafic attendu et le trafic non justifié.

• 'accès opérateur: s’il existe des groupes de sécurité Microsoft Entra ID que les opérateurs utilisent pour accéder aux machines virtuelles via Azure Bastion, informez l’équipe de plateforme. Azure Bastion est généralement 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é.

  En outre, informez l’équipe de plateforme sur les 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.

• Les adresses IP publiques: informez l’équipe de plateforme sur le profil de trafic d’entrée, y compris les adresses IP publiques attendues. Dans cette architecture, seul le trafic source internet cible l’adresse IP publique sur Application Gateway. L’équipe de plateforme doit informer l’équipe de charge de travail si ces adresses IP sont sous un plan Azure DDoS Protection ou si c’est la responsabilité de l’équipe de 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 possède cette adresse IP publique et est inscrite dans un service, comme DDoS Protection, que l’équipe de plateforme gère également.

Choix de conception de machine virtuelle

La référence SKU de machine virtuelle et les sélections de disque restent identiques à l’architecture de base de référence .

Une organisation peut imposer des exigences de conformité à l’équipe de charge de travail qui impose l’utilisation d’images de machine virtuelle spécifiques. Compte tenu de ces exigences, l’équipe de plateforme peut gérer un ensemble d’images standardisées, souvent appelées images dorées, qui sont créées pour une utilisation au sein de l’organisation.

L’équipe de plateforme peut utiliser une offre managée telle qu’Azure Compute Gallery ou un référentiel privé pour stocker des images de système d’exploitation approuvées ou des artefacts de charge de travail. Lorsque vous choisissez une image de système d’exploitation pour les machines virtuelles, consultez votre équipe de plateforme sur les sources d’images, la fréquence de mise à jour et les attentes d’utilisation. Assurez-vous également que les images peuvent répondre aux exigences métier nécessaires que la charge de travail répond.

Réseautage

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

Dans cette architecture, l’équipe de plateforme détermine la topologie réseau. La topologie hub-spoke est supposée dans cette architecture.

Télécharger 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. 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. L’équipe de plateforme possède et gère ce réseau spoke. Ce réseau contient les ressources de charge de travail . L’équipe de charge de travail possède les ressources de ce réseau, y compris ses sous-réseaux.

Assurez-vous que vous communiquer les exigences de charge de travail à l’équipe de plateforme et examinez-les régulièrement.

Sous-réseaux de réseau virtuel

Dans le réseau virtuel spoke, l’équipe de charge de travail crée et alloue les sous-réseaux. Le placement de contrôles pour restreindre le trafic entrant et sortant des sous-réseaux permet de fournir une segmentation. Cette architecture utilise la même topologie de sous-réseau que l’architecture de base , qui a des sous-réseaux dédiés pour Application Gateway, des machines virtuelles frontales, l’équilibreur de charge, les machines virtuelles principales et les points de terminaison privés.

Lorsque vous déployez votre charge de travail dans une zone d’atterrissage Azure, vous devez toujours implémenter des contrôles réseau. Les organisations peuvent imposer des restrictions pour protéger contre l’exfiltration des données et garantir la visibilité du centre d’opérations de sécurité centrale (SOC) et de l’équipe du réseau informatique.

Avec cette approche, l’équipe de plateforme peut optimiser les dépenses organisationnelles globales à l’aide de 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. Il n’est pas rentable ou pratique pour chaque équipe de charge de travail de gérer leur propre instance de pare-feu. 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 reste identique à l’architecture de base de référence .

Le propriétaire de la charge de travail est responsable des ressources liées à l’entrée d’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 d’une implémentation démilitarisée centralisée (DMZ). L’intégration à cette topologie spécifique est hors de portée pour cet article.

Trafic de sortie

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

Cette conception est différente dans cette architecture. Tout le trafic qui quitte le réseau virtuel spoke est routé via le réseau hub appairé via un pare-feu de sortie. Un itinéraire est attaché à tous les sous-réseaux possibles du réseau spoke qui dirige tout le trafic pour les adresses IP introuvables dans le réseau virtuel local (0.0.0.0.0/0) vers le Pare-feu Azure du hub.

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

La communication de charge de travail vers le point de terminaison privé pour l’accès Key Vault reste identique à l’architecture de base de référence . Ce chemin d’accès est omis dans le diagramme précédent pour la concision.

L’équipe de charge de travail doit identifier, documenter et communiquer tous les flux de trafic sortant nécessaires pour les opérations d’infrastructure et de charge de travail. L’équipe de plateforme autorise le trafic requis, et tout le trafic de sortie non commun est probablement refusé.

Le contrôle du trafic de sortie est plus que de s’assurer que le trafic attendu est autorisé. Il s’agit également de s’assurer que uniquement trafic attendu être autorisé. Le trafic sortant non commun est probablement refusé par défaut, mais il est dans le meilleur intérêt de la charge de travail pour s’assurer que le trafic est correctement routé.

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 à des points de terminaison de réseau externe, informez l’équipe de plateforme. L’équipe de plateforme peut ensuite provisionner une implémentation de passerelle NAT Azure appropriée ou ajouter des adresses IP publiques supplémentaires sur le pare-feu régional pour l’atténuation.

Votre organisation peut avoir des exigences qui découragent 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 des adresses IP publiques sur des cartes d’interface réseau de machine virtuelle et d’autres adresses IP publiques autres que vos points d’entrée connus.

Zones DNS privées

Les architectures qui utilisent des points de terminaison privés ont besoin de zones DNS privées pour fonctionner avec le fournisseur DNS. L’équipe de 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, ce qui permet au Pare-feu Azure de fonctionner en tant que proxy DNS fiable et de prendre en charge les règles de réseau de nom de domaine complet (FQDN).

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

Test de connectivité

Pour les architectures basées sur des machines virtuelles, il existe plusieurs outils de test qui peuvent aider à déterminer les problèmes de ligne de vue, de routage et DNS réseau. Vous pouvez utiliser des outils de résolution des problèmes traditionnels, tels que netstat, nslookupou tcping. En outre, vous pouvez examiner les paramètres DHCP (Dynamic Host Configuration Protocol) et DNS de la carte réseau. S’il existe des cartes réseau, vous disposez de fonctionnalités de résolution des problèmes supplémentaires qui vous permettent d’effectuer des vérifications de connectivité à l’aide d’Azure Network Watcher.

Accès de l’opérateur

Comme l’architecture de base , l’accès opérationnel via Azure Bastion est pris en charge dans cette architecture.

Toutefois, l’architecture de base déploie Azure Bastion dans le cadre de la charge de travail. Pour une organisation classique qui adopte des zones d’atterrissage Azure, elles déploient Azure Bastion en tant que ressources centrales pour chaque région. L’équipe de plateforme possède et gère Azure Bastion, et toutes les charges de travail de l’organisation la partagent. Pour illustrer ce cas d’utilisation dans cette architecture, Azure Bastion se trouve dans le réseau hub de l’abonnement de connectivité.

Identité de l’opérateur

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

Commencez toujours par le principe du privilège 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 base 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 plateforme peut dicter les opérations de mise à jour corrective afin que toutes les charges de travail soient conformes aux exigences de l’organisation.

Assurez-vous que le processus de mise à jour corrective inclut tous les composants que vous ajoutez à l’architecture. Par exemple, si vous choisissez d’ajouter des machines virtuelles d’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 de l’abonnement de gestion. Toutefois, nous vous recommandons de provisionner vos propres ressources de supervision pour faciliter les responsabilités de propriété de la charge de travail. Cette approche est cohérente avec l’architecture de base de référence .

L’équipe de charge de travail provisionne les ressources de surveillance, notamment :

• Application Insights en tant que service APM (Application Performance Monitoring) pour l’équipe de charge de travail.

• Espace de travail Log Analytics en tant que récepteur unifié pour tous les journaux et métriques collectés à partir de ressources Azure appartenant à la charge de travail et du code d’application.

Télécharger 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 de 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 plateforme peut également avoir des stratégies DINE qu’elle peut utiliser pour configurer Diagnostics afin d’envoyer des journaux à leurs abonnements de gestion centralisés. Il est important de s’assurer que votre implémentation ne limite pas les flux de journaux supplémentaires.

Mettre en corrélation les données de plusieurs récepteurs

Les journaux et les métriques de la charge de travail et ses composants d’infrastructure sont stockés dans l’espace de travail Log Analytics de la charge de travail. Toutefois, les journaux et les métriques qui ont centralisé les services, tels que le Pare-feu Azure, l’ID Microsoft Entra et Azure Bastion, sont stockés dans un espace de travail Log Analytics central. La corrélation des données 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. S’il existe un problème lié aux données provenant de plusieurs récepteurs, assurez-vous que le runbook de triage pour cette architecture l’aborde et inclut des points de contact organisationnels si le problème dépasse les ressources de charge de travail. Les administrateurs de charge de travail peuvent nécessiter de l’aide des administrateurs de plateforme pour mettre en corrélation les entrées de journal à partir de la mise en réseau, de la sécurité ou d’autres services de 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 charge de travail ou ajouter des ressources à votre déploiement, ce qui peut entraîner une différence entre les ressources qui sont déployées de manière déclarative via le modèle de charge de travail et les ressources que les demandes de traitement utilisent réellement. Une solution classique consiste à corriger ces changements avec des approches impératives, qui ne sont pas idéales.

Pour éviter cette différence, intégrez et testez de manière prédéfinie les modifications initiées 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.

Gérer les modifications au fil du temps

Les services et opérations fournis par la plateforme sont considérés comme des dépendances externes dans cette architecture. L’équipe de plateforme continue d’appliquer des modifications, d’intégrer des utilisateurs et d’appliquer des contrôles de coûts. L’équipe de plateforme, qui sert l’organisation, peut ne pas hiérarchiser les charges de travail individuelles. Les modifications apportées à ces dépendances, qu’elles soient des modifications d’image d’or, des modifications de pare-feu, des mises à jour correctives automatisées ou des modifications de règles, peuvent affecter plusieurs charges de travail.

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

Modifications de plateforme qui affectent la charge de travail

Dans cette architecture, l’équipe de plateforme gère les ressources suivantes. Les modifications apportées à ces ressources peuvent affecter la fiabilité, la sécurité, les opérations et les objectifs de performances de la charge de travail. Il est important d’évaluer ces modifications avant que l’équipe de plateforme ne les place en vigueur pour déterminer comment elles affectent la charge de travail.

• stratégies Azure: les modifications apportées aux stratégies Azure peuvent affecter les ressources de charge de travail et leurs dépendances. Par exemple, il peut y avoir des modifications de stratégie directes ou un déplacement de la zone d’atterrissage dans une nouvelle hiérarchie de groupe d’administration. Ces modifications peuvent passer inaperçues jusqu’à ce qu’il y ait un nouveau déploiement. Il est donc important de les tester soigneusement.

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

• ressources partagées: les modifications apportées à la référence SKU ou aux fonctionnalités sur les 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 peuvent affecter potentiellement la fonctionnalité de charge de travail si une charge de travail 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 charge de travail. Assurez-vous que les modifications apportées au modèle d’accès jump box ont une routine efficace, un accès ad hoc et un accès d’urgence.

• Modifications de propriété: communiquez les modifications apportées à la propriété et aux points de contact de l’équipe de charge de travail, car elles peuvent affecter les demandes de gestion et de support de la charge de travail.

Modifications de charge de travail qui affectent la plateforme

Les exemples suivants sont des modifications de charge 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 par rapport aux nouvelles modifications de l’équipe de charge de travail avant d’entrer en vigueur.

• sortie réseau: surveillez toute augmentation significative de la sortie réseau pour empêcher la charge de travail de devenir un voisin bruyant sur les appareils réseau. Ce problème peut affecter les cibles de performances ou de fiabilité d’autres charges de travail.

• d’accès public : les modifications apportées à l’accès public aux composants de 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é métier: s’il existe des modifications apportées aux contrats de niveau de service (SLA) de la charge de travail, vous devrez peut-être adopter une nouvelle approche de collaboration entre les équipes de plateforme et de charge de travail.

• Modifications de propriété: communiquez les changements de propriété et de points de contact à l’équipe de plateforme.

Modifications des besoins métier de la charge de travail

Pour maintenir les objectifs de niveau de service de la charge de travail, l’équipe de plateforme peut avoir besoin d’être impliquée dans les modifications de l’architecture de charge de travail. Ces modifications peuvent nécessiter la gestion des modifications de l’équipe de plateforme ou la validation 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 afin que l’équipe de plateforme puisse ajouter ce flux dans le pare-feu, Virtual Network Manager 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 bloquer ce flux pour maintenir 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 modifications apportées aux composants d’architecture. Chaque ressource est soumise à des stratégies et à un contrôle de pare-feu de sortie potentiellement.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, qui est un ensemble d’ensembles guidants qui peuvent être utilisés pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité garantit que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Cette architecture s’aligne sur les garanties de fiabilité dans l’architecture de base de référence .

Cibles 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 de charge de travail contrôle directement ces services Azure.

Malgré un SLO maximal plus faible possible, l’aspect clé de la fiabilité est la division des composants de charge de travail entre les équipes fonctionnelles. Avec cette méthode, l’équipe de charge de travail bénéficie d’une équipe spécialisée qui se concentre sur l’infrastructure critique utilisée par cette charge de travail et d’autres charges de travail.

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

Dépendances critiques

Affichez toutes les fonctionnalités que la charge de travail effectue dans la plateforme et la zone d’atterrissage de l’application en tant que dépendances. Les plans de réponse aux incidents nécessitent que l’équipe de charge de travail sache le point et la méthode des informations de contact pour ces dépendances. Incluez également ces dépendances dans l’analyse du mode d’échec de la charge de travail (FMA).

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 non liées à la charge de travail.

• épuisement des ports réseau: les pics d’utilisation de toutes les charges de travail partageant l’appareil réseau peuvent entraîner une saturation du réseau ou une é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 meilleur effort, 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 groupe d’administration: les 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 empêcher les écarts spécifiques à l’environnement qui peuvent bloquer un déploiement ou une mise à l’échelle. Pour plus d’informations, consultez Gérer les environnements de développement d’applications dans les zones d’atterrissage Azure.

La plupart de ces considérations peuvent exister sans zones d’atterrissage Azure, mais les équipes de charge de travail et de plateforme doivent résoudre ces problèmes en collaboration pour s’assurer que les besoins sont satisfaits.

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

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’abus de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

Les considérations de sécurité relatives à cette architecture sont passées de l’architecture de base de référence . Les recommandations des sections suivantes sont basées sur la liste de vérification de la conception de la sécurité dans laWell-Architected Framework.

Contrôles 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 via des groupes de sécurité réseau sur vos sous-réseaux ou la nature ou les contrôles nontransitifs dans le hub régional. Construisez des groupes de sécurité réseau complets qui autorisent uniquement les exigences réseau entrantes de votre application et de son infrastructure. Nous vous recommandons de ne pas vous fier uniquement à la nature nontransitive du réseau hub pour la sécurité.

L’équipe de plateforme implémente probablement des stratégies Azure pour s’assurer qu’Application Gateway dispose d’un pare-feu d’applications web défini sur mode de refus, pour limiter le nombre d’adresses IP publiques disponibles pour votre abonnement et d’autres vérifications. En plus de ces stratégies, l’équipe de charge de travail doit avoir la responsabilité de déployer des stratégies centrées sur la charge de travail qui renforcent la posture de sécurité d’entrée.

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

Source	But	Contrôle de charge de travail	Contrôle de plateforme
Internet	Flux de trafic utilisateur	Entonnoir toutes les requêtes via un groupe de sécurité réseau, un pare-feu d’applications web et des règles de routage avant d’autoriser le trafic public à passer au trafic privé qui entre les machines virtuelles frontales	Aucun
Azure Bastion	Accès des opérateurs aux machines virtuelles	Groupe de sécurité réseau sur les sous-réseaux de machines virtuelles qui bloque tout le trafic vers les ports d’accès distant, sauf s’il est source 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 nontransitif ou règles de pare-feu Azure dans le cas d’un hub sécurisé Azure Virtual WAN

Trafic de sortie

Appliquez des règles de groupe de sécurité réseau qui expriment les exigences de connectivité sortante requises de votre solution et refusent tout le reste. Ne vous fiez pas uniquement aux contrôles réseau hub. En tant qu’opérateur de charge de travail, vous avez la responsabilité d’arrêter le trafic de sortie non souhaité aussi proche de la source que possible.

N’oubliez pas que pendant que vous possédez 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 exigences capturées dans le cadre de votre processus de distribution d’abonnements. Assurez-vous que les modifications apportées aux sous-réseaux et au placement des ressources pendant la durée de vie de votre architecture sont toujours compatibles avec votre demande d’origine. Vous pouvez également travailler avec votre équipe réseau pour garantir la continuité du contrôle de sortie au moins accès.

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

Extrémité	But	Contrôle de charge de travail (NSG)	Contrôle de plateforme (hub)
ntp.ubuntu.com	Protocole NTP (Network Time Protocol) pour les machines virtuelles Linux	UDP/123 à Internet sur le sous-réseau de machine virtuelle frontale (le pare-feu de sortie réduit cette ouverture large)	Allocation de règles de réseau de pare-feu identique au contrôle de charge de travail
Points de terminaison Windows Update	Fonctionnalités De Windows Update à partir de serveurs Microsoft	tcp/443 et TCP/80 sur Internet sur le sous-réseau de la machine virtuelle principale (le pare-feu de sortie réduit cette ouverture étendue)	Règle d’allocation de pare-feu avec balise FQDN de WindowsUpdate
Surveiller les points de terminaison de l’agent	Trafic requis pour l’extension Monitor sur les machines virtuelles	TCP/443 à Internet sur les deux sous-réseaux de machines virtuelles (le pare-feu de sortie réduit cette ouverture large)	Allocations de règles d’application de pare-feu nécessaires pour tous les noms de domaine complets spécifiques sur TCP/443
nginx.org	Pour installer Nginx (un exemple de composant d’application) directement à partir du fournisseur	TCP/443 à Internet sur le sous-réseau de machine virtuelle frontale (le pare-feu de sortie réduit cette ouverture large)	Allocation de règle d’application de pare-feu nécessaire pour nginx.org sur TCP/443
Coffre de clés	Pour importer (transport Layer Security) des certificats TLS dans Application Gateway et les machines virtuelles	- TCP/443 à un sous-réseau de point de terminaison privé des deux sous-réseaux de machines virtuelles vers un sous-réseau de point de terminaison privé - tcp/443 à un sous-réseau de point de terminaison privé à partir d’un sous-réseau Application Gateway - tcp/443 à partir de machines virtuelles marquées avec une désignation de groupe de sécurité d’application (ASG) requise et un sous-réseau Application Gateway	Aucun

DDoS Protection

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 même utiliser Azure Policy pour appliquer des plans de protection de réseau virtuel. Cette architecture doit avoir une couverture, car elle implique une adresse IP publique pour l’entrée à partir d’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 suit l’architecture de base .

En tant qu’équipe de 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

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

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

Cette architecture bénéficie considérablement des ressources de la plateforme de zone d’atterrissage Azure. Même si vous utilisez ces ressources via un modèle de rétrofacturation, la sécurité et la connectivité intersite ajoutées sont plus rentables que la gestion automatique de ces ressources.

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

• Pare-feu Azure
• Informations de sécurité et gestion des événements (SIEM)
• Hôtes Azure Bastion
• Connectivité intersite, telle qu’ExpressRoute

Tirez parti d’autres offres centralisées de votre équipe de plateforme pour étendre ces avantages à votre charge de travail sans compromettre son SLO, son objectif de temps 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 de collaboration partagés entre une équipe de charge de travail et des équipes de plateforme.

abonnement vendant