Fonctionnement d’Azure Application Gateway
Azure Application Gateway dispose d’une série de composants qui s’associent pour acheminer et équilibrer en toute sécurité la charge de requêtes sur un pool de serveurs web. Application Gateway comprend les composants suivants :
- Adresse IP front-end : Les requêtes client sont reçues via une adresse IP front-end. Vous pouvez configurer Application Gateway pour qu’il ait une adresse IP publique, une adresse IP privée ou les deux. Application Gateway ne peut pas avoir plusieurs adresses IP publiques et adresses IP privées.
- Écouteurs : Application Gateway utilise un ou plusieurs écouteurs pour recevoir les requêtes entrantes. Un écouteur accepte le trafic arrivant sur une combinaison spécifiée de protocoles, ports, hôtes et adresses IP. Chaque écouteur route les requêtes vers un pool de serveurs back-end, selon les règles de routage que vous spécifiez. Un écouteur peut être de base ou multisite. Un écouteur De base route uniquement une requête selon le chemin de l’URL. Un écouteur Multisite peut également router les requêtes à l’aide de l’élément hostname de l’URL. Les écouteurs gèrent également les certificats TLS/SSL pour sécuriser votre application entre l’utilisateur et Application Gateway.
- Règles de routage : Une règle de routage lie un écouteur aux pools de back-ends. Une règle spécifie comment interpréter les éléments hostname et path de l’URL d’une requête et comment diriger la requête vers le pool de back-ends approprié. Une règle de routage est également associée à un ensemble de paramètres HTTP. Ces paramètres HTTP indiquent si le trafic est chiffré entre Application Gateway et les serveurs de back-end (et si oui, de quelle manière). D’autres informations de configuration incluent le protocole, l’adhérence de session, le drainage de connexion, le délai d’expiration des requêtes et les sondes d’intégrité.
Équilibrage de charge dans Application Gateway
Application Gateway équilibre automatiquement la charge des requêtes envoyées aux serveurs dans chaque pool de back-ends en utilisant un mécanisme de tourniquet (round-robin). L’équilibrage de charge fonctionne avec le modèle de routage OSI Layer 7 qui est implémenté par le routage Application Gateway, ce qui signifie qu’il équilibre la charge des requêtes selon les paramètres de routage (noms d’hôte et chemins) qui sont utilisés par les règles Application Gateway. En comparaison, les autres équilibreurs de charge comme Azure Load Balancer fonctionnent au niveau de la couche 4 du modèle OSI et répartissent le trafic en fonction de l’adresse IP de la cible d’une demande.
Vous pouvez configurer l’adhérence de session si toutes les demandes pour un client doivent être routées vers le même serveur d’un pool de back-ends au sein d’une même session.
Pare-feu d’applications web
Le pare-feu d’applications web (WAF) est un composant facultatif qui gère les requêtes entrantes avant qu’elles n’atteignent un écouteur. Le pare-feu d’applications web vérifie dans chaque requête la présence de nombreuses menaces courantes, d’après les recommandations de l’OWASP (Open Web Application Security Project). Les menaces courantes incluent : Violations et anomalies relatives à l’injection de code SQL, le scripting inter-site, l’injection de commande, la dissimulation de requêtes HTTP, le fractionnement de réponses HTTP, l’inclusion de fichiers distants, les bots, les robots et les analyseurs et le protocole HTTP.
L’OWASP définit un ensemble de règles génériques pour la détection des attaques. Ces règles sont les règles dites « CRS » (Core Rule Set). Ces ensembles de règles font l’objet de modifications constantes afin de répondre aux attaques de plus en plus sophistiquées. WAF prend en charge quatre ensembles de règles : CRS 3.2, 3.1, 3.0 et 2.2.9. CRS 3.1 est la valeur par défaut. Si nécessaire, vous pouvez choisir de ne sélectionner que certaines règles au sein d’un ensemble, pour ne cibler que certaines menaces. En outre, vous pouvez personnaliser le pare-feu en spécifiant les éléments d’une requête qui doivent être examinés et limiter la taille des messages afin d’éviter que des chargements en masse ne submergent vos serveurs.
Pools de back-ends
Un pool de back-ends est une collection de serveurs web qui peut se composer de : un ensemble fixe de machines virtuelles, un groupe de machines virtuelles identiques, une application hébergée par Azure App Services ou une collection de serveurs locaux.
Chaque pool de back-ends est associé à un équilibreur de charge qui répartit le travail au sein du pool. Quand vous configurez le pool, vous fournissez l’adresse IP ou le nom de chaque serveur web. Tous les serveurs du pool de back-ends doivent être configurés de la même façon, y compris leurs paramètres de sécurité.
Si vous utilisez TLS/SSL, le pool de back-ends a un paramètre HTTP qui référence un certificat utilisé pour authentifier les serveurs de back-end. La passerelle rechiffre le trafic en utilisant ce certificat avant de l’envoyer à l’un de vos serveurs dans le pool de back-ends.
Si vous utilisez Azure App Service pour héberger l’application back-end, il est inutile d’installer des certificats dans Application Gateway pour vous connecter au pool de back-ends. Toutes les communications sont automatiquement chiffrées. Application Gateway approuve les serveurs parce que c’est Azure qui les gère.
Application Gateway utilise une règle pour indiquer comment diriger les messages reçus sur son port entrant vers les serveurs du pool de back-ends. Si les serveurs utilisent TLS/SSL, vous devez configurer la règle pour indiquer :
- Que vos serveurs attendent le trafic via le protocole HTTPS.
- Quel certificat utiliser pour chiffrer le trafic et authentifier la connexion à un serveur.
Routage Application Gateway
Quand La passerelle route une demande de client vers un serveur web du pool de back-ends, elle utilise un ensemble de règles configurées pour que la passerelle puisse déterminer où la demande doit aller. Il existe deux méthodes principales pour le routage du trafic de cette demande de client : routage basé sur le chemin et routage multisite.
Routage basé sur le chemin
Le routage basé sur le chemin envoie des requêtes avec différents chemins d’URL à différents pools de serveurs back-end. Par exemple, vous pourriez diriger les requêtes avec le chemin /vidéo/* vers un pool back-end contenant des serveurs qui sont optimisés pour gérer le streaming vidéo et diriger les requêtes /images/* vers un pool de serveurs qui gèrent la récupération des images.
Routage multisite
Le routage multisite configure plusieurs applications web sur la même instance Application Gateway. Dans une configuration multisite, vous inscrivez plusieurs noms DNS (CNAME) pour l’adresse IP de la passerelle applicative, en spécifiant le nom de chaque site. Application Gateway utilise différents écouteurs pour attendre les requêtes de chaque site. Chaque écouteur passe la requête à une règle qui peut router la requête vers les serveurs d’un autre pool de back-ends. Par exemple, vous pourriez diriger toutes les requêtes de http://contoso.com vers les serveurs d’un pool de back-ends, et les requêtes de http://fabrikam.com vers un autre pool de back-ends. Le diagramme suivant montre cette configuration :
Les configurations multisites sont utiles pour prendre en charge des applications multilocataires dans lesquelles chaque tenant dispose de son propre groupe de machines virtuelles ou d’autres ressources hébergeant une application web.
Le routage Application Gateway comprend également ces fonctionnalités :
- Redirection. La redirection peut être utilisée vers un autre site, ou de HTTP vers HTTPS.
- Réécrire les en-têtes HTTP. Les en-têtes HTTP permettent au client et au serveur de passer des informations de paramètre dans la requête ou la réponse.
- Pages d’erreurs personnalisées. Application Gateway vous permet de créer des pages d’erreur personnalisées au lieu d’afficher les pages d’erreur par défaut. Vous pouvez utiliser votre marque et votre mise en page personnelle à l’aide d’une page d’erreur personnalisée.
Terminaison TLS/SSL
Quand vous terminez la connexion TLS/SSL au niveau de la passerelle applicative, la charge de travail associée à cette opération, qui nécessite une utilisation intensive du processeur, est déchargée de vos serveurs. De plus, vous n’avez pas besoin d’installer des certificats ni de configurer TLS/SSL sur vos serveurs.
Si vous avez besoin d’un chiffrement de bout en bout, Application Gateway peut déchiffrer le trafic sur la passerelle à l’aide de votre clé privée, puis le rechiffrer avec la clé publique du service exécuté dans le pool de back-ends.
Le trafic entre dans la passerelle par un port front-end. Vous pouvez ouvrir plusieurs ports, et Application Gateway peut recevoir des messages sur n’importe lequel de ces ports. La première chose que votre trafic rencontre quand il entre dans la passerelle par un port est un écouteur. L’écouteur est configuré pour écouter un nom d’hôte spécifique et un port particulier sur une adresse IP distincte. L’écouteur peut utiliser un certificat TLS/SSL pour déchiffrer le trafic qui entre dans la passerelle. L’écouteur utilise ensuite une règle que vous définissez pour diriger les demandes entrantes vers un pool de back-ends.
Le fait d’exposer votre site ou application web par le biais de la passerelle d’application signifie aussi que vous ne connectez pas directement vos serveurs au web. Vous exposez uniquement le port 80 ou le port 443 sur la passerelle applicative, qui transfert ensuite le trafic au serveur de pool de back-ends. Dans cette configuration, vos serveurs web ne sont pas directement accessibles à partir d’Internet, ce qui réduit la surface d’attaque de votre infrastructure.
Sondes d’intégrité
Les sondes d’intégrité déterminent les serveurs qui sont disponibles pour l’équilibrage de charge dans un pool de back-ends. Application Gateway utilise une sonde d’intégrité pour envoyer une requête à un serveur. Quand le serveur retourne une réponse HTTP avec un code d’état compris entre 200 et 399, le serveur est considéré comme sain. Si vous ne configurez pas de sonde d’intégrité, Application Gateway crée une sonde par défaut qui attend 30 secondes avant de déterminer qu’un serveur n’est pas disponible. Les sondes d’intégrité vérifient que le trafic n’est pas dirigé vers un point de terminaison web de pool de back-ends qui est inactif ou qui a échoué.
Mise à l’échelle automatique
Application Gateway prend en charge la mise à l’échelle automatique et peut effectuer un scale-up ou un scale-down en fonction de l’évolution des schémas de charge du trafic. La mise à l’échelle automatique vous évite aussi d’avoir à choisir une taille de déploiement ou un nombre d’instances au moment du provisionnement.
Trafic WebSocket et HTTP/2
Application Gateway prend en charge les protocoles WebSocket et HTTP/2 de manière native. Les protocoles WebSocket et HTTP/2 permettent une communication en duplex intégral entre le serveur et le client sur une connexion TCP longue. Ce type de communication est plus interactif entre le serveur web et le client et peut être bidirectionnelle sans nécessiter d’interrogations, comme c’est le cas pour les implémentations basées sur un protocole HTTP. Ces protocoles engendrent une faible surcharge (contrairement à HTTP) et peuvent réutiliser la même connexion TCP pour plusieurs requêtes/réponses, ce qui entraîne une utilisation plus efficace des ressources. Ces protocoles sont conçus pour fonctionner sur les ports HTTP traditionnels (80 et 443).