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 sur les charges de travail critiques 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 relatives à la conception

• Un service de routage lié à une seule région représente un point de défaillance unique et un risque significatif en ce qui concerne les pannes régionales.

• Si la charge de travail de l’application englobe le contrôle client, par exemple avec les applications clientes mobiles ou de bureau, il est possible de fournir une redondance de service dans la logique de routage du client.

  • Plusieurs technologies de routage globales, telles qu’Azure Front Door et Azure Traffic Manager, peuvent être envisagées en parallèle pour assurer la redondance, les clients étant configurés pour passer à une autre technologie lorsque certaines conditions d’échec sont remplies. 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 envisagée. Une approche de déploiement active-active multicloud introduit des complexités opérationnelles importantes, présentant des risques de résilience significatifs, dépassant probablement de loin les risques hypothétiques d’une interruption globale.

• Pour les scénarios où le contrôle client n’est pas possible, une dépendance doit être prise sur un seul service de routage global 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 SLA historique et atteignable 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 publié est de 100%.

Porte d’entrée azur

• Azure Front Door fournit un équilibrage de charge HTTP/S global et une connectivité optimisée à l’aide du 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 distribue du contenu statique à partir de nœuds périphériques. 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 d’Azure DDoS Protection Basic. 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 fonctionnels sont donc supprimés de manière transparente du trafic immédiatement.

• 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, à la place, Traffic Manager retourne le nom DNS de l’un des back-ends de son 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 pour une durée de vie (TTL) spécifiée, et les demandes effectuées pendant cette période vont directement au point de terminaison backend sans l'interaction de 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 dans sa version préliminaire avec des limitations techniques. Cette option n’est pas recommandée pour les charges de travail critiques.

Recommandations en matière de conception

• Utilisez Azure Front Door comme principal service de routage du trafic global pour les scénarios HTTP/S. Azure Front Door est fortement recommandé pour les charges de travail HTTP/S, car il fournit un routage de trafic optimisé, un basculement transparent, des points de terminaison internes privés (avec le SKU Premium), la mise en cache périphérique et l’intégration avec le Pare-feu d'application Web (WAF).

• Pour les scénarios d’application où le contrôle client est possible, appliquez la logique de routage côté client pour prendre en compte les scénarios de basculement où la technologie de routage globale principale échoue. Deux technologies de routage globales ou plus doivent être placées en parallèle pour une redondance ajoutée, si un contrat SLA de service unique n’est pas suffisant. La logique cliente est nécessaire pour rediriger vers la technologie de redondance en cas d’échec de 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.
  • Il convient également d'envisager l'acheminement direct vers un cachet régional unique plutôt qu'un service d'acheminement séparé. 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 répartition de charge globale avec basculement des clients en utilisant Azure Front Door comme équilibreur de charge principal global.

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 configurations de déploiement actives réparties entre deux fournisseurs de cloud ou plus, et des technologies de routage tierces redondantes employées pour le routage à l'échelle mondiale.

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 dans le flux d'entrée standard, un élément crucial supplémentaire à gérer et à mettre à l’échelle, et entraîne également des coûts supplémentaires pour garantir une haute disponibilité à l'échelle mondiale. 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 à la périphérie en cas de panne aura un impact sur les performances globales, et cela doit être aligné sur un niveau de service acceptable ou une approche de conception pour atténuer les effets. 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é de prendre en compte un service de routage global tiers à la place de deux services de routage globaux Azure. Cela fournit le niveau maximal d’atténuation des pannes et une approche de conception plus simple, car la plupart des fournisseurs CDN leaders du secteur offrent des fonctionnalités de périphérie largement cohérentes avec celles offertes par Azure Front Door.

Porte d’entrée azur

• 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 que toutes les données opérationnelles exposées par Azure Front Door sont ingérées dans l’espace de travail global Log Analytics pour faciliter la consolidation des données et offrir 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é entraînent différentes décisions de conception pour les fonctionnalités de cache et waf et 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 TTL suffisamment faible pour optimiser le temps requis pour retirer un point de terminaison de backend non sain de la circulation dans le cas où le backend devient défectueux.

• Comme avec Azure Front Door, un point d'accès TCP personnalisé doit être défini pour valider les dépendances critiques en aval dans une empreinte de déploiement régionale, ce qui doit se refléter dans la réponse fournie par les points d'accès de santé.

  Toutefois, pour Traffic Manager, il convient de prêter une attention supplémentaire au basculement régional au niveau du service. par exemple, « dog legging », pour atténuer le délai potentiel associé à la suppression d’un backend 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.

• 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 éventuellement supprimer la nécessité d'un 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 des 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 Gestion des API Azure.

Considérations relatives à 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 offre une protection prête à l’emploi contre les 10 principales vulnérabilités OWASP à l’aide de jeux de règles managés.

  • 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 réseau (NVAs) et les contrôleurs d’entrée avancés au sein de Kubernetes servent également à fournir la protection requise contre les vulnérabilités.

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

  Porte d’entrée azur

• 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. Les fonctionnalités incluent des ensembles de règles de pare-feu pour se protéger contre les attaques courantes, le filtrage géographique, le blocage des adresses, la limitation du débit et la correspondance de signature.

  Équilibreur 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 en matière 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 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 le WAF en mode Détection (c'est-à-dire qu'il enregistre les requêtes suspectes sans les bloquer) lorsque la pénalité de performance du mode Prévention est trop élevée. Le risque supplémentaire implicite doit être entièrement compris et aligné sur les exigences spécifiques du scénario de charge de travail.

• Hiérarchisez l’utilisation d’Azure Front Door WAF, car il fournit le jeu de fonctionnalités natif d'Azure le plus riche et applique des protections à l'edge mondial, ce qui simplifie la conception globale et génère des gains d'efficacité.

• Utilisez Gestion des API Azure 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 dans les charges de travail de micros-service.

  • Fournit un SLA de 99,99 % lorsqu'il est déployé dans des zones de disponibilité.
  • Fournit des fonctionnalités critiques telles que les diagnostics ou les règles sortantes.

• 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 relatives à 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 Content Delivery Network (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 en matière 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 afin de réduire la charge sur les services back-end afin d’optimiser les performances 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 publiquesans connectivité réseau d’entreprise.
2. Application publiqueavec connectivité réseau d’entreprise.
3. Application privéeavec connectivité réseau d’entreprise.

Caution

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, en intégrant l’utilisation appropriée des réseaux virtuels Azure et des services de mise en réseau Azure environnants pour garantir que les exigences d’intégration sont satisfaites de manière optimale.

Considérations relatives à 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.

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. Cependant, lorsqu’un réseau appairé modifie son espace d’adressage de réseau virtuel, une synchronisation du lien de peering est nécessaire, cela ayant pour effet de désactiver 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, le Pare-feu Azure ou la passerelle de réseau virtuel Azure. La taille de ces sous-réseaux de service est très importante, car ils doivent être suffisamment grands pour prendre en charge toutes les instances actuelles du service en tenant compte des besoins futurs en termes d'extension, mais pas au point de gaspiller inutilement des adresses.

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

Note

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 pour assurer la fiabilité et le bon fonctionnement de l’application, afin de garantir la santé du système.

Recommandations en matière de conception

• Il est recommandé que les solutions stratégiques soient déployées dans des réseaux virtuels Azure si possible pour supprimer les points de terminaison publics inutiles, limitant la surface d’attaque de l’application pour optimiser 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 envisagés pour des services qui ne supportent pas Private Link, à condition que les risques d'exfiltration de données soient acceptables ou atténués par des contrôles alternatifs.

• Pour les scénarios d’application qui ne nécessitent pas de connectivité réseau d’entreprise, traitez tous les réseaux virtuels comme des ressources éphémères qui sont remplacées lorsqu’un nouveau déploiement régional est effectué.

• 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 cela crée des complications significatives, notamment en ce qui concerne le peering de réseaux virtuels et les ressources de passerelle de réseau virtuel. 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ù la connectivité réseau d’entreprise est requise pour faciliter l’intégration des applications sur des réseaux privés, assurez-vous que l’espace d’adressage IPv4 utilisé pour les réseaux virtuels d’application régionale ne chevauche pas d’autres réseaux connectés et est correctement dimensionné pour faciliter l’échelle requise sans avoir à mettre à jour la ressource de réseau virtuel et à entraîner 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 plage limitée d’adresses IP disponibles afin de répondre aux besoins de 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 de micro-segmentation et les politiques réseau de 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.

  Note

  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.

Considérations relatives à 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 y a un grand nombre de demandes sortantes, des problèmes réseau peuvent survenir. 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 sont épuisés, 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.

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

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

Passerelle NAT Azure

• 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 par défaut. Pour obtenir la redondance de zone, un sous-réseau contenant des ressources zonales doit être aligné avec les passerelles NAT zonales correspondantes.

Recommandations en matière 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 le Pare-feu Azure pour contrôler et inspecter le trafic Internet sortant.

  • Vérifiez qu’Azure Firewall n’est pas utilisé pour inspecter le trafic entre les services Azure.

Note

Lors du déploiement dans une zone d'accueil Azure, envisagez d’utiliser la ressource de pare-feu Azure de plateforme de base (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 Firewall Manager pour fournir une gestion centralisée des instances dédiées d'Azure Firewall afin de garantir que les politiques de sécurité de l'organisation sont observées grâce à des 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 défende fortement les tampons de déploiement régionaux indépendants, de nombreux scénarios d’application peuvent encore nécessiter l’intégration réseau entre les composants d’application déployés dans différentes zones ou régions Azure, même si seulement dans des 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.

Considérations relatives à 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 de zone 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.

• Les zones de disponibilité sont traitées comme des entités logiques dans le contexte d’un abonnement unique, 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 très bavards entre les composants d’application, la répartition des couches applicatives 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 traversant des 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.

• Private Link peut être utilisé pour la communication de service à service directe en utilisant des points de terminaison privés.

• Le trafic peut être redirigé en boucle par le biais de circuits Express Route utilisés pour la connectivité sur site 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 région géographique.

  • Le trafic en épingle à cheveux via ExpressRoute contourne les coûts de transfert de données associés au peering de réseaux virtuels et peut donc être utilisé pour 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 en matière de conception

• Utilisez le peering de réseaux virtuels pour connecter des réseaux au sein d’une région et entre différentes régions. Il est fortement recommandé d’éviter l’épinglage des cheveux 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 très communicatives entre les composants, envisagez de limiter une empreinte de déploiement à une seule zone et de déployer plusieurs empreintes dans les différentes zones. Cela garantit que la redondance de zone est maintenue au niveau d’un tampon de déploiement encapsulé plutôt qu’un seul 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 la déviation de trafic 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 de santé de bout en bout pour retirer une unité de déploiement entière de la circulation en cas de défaillance d'un seul niveau de composant critique, plutôt que de rediriger le trafic au niveau de ce 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.

Considérations relatives à 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çoivent des adresses IP du même réseau virtuel auquel les nœuds du 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.

  Note

  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. La stratégie réseau est une spécification Kubernetes qui définit les stratégies d’accès pour 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 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 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 en matière 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 permettra de valider que le trafic provient d’un espace d’adressage IP de backend 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 sur tous les groupes de sécurité réseau applicables.

  • Hiérarchiser l’utilisation du plug-in réseau Azure CNI et envisager Kubenet pour les scénarios avec une plage limitée d’adresses IP disponibles pour s’adapter à 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é stratégie réseau dans 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 entre pods.

  • 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 quantification et à l’observation de l’intégrité de l’application.

Modélisation et observabilité de la santé