Mise en réseau et connectivité pour les charges de travail stratégiques sur Azure

La mise en réseau est un domaine fondamental pour une application stratégique, compte tenu de l’approche de conception active/active distribuée mondialement recommandée.

Cette zone de conception explore différentes rubriques de topologie de réseau au niveau de l’application, en tenant compte de la connectivité requise et de la gestion du trafic redondante. Plus précisément, il met en évidence les considérations et recommandations critiques destinées à guider la conception d’une topologie de réseau globale sécurisée et évolutive pour une application stratégique.

Important

Cet article fait partie de la série de charges de travail critiques Azure Well-Architected . Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par qu’est-ce qu’une charge de travail stratégique ?

Routage du trafic global

L’utilisation de plusieurs tampons de déploiement régional actifs nécessite un service de routage global pour distribuer le trafic à chaque empreinte active.

Azure Front Door, Azure Traffic Manager et Azure Standard Load Balancer fournissent les fonctionnalités de routage nécessaires pour gérer le trafic global dans une application multirégion.

Vous pouvez également envisager des technologies de routage globale tierces. Ces options peuvent être échangées de manière presque transparente pour remplacer ou étendre l’utilisation des services de routage global azure natifs. Les choix les plus populaires incluent les technologies de routage par les fournisseurs CDN.

Cette section explore les principales différences des services de routage Azure pour définir comment chacun peut être utilisé pour optimiser différents scénarios.

Considérations en matière de conception

• Un service de routage lié à une seule région représente un point de défaillance unique et un risque important eu égard aux pannes régionales.

• Si la charge de travail d’application englobe le contrôle client, comme c’est notamment le cas avec les applications clientes mobiles ou de bureau, il est possible de proposer une redondance de service dans la logique de routage client.

  • Plusieurs technologies de routage global, telles qu’Azure Front Door et Azure Traffic Manager, peuvent être envisagées en parallèle pour la redondance. Dans ce cas, les clients sont configurés pour basculer vers une autre technologie lorsque certaines conditions de défaillance sont réunies. L’introduction de plusieurs services de routage globaux introduit des complexités significatives concernant les fonctionnalités de mise en cache et de Web Application Firewall de périphérie, ainsi que la gestion des certificats pour le déchargement SSL et la validation des applications pour les chemins d’entrée.
  • Des technologies tierces peuvent également être prises en compte, fournissant une résilience de routage globale à tous les niveaux de défaillances de plateforme Azure.

• La disparité des capacités entre Azure Front Door et Traffic Manager signifie que si les deux technologies sont positionnées l’une à côté de l’autre pour la redondance, un chemin d’entrée ou une modification de conception différent est nécessaire pour garantir un niveau de service cohérent et acceptable.

• Azure Front Door et Azure Traffic Manager sont des services distribués à l’échelle mondiale avec une redondance et une disponibilité multirégion intégrées.

  • Les scénarios d’échec hypothétiques d’une échelle suffisamment grande pour menacer la disponibilité mondiale de ces services de routage résilients présentent un risque plus large pour l’application en termes d’échecs en cascade et corrélés.
    • Les scénarios d’échec de cette échelle sont uniquement possibles en raison de services de base partagés, tels qu’Azure DNS ou Microsoft Entra ID, qui servent de dépendances de plateforme globale pour presque tous les services Azure. Si une technologie Azure redondante est appliquée, il est probable que le service secondaire rencontrera également une indisponibilité ou un service dégradé.
    • Les scénarios d’échec du service de routage global sont très susceptibles d’avoir un impact significatif sur de nombreux autres services utilisés pour les composants d’application clés par le biais de dépendances interservice. Même si une technologie tierce est utilisée, l’application sera probablement dans un état non sain en raison de l’impact plus large du problème sous-jacent, ce qui signifie que le routage vers les points de terminaison d’application sur Azure n’apportera de toute façon que peu de valeur.

• La redondance du service de routage global permet d’atténuer un très petit nombre de scénarios d’échec hypothétiques, où l’impact d’une panne globale est limité au service de routage lui-même.

  Pour offrir une redondance plus large dans les scénarios de panne globale, une approche de déploiement multicloud actif-actif peut être envisagée. Cette approche de déploiement introduit des complexités opérationnelles importantes, ce qui fait courir des risques de résilience significatifs, qui peuvent être nettement supérieurs aux risques hypothétiques d’une panne mondiale.

• Pour les scénarios où le contrôle client n’est pas possible, une dépendance doit être prise auprès d’un service de routage global unique pour fournir un point d’entrée unifié pour toutes les régions de déploiement actives.

  • Lorsqu’ils sont utilisés isolément, ils représentent un point de défaillance unique au niveau du service en raison de dépendances globales, même si une redondance et une disponibilité multirégion intégrées sont fournies.
  • Le contrat SLA fourni par le service de routage global sélectionné représente le contrat SLA composite maximal pouvant être atteint, quel que soit le nombre de régions de déploiement prises en compte.

• Lorsque le contrôle client n’est pas possible, des atténuations opérationnelles peuvent être envisagées pour définir un processus de migration vers un service de routage global secondaire si une panne globale désactive le service principal. La migration d’un service de routage global vers un autre est généralement un processus long de plusieurs heures, en particulier lorsque la propagation DNS est prise en compte.

• Certains services de routage globaux tiers fournissent un contrat SLA à 100 %. Toutefois, le contrat SLA historique et réalisable fourni par ces services est généralement inférieur à 100 %.

  • Bien que ces services fournissent des réparations financières en cas d’indisponibilité, ils sont peu significatifs lorsque l’impact de l’indisponibilité est important, comme dans les scénarios critiques pour la sécurité où la vie humaine est en fin de compte en jeu. La redondance technologique ou les atténuations opérationnelles suffisantes doivent donc toujours être prises en compte même lorsque le contrat sla légal annoncé est de 100 %.

Azure Front Door

• Azure Front Door assure un équilibrage de charge HTTP/S global et offre une connectivité optimisée grâce au protocole Anycast avec TCP fractionné pour tirer parti du réseau principal global Microsoft.

  • Un certain nombre de connexions sont conservées pour chacun des points de terminaison back-end.
  • Les demandes clientes entrantes sont d’abord terminées au nœud de périphérie le plus proche du client d’origine.
  • Après toute inspection du trafic requise, les demandes sont soit transférées sur le réseau principal Microsoft vers le serveur principal approprié à l’aide de connexions existantes, soit traitées à partir du cache interne d’un nœud de périphérie.
  • Cette approche est très efficace pour répartir des volumes de trafic élevés sur les connexions back-end.

• Fournit un cache intégré qui sert du contenu statique à partir de nœuds de périphérie. Dans de nombreux cas d’usage, cela peut également éliminer la nécessité d’un réseau de distribution de contenu (CDN) dédié.

• Azure Web Application Firewall (WAF) peut être utilisé sur Azure Front Door. Étant donné qu’il est déployé sur des emplacements de périphérie réseau Azure dans le monde entier, chaque requête entrante fournie par Front Door dans est inspectée à la périphérie du réseau.

• Azure Front Door protège les points de terminaison d’application contre les attaques DDoS à l’aide d’Azure DDoS Protection De base. Azure DDoS Standard fournit des fonctionnalités de protection et de détection supplémentaires et plus avancées, et peut être ajouté en tant que couche supplémentaire à Azure Front Door.

• Azure Front Door offre un service de certificats entièrement managé. Active la sécurité des connexions TLS pour les points de terminaison sans avoir à gérer le cycle de vie des certificats.

• Azure Front Door Premium prend en charge les points de terminaison privés, ce qui permet au trafic de circuler à partir d’Internet directement vers les réseaux virtuels Azure. Cela éliminerait la nécessité d’utiliser des adresses IP publiques sur le réseau virtuel pour rendre les back-ends accessibles via Azure Front Door Premium.

• Azure Front Door s’appuie sur des sondes d’intégrité et des points de terminaison d’intégrité principaux (URL) appelés sur une base d’intervalles pour retourner un code HTTP status indiquant si le back-end fonctionne normalement, avec une réponse HTTP 200 (OK) reflétant une status saine. Dès qu’un back-end reflète un status non sain, du point de vue d’un certain nœud de périphérie, ce nœud de périphérie cesse d’y envoyer des requêtes. Les back-ends non sains sont donc supprimés de manière transparente de la circulation du trafic sans délai.

• Prend en charge les protocoles HTTP/S uniquement.

• Le WAF Azure Front Door et Application Gateway WAF fournissent un ensemble de fonctionnalités légèrement différent, bien que les deux prennent en charge des règles intégrées et personnalisées et peuvent être définis pour fonctionner en mode détection ou en mode prévention.

• L’espace IP du serveur principal Front Door peut changer, mais Microsoft s’assure de l’intégration avec les plages d’adresses IP et les étiquettes de service Azure. Il est possible de s’abonner à Des plages d’adresses IP Azure et des étiquettes de service pour recevoir des notifications sur les modifications ou mises à jour.

• Azure Front Door prend en charge différentes configurations de distribution de charge :

  • Basé sur la latence : paramètre par défaut qui achemine le trafic vers le back-end « le plus proche » à partir du client ; en fonction de la latence des requêtes.
  • Basé sur la priorité : utile pour les configurations actives/passives, où le trafic doit toujours être envoyé à un serveur principal, sauf s’il n’est pas disponible.
  • Pondéré : applicable aux déploiements canary dans lesquels un certain pourcentage de trafic est envoyé à un serveur principal spécifique. Si plusieurs back-ends ont les mêmes poids attribués, un routage basé sur la latence est utilisé.

• Par défaut, Azure Front Door utilise un routage basé sur la latence qui peut entraîner des situations où certains back-ends obtiennent beaucoup plus de trafic entrant que d’autres, selon l’origine des clients.

• Si une série de demandes clientes doit être gérée par le même back-end, l’affinité de session peut être configurée sur le serveur frontal. Il utilise un cookie côté client pour envoyer les requêtes suivantes au même back-end que la première demande, à condition que le back-end soit toujours disponible.

Azure Traffic Manager

• Azure Traffic Manager est un service de redirection DNS.

  • La charge utile de la requête réelle n’est pas traitée, mais Traffic Manager retourne le nom DNS de l’un des back-ends du pool, en fonction des règles configurées pour la méthode de routage du trafic sélectionnée.
  • Le nom DNS principal est ensuite résolu en son adresse IP finale qui est ensuite directement appelée par le client.

• La réponse DNS est mise en cache et réutilisée par le client pendant une période de durée de vie (TTL) spécifiée, et les demandes effectuées au cours de cette période sont directement envoyées au point de terminaison principal sans intervention de Traffic Manager. Élimine l’étape de connectivité supplémentaire qui offre des avantages en matière de coûts par rapport à Front Door.

• Étant donné que la requête est effectuée directement du client vers le service back-end, tout protocole pris en charge par le serveur principal peut être utilisé.

• À l’instar d’Azure Front Door, Azure Traffic Manager s’appuie également sur des sondes d’intégrité pour comprendre si un serveur principal est sain et fonctionne normalement. Si une autre valeur est retournée ou si rien n’est retourné, le service de routage reconnaît les problèmes en cours et arrête le routage des demandes vers ce back-end spécifique.

  • Toutefois, contrairement à Azure Front Door, cette suppression des back-ends non sains n’est pas instantanée, car les clients continueront à créer des connexions au serveur principal défectueux jusqu’à ce que la durée de vie du DNS expire et qu’un nouveau point de terminaison principal soit demandé au service Traffic Manager.
  • En outre, même lorsque la durée de vie expire, il n’y a aucune garantie que les serveurs DNS publics respecteront cette valeur, de sorte que la propagation DNS peut prendre beaucoup plus de temps. Cela signifie que le trafic peut continuer à être envoyé au point de terminaison non sain pendant une période prolongée.

Azure Standard Load Balancer

Important

Les Standard Load Balancer inter-régions sont disponibles en préversion avec des limitations techniques. Cette option n’est pas recommandée pour les charges de travail critiques.

Recommandations de conception

• Utilisez Azure Front Door comme service de routage du trafic global principal pour les scénarios HTTP/S. Azure Front Door est fortement recommandé pour les charges de travail HTTP/S, car il fournit un routage du trafic optimisé, un basculement transparent, des points de terminaison principaux privés (avec la référence SKU Premium), la mise en cache de périphérie et l’intégration à Web Application Firewall (WAF).

• Pour les scénarios d’application où un contrôle client est possible, appliquez une logique de routage côté client pour prendre en compte les scénarios de basculement où la technologie de routage global principale est infructueuse. Si un seul contrat SLA de service ne suffit pas, il est recommandé de positionner au moins deux technologies de routage global en parallèle pour bénéficier d’un supplément de redondance. Une logique de client est nécessaire pour assurer un routage vers la technologie redondante en cas de défaillance d’un service global.

  • Deux URL distinctes doivent être utilisées, l’une appliquée à chacun des différents services de routage globaux afin de simplifier l’expérience globale de gestion des certificats et la logique de routage pour un basculement.
  • Hiérarchiser l’utilisation de technologies de routage tierces en tant que service de basculement secondaire, car cela atténuera le plus grand nombre de scénarios de défaillance globale et les fonctionnalités offertes par les principaux fournisseurs CDN du secteur permettront une approche de conception cohérente.
  • Il convient également de prendre en compte le routage direct vers un tampon régional unique plutôt qu’un service de routage distinct. Bien que cela entraîne une dégradation du niveau de service, cela représente une approche de conception beaucoup plus simple.

Cette image montre une configuration d’équilibreur de charge globale redondante avec basculement du client à l’aide d’Azure Front Door comme équilibreur de charge global principal.

pour la

Important

Pour vraiment atténuer le risque de défaillances globales au sein de la plateforme Azure, une approche de déploiement multicloud actif-actif doit être envisagée, avec des tampons de déploiement actifs hébergés sur plusieurs fournisseurs de cloud et des technologies de routage tierces redondantes utilisées pour le routage global.

Azure peut être intégré efficacement à d’autres plateformes cloud. Toutefois, il est fortement recommandé de ne pas appliquer une approche multicloud, car elle introduit une complexité opérationnelle significative, avec différentes définitions d’empreinte de déploiement et représentations de l’intégrité opérationnelle sur les différentes plateformes cloud. Cette complexité introduit à son tour de nombreux risques de résilience dans le fonctionnement normal de l’application, qui l’emportent de loin sur les risques hypothétiques d’une panne de plateforme globale.

• Bien que cela ne soit pas recommandé, pour les charges de travail HTTP utilisant Azure Traffic Manager pour la redondance de routage globale vers Azure Front Door, envisagez de décharger Web Application Firewall (WAF) vers Application Gateway pour que le trafic acceptable transite par Azure Front Door.
  • Cela introduit un point de défaillance supplémentaire au chemin d’entrée standard, un composant de chemin critique supplémentaire à gérer et à mettre à l’échelle, et entraîne également des coûts supplémentaires pour garantir la haute disponibilité mondiale. Toutefois, il simplifiera considérablement le scénario d’échec en fournissant une cohérence entre les chemins d’entrée acceptables et non acceptables via Azure Front Door et Azure Traffic Manager, à la fois en termes d’exécution du WAF, mais également de points de terminaison d’application privée.
  • La perte de la mise en cache de périphérie dans un scénario d’échec aura un impact sur les performances globales, ce qui doit être aligné sur un niveau de service acceptable ou une approche de conception d’atténuation. Pour garantir un niveau de service cohérent, envisagez de décharger la mise en cache de périphérie vers un fournisseur CDN tiers pour les deux chemins.

Il est recommandé d’envisager un service de routage global tiers à la place des deux services de routage global Azure. Cela permet de bénéficier d’un niveau maximal d’atténuation des erreurs et d’une approche de conception plus simple, car la plupart des fournisseurs de CDN de premier plan offrent des capacités de périphérie qui se concilient bien avec celles offertes par Azure Front Door.

Azure Front Door

• Utilisez le service de certificat managé Azure Front Door pour activer les connexions TLS et supprimer la nécessité de gérer les cycles de vie des certificats.

• Utilisez azure Front Door Web Application Firewall (WAF) pour fournir une protection à la périphérie contre les failles web courantes et les vulnérabilités, telles que l’injection DE CODE SQL.

• Utilisez le cache intégré Azure Front Door pour servir du contenu statique à partir de nœuds de périphérie.

  • Dans la plupart des cas, cela élimine également la nécessité d’un réseau de distribution de contenu (CDN) dédié.

• Configurez les points d’entrée de la plateforme d’application pour valider les demandes entrantes via le filtrage basé sur l’en-tête à l’aide de X-Azure-FDID pour vous assurer que tout le trafic transite par l’instance Front Door configurée. Envisagez également de configurer le contrôle d’accès IP à l’aide de balises de service Front Door pour vérifier que le trafic provient de l’espace d’adressage IP principal Azure Front Door et des services d’infrastructure Azure. Cela garantit que le trafic transite par Azure Front Door au niveau du service, mais le filtrage basé sur l’en-tête est toujours nécessaire pour garantir l’utilisation d’une instance Front Door configurée.

• Définissez un point de terminaison d’intégrité TCP personnalisé pour valider les dépendances critiques en aval dans un tampon de déploiement régional, y compris les réplicas de plateforme de données, comme Azure Cosmos DB dans l’exemple fourni par l’implémentation de référence de base. Si une ou plusieurs dépendances deviennent non saines, la sonde d’intégrité doit le refléter dans la réponse retournée afin que l’empreinte régionale entière puisse être retirée de la circulation.

• Vérifiez que les réponses des sondes d’intégrité sont journalisées et ingèrent toutes les données opérationnelles exposées par Azure Front Door dans l’espace de travail Log Analytics global pour faciliter un récepteur de données unifié et une vue opérationnelle unique sur l’ensemble de l’application.

• À moins que la charge de travail ne soit extrêmement sensible à la latence, répartissez le trafic uniformément sur toutes les empreintes régionales considérées pour utiliser plus efficacement les ressources déployées.

  • Pour ce faire, définissez le paramètre « Sensibilité de latence (latence supplémentaire) » sur une valeur suffisamment élevée pour tenir compte des différences de latence entre les différentes régions des back-ends. Assurez-vous d’une tolérance acceptable pour la charge de travail de l’application concernant la latence globale des requêtes client.

• N’activez pas l’affinité de session, sauf si l’application l’exige, car elle peut avoir un impact négatif sur l’équilibre de la distribution du trafic. Avec une application entièrement sans état, si l’approche de conception d’application critique recommandée est suivie, toute demande peut être gérée par l’un des déploiements régionaux.

Azure Traffic Manager

• Utilisez Traffic Manager pour les scénarios non HTTP/S en remplacement d’Azure Front Door. Les différences de capacités suscitent des décisions de conception différentes pour les capacités de cache et WAF ainsi que la gestion des certificats TLS.

• Les fonctionnalités WAF doivent être prises en compte dans chaque région pour le chemin d’entrée de Traffic Manager, à l’aide de Azure Application Gateway.

• Configurez une valeur de durée de vie convenablement faible pour optimiser le temps nécessaire à la suppression d’un point de terminaison principal non sain de la circulation dans le cas où le back-end devient défectueux.

• Comme avec Azure Front Door, un point de terminaison d’intégrité TCP personnalisé doit être défini pour valider les dépendances en aval critiques dans un tampon de déploiement régional, qui doit être reflété dans la réponse fournie par les points de terminaison d’intégrité.

  Toutefois, pour Traffic Manager, une considération supplémentaire doit être accordée au basculement régional de niveau de service. par exemple, « legging de chien », pour atténuer le délai potentiel associé à la suppression d’un back-end défectueux en raison d’échecs de dépendance, en particulier s’il n’est pas possible de définir une durée de vie faible pour les enregistrements DNS.

• Les fournisseurs CDN tiers doivent être pris en compte afin d’obtenir la mise en cache de périphérie lors de l’utilisation d’Azure Traffic Manager comme service de routage global principal. Lorsque les fonctionnalités WAF de périphérie sont également offertes par le service tiers, il convient de prendre en compte de simplifier le chemin d’entrée et de supprimer éventuellement la nécessité d’Application Gateway.

Services de livraison d’applications

Le chemin d’entrée réseau d’une application stratégique doit également prendre en compte les services de livraison d’applications pour garantir un trafic d’entrée sécurisé, fiable et évolutif.

Cette section s’appuie sur les recommandations de routage globales en explorant les principales fonctionnalités de livraison d’applications, en prenant en compte les services pertinents tels que azure Standard Load Balancer, Azure Application Gateway et Azure Gestion des API.

Considérations en matière de conception

• Le chiffrement TLS est essentiel pour garantir l’intégrité du trafic utilisateur entrant vers une application stratégique, avec le déchargement TLS appliqué uniquement au point d’entrée d’une empreinte pour déchiffrer le trafic entrant. Déchargement TLS Nécessite la clé privée du certificat TLS pour déchiffrer le trafic.

• Un Web Application Firewall fournit une protection contre les vulnérabilités et exploits web courants, tels que l’injection SQL ou le script intersites, et est essentiel pour atteindre les aspirations de fiabilité maximale d’une application stratégique.

• Azure WAF fournit une protection prête à l’emploi contre les 10 principales vulnérabilités OWASP en utilisant des ensembles de règles managées.

  • Des règles personnalisées peuvent également être ajoutées pour étendre l’ensemble de règles managées.
  • Azure WAF peut être activé dans Azure Front Door, Azure Application Gateway ou Azure CDN (actuellement en préversion publique).
    • Les fonctionnalités offertes sur chacun des services diffèrent légèrement. Par exemple, le WAF Azure Front Door fournit la limitation du débit, le filtrage géographique et la protection des bots, qui ne sont pas encore proposés dans le WAF Application Gateway. Toutefois, elles prennent toutes en charge les règles intégrées et personnalisées et peuvent être définies pour fonctionner en mode détection ou en mode prévention.
    • La feuille de route d’Azure WAF garantit qu’un ensemble de fonctionnalités WAF cohérent est fourni pour toutes les intégrations de service.

• Les technologies WAF tierces, telles que les appliances virtuelles virtuelles réseau et les contrôleurs d’entrée avancés dans Kubernetes, peuvent également être considérées comme fournissant une protection contre les vulnérabilités requise.

• Une configuration WAF optimale nécessite généralement un réglage précis, quelle que soit la technologie utilisée.

  Azure Front Door

• Azure Front Door accepte uniquement le trafic HTTP et HTTPS et traite uniquement les demandes avec un en-tête connu Host . Ce blocage de protocole permet d’atténuer les attaques volumétriques réparties sur les protocoles et les ports, ainsi que les attaques d’amplification DNS et d’empoisonnement TCP.

• Azure Front Door étant une ressource Azure globale, la configuration est déployée à l’échelle mondiale sur tous les emplacements de périphérie.

  • La configuration des ressources peut être distribuée à grande échelle pour gérer des centaines de milliers de demandes par seconde.
  • Mises à jour à la configuration, y compris les routes et les pools principaux, sont transparentes et ne provoquent aucun temps d’arrêt pendant le déploiement.

• Azure Front Door fournit à la fois un service de certificat complètement managé et une méthode bring-your-own-certificate pour les certificats SSL orientés client. Le service de certificats entièrement managé offre une approche opérationnelle simplifiée et permet de réduire la complexité de la conception globale en effectuant la gestion des certificats dans une seule zone de la solution.

• Azure Front Door effectue une rotation automatique des certificats « managés » au moins 60 jours avant l’expiration du certificat pour vous protéger contre les risques liés aux certificats arrivés à expiration. Si des certificats autogérés sont utilisés, les certificats mis à jour doivent être déployés au plus tard 24 heures avant l’expiration du certificat existant. Sinon, les clients peuvent recevoir des erreurs de certificat expiré.

• Les mises à jour de certificat entraînent un temps d’arrêt uniquement si Azure Front Door passe de « Géré » à « Utiliser votre propre certificat ».

• Azure Front Door est protégé par Azure DDoS Protection Basic, qui est intégré à Front Door par défaut. Cela fournit une surveillance du trafic toujours active, une atténuation en temps réel et protège également contre les inondations de requêtes DNS de couche 7 courantes ou les attaques volumétriques de couche 3/4.

  • Ces protections permettent de maintenir la disponibilité d’Azure Front Door, même en cas d’attaque DDoS. Les attaques par déni de service distribué (DDoS) peuvent rendre une ressource ciblée indisponible en la submergeant de trafic illégitime.

• Azure Front Door fournit également des fonctionnalités WAF au niveau du trafic mondial, tandis que Application Gateway WAF doit être fourni dans chaque tampon de déploiement régional. Parmi les fonctionnalités figurent des ensembles de règles de pare-feu pour protéger contre les attaques courantes, le géofiltrage, le blocage d’adresses, la limitation de débit et la correspondance de signature.

  Équilibrage de charge Azure

• La référence SKU Azure Basic Load Balancer n’est pas soutenue par un contrat SLA et présente plusieurs contraintes de capacité par rapport à la référence SKU Standard.

Recommandations de conception

• Effectuez le déchargement TLS dans le moins d’endroits possible afin de maintenir la sécurité tout en simplifiant le cycle de vie de la gestion des certificats.

• Utilisez des connexions chiffrées (par exemple, HTTPS) à partir du point où le déchargement TLS se produit vers les back-ends d’application réels. Les points de terminaison d’application ne étant pas visibles par les utilisateurs finaux, les domaines gérés par Azure, tels que azurewebsites.net ou cloudapp.net, peuvent être utilisés avec des certificats managés.

• Pour le trafic HTTP(S), vérifiez que les fonctionnalités WAF sont appliquées dans le chemin d’entrée pour tous les points de terminaison exposés publiquement.

• Activez les fonctionnalités WAF à un emplacement de service unique, à l’échelle mondiale avec Azure Front Door ou régionalement avec Azure Application Gateway, car cela simplifie le réglage précis de la configuration et optimise les performances et les coûts.

  Configurez WAF en mode Prévention pour bloquer directement les attaques. Utilisez uniquement WAF en mode Détection (les requêtes suspectes sont alors simplement journalisées et non bloquées) quand les performances sont trop pénalisées avec le mode Prévention. Le risque supplémentaire implicite doit être entièrement compris et cadrer avec les exigences spécifiques du scénario de charge de travail.

• Donnez la priorité à l’utilisation du WAF d’Azure Front Door, car il offre l’ensemble de fonctionnalités natives Azure le plus riche et applique des protections au niveau de la périphérie mondiale, ce qui simplifie la conception globale et améliore l’efficacité.

• Utilisez Azure Gestion des API uniquement lors de l’exposition d’un grand nombre d’API à des clients externes ou à différentes équipes d’application.

• Utilisez la référence SKU Azure Standard Load Balancer pour tout scénario de distribution de trafic interne au sein des charges de travail de microservices.

  • Fournit un contrat SLA de 99,99 % lorsqu’il est déployé sur Zones de disponibilité.
  • Elle offre des fonctionnalités critiques comme les diagnostics ou les règles de trafic sortant.

• Utilisez Azure DDoS Network Protection pour protéger les points de terminaison publics hébergés dans chaque réseau virtuel d’application.

Mise en cache et remise de contenu statique

Un traitement spécial du contenu statique comme les images, JavaScript, CSS et d’autres fichiers peut avoir un impact significatif sur l’expérience utilisateur globale ainsi que sur le coût global de la solution. La mise en cache du contenu statique à la périphérie peut accélérer les temps de chargement du client, ce qui permet une meilleure expérience utilisateur et peut également réduire le coût du trafic, des opérations de lecture et de la puissance de calcul sur les services principaux impliqués.

Considérations en matière de conception

• Tout le contenu mis à disposition par une solution sur Internet n’est pas généré dynamiquement. Les applications servent à la fois des ressources statiques (images, JavaScript, CSS, fichiers de localisation, etc.) et du contenu dynamique.
• Les charges de travail avec du contenu statique fréquemment consulté bénéficient grandement de la mise en cache, car elle réduit la charge sur les services principaux et réduit la latence d’accès au contenu pour les utilisateurs finaux.
• La mise en cache peut être implémentée en mode natif dans Azure à l’aide d’Azure Front Door ou d’Azure Content Delivery Network (CDN).
  • Azure Front Door fournit des fonctionnalités de mise en cache de périphérie natives Azure et des fonctionnalités de routage pour diviser le contenu statique et dynamique.
    • En créant les règles de routage appropriées dans Azure Front Door, /static/* le trafic peut être redirigé de manière transparente vers du contenu statique.
  • Des scénarios de mise en cache plus complexes peuvent être implémentés à l’aide du service Azure CDN pour établir un réseau de distribution de contenu à part entière pour des volumes de contenu statiques importants.
    • Le service Azure CDN sera probablement plus économique, mais ne fournit pas les mêmes fonctionnalités avancées de routage et de Web Application Firewall (WAF) qui sont recommandées pour d’autres domaines d’une conception d’application. Toutefois, il offre une plus grande flexibilité pour s’intégrer à des services similaires provenant de solutions tierces, telles qu’Akamai et Verizon.
  • Lorsque vous comparez les services Azure Front Door et Azure CDN, les facteurs de décision suivants doivent être explorés :
    • Les règles de mise en cache requises peuvent-elles être exécutées à l’aide du moteur de règles.
    • Taille du contenu stocké et coût associé.
    • Prix par mois pour l’exécution du moteur de règles (facturé par demande sur Azure Front Door).
    • Exigences en matière de trafic sortant (le prix diffère selon la destination).

Recommandations de conception

• Le contenu statique généré, comme les copies dimensionnées de fichiers image qui ne changent jamais ou rarement, peut également bénéficier de la mise en cache. La mise en cache peut être configurée en fonction des paramètres d’URL et avec une durée de mise en cache variable.
• Séparez la remise de contenu statique et dynamique aux utilisateurs et fournissez du contenu pertinent à partir d’un cache pour réduire la charge au niveau des services back-ends et ainsi optimiser le niveau de performance pour les utilisateurs finaux.
• Étant donné la forte recommandation (réseau et zone de conception de connectivité) d’utiliser Azure Front Door à des fins de routage global et de Web Application Firewall (WAF), il est recommandé de hiérarchiser l’utilisation des fonctionnalités de mise en cache d’Azure Front Door, sauf s’il existe des lacunes.

Intégration du réseau virtuel

Une application stratégique englobe généralement les exigences d’intégration à d’autres applications ou systèmes dépendants, qui peuvent être hébergés sur Azure, un autre cloud public ou des centres de données locaux. Cette intégration d’application peut être effectuée à l’aide de points de terminaison publics et d’Internet, ou de réseaux privés via l’intégration au niveau du réseau. En fin de compte, la méthode d’intégration de l’application aura un impact significatif sur la sécurité, les performances et la fiabilité de la solution, et aura un impact important sur les décisions de conception dans d’autres domaines de conception.

Une application stratégique peut être déployée dans l’une des trois configurations réseau globales, ce qui détermine la façon dont l’intégration d’application peut se produire au niveau du réseau.

1. Application publiquesans connectivité réseau d’entreprise.
2. Application publiqueavec connectivité réseau d’entreprise.
3. Application privéeavec connectivité réseau d’entreprise.

Attention

Lors du déploiement dans une zone d’atterrissage Azure, configuration 1. doit être déployé dans une zone d’atterrissage en ligne, tandis que 2) et 3) doivent être déployés dans une zone d’atterrissage connectée pour faciliter l’intégration au niveau du réseau.

Cette section explore ces scénarios d’intégration réseau, la superposition dans l’utilisation appropriée des réseaux virtuels Azure et les services réseau Azure environnants pour garantir que les exigences d’intégration sont satisfaites de manière optimale.

Remarques sur la conception

Aucun réseau virtuel

• L’approche de conception la plus simple consiste à ne pas déployer l’application au sein d’un réseau virtuel.

  • La connectivité entre tous les services Azure considérés sera entièrement assurée par le biais de points de terminaison publics et du réseau principal Microsoft Azure. La connectivité entre les points de terminaison publics hébergés sur Azure traversera uniquement le réseau principal Microsoft et ne passera pas par l’Internet public.
  • La connectivité à tous les systèmes externes en dehors d’Azure sera assurée par l’Internet public.

• Cette approche de conception adopte « l’identité comme périmètre de sécurité » pour fournir un contrôle d’accès entre les différents composants de service et la solution dépendante. Il peut s’agir d’une solution acceptable pour les scénarios qui sont moins sensibles à la sécurité. Tous les services et dépendances d’application sont accessibles via un point de terminaison public les rend vulnérables aux vecteurs d’attaque supplémentaires orientés vers l’obtention d’un accès non autorisé.

• Cette approche de conception n’est pas non plus applicable à tous les services Azure, car de nombreux services, tels qu’AKS, ont une exigence matérielle pour un réseau virtuel sous-jacent.

Réseaux virtuels isolés

• Pour atténuer les risques associés aux points de terminaison publics inutiles, l’application peut être déployée au sein d’un réseau autonome qui n’est pas connecté à d’autres réseaux.

• Les requêtes clientes entrantes nécessitent toujours qu’un point de terminaison public soit exposé à Internet. Toutefois, toutes les communications ultérieures peuvent se faire au sein du réseau virtuel à l’aide de points de terminaison privés. Lorsque vous utilisez Azure Front Door Premium, il est possible d’acheminer directement des nœuds de périphérie vers des points de terminaison d’application privés.

• Bien que la connectivité privée entre les composants d’application se produise sur des réseaux virtuels, toutes les connectivités avec des dépendances externes reposent toujours sur des points de terminaison publics.

  • La connectivité aux services de plateforme Azure peut être établie avec des points de terminaison privés si pris en charge. Si d’autres dépendances externes existent sur Azure, telles qu’une autre application en aval, la connectivité est fournie via des points de terminaison publics et le réseau principal Microsoft Azure.
  • La connectivité à tous les systèmes externes en dehors d’Azure serait assurée par l’Internet public.

• Pour les scénarios où il n’existe aucune exigence d’intégration réseau pour les dépendances externes, le déploiement de la solution dans un environnement réseau isolé offre une flexibilité de conception maximale. Aucune contrainte d’adressage et de routage associée à une intégration réseau plus large.

• Azure Bastion est un service PaaS entièrement géré par la plateforme qui peut être déployé sur un réseau virtuel et fournit une connectivité RDP/SSH sécurisée aux machines virtuelles Azure. Lorsque vous vous connectez via Azure Bastion, les machines virtuelles n’ont pas besoin d’une adresse IP publique.

• L’utilisation de réseaux virtuels d’application introduit des complexités de déploiement importantes dans les pipelines CI/CD, car l’accès au plan de données et au plan de contrôle aux ressources hébergées sur des réseaux privés est nécessaire pour faciliter les déploiements d’applications.

  • Le chemin d’accès au réseau privé sécurisé doit être établi pour permettre aux outils CI/CD d’effectuer les actions requises.
  • Les agents de build privés peuvent être déployés dans des réseaux virtuels d’application pour accéder par proxy aux ressources sécurisées par le réseau virtuel.

Les réseaux virtuels connectés

• Pour les scénarios avec des exigences d’intégration de réseau externe, les réseaux virtuels d’application peuvent être connectés à d’autres réseaux virtuels au sein d’Azure, à un autre fournisseur de cloud ou à des réseaux locaux à l’aide d’une variété d’options de connectivité. Par exemple, certains scénarios d’application peuvent envisager l’intégration au niveau de l’application avec d’autres applications métier hébergées en privé au sein d’un réseau d’entreprise local.

• La conception du réseau d’applications doit s’aligner sur l’architecture réseau plus large, en particulier en ce qui concerne des sujets tels que l’adressage et le routage.

• Le chevauchement des espaces d’adressage IP entre les régions Azure ou les réseaux locaux crée une contention majeure lorsque l’intégration réseau est envisagée.

  • Une ressource de réseau virtuel peut être mise à jour pour tenir compte de l’espace d’adressage supplémentaire. Toutefois, lorsqu’un espace d’adressage de réseau virtuel d’un réseau appairé modifie une synchronisation sur le lien de peering est requise, ce qui désactivera temporairement le peering.
  • Azure réserve cinq adresses IP au sein de chaque sous-réseau, qui doivent être prises en compte lors de la détermination des tailles appropriées pour les réseaux virtuels d’application et les sous-réseaux englobants.
  • Certains services Azure nécessitent des sous-réseaux dédiés, tels qu’Azure Bastion, Pare-feu Azure ou Azure Réseau virtuel Gateway. La taille de ces sous-réseaux de service est très importante, car ils doivent être suffisamment volumineux pour prendre en charge toutes les instances actuelles du service en tenant compte des exigences de mise à l’échelle futures, mais pas si volumineux qu’ils gaspillent inutilement des adresses.

• Lorsque l’intégration réseau locale ou intercloud est requise, Azure propose deux solutions différentes pour établir une connexion sécurisée.

  • Un circuit ExpressRoute peut être dimensionné pour fournir des bandes passantes allant jusqu’à 100 Gbits/s.
  • Un réseau privé virtuel (VPN) peut être dimensionné pour fournir une bande passante agrégée allant jusqu’à 10 Gbits/s dans les réseaux hub-and-spoke et jusqu’à 20 Gbits/s dans Azure Virtual WAN.

Notes

Lors du déploiement dans une zone d’atterrissage Azure, n’oubliez pas que toute connectivité requise aux réseaux locaux doit être fournie par l’implémentation de la zone d’atterrissage. La conception peut utiliser ExpressRoute et d’autres réseaux virtuels dans Azure à l’aide de Virtual WAN ou d’une conception de réseau hub-and-spoke.

• L’inclusion de chemins et de ressources réseau supplémentaires introduit des considérations supplémentaires en matière de fiabilité et d’exploitation pour l’application afin de garantir le maintien de l’intégrité.

Recommandations de conception

• Il est recommandé de déployer des solutions stratégiques au sein de réseaux virtuels Azure dans la mesure du possible pour supprimer les points de terminaison publics inutiles, ce qui limite la surface d’attaque des applications et optimise ainsi la sécurité et la fiabilité.

  • Utilisez des points de terminaison privés pour la connectivité aux services de plateforme Azure. Les points de terminaison de service peuvent être pris en compte pour les services qui ne prennent pas en charge les Private Link, à condition que les risques d’exfiltration des données soient acceptables ou atténués par d’autres contrôles.

• Pour les scénarios d’application qui n’ont pas besoin d’une connectivité réseau d’entreprise, considérez tous les réseaux virtuels comme des ressources éphémères qui sont remplacées à l’occasion d’un nouveau déploiement régional.

• Lors de la connexion à d’autres réseaux Azure ou locaux, les réseaux virtuels d’application ne doivent pas être traités comme éphémères, car ils créent des complications importantes en ce qui concerne les ressources de peering de réseaux virtuels et de passerelle de réseau virtuel. Toutes les ressources d’application pertinentes au sein du réseau virtuel doivent rester éphémères, avec des sous-réseaux parallèles utilisés pour faciliter les déploiements bleu-vert des empreintes de déploiement régional mises à jour.

• Dans les scénarios où une connectivité réseau d’entreprise est nécessaire pour faciliter l’intégration d’applications sur des réseaux privés, vérifiez que l’espace d’adressage IPv4 utilisé pour les réseaux virtuels d’application régionaux ne se chevauche pas avec d’autres réseaux connectés et est correctement dimensionné pour faciliter la mise à l’échelle nécessaire sans avoir à mettre à jour la ressource de réseau virtuel et subir un temps d’arrêt.

  • Il est vivement recommandé d’utiliser uniquement les adresses IP de l’allocation d’adresses pour l’Internet privé (RFC 1918).
    • Pour les environnements avec une disponibilité limitée des adresses IP privées (RFC 1918), envisagez d’utiliser IPv6.
    • Si l’utilisation d’une adresse IP publique est requise, assurez-vous que seuls les blocs d’adresses détenus sont utilisés.
  • Alignez-vous sur organization plans d’adressage IP dans Azure pour vous assurer que l’espace d’adressage IP réseau de l’application ne chevauche pas d’autres réseaux dans des emplacements locaux ou des régions Azure.
  • Ne créez pas de réseaux virtuels d’application inutilement volumineux pour vous assurer que l’espace d’adressage IP n’est pas gaspiller.

• Hiérarchiser l’utilisation d’Azure CNI pour l’intégration réseau AKS, car elle prend en charge un ensemble de fonctionnalités plus riche.

  • Envisagez Kubenet pour les scénarios avec un nombre limité d’adresses IP disponibles pour s’adapter à l’application dans un espace d’adressage limité.

  • Hiérarchisez l’utilisation du plug-in réseau Azure CNI pour l’intégration réseau AKS et envisagez Kubenet pour les scénarios avec une plage limitée d’adresses IP disponibles. Pour plus d’informations, consultez Stratégies réseau de micro-segmentation et kubernetes .

• Pour les scénarios nécessitant une intégration réseau locale, hiérarchiser l’utilisation d’Express Route pour garantir une connectivité sécurisée et évolutive.

  • Vérifiez que le niveau de fiabilité appliqué à Express Route ou AU VPN répond entièrement aux exigences de l’application.
  • Plusieurs chemins réseau doivent être pris en compte pour fournir une redondance supplémentaire si nécessaire, comme des circuits ExpressRoute connectés entre les deux ou l’utilisation d’un VPN comme mécanisme de connectivité de basculement.

• Assurez-vous que tous les composants sur les chemins réseau critiques sont conformes aux exigences de fiabilité et de disponibilité des flux d’utilisateurs associés, que la gestion de ces chemins d’accès et du composant associé soit assurée par l’équipe d’application des équipes informatiques centrales.

  Notes

  Lors du déploiement dans une zone d’atterrissage Azure et de l’intégration à une topologie de réseau organisationnelle plus large, tenez compte des conseils réseau pour vous assurer que le réseau de base est aligné sur les meilleures pratiques Microsoft.

• Utilisez Azure Bastion ou des connexions privées proxiées pour accéder au plan de données des ressources Azure ou effectuer des opérations de gestion.

Sortie Internet

La sortie Internet est une exigence réseau fondamentale pour une application stratégique afin de faciliter la communication externe dans le contexte des éléments suivants :

1. Interaction directe de l’utilisateur de l’application.
2. Intégration d’applications avec des dépendances externes en dehors d’Azure.
3. Accès aux dépendances externes requises par les services Azure utilisés par l’application.

Cette section explore la façon dont la sortie d’Internet peut être obtenue tout en garantissant le maintien de la sécurité, de la fiabilité et des performances durables, en mettant en évidence les exigences de sortie clés pour les services recommandés dans un contexte stratégique.

Remarques sur la conception

• De nombreux services Azure nécessitent l’accès à des points de terminaison publics pour que diverses fonctions de plan de gestion et de contrôle fonctionnent comme prévu.

• Azure fournit différentes méthodes de connectivité sortante Internet directe, telles que la passerelle NAT Azure ou Azure Load Balancer, pour les machines virtuelles ou les instances de calcul sur un réseau virtuel.

• Lorsque le trafic à l’intérieur d’un réseau virtuel est acheminé vers Internet, la traduction d’adresses réseau (NAT) doit avoir lieu. Il s’agit d’une opération de calcul qui se produit au sein de la pile réseau et qui peut donc avoir un impact sur les performances du système.

• Lorsque la NAT a lieu à une petite échelle, l’impact sur les performances doit être négligeable, toutefois, s’il existe un grand nombre de demandes sortantes, des problèmes réseau peuvent se produire. Ces problèmes se présentent généralement sous la forme d'« épuisement du port NAT source (ou SNAT) ».

• Dans un environnement multilocataire, tel que Azure App Service, un nombre limité de ports sortants est disponible pour chaque instance. Si ces ports sont à court, aucune nouvelle connexion sortante ne peut être lancée. Ce problème peut être atténué en réduisant le nombre de traversées de périphérie privées/publiques ou en utilisant une solution NAT plus évolutive telle que la passerelle NAT Azure.

• Outre les limitations NAT, le trafic sortant peut également faire l’objet d’inspections de sécurité requises.

  • Pare-feu Azure fournit des fonctionnalités de sécurité appropriées pour sécuriser la sortie réseau.

  • Pare-feu Azure (ou une appliance virtuelle réseau équivalente) peut être utilisé pour sécuriser les exigences de sortie Kubernetes en fournissant un contrôle granulaire sur les flux de trafic sortant.

• De grands volumes de sorties Internet entraînent des frais de transfert de données.

Azure NAT Gateway

• La passerelle NAT Azure prend en charge 64 000 connexions tcp et UDP par adresse IP sortante affectée.

  • Jusqu’à 16 adresses IP peuvent être affectées à une seule passerelle NAT.
  • Délai d’inactivité TCP par défaut de 4 minutes. Si le délai d’inactivité est modifié pour une valeur plus élevée, les flux sont conservés plus longtemps, ce qui augmente la pression sur l’inventaire des ports SNAT.

• La passerelle NAT ne peut pas fournir d’isolation zonale prête à l’emploi. Pour obtenir la redondance zonale, un sous-réseau contenant des ressources zonales doit être aligné sur les passerelles NAT zonales correspondantes.

Recommandations de conception

• Réduisez le nombre de connexions Internet sortantes, car cela aura un impact sur les performances NAT.

  • Si un grand nombre de connexions Internet sont requises, envisagez d’utiliser la passerelle NAT Azure pour extraire les flux de trafic sortant.

• Utilisez Pare-feu Azure où il existe des exigences pour contrôler et inspecter le trafic Internet sortant.

  • Vérifiez Pare-feu Azure n’est pas utilisé pour inspecter le trafic entre les services Azure.

Notes

Lors du déploiement dans une zone d’atterrissage Azure, envisagez d’utiliser la plateforme de base Pare-feu Azure ressource (ou une appliance virtuelle réseau équivalente). Si une dépendance est prise sur une ressource de plateforme centrale pour la sortie Internet, le niveau de fiabilité de cette ressource et le chemin réseau associé doivent être étroitement alignés sur les exigences de l’application. Les données opérationnelles de la ressource doivent également être mises à la disposition de l’application afin d’informer les actions opérationnelles potentielles dans les scénarios de défaillance.

S’il existe des exigences à grande échelle associées au trafic sortant, vous devez prendre en compte une ressource Pare-feu Azure dédiée pour une application stratégique, afin d’atténuer les risques associés à l’utilisation d’une ressource partagée de manière centralisée, comme les scénarios de voisins bruyants.

• Lorsqu’il est déployé dans un environnement Virtual WAN, il convient de prendre en compte Firewall Manager pour fournir une gestion centralisée des instances de Pare-feu Azure d’applications dédiées afin de garantir que les postures de sécurité de l’organisation sont observées via des stratégies de pare-feu globales.
• Vérifiez que les stratégies de pare-feu incrémentielles sont déléguées aux équipes de sécurité des applications via le contrôle d’accès en fonction du rôle pour permettre l’autonomie de la stratégie d’application.

Connectivité interzone et inter-région

Bien que la conception de l’application préconise fortement des unités d’échelle de déploiement régionales indépendantes, de nombreux scénarios d’application peuvent quand même nécessiter une intégration réseau entre les composants d’application déployés au sein de différentes zones ou régions Azure, même s’il s’agit uniquement de circonstances de service dégradées. La méthode par laquelle la communication interzone et interrégion est obtenue a une incidence significative sur les performances et la fiabilité globales, qui seront explorées à l’aide des considérations et recommandations de cette section.

Remarques sur la conception

• L’approche de conception d’application pour une application stratégique approuve l’utilisation de déploiements régionaux indépendants avec redondance zonale appliquée à tous les niveaux de composants au sein d’une seule région.

• Une zone de disponibilité (AZ) est un emplacement de centre de données physiquement distinct au sein d’une région Azure, qui fournit une isolation des erreurs physiques et logiques jusqu’au niveau d’un seul centre de données.

  Une latence d’aller-retour inférieure à 2 ms est garantie pour la communication interzone. Les zones auront une faible variation de latence en fonction des distances variées et des chemins de fibre entre les zones.

• La connectivité des zones de disponibilité dépend des caractéristiques régionales. Par conséquent, le trafic entrant dans une région via un emplacement périphérique peut devoir être acheminé entre les zones pour atteindre sa destination. Cela ajoute une latence d’environ 1 ms-2 ms en fonction des contraintes de routage interzone et de « vitesse de la lumière », mais cela ne devrait avoir qu’une incidence sur les charges de travail hypersensibles.

• Zones de disponibilité sont traités comme des entités logiques dans le contexte d’un seul abonnement, de sorte que différents abonnements peuvent avoir un mappage zonal différent pour la même région. Par exemple, la zone 1 de l’abonnement A peut correspondre au même centre de données physique que la zone 2 de l’abonnement B.

• La communication entre les zones au sein d’une région entraîne des frais de transfert de données par Go de bande passante.

• Avec des scénarios d’application extrêmement bavards entre les composants de l’application, la répartition des niveaux application entre les zones peut introduire une latence significative et des coûts accrus. Il est possible d’atténuer ce problème dans la conception en limitant un tampon de déploiement à une seule zone et en déployant plusieurs empreintes dans les différentes zones.

• La communication entre différentes régions Azure entraîne des frais de transfert de données plus importants par Go de bande passante.

  • Le taux de transfert de données applicable dépend du continent des régions Azure considérées.
  • Les données parcourant les continents sont facturées à un tarif considérablement plus élevé.

• Les méthodes de connectivité Express Route et VPN peuvent également être utilisées pour connecter directement différentes régions Azure pour certains scénarios, voire pour différentes plateformes cloud.

• Pour les Private Link de communication de services à service peut être utilisée pour la communication directe à l’aide de points de terminaison privés.

• Le trafic peut être épinglé via des circuits Express Route utilisés pour la connectivité locale afin de faciliter le routage entre les réseaux virtuels au sein d’une région Azure et entre différentes régions Azure au sein de la même zone géographique.

  • Le trafic épinglant via Express Route contourne les coûts de transfert de données associés au peering de réseaux virtuels. Il peut donc être utilisé comme un moyen d’optimiser les coûts.
  • Cette approche nécessite des tronçons réseau supplémentaires pour l’intégration d’applications dans Azure, ce qui introduit des risques de latence et de fiabilité. Développe le rôle d’Express Route et des composants de passerelle associés à partir d’Azure/local pour englober également la connectivité Azure/Azure.

• Lorsque la latence inférieure à la milliseconde est requise entre les services, les groupes de placement de proximité peuvent être utilisés lorsqu’ils sont pris en charge par les services utilisés.

Recommandations de conception

• Utilisez le peering de réseaux virtuels pour connecter les réseaux au sein d’une région et entre différentes régions. Il est vivement recommandé d’éviter le hairpinning dans Express Route.

• Utilisez Private Link pour établir une communication directe entre les services de la même région ou entre les régions (service dans la région A communiquant avec le service dans la région B.

• Pour les charges de travail d’application dont les composants sont extrêmement bavards, envisagez de limiter un tampon de déploiement à une seule zone et de déployer plusieurs tampons dans les différentes zones. Cela garantit que la redondance zonale est maintenue au niveau d’un tampon de déploiement encapsulé et non d’un même composant d’application.

• Dans la mesure du possible, traitez chaque empreinte de déploiement comme indépendante et déconnectée des autres empreintes.

  • Utilisez les technologies de plateforme de données pour synchroniser l’état entre les régions plutôt que d’obtenir une cohérence au niveau de l’application avec des chemins réseau directs.
  • Évitez le trafic de « legging de chien » entre différentes régions, sauf si nécessaire, même dans un scénario de défaillance. Utilisez des services de routage globaux et des sondes d’intégrité de bout en bout pour retirer une empreinte entière de la circulation en cas de défaillance d’un seul niveau de composant critique, plutôt que de router le trafic à ce niveau de composant défectueux vers une autre région.

• Pour les scénarios d’application sensibles à l’hyper latence, donnez la priorité à l’utilisation de zones avec des passerelles réseau régionales afin d’optimiser la latence du réseau pour les chemins d’entrée.

Micro-segmentation et stratégies réseau Kubernetes

La micro-segmentation est un modèle de conception de sécurité réseau utilisé pour isoler et sécuriser des charges de travail d’application individuelles, avec des stratégies appliquées pour limiter le trafic réseau entre les charges de travail basées sur un modèle Confiance Zéro. Il est généralement appliqué pour réduire la surface d’attaque réseau, améliorer le confinement des violations et renforcer la sécurité par le biais de contrôles réseau au niveau de l’application pilotés par des stratégies.

Une application stratégique peut appliquer la sécurité réseau au niveau de l’application à l’aide de groupes de sécurité réseau (NSG) au niveau d’un sous-réseau ou d’une interface réseau, de listes de Access Control de service (ACL) et de stratégies réseau lors de l’utilisation de Azure Kubernetes Service (AKS).

Cette section explore l’utilisation optimale de ces fonctionnalités, en fournissant des considérations et des recommandations clés pour réaliser la micro-segmentation au niveau de l’application.

Remarques sur la conception

• AKS peut être déployé dans deux modèles de mise en réseau différents :

  • Mise en réseau Kubenet : Les nœuds AKS sont intégrés à un réseau virtuel existant, mais les pods existent dans un réseau de superposition virtuel sur chaque nœud. Le trafic entre les pods sur des nœuds différents est routé via kube-proxy.
  • Mise en réseau CNI (Container Networking Interface) Azure : Le cluster AKS est intégré à un réseau virtuel existant et ses nœuds, pods et services ont reçu des adresses IP du même réseau virtuel auquel les nœuds de cluster sont attachés. Cela s’applique à différents scénarios de mise en réseau nécessitant une connectivité directe entre et vers les pods. Différents pools de nœuds peuvent être déployés dans différents sous-réseaux.

  Notes

  Azure CNI nécessite plus d’espace d’adressage IP par rapport à Kubenet. Une planification et un dimensionnement initiaux appropriés du réseau sont requis. Pour plus d’informations, consultez la documentation Azure CNI.

• Par défaut, les pods ne sont pas isolés et acceptent le trafic provenant de n’importe quelle source et peuvent envoyer du trafic vers n’importe quelle destination ; un pod peut communiquer avec tous les autres pods d’un cluster Kubernetes donné ; Kubernetes ne garantit aucune isolation au niveau du réseau et n’isole pas les espaces de noms au niveau du cluster.

• La communication entre les pods et les espaces de noms peut être isolée à l’aide de stratégies réseau. Une stratégie réseau est une spécification Kubernetes qui définit les stratégies d’accès concernant la communication entre les pods. À l’aide de stratégies réseau, un ensemble ordonné de règles peut être défini pour contrôler la façon dont le trafic est envoyé/reçu, et appliqué à une collection de pods qui correspondent à un ou plusieurs sélecteurs d’étiquettes.

  • AKS prend en charge deux plug-ins qui implémentent une stratégie réseau, Azure et Calico. Les deux plug-ins utilisent des ipTables Linux pour appliquer les stratégies spécifiées. Pour plus d’informations, consultez Différences entre les stratégies Azure et Calico et leurs fonctionnalités .
  • Les stratégies réseau ne sont pas en conflit, car elles sont additives.
  • Pour qu’un flux réseau entre deux pods soit autorisé, la stratégie de sortie sur le pod source et la stratégie d’entrée sur le pod de destination doivent autoriser le trafic.
  • La fonctionnalité de stratégie réseau ne peut être activée qu’au moment de l’instanciation du cluster. Il n’est pas possible d’activer la stratégie réseau sur un cluster AKS existant.
  • La distribution de stratégies réseau est cohérente, qu’Azure ou Calico soit utilisé.
  • Calico fournit un ensemble de fonctionnalités plus riche, notamment la prise en charge des nœuds windows et prend en charge Azure CNI ainsi que Kubenet.

• AKS prend en charge la création de pools de nœuds différents pour séparer différentes charges de travail à l’aide de nœuds avec des caractéristiques matérielles et logicielles différentes, telles que des nœuds avec et sans fonctionnalités GPU.

  • L’utilisation de pools de nœuds ne fournit aucune isolation au niveau du réseau.
  • Les pools de nœuds peuvent utiliser différents sous-réseaux au sein du même réseau virtuel. Les groupes de sécurité réseau peuvent être appliqués au niveau du sous-réseau pour implémenter la micro-segmentation entre les pools de nœuds.

Recommandations de conception

• Configurez un groupe de sécurité réseau sur tous les sous-réseaux considérés pour fournir une liste de contrôle d’accès IP pour sécuriser les chemins d’accès d’entrée et isoler les composants d’application en fonction d’un modèle Confiance nulle.

  • Utilisez des étiquettes de service Front Door dans des groupes de sécurité réseau sur tous les sous-réseaux contenant des back-ends d’application définis dans Azure Front Door, car cela validera le trafic provient d’un espace d’adressage IP de back-end Azure Front Door légitime. Cela garantit que le trafic transite par Azure Front Door au niveau du service, mais le filtrage basé sur les en-têtes sera toujours nécessaire pour garantir l’utilisation d’un instance Front Door particulier et pour atténuer les risques de sécurité liés à l’usurpation d’adresses IP.

  • Le trafic Internet public doit être désactivé sur les ports RDP et SSH dans tous les groupes de sécurité réseau applicables.

  • Donnez la priorité à l’utilisation du plug-in réseau Azure CNI et envisagez Kubenet pour les scénarios avec une plage d’adresses IP disponibles limitée pour faire rentrer l’application dans un espace d’adressage limité.

    • AKS prend en charge l’utilisation d’Azure CNI et de Kubenet. Il est sélectionné au moment du déploiement.
    • Le plug-in réseau Azure CNI est un plug-in réseau plus robuste et évolutif, et il est recommandé pour la plupart des scénarios.
    • Kubenet est un plug-in réseau plus léger et est recommandé pour les scénarios avec une plage limitée d’adresses IP disponibles.
    • Pour plus d’informations, consultez Azure CNI .

• La fonctionnalité Network Policy (Stratégie réseau) de Kubernetes doit être utilisée pour définir des règles pour le trafic d’entrée et de sortie entre les pods d’un cluster. Définissez des stratégies réseau granulaires pour restreindre et limiter la communication interpod.

  • Activez la stratégie réseau pour Azure Kubernetes Service au moment du déploiement.
  • Hiérarchiser l’utilisation de Calico , car il fournit un ensemble de fonctionnalités plus riche avec une adoption et un support de la communauté plus large.

Étape suivante

Passez en revue les considérations relatives à la quantification et à l’observation de l’intégrité de l’application.

Modélisation et observabilité de l’intégrité