Mise en réseau et connectivité pour les charges de travail stratégiques
La distribution régionale des ressources dans l’architecture de référence stratégique nécessite une infrastructure réseau robuste.
Une conception distribuée à l’échelle mondiale est recommandée lorsque les services Azure se réunissent pour fournir une application hautement disponible. L’équilibreur de charge global combiné avec des tampons régionaux offre une garantie par le biais d’une connectivité fiable.
Les timbres régionaux sont l’unité déployable dans l’architecture. La possibilité de déployer rapidement un nouveau tampon offre une scalabilité et prend en charge la haute disponibilité. Les timbres suivent une conception de réseau virtuel isolé . Le trafic croisé n’est pas recommandé. Les appairages de réseaux virtuels ou les connexions VPN à d’autres empreintes ne sont pas nécessaires.
L’architecture est intentionnelle dans la définition des timbres régionaux comme étant de courte durée. L’état global de l’infrastructure est stocké dans les ressources globales.
Un équilibreur de charge global est nécessaire pour acheminer le trafic vers des sites sains et fournir des services de sécurité. Elle doit avoir certaines fonctionnalités.
Le test d’intégrité est requis afin que l’équilibreur de charge puisse vérifier l’intégrité de l’origine avant le routage du trafic.
Distribution pondérée du trafic.
Optionnellement, il doit être en mesure d’effectuer la mise en cache en périphérie. Fournissez également une assurance de sécurité pour l’entrée à l’aide du pare-feu d’applications web (WAF).
Téléchargez un fichier Visio de cette architecture.
Entrée du trafic
L’application définie dans l’architecture est accessible sur Internet et a plusieurs exigences :
Solution de routage globale pouvant distribuer le trafic entre des timbres régionaux indépendants.
Faible latence dans la vérification d’intégrité et la possibilité d’arrêter l’envoi de trafic à des tampons non sains.
Prévention des attaques malveillantes en périphérie.
Fournir des fonctionnalités de mise en cache à la périphérie.
Le point d’entrée pour tout le trafic dans la conception s’effectue via Azure Front Door. Front Door est un équilibreur de charge global qui route le trafic HTTP(S) vers des back-ends/origines inscrits. Front Door utilise des sondes d’intégrité qui émettent des requêtes à un URI dans chaque back-end/origine. Dans l’implémentation de référence, l’URI appelé est un service de santé. Le service d’intégrité publie l’intégrité de l’empreinte. Front Door utilise la réponse pour déterminer l’intégrité d’un tampon individuel et acheminer le trafic vers des empreintes saines capables de traiter les requêtes d’application.
L’intégration d’Azure Front Door à Azure Monitor fournit une surveillance quasi en temps réel du trafic, de la sécurité, des métriques de réussite et d’échec et des alertes.
Le Pare-feu d’applications web Azure, intégré à Azure Front Door, est utilisé pour empêcher les attaques en périphérie avant d’entrer dans le réseau.
Réseau virtuel isolé - API
L’API de l’architecture utilise des réseaux virtuels Azure comme limite d’isolation du trafic. Les composants d’un réseau virtuel ne peuvent pas communiquer directement avec les composants d’un autre réseau virtuel.
Azure Load Balancer externe standard distribue les demandes à la plateforme d’application. Il vérifie que le trafic qui atteint l’équilibreur de charge a été routé via Azure Front Door, ce qui garantit qu’Azure WAF inspecte tout le trafic.
Les agents de build utilisés pour les opérations et le déploiement de l’architecture doivent être en mesure d’accéder au réseau isolé. Le réseau isolé peut être ouvert pour permettre aux agents de communiquer. Vous pouvez également déployer des agents auto-hébergés dans le réseau virtuel.
La surveillance du débit réseau, les performances des composants individuels et l’intégrité de l’application sont requises.
Dépendance de communication de la plateforme d’application
La plateforme d’application utilisée avec les empreintes individuelles dans l’infrastructure présente les exigences de communication suivantes :
La plateforme d’application doit être en mesure de communiquer en toute sécurité avec les services PaaS Microsoft.
La plateforme d’application doit être en mesure de communiquer en toute sécurité avec d’autres services si nécessaire.
L’architecture telle que définie utilise Azure Key Vault pour stocker des secrets, tels que des chaînes de connexion et des clés API, pour communiquer en toute sécurité via Internet aux services PaaS Azure. Il existe des risques possibles pour exposer la plateforme d’application sur Internet pour cette communication. Les secrets peuvent être compromis et une sécurité et une surveillance accrues des points de terminaison publics sont recommandés.
Considérations relatives à la mise en réseau étendue
Cette section décrit les avantages et inconvénients des approches alternatives à la conception du réseau. Les autres considérations relatives à la mise en réseau et l’utilisation de points de terminaison privés Azure sont le focus dans les sections suivantes.
Sous-réseaux et groupes de sécurité réseau
Les sous-réseaux au sein des réseaux virtuels peuvent être utilisés pour segmenter le trafic au sein de la conception. L’isolation du sous-réseau sépare les ressources pour différentes fonctions.
Les groupes de sécurité réseau peuvent être utilisés pour contrôler le trafic autorisé dans et hors de chaque sous-réseau. Les règles utilisées dans les groupes de sécurité réseau peuvent être utilisées pour limiter le trafic en fonction de l’adresse IP, du port et du protocole pour bloquer le trafic indésirable dans le sous-réseau.
Points de terminaison privés - Entrée
La version Premium de Front Door prend en charge l’utilisation de points de terminaison privés Azure. Les points de terminaison privés exposent un service Azure à une adresse IP privée dans un réseau virtuel. Les connexions sont établies de manière sécurisée et privée entre les services sans avoir à acheminer le trafic vers des points de terminaison publics.
Azure Front Door Premium et les points de terminaison privés Azure permettent des clusters de calcul entièrement privés dans les tampons individuels. Le trafic est entièrement verrouillé pour tous les services PaaS Azure.
L’utilisation de points de terminaison privés augmente la sécurité de la conception. Toutefois, il introduit un autre point de défaillance. Les points de terminaison publics exposés dans les tampons d’application ne sont plus nécessaires et ne sont plus accessibles et exposés à une attaque DDoS possible.
La sécurité accrue doit être pesée par rapport à l’effort de fiabilité accru, au coût et à la complexité.
Les agents de build auto-hébergés doivent être utilisés pour le déploiement d’empreintes. La gestion de ces agents entraîne une surcharge de maintenance.
Points de terminaison privés - Plateforme d’applications
Les points de terminaison privés sont pris en charge pour tous les services PaaS Azure utilisés dans cette conception. Avec les points de terminaison privés configurés pour la plateforme d’application, toutes les communications transitaient par le réseau virtuel du tampon.
Les points de terminaison publics des services PaaS Azure individuels peuvent être configurés pour interdire l’accès public. Ce processus isole les ressources des attaques publiques susceptibles d’entraîner un temps d’arrêt et une limitation qui affectent la fiabilité et la disponibilité.
Les agents de build auto-hébergés doivent être utilisés pour le déploiement stamp de la même manière que précédemment. La gestion de ces agents entraîne une charge de maintenance.
Étapes suivantes
Déployez l’implémentation de référence pour obtenir une compréhension complète des ressources et de leur configuration utilisée dans cette architecture.