Déploiement de passerelle d’application privé (préversion)
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.
Intégration à la préversion publique
Les fonctionnalités des nouveaux contrôles de la configuration front-end IP privée, le contrôle des règles de groupe de sécurité réseau et le contrôle des tables de routage sont actuellement en préversion publique. Pour rejoindre la préversion publique, vous pouvez accepter l’expérience à l’aide du portail Microsoft Azure, de PowerShell, de l’interface CLI ou de l’API REST.
Lorsque vous rejoignez la préversion, toutes les nouvelles passerelles Application Gateway offrent la possibilité de définir n’importe quelle combinaison des fonctionnalités de configuration de NSG, table de routage ou IP privée. Si vous souhaitez désactiver la nouvelle fonctionnalité et revenir à la fonctionnalité en disponibilité générale actuelle d’Application Gateway, vous pouvez vous désinscrire à partir de la préversion.
Pour plus d’informations sur les fonctionnalités d’évaluation, consultez Configurer des fonctionnalités en préversion dans l’abonnement Azure
Inscription à la préversion
- Portail Azure
- Azure PowerShell
- Azure CLI
Pour vous inscrire à la préversion publique pour les contrôles réseau Application Gateway améliorés via le portail Microsoft Azure, 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 d’évaluation 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.
Remarque
L’inscription d’une fonctionnalité peut prendre jusqu’à 30 minutes pour passer de l’état Inscription à Inscrit.
Pour plus d’informations sur les fonctionnalités d’évaluation, consultez Configurer des fonctionnalités en préversion dans l’abonnement Azure
Désinscrire à partir de la préversion
- Portail Azure
- Azure PowerShell
- Azure CLI
Pour désactiver la préversion publique pour les contrôles réseau Application Gateway améliorés 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 d’évaluation 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.
Régions et disponibilité
La préversion privée d’Application Gateway est disponible pour toutes les régions de cloud public où la référence SKU Application Gateway v2 est prise en charge.
Configuration des contrôles réseau
Après l’inscription dans la préversion publique, la configuration du groupe de sécurité réseau, de la table de routage et de la configuration front-end d’adresse IP privée 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. Aucune API ou aucune modification de commande n’est introduite avec cette préversion publique.
Modifications des ressources
Une fois votre passerelle approvisionnée, une étiquette de ressource est automatiquement affectée avec le nom EnhancedNetworkControl et la valeur True. Voir l’exemple suivant :
L’étiquette de ressource est esthétique et sert à confirmer que la passerelle a été approvisionnée avec les fonctionnalités pour configurer n’importe quelle combinaison des fonctionnalités de passerelle privées uniquement. La modification ou la suppression de l’étiquette ou de la valeur ne modifie pas les fonctions de la passerelle.
Conseil
L’étiquette EnhancedNetworkControl peut être utile lorsque les passerelles Application Gateway existantes ont été déployées dans l’abonnement avant l’activation des fonctionnalités et que vous souhaitez différencier la passerelle qui peut utiliser la nouvelle fonctionnalité.
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é.
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) 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.
Remarque
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.
| N° de règle | Source | Balise du service source | Source port ranges | Destination | Service | Plages de ports dest | Protocol | Action | Priorité | Nom |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Tout | * | Quelconque | HTTP | 80 | TCP | Autoriser | 1028 | AllowWeb | |
| 2 | Quelconque | * | Quelconque | Personnalisée | 8080 | TCP | Autoriser | 1029 | AllowWeb8080 | |
| 3 | Étiquette du service | AzureLoadBalancer | * | Tout | Personnalisée | * | Tout | Allow | 1045 | AllowLB |
| 4 | Quelconque | * | Quelconque | Personnalisée | * | Tout | 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 20.62.8.49
- 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.
Remarque
- 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é.
- 20.63.8.49 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.
| N° de règle | Source | Plages d’adresses IP/CIDR sources | Source port ranges | Destination | Plages d’adresses IP/CIDR de destination | Service | Plages de ports dest | Protocol | Action | Priorité | Nom |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Adresses IP | 10.10.4.0/24 | * | Adresses IP | 20.63.8.49 | HTTPS | 443 | TCP | Autoriser | 400 | AllowToBackendTarget |
| 2 | Adresses IP | 10.10.4.0/24 | * | Adresses IP | 10.13.0.4 | HTTP | 80 | TCP | Autoriser | 401 | AllowToPeeredVnetVM |
| 3 | Quelconque | * | Quelconque | Personnalisée | * | Tout | 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.
Résultat :
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’inscription de la fonctionnalité d’évaluation publique, 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 tronçon 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
La préversion publique a les limitations suivantes :
Configuration d’une liaison privée (préversion)
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.
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.
État d’intégrité des back-ends inconnu
Si l’intégrité du serveur back-end est Inconnu, l’erreur suivante peut s’afficher :
- Impossible de récupérer l’état d’intégrité du back-end. Cela se produit quand un NSG/UDR/pare-feu du sous-réseau de passerelle applicative bloque le trafic sur les ports 65503 à 65534 s’il y a une référence SKU v1 et sur les ports 65200 à 65535 s’il y a une référence SKU v2 ou si le nom de domaine complet (FQDN) configuré dans le pool principal n’a pas pu être résolu en adresse IP. Pour en savoir plus, consultez https://aka.ms/UnknownBackendHealth.
Cette erreur peut être ignorée et sera expliquée dans une prochaine version.
É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é.