Intégration d’Application Gateway

Article
01/10/2025

Cet article explique comment configurer Application Gateway avec App Service en utilisant des points de terminaison privés 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 les environnements App Service internes et externes. Enfin, l’article décrit comment définir des restrictions d’accès sur un site Source Control Manager (SCM).

Intégration avec App Service

Vous pouvez utiliser des points de terminaison privés pour sécuriser le trafic entre Application Gateway et votre application App Service. 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.

Diagramme qui montre le trafic circulant vers une passerelle d’application passant par 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. 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

En savoir plus sur la configuration d'une application App Service avec un point de terminaison privé.

Considérations pour l’utilisation des points de terminaison de service

Au lieu des points de terminaison privés, vous pouvez utiliser des points de terminaison de service pour sécuriser le trafic depuis Application Gateway. 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.

Diagramme qui montre qu’Internet circule vers une passerelle d’application dans un réseau virtuel Azure, puis traverse une icône de pare-feu vers des instances d’applications dans App Service.

Cette configuration comporte deux parties, outre la création de l’instance d’application 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.

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 bloque votre accès.

Capture d’écran montrant le texte Erreur 403 : Interdit.

Considérations relatives à un environnement App Service Environment interne

Un environnement App Service Environment interne 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 interne, 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 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 les applications App Service multi-tenant. Les points de terminaison de service ne fonctionnent pas pour un environnement App Service Environment. Avec App Service Environment, vous pouvez 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.

Vous pouvez également ajouter des points de terminaison privés à des applications hébergées sur un environnement de services applicatifs externe.

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é de session

Dans les déploiements à plusieurs instances, l’affinité de session 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é de session peut être configurée pour adapter le domaine de cookie à l’en-tête entrant à partir du proxy inverse. En configurant le proxy d’affinité de session sur true, l’affinité de session recherche X-Original-Host ou X-Forwarded-Host et adapte le domaine de cookie au domaine trouvé dans cet en-tête. Pour l’activation du proxy d’affinité de session, nous vous recommandons de configurer vos restrictions d’accès sur le site pour vous assurer que le trafic provient de votre proxy inverse.

Vous pouvez également configurer clientAffinityProxyEnabled à l’aide de la commande suivante :

az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

É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