Cette architecture fournit une aide pour la conception d’une charge de travail stratégique avec des contrôles réseau stricts en place pour empêcher tout accès public non autorisé aux ressources de charge de travail à partir d’Internet. L’intention est d’arrêter les vecteurs d’attaque au niveau de la couche réseau pour que la fiabilité globale du système ne soit pas impactée. Par exemple, une attaque par déni de service distribué (DDoS, Distributed Denial of Service) qui n’est pas surveillée peut entraîner l’indisponibilité d’une ressource en la surchargeant avec un trafic illégitime.
Cette architecture s’appuie sur l’architecture de référence stratégique, qui est axée sur l’optimisation de la fiabilité et de l’efficacité opérationnelle sans contrôles réseau. Cette architecture ajoute des fonctionnalités pour limiter les chemins d’entrée et de sortie à l’aide de fonctionnalités natives cloud appropriées telles que les points de terminaison privés et le Réseau virtuel (VNet) Azure, Azure Private Link, la zone DNS privée Azure, etc.
Il est recommandé de se familiariser avec la base de référence avant de suivre cet article.
Stratégies de conception
Les stratégies de conception pour la base de référence stratégique s’appliquent toujours dans ce cas d’usage. Voici les considérations réseau supplémentaires pour cette architecture :
Contrôler le trafic d’entrée
Les communications en entrée (ou entrantes) vers le réseau virtuel doivent être limitées pour empêcher les attaques.
Appliquez les fonctionnalités WAF (Web Application Firewall) au niveau global pour arrêter les attaques à la périphérie du réseau, plus près de la source de l’attaque.
Éliminez la connectivité publique aux services Azure. Une approche consiste à utiliser des points de terminaison privés.
Inspectez le trafic avant son entrée dans le réseau. Des groupes de sécurité réseau sur les sous-réseaux permettent de filtrer le trafic en autorisant ou en refusant le flux vers les adresses IP et les ports configurés. Ce niveau de contrôle permet également une journalisation précise.
Contrôler le trafic de sortie
Le trafic de sortie à partir d’un réseau virtuel vers des entités extérieures à ce réseau doit être limité. L’absence de contrôles peut permettre à des services tiers malveillants d’effectuer des attaques d’exfiltration de données.
Limitez le trafic sortant vers Internet à l’aide du Pare-feu Azure. Celui-ci peut filtrer le trafic de manière précise à l’aide du nom de domaine complet.
Équilibrer les compromis liés à la sécurité
L’ajout de fonctionnalités de sécurité à une architecture de charge de travail entraîne d’importants compromis. Vous remarquerez peut-être un impact sur les performances, l’agilité opérationnelle et même la fiabilité. Toutefois, les attaques de type DDoS, intrusions de données, etc. peuvent cibler la fiabilité globale du système et, au final, provoquer une indisponibilité.
Les stratégies sont basées sur l’aide globale fournie pour les charges de travail stratégiques dans Charges de travail stratégiques Well-Architected. Nous vous suggérons d’explorer la zone de conception réseau et connectivité afin d’obtenir des recommandations et de connaître les bonnes pratiques pour définir votre propre architecture stratégique.
Architecture
Téléchargez un fichier Visio de cette architecture.
Les composants de cette architecture peuvent être classés de manière générale de cette manière. Pour obtenir de la documentation sur les services Azure, consultez Ressources associées.
Ressources globales
Les ressources globales ont une longue durée de vie et partagent la durée de vie du système. Ils ont la capacité d’être disponibles globalement dans le contexte d’un modèle de déploiement multirégion. Pour plus d’informations, consultez Ressources globales.
La référence SKU Azure Front Door Premium est utilisée comme équilibreur de charge global pour router, de manière fiable, le trafic vers les déploiements régionaux exposés par le biais de points de terminaison privés.
Reportez-vous aux charges de travail stratégiques Well-Architected : routage du trafic global.
Azure Cosmos DB for NoSQL est toujours utilisé pour stocker l’état en dehors du cluster de calcul. Il dispose de paramètres de configuration de référence pour la fiabilité. L’accès est limité aux connexions de point de terminaison privé autorisées.
Reportez-vous aux charges de travail stratégiques Well-Architected : magasin de données multi-écriture distribué à l’échelle mondiale.
Azure Container Registry est utilisé pour stocker toutes les images conteneur avec des fonctionnalités de géoréplication. L’accès est limité aux connexions de point de terminaison privé autorisées.
Reportez-vous aux charges de travail stratégiques Well-Architected : registre de conteneurs.
Ressources régionales
Les ressources régionales sont approvisionnées dans le cadre d’un tampon de déploiement dans une seule région Azure. Elles ont une courte durée de vie pour offrir plus de résilience, de scalabilité et de proximité avec les utilisateurs. Ces ressources ne partagent rien avec les ressources d’une autre région. Elles peuvent être répliquées dans d’autres régions ou supprimées de manière indépendante. Toutefois, ils partagent les ressources globales entre elles. Pour plus d’informations, consultez Ressources d’empreinte régionales.
Un site web statique dans un compte Stockage Azure héberge une application monopage qui envoie des requêtes aux services back-end. Ce composant a la même configuration que le front-end de référence. L’accès est limité aux connexions de point de terminaison privé autorisées.
Les réseaux virtuels Azure fournissent des environnements sécurisés pour l’exécution de la charge de travail et les opérations de gestion.
L’équilibreur de charge interne est l’origine de l’application. Front Door utilise cette origine pour établir une connectivité privée et directe au back-end à l’aide de Private Link.
Azure Kubernetes Service (AKS) est l’orchestrateur du calcul back-end qui exécute une application et est sans état. Le cluster AKS est déployé en tant que cluster privé. Le serveur d’API Kubernetes n’est donc pas exposé à l’Internet public. L’accès au serveur d’API est limité à un réseau privé. Pour plus d’informations, consultez l’article Cluster de calcul de cette architecture.
Reportez-vous aux charges de travail stratégiques Well-Architected : orchestration de conteneurs et Kubernetes.
Le Pare-feu Azure inspecte et protège tout le trafic de sortie des ressources du Réseau virtuel Azure.
Azure Event Hubs est utilisé comme répartiteur de messages. L’accès est limité aux connexions de point de terminaison privé autorisées.
Reportez-vous aux charges de travail stratégiques Well-Architected : architecture basée sur des événements à faible couplage.
Azure Key Vault est utilisé comme magasin secret régional. L’accès est limité aux connexions de point de terminaison privé autorisées.
Reportez-vous aux charges de travail stratégiques Well-Architected : protection de l’intégrité des données.
Ressources de pipeline de déploiement
Les pipelines de build et de mise en production pour une application stratégique doivent être entièrement automatisés pour garantir un moyen cohérent de déployer une empreinte validée.
GitHub est toujours utilisé pour le contrôle de code source comme plateforme Git hautement disponible.
Azure Pipelines est choisi pour automatiser les pipelines requis pour la génération, le test et le déploiement d’une charge de travail dans les environnements de préproduction et de production.
Reportez-vous aux charges de travail stratégiques Well-Architected : processus DevOps.
Des pools d’agents de build Azure DevOps auto-hébergés sont utilisés pour permettre un meilleur contrôle des builds et des déploiements. Ce niveau d’autonomie est nécessaire, car le cluster de calcul et toutes les ressources PaaS sont privés, et ceci implique une intégration au niveau du réseau que ne permettent pas les agents de build hébergés par Microsoft.
Ressources d’observabilité
Les données de surveillance des ressources globales et des ressources régionales sont stockées indépendamment. Un magasin d’observabilité centralisé n’est pas recommandé pour éviter un point de défaillance unique. Pour plus d’informations, consultez Ressources d’observabilité.
Azure Log Analytics est utilisé comme récepteur unifié pour stocker les journaux et les métriques pour tous les composants d’application et d’infrastructure.
Azure Application Insights est utilisé comme outil APM (Application Performance Management) pour collecter toutes les données de supervision des applications et les stocker directement dans Log Analytics.
Reportez-vous aux charges de travail stratégiques Well-Architected : actions prédictives et opérations d’IA.
Ressources de gestion
Le cluster de calcul représente un changement de conception majeur par rapport à l’architecture de référence. Dans le cadre de cette conception, le cluster AKS est privé. De par ce changement, l’obtention de l’accès nécessite le provisionnement de ressources supplémentaires.
Azure Virtual Machine Scale Sets pour que les agents de build privés et les instances de jump box exécutent des outils sur le cluster (kubectl, par exemple).
Azure Bastion fournit un accès sécurisé aux machines virtuelles jump box et élimine la nécessité pour les machines virtuelles d’avoir des IP publiques.
Points de terminaison privés pour les services PaaS
Pour traiter les opérations métier ou de déploiement, l’application et les agents de build doivent atteindre plusieurs services PaaS Azure provisionnés globalement, au sein de la région et même dans l’empreinte. Dans l’architecture de référence, cette communication a lieu sur les points de terminaison publics des services.
Dans le cadre de cette conception, ces services ont été protégés avec des points de terminaison privés pour les supprimer de l’accès Internet public. Cette approche réduit la surface d’attaque globale et atténue ainsi le risque de falsification directe des services à partir de sources inattendues. Toutefois, elle introduit un autre point de défaillance potentiel et augmente la complexité. Évaluez minutieusement les compromis liés à la sécurité avant d’adopter cette approche.
Les points de terminaison privés doivent être placés dans un sous-réseau dédié du réseau virtuel de l’empreinte. Les adresses IP privées des points de terminaison privés sont attribuées à partir de ce sous-réseau. D’une manière générale, toute ressource du réseau virtuel peut communiquer avec le service en atteignant l’adresse IP privée. Veillez à ce que l’espace d’adressage soit suffisamment étendu pour comprendre tous les points de terminaison privés nécessaires à cette empreinte.
Pour vous connecter sur un point de terminaison privé, vous avez besoin d’un enregistrement DNS. Il est recommandé de conserver les enregistrements DNS associés aux services dans des zones DNS privées Azure gérées par Azure DNS. Veillez à ce que le nom de domaine complet corresponde à l’adresse IP privée.
Dans cette architecture, les points de terminaison privés ont été configurés pour Azure Container Registry, Azure Cosmos DB, Key Vault, les ressources de stockage et Event Hubs. En outre, le cluster AKS est déployé comme cluster privé, qui crée un point de terminaison privé pour le service d’API Kubernetes dans le réseau du cluster.
Il existe deux réseaux virtuels provisionnés dans cette conception et ils ont tous deux des sous-réseaux dédiés où seront placés les points de terminaison privés pour tous ces services. La disposition réseau est décrite dans Disposition de réseau virtuel.
À mesure que vous ajoutez des composants à l’architecture, envisagez d’ajouter d’autres points de terminaison privés. Par exemple, vous pouvez ajouter des restrictions aux ressources d’observabilité. Azure Log Analytics et Azure Application Insights prennent en charge l’utilisation de points de terminaison privés. Pour obtenir des informations détaillées, consultez Utiliser Azure Private Link pour connecter des réseaux à Azure Monitor.
Ils peuvent être créés sur des sous-réseaux identiques ou différents au sein du même réseau virtuel. Il existe des limites au nombre d’instances Private Endpoint que vous pouvez créer dans un abonnement. Pour plus d'informations, consultez Limites Azure.
Contrôlez l’accès aux services de façon plus poussée en utilisant des groupes de sécurité réseau sur le sous-réseau.
Entrée privée
La référence SKU Azure Front Door Premium est utilisée comme point d’entrée global pour l’ensemble du trafic client entrant. Elle utilise les fonctionnalités WAF (Web Application Firewall) pour autoriser ou refuser le trafic à la périphérie du réseau. Les règles WAF configurées empêchent les attaques avant même qu’elles ne pénètrent dans les réseaux virtuels d’empreinte.
Cette architecture tire également parti de la capacité de Front Door à utiliser Azure Private Link pour accéder à l’origine de l’application sans utiliser d’IP/points de terminaison publics sur les back-ends. Ceci nécessite un équilibreur de charge interne dans le réseau virtuel d’empreinte. Cette ressource se trouve devant le contrôleur d’entrée Kubernetes qui s’exécute dans le cluster. En plus de cet équilibreur de charge privé, un service Private Link est créé par AKS et utilisé pour la connexion privée à partir de Front Door.
Quand la connexion est établie, les points de terminaison privés sur le réseau Front Door ont une connectivité directe avec l’équilibreur de charge et le site web statique dans le réseau d’empreinte sur Private Link.
Pour plus d’informations, consultez Comment fonctionne Private Link.
Consultez Charges de travail stratégiques Well-Architected : services de distribution d’applications.
Sortie limitée
Les applications peuvent nécessiter une connectivité Internet sortante. Le contrôle de ce trafic permet de limiter, de superviser et de restreindre le trafic de sortie. Sinon, un accès sortant inattendu peut entraîner une compromission et, potentiellement, un état système non fiable. Une sortie limitée peut également résoudre d’autres problèmes de sécurité, notamment l’exfiltration de données.
L’utilisation du pare-feu et de groupes de sécurité réseau peut garantir l’inspection et la journalisation du trafic sortant à partir de l’application.
Dans cette architecture, le Pare-feu Azure est le seul point de sortie et est utilisé pour inspecter l’ensemble du trafic sortant provenant du réseau virtuel. Des routes définies par l’utilisateur sont utilisées sur les sous-réseaux capables de générer du trafic de sortie comme le sous-réseau d’application.
Pour obtenir des informations sur la limitation du trafic de sortie, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans Azure Kubernetes Service (AKS).
Disposition de réseau virtuel
Isolez les ressources régionales et les ressources de gestion dans des réseaux virtuels distincts, dont les caractéristiques, rôles et considérations de sécurité diffèrent.
Type de trafic : ressources régionales, qui participent au traitement des opérations métier et nécessitent des contrôles de sécurité plus élevés. Par exemple, le cluster de calcul doit être protégé du trafic Internet direct. Les ressources de gestion sont provisionnées uniquement pour accéder aux ressources régionales pour les opérations.
Durée de vie : la durée de vie attendue de ces ressources diffère également. Les ressources régionales sont supposées avoir une courte durée de vie (ressources éphémères). Elles sont créées dans le cadre de l’empreinte de déploiement et détruites en même temps que l’empreinte. Les ressources de gestion ont la même durée de vie que la région et survivent aux ressources d’empreinte.
Dans cette architecture, il existe deux réseaux virtuels : le réseau d’empreinte et le réseau d’opérations. Créez une isolation supplémentaire au sein de chaque réseau virtuel à l’aide de sous-réseaux et de groupes de sécurité réseau pour sécuriser la communication entre les sous-réseaux.
Consultez Charges de travail stratégiques Well-Architected : réseaux virtuels isolés.
Réseau virtuel d’empreinte régionale
L’empreinte de déploiement provisionne un réseau virtuel dans chaque région.
Le réseau virtuel est composé des principaux sous-réseaux décrits plus bas. Des groupes de sécurité réseau (NSG, network security group) sont attribués à tous les sous-réseaux pour bloquer tout accès non autorisé à partir du réseau virtuel. Ces NSG limitent le trafic entre le sous-réseau d’application et d’autres composants du réseau.
Sous-réseau d’application
Les pools de nœuds de cluster AKS sont isolés dans un sous-réseau. Si vous devez isoler davantage le pool de nœuds système du pool de nœuds Worker, vous pouvez les placer dans des sous-réseaux distincts.
Sous-réseau d’entrée d’empreinte
Le point d’entrée vers chaque empreinte est un équilibreur de charge Azure Standard Load Balancer interne placé dans un sous-réseau dédié. Le service Private Link utilisé pour la connexion privée à partir de Front Door est également placé ici.
Les deux ressources sont provisionnées dans le cadre du déploiement d’empreinte.
Sous-réseau de sortie d’empreinte
Le Pare-feu Azure est placé dans un sous-réseau distinct et inspecte le trafic de sortie à partir du sous-réseau d’application à l’aide d’une route définie par l’utilisateur.
Sous-réseau de points de terminaison privés
Le sous-réseau d’application doit accéder aux services PaaS dans l’empreinte régionale, Key Vault, etc. Un accès aux ressources globales telles que le registre de conteneurs est également nécessaire. Dans cette architecture, tous les services PaaS sont verrouillés et sont accessibles uniquement par le biais de points de terminaison privés. Un autre sous-réseau est donc créé pour ces points de terminaison. L’accès entrant à ce sous-réseau est sécurisé par un NSG qui autorise uniquement le trafic à partir de l’application.
Vous pouvez ajouter d’autres restrictions en utilisant la prise en charge des routes définies par l’utilisateur pour les points de terminaison privés afin que ce trafic de sortie puisse également passer par le sous-réseau de sortie d’empreinte.
Réseau virtuel d’opérations
Le trafic opérationnel est isolé dans un réseau virtuel distinct. Étant donné que le service d’API du cluster AKS est privé dans cette architecture, l’ensemble du trafic de déploiement et opérationnel doit également provenir de ressources privées, par exemple des jump boxes et des agents de build auto-hébergés. Ces ressources sont déployées dans un réseau virtuel distinct avec une connectivité directe aux ressources d’application par le biais de leur propre ensemble de points de terminaison privés. Les agents de build et les jump boxes se trouvent dans des sous-réseaux distincts.
Plutôt que d’utiliser des points de terminaison privés, une autre approche consiste à utiliser l’appairage de réseaux virtuels. Toutefois, l’appairage ajoute une complexité qui peut être difficile à gérer, en particulier quand les réseaux virtuels sont conçus pour être éphémères.
Les agents de build (et éventuellement les jump boxes) doivent accéder aux services PaaS qui sont placés de manière globale et dans l’empreinte régionale. Comme dans le cas du réseau virtuel d’empreinte régionale, un sous-réseau dédié est créé pour les points de terminaison privés sur les services PaaS nécessaires. Un NSG sur ce sous-réseau garantit que le trafic d’entrée est autorisé uniquement à partir des sous-réseaux de gestion et de déploiement.
Opérations de gestion
Un opérateur qui doit accéder au cluster de calcul pour exécuter des outils et des commandes de gestion représente un cas d’usage classique. Le service API dans un cluster privé n’est pas accessible directement. C’est pourquoi des jump boxes sont provisionnées là où l’opérateur peut exécuter les outils. Il existe un sous-réseau distinct pour les jump boxes.
Toutefois, ces jump boxes doivent également être protégés contre tout accès non autorisé. L’accès direct aux jump boxes avec l’ouverture de ports RDP/SSH doit être évité. Il est recommandé pour cela d’utiliser Azure Bastion, qui nécessite un sous-réseau dédié dans ce réseau virtuel.
Attention
La connectivité par le biais d’Azure Bastion et des jump boxes peut avoir un impact sur la productivité des développeurs. L’exécution d’outils de débogage, notamment, nécessite un processus supplémentaire. Tenez compte de ces impacts avant de décider de durcir la sécurité pour votre charge de travail stratégique.
Vous pouvez limiter davantage l’accès au sous-réseau jump box à l’aide d’un NSG qui autorise uniquement le trafic entrant à partir du sous-réseau Bastion sur SSH.
Opérations de déploiement
Pour générer des pipelines de déploiement, vous devez provisionner des ressources de calcul supplémentaires pour exécuter les agents de build. Ces ressources n’impactent pas directement la disponibilité du runtime de la charge de travail. Cependant, un défaut de fiabilité peut compromettre la capacité à déployer ou faire fonctionner votre environnement stratégique. Les fonctionnalités de fiabilité doivent donc être étendues à ces ressources.
Cette architecture utilise des groupes de machines virtuelles identiques pour les agents de build et les jumpboxes (et non des machines virtuelles uniques). En outre, la segmentation du réseau repose sur l’utilisation de sous-réseaux. L’entrée est limitée à Azure DevOps.
Considérations relatives au coût
Cette approche a un impact significatif en termes de coûts pour les charges de travail stratégiques. Dans cette architecture, les choix technologiques tels que l’utilisation de la référence SKU Azure Front Door Premium et le provisionnement du Pare-feu Azure dans chaque empreinte augmentent les coûts. Les ressources de maintenance et opérationnelles entraînent également des coûts supplémentaires. Vous devez évaluer minutieusement ces compromis avant d’adopter une version de l’architecture de référence contrôlée par le réseau.
Déployer cette architecture
Les aspects de cette architecture relatifs au réseau sont implémentés dans l’implémentation Mission-Critical Connected.
Notes
L’implémentation Connected est destinée à illustrer une charge de travail stratégique qui repose sur des ressources organisationnelles, s’intègre à d’autres charges de travail et utilise des services partagés. Elle s’appuie sur cette architecture et utilise les contrôles réseau décrits dans cet article. Toutefois, le scénario Connected suppose l’existence préalable d’un réseau privé virtuel ou d’une zone DNS privée Azure dans l’abonnement de connectivité des zones d’atterrissage Azure.
Étapes suivantes
Pour plus d’informations sur les décisions de conception prises dans le cadre de cette architecture, reportez-vous à la zone de conception réseau et connectivité pour les charges de travail stratégiques dans Azure Well-Architected Framework.
Ressources associées
Pour obtenir de la documentation sur les services Azure utilisés dans cette architecture, consultez ces articles.