Architecture de base stratégique avec des contrôles réseau
Cette architecture fournit des conseils pour la conception d’une charge de travail stratégique qui dispose de contrôles réseau stricts en place pour empêcher tout accès public non autorisé à partir d’Internet à l’une des ressources de charge de travail. L’intention est d’arrêter les vecteurs d’attaque au niveau de la couche réseau afin que la fiabilité globale du système ne soit pas affectée. Par exemple, une attaque par déni de service distribué (DDoS), si elle n’est pas cochée, peut entraîner l’indisponibilité d’une ressource en l’accablant avec le trafic illicite.
Il s’appuie sur l’architecture de base 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 permettant de restreindre les chemins d’entrée et de sortie à l’aide des fonctionnalités cloud natives appropriées, telles que le réseau virtuel Azure (VNet) et les points de terminaison privés, Azure Private Link, Azure Private DNS Zone, etc.
Il est recommandé de vous familiariser avec la base de référence avant de passer à cet article.
Stratégies de conception clés
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 supplémentaires relatives à la mise en réseau pour cette architecture :
Contrôler le trafic d’entrée
L’entrée ou la communication entrante dans le réseau virtuel doit être limitée pour empêcher les attaques malveillantes.
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 d’attaque.
Éliminez la connectivité publique aux services Azure. Une approche consiste à utiliser des points de terminaison privés.
Inspectez le trafic avant d’entrer dans le réseau. Les groupes de sécurité réseau (NSG) 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 aide également à la journalisation granulaire.
Contrôler le trafic de sortie
Le trafic de sortie d’un réseau virtuel vers des entités extérieures à ce réseau doit être restreint. Le manque de contrôles peut entraîner des attaques d’exfiltration de données par des services tiers malveillants.
Limitez le trafic sortant vers Internet à l’aide du Pare-feu Azure. Le pare-feu peut filtrer le trafic de manière granulaire à l’aide du nom de domaine complet (FQDN).
Équilibrer les compromis avec la sécurité
Il existe des compromis significatifs lorsque les fonctionnalités de sécurité sont ajoutées à une architecture de charge de travail. Vous remarquerez peut-être un impact sur les performances, l’agilité opérationnelle et même la fiabilité. Toutefois, les attaques, telles que déni-Of-Service (DDoS), les intrusions de données et d’autres, peuvent cibler la fiabilité globale du système et éventuellement provoquer une indisponibilité.
Les stratégies sont basées sur les conseils globaux fournis pour les charges de travail stratégiques dans les charges de travail stratégiques bien conçues. Nous vous suggérons d’explorer le domaine de conception de la mise en réseau et de la connectivité pour les recommandations et les meilleures pratiques lors de la définition de votre propre architecture critique.
Architecture
Téléchargez un fichier Visio de cette architecture.
Les composants de cette architecture peuvent être catégorisés de cette manière. Pour obtenir de la documentation sur les services Azure, consultez les ressources associées.
Ressources globales
Les ressources globales vivent longtemps et partagent la durée de vie du système. Ils ont la possibilité 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 acheminer de manière fiable le trafic vers les déploiements régionaux, qui sont exposés via des points de terminaison privés.
Reportez-vous aux charges de travail stratégiques bien conçues : routage du trafic global.
Azure Cosmos DB pour NoSQL est toujours utilisé pour stocker l’état en dehors du cluster de calcul et a des 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.
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 bien conçues : 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. Ils sont de courte durée pour fournir plus de résilience, de mise à l’échelle et de proximité aux utilisateurs. Ces ressources ne partagent rien avec les ressources d’une autre région. Elles peuvent être supprimées ou répliquées indépendamment dans d’autres régions. Toutefois, ils partagent des ressources globales entre elles. Pour plus d’informations, consultez les ressources d’horodatage régional.
Le site web statique d’un compte de stockage Azure héberge une application monopage (SPA) qui envoie des demandes aux services principaux. Ce composant a la même configuration que le serveur frontal 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 des opérations de charge de travail et 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 pour le calcul principal qui exécute une application et sans état. Le cluster AKS est déployé en tant que cluster privé. Par conséquent, le serveur d’API Kubernetes n’est 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 du cluster de calcul de cette architecture.
Le Pare-feu Azure inspecte et protège tout le trafic de sortie des ressources de 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.
Azure Key Vault est utilisé comme magasin de secrets régional. L’accès est limité aux connexions de point de terminaison privé autorisées.
Ressources de pipeline de déploiement
Les pipelines de génération 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 un tampon validé.
GitHub est toujours utilisé pour le contrôle de code source en tant que plateforme git hautement disponible.
Azure Pipelines est choisi pour automatiser les pipelines requis pour la création, 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 bien conçues : processus DevOps.
Les pools d’agents de build Azure DevOps auto-hébergés sont utilisés pour contrôler davantage les builds et les déploiements. Ce niveau d’autonomie est nécessaire, car le cluster de calcul et toutes les ressources PaaS sont privés, ce qui nécessite une intégration au niveau du réseau qui n’est pas possible sur 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ée unique 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 surveillance des applications et les stocker directement dans Log Analytics.
Ressources de gestion
Une modification significative de la conception de l’architecture de base est le cluster de calcul. Dans cette conception, le cluster AKS est privé. Cette modification nécessite l’approvisionnement de ressources supplémentaires pour obtenir l’accès.
Groupes de machines virtuelles identiques Azure pour les agents de build privés et les instances de jump box pour exécuter des outils sur le cluster, tels que kubectl.
Azure Bastion fournit un accès sécurisé aux machines virtuelles jump box et supprime la nécessité pour les machines virtuelles d’avoir des adresses IP publiques.
Points de terminaison privés pour les services PaaS
Pour traiter les opérations d’entreprise ou de déploiement, l’application et les agents de build doivent atteindre plusieurs services PaaS Azure approvisionnés globalement, au sein de la région et même dans le tampon. Dans l’architecture de base, cette communication se trouve sur les points de terminaison publics des services.
Dans 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’exposition d’attaque globale pour atténuer la falsification directe du service à partir de sources inattendues. Toutefois, il introduit un autre point de défaillance potentiel et augmente la complexité. Prenez soigneusement en compte les compromis avec 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 du tampon. Les adresses IP privées aux points de terminaison privés sont affectées à partir de ce sous-réseau. Essentiellement, toute ressource du réseau virtuel peut communiquer avec le service en atteignant l’adresse IP privée. Assurez-vous que l’espace d’adressage est suffisamment grand pour prendre en charge tous les points de terminaison privés nécessaires pour ce tampon.
Pour vous connecter sur un point de terminaison privé, vous avez besoin d’un enregistrement DNS. Il est recommandé que les enregistrements DNS associés aux services soient conservés dans des zones DNS privées Azure serviceées par Azure DNS. Assurez-vous que le nom de domaine complet (FQDN) est résolu en 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, ressources de stockage et Event Hubs. En outre, le cluster AKS est déployé en tant que cluster privé, ce 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 ont tous deux des sous-réseaux dédiés pour contenir des points de terminaison privés pour tous ces services. La disposition du réseau est décrite dans la disposition du réseau virtuel.
Lorsque vous ajoutez d’autres 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 plus d’informations, consultez Utiliser Azure Private Link pour connecter des réseaux à Azure Monitor.
Ils peuvent être créés sur les mêmes sous-réseaux 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 à l’aide de 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 tout le trafic client entrant. Il utilise des 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 n’entrent dans les réseaux virtuels d’horodatage.
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’adresses IP/points de terminaison publics sur les back-ends. Cela nécessite un équilibreur de charge interne dans le réseau virtuel d’horodatage. Cette ressource est devant le contrôleur d’entrée Kubernetes s’exécutant dans le cluster. Outre cet équilibreur de charge privé, un service Private Link est créé par AKS, qui est utilisé pour la connexion privée à partir de Front Door.
Une fois la connexion établie, les points de terminaison privés sur le réseau Front Door disposent d’une connectivité directe avec l’équilibreur de charge et le site web statique dans le réseau d’horodatage sur Private Link.
Pour plus d’informations, consultez le fonctionnement de Private Link.
Reportez-vous aux charges de travail stratégiques bien conçues : services de remise d’applications.
Sortie restreinte
Les applications peuvent nécessiter une connectivité Internet sortante. Le contrôle de ce trafic permet de limiter, surveiller et restreindre le trafic de sortie. Sinon, un accès inattendu à l’intérieur peut entraîner une compromission et un état système potentiellement non fiable. La sortie restreinte peut également résoudre d’autres problèmes de sécurité, tels que l’exfiltration des données.
L’utilisation du pare-feu et des groupes de sécurité réseau (NSG) permet de s’assurer que le trafic sortant de l’application est inspecté et journalisé.
Dans cette architecture, le pare-feu Azure est le point de sortie unique et est utilisé pour inspecter tout le trafic sortant provenant du réseau virtuel. Les itinéraires définis par l’utilisateur sont utilisés sur des sous-réseaux capables de générer le trafic de sortie, tel que le sous-réseau de l’application.
Pour plus d’informations sur la restriction du trafic sortant, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans Azure Kubernetes Service (AKS).
Disposition du réseau virtuel
Isoler les ressources régionales et les ressources de gestion dans des réseaux virtuels distincts. Ils ont des caractéristiques, des objectifs et des considérations de sécurité distincts.
Type de trafic : les ressources régionales, qui participent au traitement des opérations métier, ont besoin de contrôles de sécurité plus élevés. Par exemple, le cluster de calcul doit être protégé contre le trafic Internet direct. Les ressources de gestion sont approvisionnées uniquement pour accéder aux ressources régionales pour les opérations.
Durée de vie : les durées de vie attendues de ces ressources sont également différentes. Les ressources régionales devraient être de courte durée (éphémère). Ils sont créés dans le cadre du tampon de déploiement et détruits lorsque le tampon est détruit. Les ressources de gestion partagent la durée de vie de la région et les ressources d’horodatage.
Dans cette architecture, il existe deux réseaux virtuels : réseau d’empreintes et 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 (NSG) pour sécuriser la communication entre les sous-réseaux.
Reportez-vous aux charges de travail stratégiques bien conçues : réseaux virtuels isolés.
Réseau virtuel d’horodatage régional
Le tampon de déploiement provisionne un réseau virtuel dans chaque région.
Le réseau virtuel est divisé en sous-réseaux principaux. Tous les sous-réseaux ont des groupes de sécurité réseau affectés pour bloquer tout accès non autorisé à partir du réseau virtuel. Les groupes de sécurité réseau limitent le trafic entre le sous-réseau de l’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 de chaque tampon est un équilibreur de charge Standard Azure 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 approvisionnées dans le cadre du déploiement d’empreintes.
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 du sous-réseau d’application à l’aide d’un itinéraire défini par l’utilisateur (UDR).
Sous-réseau des points de terminaison privés
Le sous-réseau d’application doit accéder aux services PaaS dans le tampon régional, Key Vault et d’autres. En outre, l’accès aux ressources globales telles que le registre de conteneurs est nécessaire. Dans cette architecture, tous les services PaaS sont verrouillés et peuvent uniquement être atteints via des points de terminaison privés. Par conséquent, un autre sous-réseau est créé pour ces points de terminaison. L’accès entrant à ce sous-réseau est sécurisé par le groupe de sécurité réseau qui autorise uniquement le trafic de l’application.
Vous pouvez ajouter d’autres restrictions à l’aide de la prise en charge de l’UDR pour les points de terminaison privés, afin que ce trafic puisse également passer par le sous-réseau de sortie de tampon.
Réseau virtuel des 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, tout le déploiement et le trafic opérationnel doivent également provenir de ressources privées telles que les agents de build auto-hébergés et les jump box. Ces ressources sont déployées dans un réseau virtuel distinct avec une connectivité directe aux ressources de l’application via leur propre ensemble de points de terminaison privés. Les agents de build et les zones de saut se trouvent dans des sous-réseaux distincts.
Au lieu d’utiliser des points de terminaison privés, une autre approche consiste à utiliser le peering de réseaux virtuels. Toutefois, le peering ajoute de la complexité qui peut être difficile à gérer en particulier lorsque les réseaux virtuels sont conçus pour être éphémères.
Les agents de build (et éventuellement les zones de saut) doivent accéder aux services PaaS situés globalement et dans le tampon régional. Comme pour le réseau virtuel d’horodatage régional, un sous-réseau dédié est créé pour les points de terminaison privés aux services PaaS nécessaires. Le groupe de sécurité réseau 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 cas d’usage classique est lorsqu’un opérateur doit accéder au cluster de calcul pour exécuter des outils de gestion et des commandes. Le service d’API d’un cluster privé n’est pas accessible directement. C’est pourquoi les sauts sont provisionnés où l’opérateur peut exécuter les outils. Il existe un sous-réseau distinct pour les zones de saut.
Toutefois, ces sauts doivent également être protégés contre les accès non autorisés. L’accès direct aux zones de saut en ouvrant des ports RDP/SSH doit être évité. Azure Bastion est recommandé à cet effet et nécessite un sous-réseau dédié dans ce réseau virtuel.
Avertissement
La connectivité via Azure Bastion et les zones de rebond peuvent avoir un impact sur la productivité des développeurs, par exemple l’exécution d’outils de débogage nécessite un processus supplémentaire. Tenez compte de ces impacts avant de décider de renforcer la sécurité de votre charge de travail stratégique.
Vous pouvez restreindre davantage l’accès au sous-réseau de zone de rebond à l’aide d’un groupe de sécurité réseau qui autorise uniquement le trafic entrant à partir du sous-réseau Bastion via SSH.
Opérations de déploiement
Pour générer des pipelines de déploiement, vous devez provisionner des calculs supplémentaires pour exécuter des agents de build. Ces ressources n’affectent pas directement la disponibilité du runtime de la charge de travail, mais une défaillance de fiabilité peut compromettre la possibilité de déployer ou de traiter votre environnement stratégique. Par conséquent, les fonctionnalités de fiabilité doivent être étendues à ces ressources.
Cette architecture utilise des groupes de machines virtuelles identiques pour les agents de build et les zones de rebond (par opposition à des machines virtuelles uniques). En outre, la segmentation du réseau est fournie via l’utilisation de sous-réseaux. L’entrée est limitée à Azure DevOps.
Considérations relatives au coût
Il y a un impact significatif sur les coûts des 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 l’approvisionnement du pare-feu Azure dans chaque tampon entraînent des coûts accrus. Il existe également des coûts supplémentaires liés à la maintenance et aux ressources opérationnelles. Ces compromis doivent être soigneusement pris en compte avant d’adopter une version contrôlée par le réseau de l’architecture de base.
Déployer cette architecture
Les aspects réseau de cette architecture sont implémentés dans l’implémentation connectée stratégique.
Remarque
L’implémentation connectée est destinée à illustrer une charge de travail stratégique qui s’appuie sur des ressources organisationnelles, s’intègre à d’autres charges de travail et utilise des services partagés. Il s’appuie sur cette architecture et utilise les contrôles réseau décrits dans cet article. Toutefois, le scénario connecté suppose que le réseau privé virtuel ou la zone DNS privée Azure existent déjà dans l’abonnement de connectivité des zones d’atterrissage Azure.
Étapes suivantes
Pour plus d’informations sur les décisions de conception prises dans cette architecture, passez en revue la zone de conception de la mise en réseau et de la 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.