Intégration d’Application Gateway

Article
10/20/2023

Trois variantes d’Azure App Service nécessitent une configuration légèrement différente de l’intégration avec Azure Application Gateway. Les variantes incluent App Service standard (également appelé multitenant), un environnement App Service d’équilibreur de charge interne (ILB) et un environnement App Service Environment externe.

Cet article explique comment configurer Application Gateway avec App Service (multitenant) en utilisant des points de terminaison de service pour sécuriser le trafic. L’article aborde également les considérations liées à l’utilisation de points de terminaison privés et à l’intégration avec ILB et les environnements App Service Environment externes. Enfin, l’article décrit comment définir des restrictions d’accès sur un site Source Control Manager (SCM).

Intégration à App Service (multilocataire)

App Service (multitenant) dispose d’un point de terminaison public accessible sur Internet. En utilisant des points de terminaison de service, vous pouvez autoriser le trafic provenant uniquement d’un sous-réseau spécifique au sein d’un réseau virtuel Azure, puis bloquer tout le reste. Dans le scénario suivant, vous utilisez cette fonctionnalité pour garantir qu’une instance App Service peut recevoir le trafic provenant uniquement d’une passerelle applicative spécifique.

Diagram that shows the internet flowing to an application gateway in an Azure virtual network and then flowing through a firewall icon to instances of apps in App Service.

Cette configuration comporte deux parties, outre la création de l’instance App Service et de la passerelle applicative. La première partie consiste à activer les points de terminaison de service dans le sous-réseau du réseau virtuel où la passerelle applicative est déployée. Les points de terminaison de service garantissent que tout le trafic réseau quittant le sous-réseau vers App Service est balisé avec l’ID de sous-réseau spécifique.

La deuxième partie consiste à définir une restriction d’accès sur 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 configurer la restriction d’accès à l’aide de différents outils, selon vos préférences.

Configurer les services à l’aide du Portail Azure

Avec le Portail Azure, vous suivez quatre étapes pour créer, puis configurer App Service et Application Gateway. Si vous disposez de ressources existantes, vous pouvez ignorer les premières étapes.

Créez une instance App Service à l’aide de l’un des démarrages rapides de la documentation App Service. Le démarrage rapide de .NET Core constitue un exemple.
Créez une passerelle applicative à l’aide du démarrage rapide du portail, mais ignorez la section sur l’ajout de cibles back-end.
Configurez App Service en tant que back end dans Application Gateway mais ignorez la section sur la restriction de l’accès.
Créez la restriction d’accès à l’aide de points de terminaison de service.

Vous pouvez maintenant accéder à App Service via Application Gateway. Si vous essayez d’accéder directement à App Service, le système affiche normalement une erreur HTTP 403 indiquant que l’application web a bloqué votre accès.

Screenshot shows the text of Error 403 - Forbidden.

Configurer des services à l’aide d’un modèle Azure Resource Manager

Le modèle de déploiement Azure Resource Manager crée un scénario complet. Le scénario consiste en une instance App Service verrouillée avec des points de terminaison de service et une restriction d’accès pour recevoir le trafic uniquement depuis Application Gateway. Le modèle comprend de nombreuses valeurs par défaut intelligentes et de nombreux suffixes uniques ajoutés aux noms de ressources pour rester simple. 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 dans la description du modèle. Vous pouvez également utiliser le code PowerShell ou Azure CLI approprié.

Configurer les services à l’aide d’Azure CLI

L’échantillon Azure CLI crée une instance App Service verrouillée avec des points de terminaison de service et une restriction d’accès pour recevoir le trafic uniquement depuis Application Gateway. Si vous devez uniquement isoler le trafic vers une instance App Service existante depuis une passerelle applicative existante, utilisez la commande suivante :

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 garantit la configuration du point de terminaison de service dans le sous-réseau et la restriction d’accès dans App Service.

Considérations relatives à l’utilisation de points de terminaison privés

Au lieu des points de terminaison de service, vous pouvez utiliser des points de terminaison privés pour sécuriser le trafic entre Application Gateway et App Service (multitenant). Vous devez vérifier qu’Application Gateway peut utiliser DNS pour résoudre l’adresse IP privée des applications App Service. Vous pouvez également utiliser l’adresse IP privée dans le pool principal, puis substituer le nom d’hôte dans les paramètres HTTP.

Diagram that shows traffic flowing to an application gateway in an Azure virtual network and then flowing through a private endpoint to instances of apps in App Service.

Application Gateway met en cache les résultats de la recherche DNS. Si vous utilisez des noms de domaine complets (FQDN) et que vous comptez sur la recherche DNS pour obtenir l’adresse IP privée, vous devrez peut-être redémarrer la passerelle applicative si la mise à jour DNS ou le lien vers une zone DNS privée Azure s’est produit après la configuration du pool back-end.

Pour redémarrer la passerelle applicative, arrêtez-la, puis démarrez-la à l’aide d’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 à un environnement App Service Environment ILB

Un environnement App Service Environment ILB n’est pas exposé à Internet. Le trafic entre l’instance et une passerelle applicative est déjà isolé du réseau virtuel. Pour configurer un environnement App Service ILB, puis l’intégrer à une passerelle applicative à l’aide du Portail Microsoft Azure, consultez le guide pratique.

Si vous souhaitez vérifier que seul le trafic du sous-réseau Application Gateway atteint App Service Environment, vous pouvez configurer un groupe de sécurité réseau (NSG) qui affecte toutes les applications web dans App Service Environment. Pour le NSG, vous pouvez spécifier la plage IP du sous-réseau et éventuellement les ports (80/443). Pour qu’App Service Environment fonctionne correctement, veillez à ne pas substituer les règles NSG requises.

Pour isoler le trafic vers une application web individuelle, vous devez utiliser des restrictions d’accès basées sur IP, car les points de terminaison de service ne fonctionnent pas avec un environnement App Service Environment. L’adresse IP doit être l’adresse IP privée de la passerelle applicative.

Considérations relatives à un environnement App Service Environment externe

Un environnement App Service Environment externe dispose d’un équilibreur de charge public comme App Service multitenant. Les points de terminaison de service ne fonctionnent pas pour un environnement App Service Environment. Vous devez donc utiliser des restrictions d’accès basées sur IP à l’aide de l’adresse IP publique de la passerelle applicative. Pour créer un environnement App Service Environment externe à l’aide du Portail Azure, vous pouvez suivre ce démarrage rapide.

Considérations relatives à un site Kudu/SCM

Le site SCM, également connu sous le nom de Kudu, est un site administrateur qui existe pour chaque application web. Il n’est pas possible d’utiliser un proxy inverse pour le site SCM. Vous souhaiterez probablement également le verrouiller sur des adresses IP individuelles ou sur 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 via la commande suivante :

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

Si vous souhaitez ajouter des restrictions d’accès individuelles au site GDS, vous pouvez utiliser l’indicateur --scm-site :

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

Considérations relatives à l’utilisation du domaine par défaut

La configuration d’Application Gateway pour substituer le nom d’hôte, puis utiliser le domaine par défaut d’App Service (généralement azurewebsites.net) constitue le moyen le plus simple de configurer l’intégration. Cela ne nécessite pas la configuration d’un domaine personnalisé et d’un certificat dans App Service.

Cet article traite des considérations générales relatives au remplacement du nom d’hôte d’origine. Dans App Service, il existe deux scénarios dans lesquels vous devez faire attention à cette configuration.

Authentification

Lorsque vous utilisez la fonctionnalité d’authentification dans App Service (également connue sous le nom d’Easy Auth), votre application renvoie généralement à la page de connexion. Étant donné qu’App Service ne connaît pas le nom d’hôte d’origine de la requête, la redirection est effectuée sur le nom de domaine par défaut et entraîne généralement une erreur.

Pour contourner la redirection par défaut, vous pouvez configurer l’authentification pour inspecter un en-tête transféré, puis adapter le domaine de redirection au domaine d’origine. Application Gateway utilise un en-tête appelé X-Original-Host. En utilisant la configuration basée sur des fichiers pour configurer l’authentification, vous pouvez configurer App Service pour l’adapter au nom d’hôte d’origine. Ajoutez cette configuration à votre fichier de configuration :

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

Affinité ARR

Dans les déploiements à plusieurs instances, l’affinité ARR garantit que les demandes des clients sont acheminées vers la même instance pendant toute la durée de vie de la session. L’affinité ARR ne fonctionne pas avec les remplacements de nom d’hôte. Pour que l’affinité de session fonctionne, vous devez configurer un domaine personnalisé et un certificat identiques dans App Service et dans Application Gateway et ne pas remplacer le nom d’hôte.

Étapes suivantes

Si vous souhaitez en savoir plus sur les environnements App Service Environment, veuillez consulter la 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 Azure Web Application Firewall.

Pour déployer un site sécurisé et résilient avec un domaine personnalisé sur App Service à l’aide d’Azure Front Door ou d’Application Gateway, veuillez consulter ce didacticiel.

Partager via