Intégration d’Application Gateway

Il existe trois variantes d’App Service qui nécessitent une configuration légèrement différente de l’intégration avec Azure Application Gateway. Les variantes incluent la version standard d’App Service, également appelée multilocataire, l’environnement App Service Environment (ASE) Load Balancer (ILB) interne et l’environnement App Service Environment externe. Cet article explique comment le configurer avec App Service (multilocataire) à l’aide du point de terminaison de service pour sécuriser le trafic. L’article aborde également les considérations relatives à l’utilisation d’un point de terminaison privé et à l’intégration avec ILB et l’environnement App Service Environment externe. Enfin, l’article présente des considérations sur le site SCM/Kudu.

Intégration à App Service (multilocataire)

App Service (multilocataire) dispose d’un point de terminaison public accessible sur Internet. À l’aide des points de terminaison de service, vous pouvez autoriser le trafic uniquement à partir d’un sous-réseau spécifique au sein d’un réseau virtuel Azure et bloquer tout le reste. Dans le scénario suivant, nous allons utiliser cette fonctionnalité pour nous assurer qu’une instance App Service peut uniquement recevoir le trafic d’une instance Application Gateway spécifique.

Diagramme montrant le flux Internet qui se dirige vers une passerelle applicative dans un réseau virtuel Azure et, de là, traverse une icône de pare-feu pour continuer vers des instances d’applications dans App Service.

Cette configuration comprend deux parties, en plus de la création des instances App Service et Application Gateway. La première partie consiste à activer des points de terminaison de service dans le sous-réseau du réseau virtuel sur lequel Application Gateway est déployé. Les points de terminaison de service garantissent que tout le trafic qui quitte le sous-réseau vers App Service sera marqué avec l’ID spécifique du sous-réseau. La deuxième partie consiste à définir une restriction d’accès de l’application web spécifique pour garantir que seul le trafic marqué avec cet ID de sous-réseau spécifique est autorisé. Vous pouvez le configurer à l’aide de différents outils, selon vos préférences.

En passant par le portail Azure

Avec Portail Azure, vous suivez quatre étapes pour approvisionner et configurer l’installation. Si vous disposez de ressources existantes, vous pouvez ignorer les premières étapes.

  1. Créez une instance App Service à l’aide de l’un des guides de démarrage rapide dans la documentation d’App Service, par exemple Guide de démarrage rapide .NET Core.
  2. Créez une instance Application Gateway à l’aide du portail Démarrage rapide, mais ignorez la section Ajouter des cibles de serveur principal.
  3. Configurez App Service en tant que serveur principal dans Application Gateway, mais ignorez la section Restreindre l’accès.
  4. Enfin, créez la restriction d’accès à l’aide de points de terminaison de service.

Vous pouvez maintenant accéder au App Service via Application Gateway, mais si vous essayez d’y accéder directement, vous devriez recevoir une erreur HTTP 403 indiquant que le site web est arrêté.

Capture d’écran montrant le texte d’une erreur 403 – Interdit.

Utilisation d’un modèle Azure Resource Manager

Le modèle de déploiement Resource Manager fournira un scénario complet. Le scénario se compose d’une instance App Service verrouillée par des points de terminaison de service et une restriction d’accès pour recevoir uniquement le trafic provenant d’Application Gateway. Le modèle comprend de nombreuses valeurs Smart Defaults et des suffixes uniques ajoutés aux noms des ressources pour qu’ils soient simples. Pour les remplacer, vous devez cloner le référentiel ou télécharger le modèle pour le modifier.

Pour appliquer le modèle, vous pouvez utiliser le bouton Déployer sur Azure figurant dans la description du modèle, ou vous pouvez utiliser l’outil PowerShell/CLI approprié.

Utilisation de l’interface de ligne de commande Azure

L’exemple de l’interface de ligne de commande Azure configurera une instance App Service verrouillée par des points de terminaison de service et une restriction d’accès pour recevoir uniquement le trafic provenant d’Application Gateway. Si vous devez uniquement isoler le trafic vers une instance App Service existante et provenant d’une instance Application Gateway existante, la commande suivante suffit.

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

Dans la configuration par défaut, la commande vérifie à la fois le paramétrage de la configuration du point de terminaison de service dans le sous-réseau et la restriction d’accès dans l’App Service.

Considérations relatives à l’utilisation d’un point de terminaison privé

Comme alternative au point de terminaison de service, vous pouvez utiliser un point de terminaison privé pour sécuriser le trafic entre Application Gateway et App Service (multilocataire). Vous devez vous assurer qu’Application Gateway peut résoudre par DNS l’adresse IP privée des applications App Service ou que vous utilisez l’adresse IP privée dans le pool back-end et que vous remplacez le nom d’hôte dans les paramètres http.

Diagramme montrant le trafic dirigé vers une passerelle applicative dans un réseau virtuel Azure et, de là, traversant un point de terminaison privé vers des instances d’applications dans App Service

Application Gateway met en cache les résultats de la recherche DNS. Par conséquent, si vous utilisez des noms de domaine complets et que vous comptez sur la recherche DNS pour obtenir l’adresse IP privée, vous devrez peut-être redémarrer Application Gateway si la mise à jour DNS ou la liaison avec la zone DNS privée Azure a été effectuée après la configuration du pool principal. Pour redémarrer Application Gateway, vous devez démarrer et arrêter l’instance. Pour ce faire, utilisez Azure CLI :

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

Considérations relatives à ASE ILB

L’environnement App Service Environment ILB n’est pas exposé à Internet et le trafic entre l’instance et une passerelle Application Gateway est donc déjà isolé dans le réseau virtuel. Le guide pratique suivant configure un environnement App Service Environment ILB et l’intègre à une passerelle Application Gateway à l’aide du portail Azure.

Si vous souhaitez vous assurer que seul le trafic provenant du sous-réseau Application Gateway atteint l’environnement App Service Environment, vous pouvez configurer un groupe de sécurité réseau (NSG) qui affecte toutes les applications web de cet environnement. Pour le NSG, vous pouvez spécifier la plage d’adresses IP du sous-réseau et éventuellement les ports (80/443). Veillez à ne pas remplacer les règles NSG nécessaires au bon fonctionnement de l’environnement App Service Environment.

Pour isoler le trafic à une application web individuelle, vous devez utiliser des restrictions d’accès basées sur l’adresse IP, car les points de terminaison de service ne fonctionneront pas pour ASE. L’adresse IP doit être l’adresse IP privée de l’instance Application Gateway.

Considérations relatives à ASE externe

L’environnement App Service Environment externe dispose d’un équilibreur de charge public, comme App Service multilocataire. Les points de terminaison de service ne fonctionnent pas pour l’environnement App Service Environment. Vous devez donc appliquer des restrictions d’accès basées sur l’adresse IP en utilisant l’adresse IP publique de l’instance Application Gateway. Pour créer un environnement App Service Environment externe à l’aide du portail Azure, vous pouvez suivre ce guide de démarrage rapide.

Considérations relatives au site kudu/scm

Le site scm, également appelé kudu, est un site d’administration qui existe pour chaque application web. Il n’est pas possible d’inverser le proxy du site scm et il est fort probable que vous souhaitiez également le verrouiller à des adresses IP individuelles ou à un sous-réseau spécifique.

Si vous souhaitez utiliser les mêmes restrictions d’accès que le site principal, vous pouvez hériter des paramètres à l’aide de la commande suivante.

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

Si vous souhaitez définir des restrictions d’accès individuelles pour le site scm, vous pouvez ajouter des restrictions d’accès à l’aide de l’indicateur --scm-site comme indiqué ci-dessous.

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Étapes suivantes

Pour plus d’informations sur App Service Environment, consultez Documentation sur App Service Environment.

Pour renforcer la sécurité de votre application web, vous trouverez des informations relatives au pare-feu d’applications web sur Application Gateway dans la documentation du pare-feu d’applications web Azure.