Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
Introduction
Historiquement, les références SKU Application Gateway v2 et, dans une certaine mesure, v1, requièrent l’IP publique pour permettre la gestion du service. Cette exigence a imposé plusieurs limitations lors de l’utilisation de contrôles précis dans les groupes de sécurité réseau et les tables de routage. Plus précisément, les défis suivantes ont été observés :
- Tous les déploiements Application Gateways v2 doivent contenir une configuration IP front-end publique pour permettre la communication avec l’étiquette de service Gestionnaire de passerelle.
- Les associations de groupes de sécurité réseau nécessitent des règles pour autoriser l’accès entrant à partir du GatewayManager et de l’accès sortant à Internet.
- Lors de l’introduction d’un itinéraire par défaut (0.0.0.0/0) pour transférer le trafic n’importe où autre que l’Internet, les métriques, l’analyse et les mises à jour de la passerelle entraînent un échec de l’état.
Application Gateway v2 peut désormais traiter chacun de ces éléments afin d’éliminer davantage les risques d’exfiltration de données et de contrôler la confidentialité des communications à partir du réseau virtuel. Ces modifications incluent notamment les fonctionnalités suivantes :
- Adresse IP privée uniquement en configuration IP front-end
- Pas de ressource d’adresse IP publique nécessaire
- Élimination du trafic entrant à partir de l’étiquette de service GatewayManager via le groupe de sécurité réseau
- Possibilité de définir une règle de groupe de sécurité réseau sortant (NSG)Tout refuser pour restreindre le trafic de sortie à Internet
- Possibilité de remplacer l’itinéraire par défaut vers Internet (0.0.0.0/0)
- Résolution DNS via des résolveurs définis sur le réseau virtuel En savoir plus, y compris les zones DNS privées de liaison privée.
Chacune de ces fonctionnalités peut être configurée indépendamment. Par exemple, une adresse IP publique peut être utilisée pour autoriser le trafic entrant depuis Internet et vous pouvez définir une règle de trafic sortantTout refuser dans la configuration du groupe de sécurité réseau pour empêcher l’exfiltration des données.
À bord de la fonctionnalité
Les nouveaux contrôles pour la configuration frontale IP privée, la gestion des règles de groupe de sécurité réseau et la configuration de table de routage sont généralement disponibles et pris en charge en production. Pour utiliser ces fonctionnalités, vous devez choisir l’expérience à l’aide du portail Azure, de PowerShell, de l’interface CLI ou de l’API REST. Ce mécanisme d’opt-in offre également une flexibilité si vous devez revenir à la fonctionnalité Application Gateway traditionnelle si nécessaire (par exemple, pour activer Private Link).
Une fois inscrites, toutes les nouvelles passerelles Application Gateway permettent de définir une combinaison de groupe de sécurité réseau, de table de route ou de fonctionnalités de configuration d’adresse IP privée. Si vous souhaitez désactiver la nouvelle fonctionnalité, vous pouvez le faire en annulant l’inscription de la fonctionnalité.
Conseil / Astuce
Les passerelles fonctionnent à l’aide des fonctionnalités disponibles au moment où elles sont approvisionnées. Si vous annulez l’inscription à partir de la fonctionnalité, les passerelles existantes continuent à fonctionner avec les fonctionnalités qui ont été activées lors de leur création.
Inscrire la fonctionnalité
Note
Dans l’expérience du portail Azure, le processus d’inscription des fonctionnalités est étiqueté comme préversion ; Toutefois, cette expérience est en disponibilité générale, entièrement prise en charge pour les charges de travail de production et couvertes par les contrats SLA Application Gateway publiés.
Suivez les étapes suivantes pour vous inscrire à la fonctionnalité des contrôles réseau Application Gateway améliorés via le Portail Microsoft Azure :
Connectez-vous au portail Azure.
Dans la zone de recherche, entrez abonnements et sélectionnez Abonnements.
Sélectionnez le lien pour le nom de votre abonnement.
Dans le menu de gauche, sous Paramètres, sélectionnez Fonctionnalités d’évaluation.
La liste des fonctionnalités et de l’état actuel de l’inscription s’affiche.
À partir de fonctionnalités d’aperçu tapez dans la zone de filtre EnableApplicationGatewayNetworkIsolation, cochez la fonctionnalité, puis cliquez sur Inscrire.
Note
L’inscription d’une fonctionnalité peut prendre jusqu’à 30 minutes pour passer de l’état Inscription à Inscrit.
Désenregistrer la fonctionnalité
Pour désactiver la fonctionnalité des contrôles réseau améliorés de la passerelle d'application via le portail, procédez comme suit :
Connectez-vous au portail Azure.
Dans la zone de recherche, entrez abonnements et sélectionnez Abonnements.
Sélectionnez le lien pour le nom de votre abonnement.
Dans le menu de gauche, sous Paramètres, sélectionnez Fonctionnalités d’évaluation.
La liste des fonctionnalités et de l’état actuel de l’inscription s’affiche.
À partir de fonctionnalités d’aperçu tapez dans la zone de filtre EnableApplicationGatewayNetworkIsolation, cochez la fonctionnalité, puis cliquez sur Désinscrire.
Configuration des contrôles réseau
Après avoir enregistré la fonctionnalité, la configuration du NSG, de la table de routage et de l'adresse IP privée du frontend peut être effectuée à l'aide de n'importe quelle méthode. Par exemple : API REST, modèle ARM, déploiement Bicep, Terraform, PowerShell, CLI ou Portail.
Note
Si votre application cliente se connecte à App Gateway via une adresse IP privée, nécessite un délai d’inactivité supérieur > à 4 minutes et que l’application cliente n’envoie pas de paquets TCP keep-alive, contactez-le appgw-idle-timeout@microsoft.com pour demander l’initiation de keep-alive à partir d’Application Gateway.
Sous-réseau d’Application Gateway
Le sous-réseau Application Gateway est l’espace désigné au sein du réseau virtuel où les ressources Application Gateway seront déployées. Dans la configuration des adresses IP privées frontales, il est important que ce sous-réseau puisse accéder de manière privée aux ressources qui demandent la connexion à votre application ou site exposé.
Note
Depuis le 5 mai 2025, les déploiements nouveaux et existants d’Application Gateway privé nécessitent la délégation de sous-réseau vers Microsoft.Network/applicationGateways.
Suivez ces étapes pour configurer la délégation de sous-réseau.
Connectivité Internet sortante
Les déploiements Application Gateway qui contiennent uniquement une configuration d’IP front-end privée (et aucune configuration d’IP front-end publique associée à une règle d’acheminement de requête) ne sont pas en mesure d’envoyer le trafic de sortie destiné à Internet. Cette configuration affecte la communication avec les cibles back-end accessibles publiquement via Internet.
Pour activer la connectivité sortante à partir de votre passerelle Application Gateway vers une cible back-end accessible sur Internet, vous pouvez utiliser le service NAT de réseau virtuel ou transférer le trafic vers une appliance virtuelle qui a accès à Internet.
Le service NAT de réseau virtuel offre un contrôle sur l’adresse IP ou le préfixe à utiliser, ainsi que sur le délai d’inactivité configurable. Pour le configurer, créez une passerelle NAT Gateway avec une adresse IP publique ou un préfixe public et associez-la au sous-réseau contenant Application Gateway.
Si une appliance virtuelle est requise pour la sortie Internet, consultez la section Contrôle de table de routage de ce document.
Scénarios courants où l’utilisation de l’adresse IP publique est requise :
- Communication vers le coffre de clés sans utiliser de points de terminaison privés ou de points de terminaison de service
- La communication sortante n’est pas requise pour les fichiers pfx chargés directement sur Application Gateway
- Communication avec les cibles back-end via Internet
- Communication vers la liste de révocation de certificats ou les points de terminaison OCSP accessibles sur Internet
Contrôle des groupes de sécurité réseau
Les groupes de sécurité réseau associés à un sous-réseau Application Gateway ne nécessitent plus de règles de trafic entrant pour GatewayManager et ne nécessitent pas d’accès sortant à Internet. La seule règle requise est Autoriser le trafic entrant à partir d’AzureLoadBalancer pour garantir que les sondes d’intégrité peuvent atteindre la passerelle.
La configuration suivante est un exemple de l’ensemble de règles de trafic entrant le plus restrictif, refusant tout le trafic sauf les sondes d’intégrité Azure. Outre les règles définies, des règles explicites sont définies pour permettre au trafic client d’atteindre l’écouteur de la passerelle.
Note
Application Gateway affiche une alerte demandant de s’assurer que la règle Autoriser LoadBalanceRule est spécifiée si une règle DenyAll limite par inadvertance l’accès aux sondes d’intégrité.
Exemple de scénario
Cet exemple décrit la création d’un groupe de sécurité réseau à l’aide du portail Microsoft Azure avec les règles suivantes :
- Autoriser le trafic entrant vers le port 80 et 8080 vers Application Gateway à partir des demandes clientes provenant d’Internet
- Refuser tout autre trafic entrant
- Autoriser le trafic sortant vers une cible back-end dans un autre réseau virtuel
- Autoriser le trafic sortant vers une cible back-end accessible par Internet
- Refuser tout autre trafic sortant
Tout d’abord, créez un groupe de sécurité réseau. Ce groupe de sécurité contient vos règles de trafic entrant et sortant.
Règles de trafic entrant
Trois règles de trafic entrant par défaut sont déjà approvisionnées dans le groupe de sécurité. Voir l’exemple suivant :
Ensuite, créez les quatre nouvelles règles de sécurité entrantes suivantes :
- Autoriser le port entrant 80, le tcp, à partir d’Internet (n’importe lequel)
- Autoriser le port entrant 8080, le tcp, à partir d’Internet (n’importe lequel)
- Autoriser le trafic entrant à partir d’AzureLoadBalancer
- Refuser tout trafic entrant
Pour créer ces règles :
- Sélectionnez Règles de sécurité de trafic entrant
- Sélectionnez Ajouter
- Ajoutez les informations suivantes pour chaque règle dans le volet Ajouter une règle de sécurité de trafic entrant.
- Lorsque vous avez entré les informations, sélectionnez Ajouter pour créer la règle.
- La création de chaque règle prend un moment.
| Règle n° | Source | Balise du service source | Plages de ports sources | Destination | Service | Plages de ports dest | Protocol | Action | Priority | Name |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Any | * | Any | HTTP | 80 | TCP | Allow | 1028 | AllowWeb | |
| 2 | Any | * | Any | Custom | 8080 | TCP | Allow | 1029 | AllowWeb8080 | |
| 3 | Identifiant de service | AzureLoadBalancer | * | Any | Custom | * | Any | Allow | 1045 | AllowLB |
| 4 | Any | * | Any | Custom | * | Any | Deny | 4095 | DenyAllInbound |
Sélectionnez Actualiser pour passer en revue toutes les règles lorsque l’approvisionnement est terminé.
Règles de trafic sortant
Trois règles de trafic sortant par défaut avec la priorité 65000, 65001 et 65500 sont déjà configurées.
Créez les trois nouvelles règles de sécurité de trafic sortant suivantes :
- Autoriser TCP 443 de 10.10.4.0/24 à la cible back-end 203.0.113.1
- Autoriser TCP 80 de la source 10.10.4.0/24 à destination 10.13.0.4
- Refuser toutes les règles de trafic
Ces règles se voient attribuer une priorité de 400, 401 et 4096, respectivement.
Note
- 10.10.4.0/24 est l’espace d’adressage du sous-réseau Application Gateway.
- 10.13.0.4 est une machine virtuelle dans un réseau virtuel appairé.
- 203.0.113.1 est une machine virtuelle cible back-end.
Pour créer ces règles :
- Sélectionnez Règles de sécurité de trafic sortant
- Sélectionnez Ajouter
- Ajoutez les informations suivantes pour chaque règle dans le volet Ajouter une règle de sécurité de trafic sortant.
- Lorsque vous avez entré les informations, sélectionnez Ajouter pour créer la règle.
- La création de chaque règle prend un moment.
| Règle n° | Source | Adresses IP sources/plages CIDR | Plages de ports sources | Destination | Plages d’adresses IP/CIDR de destination | Service | Plages de ports dest | Protocol | Action | Priority | Name |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Adresses IP | 10.10.4.0/24 | * | Adresses IP | 203.0.113.1 | HTTPS | 443 | TCP | Allow | 400 | AllowToBackendTarget |
| 2 | Adresses IP | 10.10.4.0/24 | * | Adresses IP | 10.13.0.4 | HTTP | 80 | TCP | Allow | 401 | AllowToPeeredVnetVM |
| 3 | Any | * | Any | Custom | * | Any | Deny | 4096 | DenyAll |
Sélectionnez Actualiser pour passer en revue toutes les règles lorsque l’approvisionnement est terminé.
Associer un groupe NSG à un sous-réseau
La dernière étape consiste à associer le groupe de sécurité réseau au sous-réseau qui contient votre Application Gateway.
Result:
Important
Soyez prudent lorsque vous définissez les règles DenyAll , car vous risquez de refuser par inadvertance le trafic entrant des clients auxquels vous voulez autoriser l’accès. Vous pourriez également refuser par inadvertance le trafic sortant vers la cible back-end, ce qui entraînerait l’échec de l’intégrité du serveur principal et produirait des réponses 5XX.
Contrôle de Table de routage
Dans l’offre actuelle d’Application Gateway, l’association d’une table de routage avec une règle (ou la création d’une règle) définie comme 0.0.0.0.0/0 avec un tronçon suivant en tant qu’appliance virtuelle n’est pas prise en charge pour garantir la gestion appropriée d’Application Gateway.
Après l'enregistrement de la fonctionnalité, la possibilité de transférer le trafic vers une appliance virtuelle est désormais possible via la définition d'une règle de table de routage qui définit 0.0.0.0/0 avec un saut suivant vers l'appliance virtuelle.
Le tunneling forcé ou l’apprentissage de la route 0.0.0.0/0 via la publicité BGP n’affecte pas l’intégrité d’Application Gateway et est honoré pour le flux de trafic. Ce scénario peut être applicable lors de l’utilisation d’un VPN, d’ExpressRoute, d’un serveur de routes, ou d’Azure Virtual WAN.
Exemple de scénario
Dans l’exemple suivant, nous créons une table de routage et l’associons au sous-réseau Application Gateway pour assurer que l’accès Internet sortant à partir du sous-réseau sera sortant à partir d’une appliance virtuelle. À un niveau élevé, la conception suivante est résumée dans la figure 1 :
- Application Gateway est en réseau virtuel spoke
- Il existe une appliance virtuelle réseau (une machine virtuelle) dans le réseau hub
- Une table de routage avec un itinéraire par défaut (0.0.0.0/0) vers l’appliance virtuelle est associée au sous-réseau Application Gateway
Figure 1 : sortie d’accès Internet via une appliance virtuelle
Pour créer une table de routage et l’associer au sous-réseau Application Gateway :
- Sélectionnez Itinéraires et créez la règle de tronçon suivant pour 0.0.0.0/0 et configurez la destination comme adresse IP de votre machine virtuelle :
- Sélectionnez Sous-réseaux et associez la table de route au sous-réseau Application Gateway :
- Vérifiez que le trafic transite par l’appliance virtuelle.
Limitations / problèmes connus
Les limites suivantes s'appliquent :
Configuration d’une liaison privée
La prise en charge de configuration de liaison privée pour le tunneling du trafic via des points de terminaison privés vers Application Gateway n’est pas prise en charge avec une passerelle privée uniquement.
Limitation du débit de pare-feu d’applications web (WAF)
Les Règles personnalisées de limitation du débit pour WAF v2 d’Application Gateway ne sont actuellement pas prises en charge.
Configuration frontend de l’IP privée uniquement avec AGIC
AGIC v1.7 doit être utilisé pour introduire uniquement la prise en charge de l’adresse IP front-end privée.
Connectivité de point de terminaison privé via le peering de réseaux virtuels mondial
Si Application Gateway a une référence de cible back-end ou de coffre de clés à un point de terminaison privé situé dans un réseau virtuel accessible via le peering mondial de réseaux virtuels, le trafic est supprimé, ce qui entraîne un état non sain.
Intégration de Network Watcher
Les diagnostics relatifs à la résolution des problèmes de connexion et aux NSG (groupes de sécurité réseau) retournent une erreur lors de l’exécution de tests de vérification et de diagnostic.
Coexistence de passerelles Application Gateway v2 créées avant d’activer le contrôle réseau amélioré
Si un sous-réseau partage des déploiements Application Gateway v2 créés avant et après l’activation de la fonctionnalité de contrôle réseau améliorée, le groupe de sécurité réseau (NSG) et la fonctionnalité table de routage sont limités au déploiement de passerelle précédent. Les passerelles d’application configurées avant l’activation de la nouvelle fonctionnalité doivent être reconfigurées, ou les passerelles nouvellement créées doivent utiliser un autre sous-réseau pour activer des fonctionnalités améliorées de groupe de sécurité réseau et de table de routage.
- Si une passerelle déployée avant l’activation de la nouvelle fonctionnalité existe dans le sous-réseau, vous pouvez voir des erreurs telles que :
For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet'lors de l’ajout d’entrées de table de routage. - Lorsque vous ajoutez des règles de groupe de sécurité réseau au sous-réseau, vous pouvez voir :
Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku.
Étapes suivantes
- Consultez Base de référence de sécurité Azure pour Application Gateway pour connaître d’autres meilleures pratiques de sécurité.