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, compte tenu 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 à informer la conception d’une topologie de réseau global sécurisée et évolutive pour une application stratégique.

Important

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

Routage global du trafic

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

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 globales tierces. Ces options peuvent être échangées de manière presque transparente pour remplacer ou étendre l’utilisation des services de routage globaux natifs Azure. Parmi les choix courants, citons les technologies de routage par les fournisseurs CDN.

Cette section explore les principales différences entre les services de routage Azure pour définir la façon dont chacun peut être utilisé pour optimiser différents scénarios.

Considérations sur la 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 importantes autour de la mise en cache edge et des fonctionnalités de pare-feu d’applications web, ainsi que la gestion des certificats pour le déchargement SSL et la validation d’application pour les chemins d’entrée.
  • Les technologies tierces peuvent également être prises en compte, fournissant une résilience de routage globale à tous les niveaux des défaillances de plateforme Azure.

• La disparité des capacités entre Azure Front Door et Traffic Manager signifie que si les deux technologies sont placées en même temps que les autres pour la redondance, un chemin d’entrée ou des modifications de conception différents serait nécessaire pour garantir un niveau de service cohérent et acceptable.

• Azure Front Door et Azure Traffic Manager sont des services distribués globalement 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é globale de ces services de routage résilients présentent un risque plus large pour l’application en termes de défaillances en cascade et corrélées.
    • Les scénarios d’échec de cette échelle ne sont possibles que par des services fondamentaux 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 rencontre également une indisponibilité ou un service détérioré.
    • Les scénarios d’échec de 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 ne fournit que peu de valeur.

• La redondance globale du service de routage fournit une atténuation pour 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 fournir une redondance plus large aux scénarios de panne globaux, une approche de déploiement active-active multicloud peut être prise en compte. Une approche de déploiement active-active multicloud introduit des complexités opérationnelles importantes, qui présentent des risques de résilience significatifs, qui dépassent probablement de loin les risques hypothétiques d’une panne globale.

• 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’elles sont utilisées en isolation, elles représentent un point de défaillance unique au niveau du service en raison de dépendances globales, même si la redondance et la disponibilité multirégion intégrées sont fournies.
  • Le contrat SLA fourni par le service de routage global sélectionné représente le SLO 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, les atténuations opérationnelles peuvent être prises en compte 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 une autre est généralement un processus long qui dure plusieurs heures, en particulier lorsque la propagation DNS est considérée.

• Certains services de routage globaux tiers fournissent un contrat SLA de 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 pour l’indisponibilité, il est peu important lorsque l’impact de l’indisponibilité est significatif, comme dans les scénarios critiques en matière de sécurité où la vie humaine est 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 principaux.
  • Les requêtes clientes entrantes sont d’abord arrêtées au niveau du nœud de périphérie le plus proche du client d’origine.
  • Une fois l’inspection du trafic requise effectuée, les demandes sont transférées sur le serveur principal Microsoft vers le serveur principal approprié à l’aide de connexions existantes ou servies à partir du cache interne d’un nœud de périphérie.
  • Cette approche est 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 dédié (CDN).

• Le pare-feu d’applications web Azure (WAF) peut être utilisé sur Azure Front Door et, étant donné qu’il est déployé sur des emplacements de périphérie réseau Azure dans le monde entier, chaque demande entrante fournie par Front Door 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 de la protection Azure DDoS 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ée en tant que couche supplémentaire à Azure Front Door.

• Azure Front Door offre un service de certificat 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 passer d’Internet directement sur des réseaux virtuels Azure. Cela élimine le besoin 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ées à intervalles pour retourner un code d’état HTTP reflétant si le serveur principal fonctionne normalement, avec une réponse HTTP 200 (OK) reflétant un état sain. Dès qu’un back-end reflète un état non sain, du point de vue d’un nœud de périphérie donné, ce nœud de périphérie cesse d’envoyer des requêtes là-bas. Les back-ends non sains sont donc supprimés de manière transparente de la circulation du trafic sans aucun délai.

• Prend uniquement en charge les protocoles HTTP/S.

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

• L’espace IP principal Front Door peut changer, mais Microsoft garantit l’intégration avec les plages d’adresses IP Azure et les étiquettes de service. Il est possible de s’abonner aux plages d’adresses IP Azure et aux balises 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 serveur principal « le plus proche » à partir du client ; en fonction de la latence des requêtes.
  • Basé sur la priorité : utile pour les configurations actives et passives, où le trafic doit toujours être envoyé à un back-end 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, le routage basé sur la latence est utilisé.

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

• Si une série de requêtes clientes doit être gérée par le même serveur principal, l’affinité de session peut être configurée sur le front-end. Il utilise un cookie côté client pour envoyer des demandes ultérieures au même back-end que la première requête, à condition que le serveur principal 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 plutôt le nom DNS de l’un des back-ends qu’il contient, 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 pour une période de durée de vie (TTL) spécifiée, et les demandes effectuées pendant cette période vont directement au point de terminaison principal sans interaction traffic Manager. Élimine l’étape de connectivité supplémentaire qui offre des avantages de coût par rapport à Front Door.

• Étant donné que la demande est effectuée directement du client au service principal, 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 back-end est sain et fonctionne normalement. Si une autre valeur est retournée ou que rien n’est retourné, le service de routage reconnaît les problèmes en cours et arrête le routage des demandes vers ce serveur principal spécifique.

  • Toutefois, contrairement à Azure Front Door, cette suppression de back-ends non sains n’est pas instantanée, car les clients continueront à créer des connexions au back-end défectueux jusqu’à ce que la durée de vie DNS expire et qu’un nouveau point de terminaison principal soit demandé auprès du service Traffic Manager.
  • En outre, même lorsque la durée de vie expire, il n’existe aucune garantie que les serveurs DNS publics respectent 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

L’équilibreur de charge standard inter-régions est disponible 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 au pare-feu d’applications web (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, avec une application à chacun des différents services de routage globaux pour simplifier l’expérience globale de gestion des certificats et la logique de routage pour un basculement.
  • Hiérarchiser l’utilisation des technologies de routage tierces comme service de basculement secondaire, car cela atténuera le plus grand nombre de scénarios d’échec globaux et les fonctionnalités offertes par les principaux fournisseurs CDN permettront d’adopter une approche de conception cohérente.
  • Vous devez également tenir compte du routage direct vers un tampon régional unique plutôt qu’un service de routage distinct. Bien que cela entraîne un niveau de service détérioré, il représente une approche de conception beaucoup plus simple.

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

Important

Pour atténuer réellement le risque d’échecs globaux au sein de la plateforme Azure, une approche de déploiement active-active multicloud doit être prise en compte, avec des tampons de déploiement actifs hébergés sur deux fournisseurs de cloud ou plus 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’empreintes 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 au sein du fonctionnement normal de l’application, ce qui dépasse largement les risques hypothétiques d’une panne de plateforme mondiale.

• Bien qu’il ne soit pas recommandé, pour les charges de travail HTTP à l’aide d’Azure Traffic Manager pour la redondance globale du routage vers Azure Front Door, envisagez de décharger le pare-feu d’applications web (WAF) vers Application Gateway pour le trafic acceptable transitant par Azure Front Door.
  • Cela introduit un point d’échec supplémentaire vers le chemin d’entrée standard, un composant de chemin critique supplémentaire pour gérer et mettre à l’échelle, et entraîne également des coûts supplémentaires pour garantir la haute disponibilité globale. Toutefois, il simplifie 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, tant en termes d’exécution de WAF que de points de terminaison d’application privés.
  • La perte de 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 sur 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 supprimez la nécessité de gérer les cycles de vie des certificats.

• Utilisez le pare-feu d’applications web Azure Front Door (WAF) pour fournir une protection à la périphérie contre les attaques et vulnérabilités web courantes, telles que l’injection 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 dédié (CDN).

• Configurez les points d’entrée de la plateforme d’application pour valider les requêtes entrantes via le filtrage basé sur l’en-tête à l’aide du 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 des balises de service Front Door pour valider le trafic provenant 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 en aval critiques au sein d’un tampon de déploiement régional, y compris les réplicas de plateforme de données, tels qu’Azure Cosmos DB dans l’exemple fourni par l’implémentation de référence fondamentale. Si une ou plusieurs dépendances ne sont pas saines, la sonde d’intégrité doit refléter cela dans la réponse retournée afin que l’intégralité de l’empreinte régionale puisse être retirée de la circulation.

• Vérifiez que les réponses des sondes d’intégrité sont journalisées et ingérées 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.

• Sauf si la charge de travail est extrêmement sensible à la latence, répartissez le trafic uniformément entre tous les tampons régionaux considérés pour utiliser les ressources déployées de manière la plus efficace.

  • Pour ce faire, définissez le paramètre « Sensibilité de latence (latence supplémentaire) » sur une valeur suffisamment élevée pour répondre aux 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 en ce qui concerne la latence globale des demandes du client.

• N’activez pas l’affinité de session, sauf si elle est requise par l’application, 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 recommandée de conception d’application critique 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 Traffic Manager, à l’aide d’Azure Application Gateway.

• Configurez une valeur de durée de vie convenablement faible pour optimiser le temps nécessaire pour supprimer un point de terminaison principal non sain de la circulation dans l’événement 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 la prise en compte supplémentaire de Traffic Manager, le basculement régional au niveau du service doit être pris en compte. 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épendances, en particulier s’il n’est pas possible de définir une durée de vie faible pour les enregistrements DNS.

• Vous devez prendre en compte les fournisseurs DE CDN tiers afin d’obtenir une 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 proposées par le service tiers, vous devez prendre en compte la nécessité de simplifier le chemin d’entrée et de supprimer potentiellement 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 remise 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 remise d’applications, en tenant compte des services pertinents tels qu’Azure Standard Load Balancer, Azure Application Gateway et Azure Gestion des API.

Considérations sur la 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’un tampon pour déchiffrer le trafic entrant. Le déchargement TLS nécessite la clé privée du certificat TLS pour déchiffrer le trafic.

• Un pare-feu d’applications web offre une protection contre les attaques et vulnérabilités web courantes, telles que l’injection SQL ou les scripts intersites, et est essentiel pour atteindre les aspirations de fiabilité maximales 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 proposées sur chacun des services diffèrent légèrement. Par exemple, le WAF Azure Front Door fournit une limitation de débit, un filtrage géographique et une protection bot, qui ne sont pas encore proposés dans le WAF Application Gateway. Toutefois, ils prennent tous en charge les règles intégrées et personnalisées et peuvent être définies pour fonctionner en mode de détection ou en mode de prévention.
    • La feuille de route pour Azure WAF garantit qu’un ensemble de fonctionnalités WAF cohérent est fourni dans 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 au sein de Kubernetes peuvent également être prises en compte pour fournir une protection des 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 requêtes avec un en-tête connu Host . Ce blocage de protocole permet d’atténuer les attaques volumétriques réparties entre les protocoles et les ports, ainsi que les attaques d’amplification DNS et d’empoisonnement TCP.

• Azure Front Door est une ressource Azure globale, de sorte que la configuration est déployée globalement 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 requêtes par seconde.
  • Les mises à jour apportées à la configuration, y compris les itinéraires 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 entièrement managé et une méthode bring-your-own-certificate pour les certificats SSL côté client. Le service de certificats entièrement géré offre une approche opérationnelle simplifiée et permet de réduire la complexité de la conception globale en effectuant une gestion des certificats dans une seule zone de la solution.

• Azure Front Door fait pivoter automatiquement les certificats « gérés » au moins 60 jours avant l’expiration du certificat pour vous protéger contre les risques de certificat expirés. Si des certificats auto-managé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ées.

• Les mises à jour de certificat entraînent un temps d’arrêt uniquement si Azure Front Door est basculé entre « Géré » et « 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 aident à 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 l’accablant avec du trafic illégal.

• Azure Front Door fournit également des fonctionnalités WAF au niveau du trafic global, tandis que le WAF Application Gateway 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 sauvegardée par un contrat SLA et a plusieurs contraintes de capacité par rapport à la référence SKU Standard.

Recommandations de conception

• Effectuez le déchargement TLS dans le plus petit nombre 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 seront pas visibles pour les utilisateurs finaux. Par conséquent, 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 de tous les points de terminaison exposés publiquement.

• Activez les fonctionnalités WAF à un seul emplacement de service, soit globalement avec Azure Front Door, soit régionalement avec Azure Application Gateway, car cela simplifie le réglage 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’applications.

• 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 % lors du déploiement 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

Le 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 entraîne 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 sur la conception

• Tout le contenu qu’une solution met à disposition 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é tirent considérablement parti de la mise en cache, car elle réduit la charge sur les services back-end 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 réseau de distribution de contenu (CDN).
  • Azure Front Door fournit des fonctionnalités de mise en cache de périphérie native 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 rentable, mais ne fournit pas les mêmes fonctionnalités de routage avancées et de pare-feu d’applications web (WAF) qui sont recommandées pour d’autres domaines de conception d’application. Toutefois, elle 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 être effectuées à l’aide du moteur de règles.
    • Taille du contenu stocké et du coût associé.
    • Prix par mois pour l’exécution du moteur de règles (facturé par demande sur Azure Front Door).
    • Exigences de trafic sortant (le prix diffère par destination).

Recommandations de conception

• Le contenu statique généré, tel que les copies de taille des 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 recommandation forte (zone de conception réseau et de connectivité ) d’utiliser Azure Front Door à des fins de routage global et de pare-feu d’applications web (WAF), il est recommandé de hiérarchiser l’utilisation des fonctionnalités de mise en cache Azure Front Door, sauf si des lacunes existent.

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. Finalement, la méthode par laquelle l’intégration d’applications est obtenue aura un impact significatif sur la sécurité, les performances et la fiabilité de la solution, et aura un impact fort 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, qui détermine la façon dont l’intégration de l’application peut se produire au niveau du réseau.

1. Application publique sans connectivité réseau d’entreprise.
2. Application publique avec connectivité réseau d’entreprise.
3. Application privée avec 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 d’entreprise pour faciliter l’intégration au niveau du réseau.

Cette section explore ces scénarios d’intégration réseau, la couche dans l’utilisation appropriée d’Azure Réseau virtuel s et les services de mise en 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 fournie par le biais de points de terminaison publics et de la colonne principale microsoft Azure. La connectivité entre les points de terminaison publics hébergés sur Azure traverse uniquement le réseau principal Microsoft et ne passe pas par l’Internet public.
  • La connectivité à tous les systèmes externes en dehors d’Azure sera fournie par l’Internet public.

• Cette approche de conception adopte l'« identité en tant que 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 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 autour de l’obtention d’un accès non autorisé.

• Cette approche de conception n’est pas applicable à tous les services Azure, car de nombreux services, tels qu’AKS, ont une exigence difficile 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 dans 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 suivantes peuvent se trouver dans le réseau virtuel à l’aide de points de terminaison privés. Lors de l’utilisation d’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é.

• 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 s’appuient 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 principal Microsoft Azure.
  • La connectivité à tous les systèmes externes en dehors d’Azure serait fournie par l’Internet public.

• Pour les scénarios où il n’existe aucune configuration requise pour l’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 réseau privé sécurisé doit être établi pour permettre à l’outil 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 proxyr l’accès 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 dans Azure, un autre fournisseur de cloud ou des réseaux locaux à l’aide de diverses options de connectivité. Par exemple, certains scénarios d’application peuvent prendre en compte 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 les sujets tels que l’adressage et le routage.

• Les espaces d’adressage IP qui se chevauchent entre les régions Azure ou les réseaux locaux créent une contention majeure lorsque l’intégration réseau est prise en compte.

  • Une ressource de réseau virtuel peut être mise à jour pour prendre en compte un 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 nécessaire, ce qui désactive 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 inclus.
  • 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 elles doivent être suffisamment volumineuses pour prendre en charge toutes les instances actuelles du service en tenant compte des exigences futures en matière de mise à l’échelle, mais pas si volumineuses que pour les adresses inutiles de déchets.

• Lorsque l’intégration de réseau local 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 bande 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.

Remarque

Lors du déploiement dans une zone d’atterrissage Azure, sachez 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 la maintenance 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 Private Link, les risques d’exfiltration de données fournis sont acceptables ou atténués par le biais de contrôles alternatifs.

• 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.

• Lorsque vous vous connectez à d’autres réseaux Azure ou locaux, les réseaux virtuels d’application ne doivent pas être traités comme éphémères, car il crée des complications significatives où le peering de réseaux virtuels et les ressources de passerelle de réseau virtuel sont concernés. Toutes les ressources d’application pertinentes au sein du réseau virtuel doivent continuer à être éphémères, avec des sous-réseaux parallèles utilisés pour faciliter les déploiements bleu-vert des tampons de déploiement régionaux mis à 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 fortement recommandé d’utiliser uniquement les adresses IP de l’allocation d’adresses pour Internet privé (RFC 1918).
    • Pour les environnements avec une disponibilité limitée d’adresses IP privées (RFC 1918), envisagez d’utiliser IPv6.
    • Si l’utilisation de l’adresse IP publique est requise, vérifiez que seuls les blocs d’adresses détenus sont utilisés.
  • Alignez-vous avec les plans d’organisation pour l’adressage IP dans Azure pour vous assurer que l’espace d’adressage IP du réseau d’applications ne chevauche pas d’autres réseaux entre des emplacements locaux ou des régions Azure.
  • Ne créez pas inutilement de grands réseaux virtuels d’application 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 une rage limitée d’adresses IP disponibles pour s’adapter à l’application dans un espace d’adressage limité.

  • Hiérarchiser l’utilisation du plug-in réseau Azure CNI pour l’intégration réseau AKS et envisager Kubenet pour les scénarios avec une plage limitée d’adresses IP disponibles. Pour plus d’informations, consultez les 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.

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

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

  Remarque

  Lors du déploiement dans une zone d’atterrissage Azure et de l’intégration à une topologie de réseau d’organisation plus large, tenez compte des conseils réseau pour vous assurer que le réseau fondamental 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 de :

1. Interaction directe de l’utilisateur de l’application.
2. Intégration d’applications à 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 explique comment la sortie Internet peut être obtenue tout en garantissant la sécurité, la fiabilité et les performances durables maintenues, en mettant en évidence les principales exigences de sortie pour les services recommandés dans un contexte stratégique.

Remarques sur la conception

• De nombreux services Azure nécessitent l’accès aux 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 de l’intérieur d’un réseau virtuel se déplace vers Internet, la traduction d’adresses réseau (NAT) doit avoir lieu. Il s’agit d’une opération de calcul qui se produit dans la pile réseau et qui peut donc avoir un impact sur les performances du système.

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

• Dans un environnement multilocataire, tel qu’Azure App Service, il existe un nombre limité de ports sortants disponibles pour chaque instance. Si ces ports s’exécutent, 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.

• En plus des limitations NAT, le trafic sortant peut également être soumis à des 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îneront des frais de transfert de données.

Azure NAT Gateway

• La passerelle NAT Azure prend en charge 64 000 connexions pour 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é à 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é avec 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 liées à Internet sont requises, envisagez d’utiliser la passerelle NAT Azure pour extraire les flux de trafic sortant.

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

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

Remarque

Lors du déploiement dans une zone d’atterrissage Azure, envisagez d’utiliser la plateforme fondamentale 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 d’échec.

S’il existe des exigences à grande échelle associées au trafic sortant, vous devez prendre en compte une ressource de 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 centralisée, comme les scénarios de voisin bruyant.

• Lorsqu’il est déployé dans un environnement Virtual WAN, vous devez prendre en compte Pare-feu Manager pour fournir une gestion centralisée des instances d’application dédiées Pare-feu Azure afin de garantir que les postures de sécurité organisationnelles sont observées par le biais de stratégies de pare-feu globales.
• Assurez-vous 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 des stratégies d’application.

Connectivité interzone et interré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 un impact significatif sur les performances et la fiabilité globales, qui seront explorées par les considérations et recommandations contenues dans 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 une 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, fournissant une isolation de panne physique et logique jusqu’au niveau d’un centre de données unique.

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

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

• Zones de disponibilité sont traitées 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.

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

• La communication entre différentes régions Azure entraîne une plus grande charge de transfert de données 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 traversées de continents sont facturées à un taux beaucoup 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 différentes plateformes cloud.

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

• Le trafic peut être épinglé par le biais de 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 dans la même zone géographique.

  • Le trafic épinglage par le biais d’ExpressRoute contourne les coûts de transfert de données associés au peering de réseaux virtuels, afin de pouvoir être utilisé comme 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 de sous-illiseconde 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 directement entre les services de la même région ou entre les régions (service dans la région A communication 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 tampon de déploiement comme indépendant et déconnecté des autres tampons.

  • Utilisez des 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 « legging chien » entre différentes régions, sauf si nécessaire, même dans un scénario d’échec. Utilisez des services de routage globaux et des sondes d’intégrité de bout en bout pour retirer toute la circulation en cas d’échec 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 à la latence, hiérarchiser 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. Elle est généralement appliquée pour réduire la surface d’attaque réseau, améliorer l’endiguement des violations et renforcer la sécurité par le biais de contrôles réseau 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, des listes de contrôle d’accès au service (ACL) et des stratégies réseau lors de l’utilisation d’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 atteindre 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 différents nœuds 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 reçus des adresses IP du même réseau virtuel auquel les nœuds de cluster sont attachés. Cela s’applique aux différents scénarios de mise en réseau nécessitant une connectivité directe depuis et vers des pods. Différents pools de nœuds peuvent être déployés dans différents sous-réseaux.

  Remarque

  Azure CNI nécessite davantage d’espace d’adressage IP par rapport à Kubenet. Une planification initiale et un dimensionnement appropriés du réseau sont nécessaires. 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 dans 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 Network Policy, Azure et Calico. Les deux plug-ins utilisent des IPTables Linux pour appliquer les stratégies spécifiées. Pour plus d’informations, consultez les 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 additifs.
  • 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 des stratégies réseau est cohérente, que ce soit Azure ou Calico 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 différentes caractéristiques matérielles et logicielles, telles que les 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’entrée et isoler les composants d’application en fonction d’un modèle Confiance Zéro.

  • 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 valide le trafic provient d’un espace d’adressage IP principal Azure Front Door légitime. Cela garantit que le trafic transite par Azure Front Door au niveau d’un service, mais le filtrage basé sur l’en-tête sera toujours nécessaire pour garantir l’utilisation d’une instance Front Door particulière et pour atténuer également les risques de sécurité d’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 Kubenet. Ce choix de mise en réseau 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 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 elle fournit un ensemble de fonctionnalités plus riche avec l’adoption et le support de la communauté plus larges.

Étape suivante

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

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