Configurer des composants Azure Application Gateway
Azure Application Gateway dispose d’une série de composants qui s’associent pour acheminer les requêtes vers un pool de serveurs web et pour vérifier l’intégrité de ces serveurs web. Ces composants incluent l’adresse IP front-end, les pools back-end, les règles d’acheminement, les sondes d’intégrité et les écouteurs. En option, la passerelle peut également implémenter un pare-feu.
Éléments à connaître concernant les composants Application Gateway
Nous allons explorer la façon dont les composants d’une passerelle applicative fonctionnent en synergie.
L’adresse IP front-end reçoit les requêtes clientes.
Un Pare-feu d’applications web facultatif vérifie le trafic entrant pour les menaces courantes avant que les requêtes atteignent les écouteurs.
Un ou plusieurs écouteurs reçoivent le trafic et acheminent les requêtes vers le pool back-end.
Les règles d’acheminement définissent comment analyser la requête pour la diriger vers le pool back-end approprié.
Un pool back-end contient des serveurs web pour des ressources telles que des machines virtuelles ou des Virtual Machine Scale Sets. Chaque pool dispose d’un équilibreur de charge pour distribuer la charge de travail entre les ressources.
Les sondes d’intégrité déterminent quels serveurs dans le pool back-end sont disponibles pour l’équilibrage de charge.
L’organigramme suivant montre comment les composants Application Gateway fonctionnent en synergie pour diriger les requêtes de trafic entre les pools front-end et back-end de votre configuration.
Adresse IP front-end
Les requêtes clientes sont reçues via votre adresse IP front-end. Votre passerelle applicative peut avoir une adresse IP publique ou privée, ou les deux. Vous ne pouvez avoir qu’une seule adresse IP publique et une seule adresse IP privée.
Pare-feu d’applications web (facultatif)
Vous pouvez activer Azure Web Application Firewall pour permettre à Azure Application Gateway de gérer les requêtes entrantes avant qu’elles n’atteignent votre écouteur. Le pare-feu vérifie dans chaque requête la présence de menaces d’après les recommandations de l’Open Web Application Security Project (OWASP). Les menaces courantes incluent l’injection SQL, le scripting inter-site, l’injection de commandes, le trafic de requêtes HTTP et le fractionnement de réponse, et l’inclusion de fichiers distants. D’autres menaces peuvent provenir des bots, des crawlers, des scanneurs et des violations et anomalies du 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. Azure Web Application Firewall prend en charge deux ensembles de règles : CRS 2.2.9 et CRS 3.0. CRS 3.0 est celui par défaut et le plus récent des deux. 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.
Écouteurs
Les écouteurs acceptent le trafic arrivant sur une combinaison spécifiée de protocole, port, hôte et adresse IP. Chaque écouteur achemine les requêtes vers un pool back-end de serveurs en fonction de vos règles d’acheminement. 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 acheminer 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 d’acheminement lie vos écouteurs aux pools back-end. Une règle spécifie comment interpréter les éléments hostname et path de l’URL d’une requête, puis 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é.
Pools de back-ends
Un pool de back-ends référence une collection de serveurs web. Lors de la configuration du pool, vous fournissez l’adresse IP de chaque serveur web et le port sur lequel il écoute les requêtes. Chaque pool peut spécifier un ensemble fixe de machines virtuelles, de Virtual Machine Scale Sets, 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.
Sondes d’intégrité
Les sondes d’intégrité déterminent les serveurs dans votre pool back-end qui sont disponibles pour l’équilibrage de charge. 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 d’identifier un serveur comme indisponible (non sain).