Migrer et moderniser le parcours de conception réseau

Ce guide fournit un chemin de lecture séquencé dans le guide de conception de mise en réseau Azure pour les clients qui adoptent des services PaaS (Platform as a Service), des conteneurs et des bases de données managées. Suivez les étapes numérotées pour créer un réseau multirégion, en couches de sécurité qui prend en charge les architectures d’application modernes.

Overview

Migrer et moderniser des projets au-delà des machines virtuelles vers des services natifs Azure : Azure Kubernetes Service (AKS) pour les conteneurs, les Azure App Service pour les applications web, les Azure SQL Database et les Azure Cosmos DB pour les données managées et Azure Front Door pour la distribution du trafic global. Votre réseau doit prendre en charge la connectivité privée à ces services PaaS, aux déploiements multirégions actifs et à une segmentation de sécurité stricte entre les niveaux d’application.

Votre architecture cible utilise une topologie double hub couvrant deux régions Azure. Les réseaux virtuels hub gérés par le service informatique hébergent des services partagés comme Pare-feu Azure et passerelle VPN. Les équipes d'application possèdent leurs réseaux virtuels spoke et contrôlent leurs propres sous-réseaux Private Link pour la connectivité PaaS. Le trafic entre via Azure Front Door ou Azure Traffic Manager, passe par l'inspection du pare-feu du hub et atteint les services d'application exécutés dans des spokes isolés.

Ce parcours de lecture vous guide dans 14 articles essentiels en cinq phases. Ce parcours est plus long qu’une approche lift-and-shift, car les architectures modernes exigent des décisions concernant les modèles d’exposition des flux entrants, la connectivité PaaS privée, les pare-feu d’applications web et la protection contre les attaques DDoS, que les architectures reposant uniquement sur l’IaaS peuvent remettre à plus tard. Deux points de contrôle de jalon vous aident à identifier quand vous pouvez passer à l’avance si votre charge de travail n’a pas besoin de tous les composants.

Prerequisites

  • Lisez la vue d’ensemble du plan de mise en réseau et de la conception Azure pour obtenir une orientation sur les services disponibles.
  • Savez quels services PaaS ciblent vos applications (AKS, App Service, Azure SQL, Azure Cosmos DB ou d’autres).
  • Déterminez si votre déploiement s’étend sur plusieurs régions Azure (active-active ou active-passive).
  • Identifiez votre modèle d’entrée : votre application traite-t-elle le trafic web public, le trafic d’API mobile ou le trafic interne uniquement ?

Votre chemin de lecture

Phase 1 : Fondements

1. Réseaux virtuels et sous-réseaux

Dimensionner vos sous-réseaux pour les pools de nœuds AKS, les sous-réseaux délégués App Service Environment (ASE) et les sous-réseaux Private Link. Lorsque vous utilisez AKS CNI Overlay, les adresses IP des pods proviennent d’une plage CIDR de superposition distincte et ne consomment pas l’espace du sous-réseau VNet. Seules les adresses IP de nœud nécessitent des adresses de sous-réseau. Planifiez votre plage CIDR de superposition afin de prendre en charge la mise à l'échelle des pods, et allouez des sous-réseaux dédiés pour chaque type de service.

2. Planification des adresses IP

Planifiez la répartition des adresses IP sur deux régions pour un déploiement actif-actif. Vos régions principales et de sauvegarde ont besoin d’espaces d’adressage qui ne se chevauchent pas et prennent en charge le peering de réseaux virtuels et la réplication inter-régions. Allouez des plages suffisamment grandes pour permettre l'ajout futur de spokes.

3. Groupes de sécurité réseau et groupes de sécurité d’application

Concevez une segmentation stricte afin que seul le trafic d’équilibreur de charge atteigne les sous-réseaux d’application. Bloquer l’accès direct à Internet pour les tiers applicatifs. Utilisez des groupes de sécurité d’application (ASG) pour appliquer des règles en fonction du rôle de charge de travail au lieu d’adresses IP individuelles.

Phase 2 : Topologie

4. Topologie hub-and-spoke

Déployez une topologie à double hub pour un environnement multirégional. L’abonnement IT contient les deux réseaux virtuels hub et gère des services partagés tels qu’Pare-feu Azure, passerelle VPN et les redirecteurs DNS. Les équipes applicatives sont responsables de leurs réseaux virtuels spoke et gèrent les sous-réseaux Private Link, les clusters AKS et les ressources applicatives dans l’espace d’adressage qui leur est alloué.

5. Mise en réseau multirégion

Concevoir un déploiement actif-actif entre une région principale et une région de secours. Configurez le peering de réseaux virtuels interrégion entre les hubs, configurez le routage de basculement et planifiez la défaillance d'une région unique. Les deux régions acheminent simultanément le trafic, Azure Front Door répartissant les requêtes en fonction de la latence et des sondes d’intégrité.

Note

Jalon : la topologie est terminée. Votre topologie à double hub et multirégion est en place. Si votre application est interne uniquement sans point de terminaison accessible sur Internet, vous pouvez passer à l’étape 9 (accès Internet sortant) et continuer à partir de là.

Ce que vous ignorez : Les étapes 6 à 8 couvrent l’entrée Internet, la remise des applications et les performances, ainsi que l’accès privé PaaS. Vous pouvez ignorer cette étape en toute sécurité si votre charge de travail n’a aucun point de terminaison accessible au public et aucune exigence Private Link.

Important: Même les applications internes uniquement ont souvent besoin de Private Link (étape 8) s’ils se connectent à Azure SQL, stockage Azure, Azure Key Vault ou d’autres services PaaS sur des points de terminaison privés. Si votre application utilise l’un de ces services, effectuez l’étape 8 avant de passer à l’étape 9.

Articles restants : Six articles après avoir sauté (étapes 9–14), contre neuf articles sans saut (étapes 6–14).

Phase 3 : Connectivité

6. Entrée Internet

Les modèles de trafic côté client déterminent la forme externe de votre architecture. Utilisez Azure Front Door pour les applications web qui ont besoin d’équilibrage de charge global, de mise en cache et de Web Application Firewall (WAF). Utilisez Azure Traffic Manager pour les applications mobiles ou API où le routage DNS avec des sondes d’intégrité est suffisant.

7. Livraison et performances des applications

Choisissez entre Azure Front Door et Azure Traffic Manager en fonction de votre type d’application. Les applications web bénéficient des fonctionnalités de couche 7 de Front Door : déchargement TLS, mise en cache, routage basé sur l’URL et WAF intégré. Les back-ends mobiles et API utilisent Traffic Manager pour le basculement au niveau DNS avec une surcharge réduite.

8. Accès privé PaaS

Créez des sous-réseaux Private Link dans chaque réseau virtuel spoke pour assurer la connectivité aux services PaaS. Les équipes d’applications gèrent leurs propres points de terminaison privés : AKS extrait les images conteneur sur Private Link, les applications web se connectent à Azure SQL sur des points de terminaison privés et aucun trafic PaaS ne traverse l’Internet public. Dédiez un sous-réseau par spoke aux ressources Private Link.

Note

Jalon : Connectivité terminée. Votre ingress et votre connectivité PaaS privée sont configurés.

Étapes restantes : Sortie sortante (étape 9), Pare-feu Azure (étape 10), Web Application Firewall (étape 11), protection DDoS (étape 12), sécurité DNS (étape 13) et surveillance réseau (étape 14), pour 6 articles au total.

Essentiel pour tous les déploiements : Les étapes 9 à 10 (sortie sortante et Pare-feu Azure) s’appliquent à chaque déploiement de modernisation. Votre pare-feu hub contrôle tout le trafic sortant et fournit une inspection centralisée, que votre charge de travail soit publique ou interne uniquement.

Points de terminaison publics uniquement : Les étapes 11 à 12 (protection WAF et DDoS) s’appliquent uniquement si votre application expose des points de terminaison publics via Azure Front Door, Application Gateway ou un Load Balancer public. Les charges de travail internes uniquement peuvent ignorer ces deux articles et passer à l’étape 13 (sécurité DNS).

9. Accès Internet sortant

Acheminez tout le trafic sortant de chaque spoke vers le pare-feu du hub à l’aide de routes définies par l’utilisateur (UDR). Le pare-feu du hub sert de point de traduction d’adresses réseau source (SNAT) pour tout le trafic sortant. Le service informatique gère les règles de pare-feu de manière centralisée, afin que les équipes d’applications ne puissent pas contourner les contrôles sortants.

Phase 4 : Sécurité

10. Pare-feu Azure

Configurez Pare-feu Azure dans les deux réseaux virtuels hub comme point SNAT et DNAT (Destination Network Address Translation). Tout le trafic d’entrée passe par le pare-feu avant d’atteindre la couche Application. Utilisez des stratégies de pare-feu pour contrôler le trafic est-ouest entre les spokes et le trafic nord-sud vers Internet.

11. Web Application Firewall

Déployez WAF sur Azure Front Door ou Azure Application Gateway pour vos applications web. WAF protège contre Open Web Application Security Project (OWASP) Les 10 principales menaces, l’injection SQL, les scripts intersites et d’autres attaques de couche HTTP. Utilisez des ensembles de règles managés et ajoutez des règles personnalisées pour les modèles spécifiques de votre application.

12. Protection contre les attaques DDoS

Activez Azure protection DDoS pour toutes les ressources IP publiques. La protection DDoS offre une surveillance du trafic toujours activée, une atténuation automatique des attaques et des garanties de protection des coûts. Combinez la protection DDoS avec WAF pour la défense en couches contre les attaques de couche volume et d’application.

13. Sécurité DNS et résolution de noms privés

Configurez des zones DNS publiques pour vos domaines orientés client avec des enregistrements CNAME pointant vers des points de terminaison Azure Front Door ou Traffic Manager. Appliquez Role-Based Access Control (RBAC) aux zones DNS afin que seules les équipes autorisées puissent modifier les enregistrements. Activez les extensions de sécurité DNS (DNSSEC) pour les zones qui nécessitent une validation de chiffrement.

Phase 5 : Opérations

14. Surveillance et observabilité du réseau

La préparation de la production nécessite la surveillance dès le premier jour. Activez Azure Network Watcher pour les diagnostics de connectivité, les Analyseur de performances réseau pour le suivi de la latence et les journaux de flux pour l’analyse du trafic. Les équipes d’applications surveillent leurs propres charges de travail AKS et ASE. L’équipe de plateforme surveille l’infrastructure hub et la connectivité entre régions.

Articles conditionnels

Incluez ces articles en fonction de vos besoins spécifiques :

Pathologie Article Quand inclure
Coexistence hybride Connectivité hybride Vos applications modernisées doivent coexister avec les systèmes locaux pendant la période de transition
Accès administrateur de machine virtuelle nécessaire Accès développeur et administrateur Votre patrimoine inclut des machines virtuelles qui ont besoin d’un accès RDP/SSH sécurisé en même temps que les charges de travail PaaS
Vaste domaine gouverné Gestion centralisée du réseau Vous gérez un parc de réseaux virtuels (VNet) réparti sur plusieurs abonnements et équipes, qui nécessite une application centralisée des stratégies.
Intercloud Connectivité interrégion et multicloud Votre architecture nécessite une connectivité privée interrégion explicite au-delà de ce que fournit la mise en réseau multirégion
Très petite charge de travail Topologie de réseau plat Vous disposez d’une charge de travail unique qui ne justifie pas la complexité de la topologie hub-and-spoke

Résumé

En suivant ce chemin de lecture, vous avez conçu une architecture réseau multirégion, en couches de sécurité pour les charges de travail PaaS. Votre conception comprend une topologie à double hub avec des services partagés gérés par l’informatique, une multirégion active active avec des Azure Front Door ou des Azure Traffic Manager, une connectivité Private Link pour les services PaaS, une inspection centralisée du pare-feu pour tous les flux de trafic, waf et protection DDoS pour les points de terminaison publics et DNS avec RBAC et DNSSEC. Cette architecture prend en charge les modèles d’application modernes tout en conservant la gouvernance centralisée de la sécurité.

Liste de contrôle de validation

Utilisez cette liste de contrôle pour confirmer que votre conception réseau de modernisation est terminée :

  • Topologie double hub déployée dans les régions principales et de sauvegarde.
  • Espaces d'adressage sans chevauchement alloués aux deux régions et aux futurs spokes.
  • Azure Front Door ou Azure Traffic Manager configuré pour le trafic d'entrée mondial, si votre charge de travail est exposée publiquement.
  • Sous-réseaux Private Link approvisionnés dans chaque réseau virtuel spoke hébergeant des dépendances PaaS.
  • Les itinéraires définis par l’utilisateur acheminent le trafic sortant du réseau spoke par le pare-feu du hub.
  • Pare-feu Azure déployé dans les deux réseaux virtuels hub pour l’inspection du trafic entrant, du trafic est-ouest et du trafic sortant.
  • Les stratégies WAF appliquées aux points de terminaison web publics, le cas échéant.
  • Protection DDoS activée sur les ressources IP publiques, le cas échéant.
  • Zones DNS et résolution DNS privée configurée pour les points de terminaison privés.
  • Network Watcher, les journaux des flux et la surveillance de la connectivité entre régions activés.

Étapes suivantes

  • Last updated on