Création et configuration d’une instance Application Gateway
Application Gateway comprend plusieurs composants qui s’associent pour router les requêtes vers un pool de serveurs web et pour vérifier l’intégrité de ces serveurs. Nous allons voir comment ces composants sont liés et quel rôle ils jouent dans Application Gateway.
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 plus qu’une adresse IP publique et une adresse IP privée.
É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 acheminer les requêtes à l’aide de l’élément hostname de l’URL.
Les écouteurs gèrent également des certificats 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, puis comment diriger la requête vers le pool de back-end approprié. Une règle de routage est également associée à un ensemble de paramètres HTTP. Ces paramètres indiquent si le trafic est chiffré entre Application Gateway et les serveurs back-end (et si oui, de quelle manière) ainsi que d’autres informations de configuration telles que :
- Le protocole (HTTP ou HTTPS)
- L’adhérence des sessions, pour passer toutes les requêtes d’une session cliente au même serveur web, plutôt que de les répartir entre les serveurs avec l’équilibrage de charge
- Le drainage de connexion pour que les serveurs d’un pool de back-end puissent être supprimés sans perte de données.
- Le délai d’expiration des requêtes, en secondes
- Les sondes d’intégrité, qui spécifient une URL de sonde, les délais d’expiration et autres paramètres utilisés pour déterminer si un serveur du pool de back-end est disponible.
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, 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.
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’Open Web Application Security Project. Il s’agit, entre autres, des suivantes :
- Injection de code SQL
- Attaque par scripts intersites (XSS)
- Injection de commandes
- Attaque par dissimulation de requête HTTP
- Attaque par fractionnement de réponse HTTP
- Attaque par inclusion de fichier distant
- Bots, robots de recherche et scanneurs
- Anomalies et violations du protocole HTTP
OWASP a défini un ensemble de règles génériques pour détecter les attaques appelées Core Rule Set (CRS). Ces ensembles de règles font l’objet de modifications constantes afin de répondre aux attaques de plus en plus sophistiquées. Le pare-feu d’applications web 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.
Pour activer le pare-feu d’applications web dans Application Gateway, vous devez sélectionner le niveau WAF lorsque vous créez la passerelle.
Sondes d’intégrité
Les sondes d’intégrité sont importantes, car elles aident l’équilibreur de charge à déterminer quels serveurs sont disponibles pour l’équilibrage de charge au sein d’un pool de back-end. Application Gateway utilise une sonde d’intégrité pour envoyer une requête à un serveur. Si 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.
Configuration réseau pour Application Gateway
Application Gateway doit s’exécuter dans un réseau virtuel. Avant de configurer Application Gateway, vous devez créer ce réseau virtuel ainsi qu’un sous-réseau dédié. Application Gateway utilise plusieurs adresses privées pour une utilisation interne et pour communiquer avec chaque instance en cas de scale-out de la passerelle. Par exemple, si vous prévoyez d’effectuer un scale-out afin d’obtenir quatre instances, créez un sous-réseau de taille /28. Si vous prévoyez un scale-out de plus grande échelle, créez un sous-réseau plus grand.
Vous pouvez exposer Application Gateway à travers une adresse IP publique ou faire en sorte qu’elle reste privée en lui attribuant uniquement une adresse IP privée à l’intérieur du réseau virtuel. Ceci est utile si vous souhaitez que vos sites internes utilisent Application Gateway à des fins d’équilibrage de charge.
Options Application Gateway
Vous pouvez créer une instance Application Gateway dans le niveau Standard et le niveau WAF. Vous pouvez également choisir parmi trois tailles ayant différents niveaux de performances et de scalabilité, et différents tarifs : Petit, Moyen et Grand.
Les niveaux Standard et WAF sont disponibles en deux versions : V1 et V2. La version V2 prend en charge les zones de disponibilité Azure, mais il s’agit d’une préversion.
Application Gateway prend en charge la mise à l’échelle manuelle et automatique. Si vous sélectionnez la mise à l’échelle automatique, Application Gateway effectuera un scale-out ou un scale-in automatiquement, en fonction du trafic des applications. Vous pouvez limiter le nombre minimal et maximal d’instances Application Gateway.
Créer et configurer une passerelle
Vous pouvez créer et configurer une instance Application Gateway à l’aide du portail Azure, d’Azure PowerShell ou de l’interface Azure CLI. Pour Azure CLI, nous allons utiliser la commande az network application-gateway create pour créer une passerelle. Si vous préférez PowerShell, vous pouvez utiliser l’applet de commande New-AzApplicationGateway. Vous pouvez également utiliser le portail Azure pour effectuer la plupart des opérations.
Vous pouvez examiner et modifier la configuration des composants d’une passerelle en utilisant les commandes az network application-gateway http-listener, az network application-gateway rule, az network application-gateway address-pool, az network application-gateway http-settings et az network application-gateway front-end-port à partir d’Azure CLI. La série d’applets de commande Get-AzApplicationGateway* et Set-AzApplicationGateway* fournit les mêmes opérations pour PowerShell.
Nous allons créer et configurer une instance Application Gateway pour les sites web du service Véhicules que nous avons déployés.