Pare-feu et Application Gateway pour réseaux virtuels

Pour sécuriser des charges de travail d’application Azure, vous devez utiliser des mesures de protection telles que l’authentification et le chiffrement dans les applications proprement dites. Vous pouvez également ajouter des couches de sécurité aux réseaux virtuels (VNets) qui hébergent les applications. Ces couches de sécurité protègent les flux entrants de l’application contre toute utilisation inattendue. Elles limitent également les flux sortants vers Internet aux seuls points de terminaison dont votre application a besoin. Cet article décrit les services de sécurité Réseau virtuel Azure, comme Azure DDoS Protection, le Pare-feu Azure et Azure Application Gateway, quand utiliser chaque service et les options de conception de réseau qui les combinent.

• Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel de périmètre.
• Le Pare-feu Azure est un pare-feu de nouvelle génération géré, qui intègre la traduction d’adresses réseau (NAT). Le Pare-feu Azure base le filtrage des paquets sur les adresses IP et les ports TCP/UDP, ou sur des attributs HTTP(S) ou SQL basés sur l'application. Le Pare-feu Azure tire applique également le renseignement sur les menaces de Microsoft pour identifier les adresses IP malveillantes. Pour plus d’informations, consultez la Documentation du Pare-feu Azure.
• Le Pare-feu Azure Premium comprend toutes les fonctionnalités du Pare-feu Azure Standard et d’autres fonctionnalités telles que l’inspection TLS et un système de protection et de détection des intrusions (IDPS)
• Le service Azure Application Gateway est un équilibreur de charge de trafic web géré et un proxy inverse HTTP(S) capable d’effectuer le chiffrement et le déchiffrement SSL. La passerelle applicative conserve l’adresse IP du client d’origine dans un en-tête HTTP X-Forwarded-For. Application Gateway utilise également le pare-feu d’applications web pour inspecter le trafic web et détecter des attaques au niveau de la couche HTTP. Pour plus d’informations, consultez la Documentation Application Gateway.
• Azure Web Application Firewall (WAF) est un ajout facultatif à Azure Application Gateway. Il assure l’inspection des requêtes HTTP et empêche les attaques malveillantes au niveau de la couche web, telles que l’injection de code SQL ou le scripting inter-site. Pour plus d’informations, consultez la Documentation du pare-feu d’applications web.

Ces services Azure sont complémentaires. Les deux peuvent convenir pour vos charges de travail, ou vous pouvez les utiliser ensemble pour une protection optimale au niveau des couches réseau et Application. Utilisez l’arbre de décision suivant et les exemples de cet article pour déterminer l’option de sécurité optimale pour le réseau virtuel de votre application.

Le Pare-feu Azure et Azure Application Gateway utilisent différentes technologies et prennent en charge la sécurisation de différents flux :

En fonction des flux réseau dont une application a besoin, la conception peut être différente pour chaque application. Le diagramme suivant offre un arbre de décision simplifié qui aide à choisir l’approche recommandée pour une application. La décision varie selon que l’application est publiée via HTTP(S) ou un autre protocole :

Cet article aborde les conceptions largement recommandées de l’organigramme ainsi que d’autres qui s’appliquent à des scénarios moins courants :

• Le Pare-feu Azure seul, quand il n’existe aucune application web dans le réseau virtuel. Il contrôle le trafic entrant vers les applications et le trafic sortant.
• Le service Application Gateway seul, quand le réseau virtuel ne comprend que des applications web et que les groupes de sécurité réseau (NSG) fournissent un filtrage de sortie suffisant. Les fonctionnalités fournies par le Pare-feu Azure peuvent empêcher de nombreux scénarios d’attaque (par exemple, exfiltration de données, IDPS, etc.). Pour cette raison, le scénario Application Gateway seul n’est généralement pas recommandé. Par conséquent, il est non documenté et n’apparaît pas dans le graphique en flux ci-dessus.
• Le Pare-feu Azure et Application Gateway en parallèle, qui est l’une des conceptions les plus courantes. Utilisez cette combinaison lorsque vous souhaitez qu’Azure Application Gateway protège les applications HTTP(S) contre les attaques web et que le Pare-feu Azure protège toutes les autres charges de travail et filtre le trafic sortant.
• Application Gateway devant le Pare-feu Azure, lorsque vous souhaitez que le Pare-feu Azure inspecte tout le trafic, que WAF protège le trafic web et que l’application connaisse l’adresse IP source du client. Avec le Pare-feu Azure Premium et l’inspection TLS, cette conception prend également en charge le scénario SSL de bout en bout.
• Le Pare-feu Azure devant Application Gateway, quand vous souhaitez que le Pare-feu Azure inspecte et filtre le trafic avant qu’il atteigne le service Application Gateway. Le Pare-feu Azure n’étant pas en mesure de déchiffrer le trafic HTTPS, la fonctionnalité qu’il ajoute à Application Gateway est limitée. Ce scénario n’est pas documenté dans l’organigramme ci-dessus.

Dans la dernière partie de cet article, des variantes des conceptions fondamentales précédentes sont décrites. Il s’agit des variantes suivantes :

• Clients d’application locaux
• Réseaux hubs-and-spoke
• Implémentations d’Azure Kubernetes Service (AKS)

Vous pouvez ajouter d’autres services de proxy inverse tels qu’une passerelle Gestion des API ou Azure Front Door, ou encore remplacer les ressources Azure par des appliances virtuelles réseau tierces.

Pare-feu Azure uniquement

Si le réseau virtuel n’inclut pas de charges de travail web susceptibles de pouvoir tirer parti du pare-feu d’applications web, vous pouvez utiliser uniquement le Pare-feu Azure. Dans ce cas, la conception est simple, mais l’examen du flux de paquets permet de mieux comprendre les conceptions plus complexes. Dans cette conception, tout le trafic entrant est envoyé au Pare-feu Azure par le biais de routes définies par l’utilisateur (UDR) pour les connexions à partir d’emplacements locaux ou d’autres réseaux virtuels Azure. Il est adressé à l’adresse IP publique du Pare-feu Azure pour les connexions à partir de l’internet public, comme le montre le diagramme ci-dessous. Le trafic sortant des réseaux virtuels Azure est envoyé au pare-feu via des UDR, comme dans la boîte de dialogue ci-dessous.

Le tableau suivant récapitule les flux de trafic pour ce scénario :

Le Pare-feu Azure n’inspectera pas le trafic HTTP(S) entrant. Toutefois, il sera en mesure d’appliquer des règles de couche 3 et de couche 4 et des règles d’application basées sur le nom de domaine complet. Le Pare-feu Azure inspectera le trafic HTTP(S) sortant en fonction du niveau de Pare-feu Azure et selon que vous configurez ou non l’inspection TLS :

• Le Pare-feu Azure Standard inspectera uniquement les attributs des couches 3 et 4 des paquets dans les règles de réseau, et l’en-tête HTTP de l’hôte dans les règles d’application.
• Le Pare-feu Azure Premium ajoute des fonctionnalités telles que l’inspection d’autres en-têtes HTTP (tels que User-Agent) et l’activation de l’inspection TLS pour une analyse plus approfondie des paquets. Le Pare-feu Azure n’est pas équivalent à Web Application Firewall. Si vous avez des charges de travail web dans votre réseau virtuel, l’utilisation de WAF est vivement recommandée.

L’exemple de parcours de paquets suivant montre comment un client accède à une application hébergée sur une machine virtuelle à partir de l’Internet public. Par souci de simplicité, le diagramme ne comprend qu’une seule machine virtuelle. Pour une disponibilité et une extensibilité supérieures, vous pouvez avoir plusieurs instances d’application derrière un équilibreur de charge. Dans cette conception, le Pare-feu Azure inspecte les connexions entrantes à partir de l’Internet public et les connexions sortantes à partir de la machine virtuelle du sous-réseau de l’application à l’aide de l’UDR.

• Le service Pare-feu Azure déploie plusieurs instances en arrière-plan, ici avec l’adresse IP front-end 192.168.100.4 et les adresses internes dans la plage 192.168.100.0/26. Ces instances individuelles sont normalement invisibles pour l’administrateur Azure, mais il est utile de noter la différence dans certains cas, par exemple lors de la résolution des problèmes réseau.
• Si le trafic provient d’un réseau privé virtuel (VPN) local ou d’une passerelle Azure ExpressRoute au lieu d’Internet, le client établit la connexion à l’adresse IP de la machine virtuelle. Il ne démarre pas la connexion à l’adresse IP du pare-feu, et le pare-feu et n’effectue aucune traduction d’adresses réseau (NAT) source par défaut.

Architecture

Le diagramme suivant montre le flux de trafic en supposant que l’adresse IP de l’instance est 192.168.100.7.

Workflow

1. Le client lance la connexion à l’adresse IP publique du Pare-feu Azure :
   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AzFwPIP
2. La demande à l’adresse IP publique du Pare-feu Azure est distribuée à une instance back-end du pare-feu, dans ce cas 192.168.100.7. La règle de NAT de destination (DNAT) du Pare-feu Azure convertit l’adresse IP de destination en adresse IP de l’application au sein du réseau virtuel. Le Pare-feu Azure trouve également les NAT sources (SNAT) du paquet s’il effectue DNAT. Pour plus d’informations, consultez Problèmes connus du Pare-feu Azure. La machine virtuelle voit les adresses IP suivantes dans le paquet entrant :
   • Adresse IP source : 192.168.100.7
   • Adresse IP de destination : 192.168.1.4
3. La machine virtuelle répond à la demande de l’application, en inversant les adresses IP source et de destination. Le trafic entrant ne nécessite pas d’Itinéraire défini par l’utilisateur (UDR) , car l’adresse IP source est l’adresse IP du Pare-feu Azure. Dans le diagramme, l'UDR de 0.0.0.0/0 concerne les connexions sortantes, pour veiller à ce que les paquets acheminés vers l'Internet public passent par le Pare-feu Azure.
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.100.7
4. Enfin, le Pare-feu Azure annule les opérations SNAT et DNAT et remet la réponse au client :
   • Adresse IP source : AzFwPIP
   • Adresse IP de destination : ClientPIP

Application Gateway uniquement

Cette conception couvre le cas d’usage dans lequel seules des applications web existent dans le réseau virtuel, et où l’inspection du trafic sortant avec des groupes de sécurité réseau (NSG) suffit pour protéger les flux sortants vers Internet.

La principale différence par rapport à la conception précédente avec uniquement le Pare-feu Azure est qu’Application Gateway ne fait pas office de dispositif de routage avec NAT. Il se comporte comme un proxy d’application inverse complet. Autrement dit, Application Gateway met fin à la session web à partir du client, et établit une session distincte avec l’un de ses serveurs principaux. Les connexions HTTP(S) entrantes en provenance d’Internet doivent être envoyées à l’adresse IP publique de la passerelle applicative, et les connexions en provenance d’Azure ou locales à l’adresse IP privée de la passerelle. Le retour du trafic à partir des machines virtuelles Azure suivra le routage de réseau virtuel standard vers l’Application Gateway (pour plus d’informations, voir plus loin le parcours de paquets). Les flux Internet sortants des machines virtuelles Azure sont directement dirigés vers Internet.

Le tableau suivant récapitule les flux de trafic :

Architecture

L’exemple de parcours de paquets suivant montre comment un client accède à l’application hébergée sur une machine virtuelle à partir de l’Internet public.

Workflow

1. Le client lance la connexion à l’adresse IP publique d’Azure Application Gateway :
   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AppGwPIP
2. La demande à l’adresse IP publique d’Application Gateway est distribuée à une instance back-end de la passerelle, dans ce cas 192.168.200.7. L’instance Application Gateway qui reçoit la requête met fin à la connexion du client et établit une nouvelle connexion avec l’un des serveurs principaux. Le serveur principal voit l’instance Application Gateway en tant qu’adresse IP source. Le service Application Gateway insère un en-tête HTTP X-Forwarded-For avec l’adresse IP du client d’origine.
   • Adresse IP source : 192.168.200.7 (adresse IP privée de l’instance Application Gateway)
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : ClientPIP
3. La machine virtuelle répond à la demande de l’application, en inversant les adresses IP source et de destination. La machine virtuelle sait déjà comment atteindre le service Application Gateway. Elle n’a donc pas besoin d’UDR.
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7
4. Enfin, l’instance Application Gateway répond au client :
   • Adresse IP source : AppGwPIP
   • Adresse IP de destination : ClientPIP

Azure Application Gateway ajoute des métadonnées aux en-têtes HTTP de paquet, tels que l’en-tête X-Forwarded-For contenant l’adresse IP du client d’origine. Certains serveurs d’applications ont besoin de l’adresse IP du client source pour servir le contenu spécifique de la géolocalisation ou pour la journalisation. Pour plus d’informations, consultez Fonctionnement d’une passerelle d’application.

• L’adresse IP 192.168.200.7 est l’une des instances que le service Azure Application Gateway déploie en coulisses, ici avec l’adresse IP front-end 192.168.200.4. Ces instances individuelles sont normalement invisibles pour l’administrateur Azure, mais il est utile de noter la différence dans certains cas, par exemple lors de la résolution des problèmes réseau.

• Le flux est similaire si le client provient d’un réseau local via une passerelle VPN ou ExpressRoute. La différence est que le client accède à l’adresse IP privée d’Application Gateway plutôt qu’à l’adresse publique.

Pare-feu et service Application Gateway en parallèle

En raison de sa simplicité et de sa flexibilité, l’exécution d’Application Gateway et du Pare-feu Azure en parallèle est souvent le meilleur scénario.

Implémentez cette conception s’il existe une combinaison de charges de travail web et non web dans le réseau virtuel. Le pare-feu d’applications web Azure dans Azure Application Gateway protège le trafic entrant vers les charges de travail web, et le Pare-feu Azure inspecte le trafic entrant pour les autres applications. Le Pare-feu Azure couvre les flux sortants des deux types de charges de travail.

Les connexions HTTP(S) entrantes en provenance d’Internet doivent être envoyées à l’adresse IP publique de l’Application Gateway, et les connexions HTTP(S) en provenance d’Azure ou locales à l’adresse IP privée. Le routage de réseau virtuel standard enverra les paquets en provenance de l’Application Gateway aux machines virtuelles de destination, et renverra les paquets en provenance des machines virtuelles de destination à l’Application Gateway (pour plus d’informations, voir plus loin le parcours des paquet). Pour les connexions entrantes non-HTTP(S), le trafic doit cibler l’adresse IP publique du Pare-feu Azure (s’il provient de l’Internet public), ou sera envoyé via le Pare-feu Azure par des UDR (s’il provient d’autres réseaux virtuels ou réseaux locaux Azure). Tous les flux sortants de machines virtuelles Azure seront transférés vers le Pare-feu Azure par des UDR.

Le tableau suivant récapitule les flux de trafic pour ce scénario :

Cette conception permet un filtrage de sortie bien plus précis que les groupes de sécurité réseau. Par exemple, si des applications ont besoin d’une connectivité à un compte Stockage Azure spécifique, vous pouvez utiliser des filtres basés sur le nom de domaine complet (FQDN). Avec les filtres FQDN, les applications n’envoient pas de données aux comptes de stockage non autorisés. Ce scénario ne pourrait pas être évité simplement à l’aide de NSG. Cette conception est souvent utilisée lorsque le trafic sortant nécessite un filtrage basé sur le nom de domaine complet. C’est le cas par exemple lorsqu’il s’agit de limiter le trafic sortant à partir d’un cluster Azure Kubernetes Services.

Architectures

Le diagramme suivant illustre le flux de trafic pour les connexions HTTP(S) entrantes à partir d’un client externe :

Le diagramme suivant illustre le flux de trafic pour les connexions sortantes des machines virtuelles réseau vers Internet : Il pourrait s’agir par exemple de la connexion à des systèmes back-end ou de la récupération de mises à jour du système d’exploitation :

Les étapes du flux de paquets pour chaque service sont les mêmes que celles des options de conception autonome précédentes.

Service Application Gateway devant le pare-feu

Cette conception est expliquée plus en détail dans le Réseau Confiance Zéro pour les applications web avec le Pare-feu Azure et Application Gateway. Ce document se concentre principalement sur la comparaison avec les autres options de conception. Dans cette topologie, le trafic web entrant transite par le Pare-feu Azure et le pare-feu d'applications web (WAF). Le pare-feu d’applications web fournit une protection au niveau de la couche Application web. Le Pare-feu Azure agit comme un point de contrôle et de journalisation centralisé, et inspecte le trafic entre Application Gateway et les serveurs principaux. Le service Application Gateway et le Pare-feu Azure n’opèrent pas en parallèle, mais en série.

Avec le Pare-feu Azure Premium, cette conception peut prendre en charge des scénarios de bout en bout, où le Pare-feu Azure applique l’inspection TLS pour effectuer la protection et la détection des intrusions (IDPS) sur le trafic chiffré entre Application Gateway et le back-end web.

Cette conception est appropriée pour les applications qui ont besoin de connaître les adresses IP sources de client entrantes, par exemple, pour servir du contenu spécifique de la géolocalisation ou à des fins de journalisation. Le service Application Gateway devant le Pare-feu Azure capture l’adresse IP source du paquet entrant dans l’en-tête X-Forwarded-For, afin que le serveur web puisse voir l’adresse IP d’origine dans cette en-tête. Pour plus d’informations, consultez Fonctionnement d’une passerelle d’application.

Les connexions HTTP(S) entrantes en provenance d’Internet doivent être envoyées à l’adresse IP publique de l’Application Gateway, et les connexions HTTP(S) en provenance d’Azure ou locales à l’adresse IP privée. À partir de l’Application Gateway, les UDR veillent à ce que les paquets soient acheminés via le Pare-feu Azure (pour plus d’informations, voir plus loin le parcours de paquets). Pour les connexions entrantes non-HTTP(S), le trafic doit cibler l’adresse IP publique du Pare-feu Azure (s’il provient de l’Internet public), ou sera envoyé via le Pare-feu Azure par des UDR (s’il provient d’autres réseaux virtuels ou réseaux locaux Azure). Tous les flux sortants de machines virtuelles Azure seront transférés vers le Pare-feu Azure par des UDR.

Une remarque importante concernant cette conception est que le Pare-feu Azure Premium voit le trafic avec une adresse IP dont la source est le sous-réseau d'Application Gateway. Si ce sous-réseau est configuré avec une adresse IP privée (dans 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 ou 100.64.0.0/10), le Pare-feu Azure Premium considère le trafic en provenance d’Application Gateway comme étant interne, et n’applique pas les règles IDPS relatives au trafic entrant. Pour en savoir plus sur les instructions relatives aux règles IDPS du Pare-feu Azure et les préfixes des IP privées pour l'IDPS, reportez-vous à la section Règles IDPS du Pare-feu Azure. Par conséquent, il est recommandé de modifier les préfixes privés IDPS dans la stratégie de Pare-feu Azure pour éviter que le sous-réseau d'Application Gateway ne soit considéré comme une source interne, et pouvoir ainsi appliquer des signatures IDPS au trafic entrant et sortant.

Le tableau suivant récapitule les flux de trafic pour ce scénario :

Pour le trafic web de l’environnement local ou Internet vers Azure, le Pare-feu Azure inspecte les flux que le pare-feu d’applications web a déjà autorisés. Selon qu’Application Gateway chiffre ou non le trafic back-end (le trafic d’Application Gateway vers les serveurs d’applications), vous avez différents scénarios potentiels :

1. Application Gateway chiffre le trafic en suivant les principes de Confiance Zéro (chiffrement TLS de bout en bout), et le Pare-feu Azure reçoit le trafic chiffré. Toutefois, le Pare-feu Azure Standard sera toujours en mesure d’appliquer des règles d’inspection telles que le filtrage de couche 3 et de couche 4 dans les règles de réseau ou le filtrage FQDN dans les règles d’application avec l’en-tête Indication du nom du serveur (SNI) TLS. Le Pare-feu Azure Premium offre une meilleure visibilité avec l'inspection TLS, comme le filtrage basé sur l’URL.
2. Si Application Gateway envoie du trafic non chiffré aux serveurs d’applications, le Pare-feu Azure verra le trafic entrant en texte clair. L’inspection TLS n’est pas nécessaire dans le Pare-feu Azure.
3. Si le système IDPS est activé dans le Pare-feu Azure, il vérifie que l'en-tête HTTP Host correspond à l'adresse IP de destination. À cette fin, une résolution de noms est nécessaire pour le nom de domaine complet spécifié dans l’en-tête Host. Cette résolution de noms peut être réalisée avec Azure DNS Private Zones et les paramètres DNS par défaut du Pare-feu Azure à l’aide d’Azure DNS. Elle peut également être obtenue avec des serveurs DNS personnalisés qui doivent être configurés dans les paramètres du Pare-feu Azure. (Pour plus d’informations, consultez Paramètres DNS du Pare-feu Azure.) S’il n’y a pas d’accès administratif au réseau virtuel où le Pare-feu Azure est déployé, la dernière méthode est la seule possibilité. C’est notamment le cas pour les Pare-feu Azure déployés dans des hubs sécurisés Virtual WAN.

Architecture

Pour le reste des flux (trafic entrant non-HTTP(S) et tout trafic sortant), le Pare-feu Azure fournit l’inspection IDPS (et, le cas échéant, l’inspection TLS). Il fournit également le filtrage basé sur le nom de domaine complet dans les règles de réseau en fonction du système DNS.

Workflow

Le trafic réseau provenant de l’Internet public suit le flux suivant :

1. Le client lance la connexion à l’adresse IP publique d’Azure Application Gateway :
   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AppGwPIP
2. La demande à l’adresse IP publique d’Application Gateway est distribuée à une instance back-end de la passerelle, dans ce cas 192.168.200.7. L’instance Application Gateway met fin à la connexion à partir du client, et établit une nouvelle connexion avec l’un des serveurs principaux. L’UDR vers 192.168.1.0/24 dans le sous-réseau du service Application Gateway transfère le paquet au Pare-feu Azure, tout en conservant l’adresse IP de destination de l’application web :
   • Adresse IP source : 192.168.200.7 (adresse IP privée de l’instance Application Gateway)
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : ClientPIP
3. Le Pare-feu Azure n’applique pas la traduction SNAT au trafic, car celui-ci va vers une adresse IP privée. Il transfère le trafic à la machine virtuelle d’application si les règles le permettent. Pour plus d’informations, consultez SNAT du Pare-feu Azure. Toutefois, si le trafic déclenche une règle d’application dans le pare-feu, la charge de travail verra l’adresse IP source de l’instance de pare-feu spécifique qui a traité le paquet, car le Pare-feu Azure proxysera la connexion :
   • Adresse IP source si le trafic est autorisé par une règle réseau Pare-feu Azure : 192.168.200.7 (adresse IP privée de l’une des instances d’Application Gateway).
   • Adresse IP source si le trafic est autorisé par une règle d’application Pare-feu Azure : 192.168.100.7 (adresse IP privée de l’une des instances de Pare-feu Azure).
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : ClientPIP
4. La machine virtuelle répond à la demande, en inversant les adresses IP source et de destination. L’UDR vers 192.168.200.0/24 capture le paquet renvoyé au service Application Gateway et le redirige vers le Pare-feu Azure, tout en conservant l’adresse IP de destination du service Application Gateway.
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7
5. Une fois encore, le Pare-feu Azure n’a pas de point d’effectuer l’opération SNAT sur le trafic, car il accède à une adresse IP privée et transfère le trafic vers le service Application Gateway.
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7
6. Enfin, l’instance Application Gateway répond au client :
   • Adresse IP source : AppGwPIP
   • Adresse IP de destination : ClientPIP

Les flux sortants des machines virtuelles vers l’Internet public passent par le Pare-feu Azure, comme défini par l’UDR vers 0.0.0.0/0.

Application Gateway derrière un pare-feu

Cette conception permet au Pare-feu Azure de filtrer et d’écarter le trafic malveillant avant qu’il atteigne le service Application Gateway. Par exemple, il peut appliquer des fonctionnalités telles que le filtrage basé sur le renseignement sur les menaces. Un autre avantage est que l’application obtient la même adresse IP publique pour le trafic entrant et le trafic sortant, quel que soit le protocole. Cependant, comme le Pare-feu Azure applique l’opération SNAT au trafic entrant, l’application n’a pas de visibilité sur l’adresse IP d’origine des requêtes HTTP. Du point de vue de l’administration, par exemple à des fins de résolution des problèmes, vous pouvez obtenir l’adresse IP cliente réelle pour une connexion spécifique en la mettant en corrélation avec les journaux SNAT du Pare-feu Azure.

Ce scénario offre un avantage limité, car le Pare-feu Azure voit uniquement le trafic chiffré dirigé vers Application Gateway. Dans certains scénarios, cette conception peut être préférable. C’est le cas, par exemple, si un autre WAF se trouvait antérieurement dans le réseau (par exemple, avec Azure Front Door), qui pouvait capturer l’adresse IP source d’origine dans l’en-tête HTTP X-Forwarded-For. Cette conception est également préférable si de nombreuses adresses IP publiques sont requises.

Les flux entrants HTTP(S) en provenance de l’Internet public doivent cibler l’adresse IP publique du Pare-feu Azure, et le Pare-feu Azure effectue une opération DNAT (et SNAT) sur les paquets envoyés à l’adresse IP privée de l’Application Gateway. À partir d’autres réseaux virtuels Azure ou de réseaux locaux, le trafic HTTP(S) doit être envoyé à l’adresse IP privée d’Application Gateway et transmis par le biais du Pare-feu Azure avec des UDR. Le routage de réseau virtuel standard veille à ce que le trafic de retour des machines virtuelles Azure revienne à l’Application Gateway, et de l’Application Gateway au Pare-feu Azure si des règles de DNAT ont été utilisées. Pour le trafic en provenance d’UDR locales ou Azure dans Application Gateway, un sous-réseau doit être utilisé (pour plus d’informations, examinez plus loin le parcours de paquets). Tout le trafic sortant des machines virtuelles Azure vers Internet est acheminé via le Pare-feu Azure par des UDR.

Le tableau suivant récapitule les flux de trafic pour ce scénario :

Pour le trafic HTTP entrant, le Pare-feu Azure ne déchiffre généralement pas le trafic. Au lieu de cela, il applique des stratégies IDPS qui ne nécessitent pas d’inspection TLS, comme le filtrage basé sur l’adresse IP ou l’utilisation d’en-têtes HTTP.

Architecture

L’application ne peut pas voir l’adresse IP source d’origine du trafic web ; le Pare-feu Azure effectue l’opération SNAT sur les paquets à mesure qu’ils entrent dans le réseau virtuel. Pour éviter ce problème, utilisez Azure Front Door devant le pare-feu. Azure Front Door injecte l’adresse IP du client en tant qu’en-tête HTTP avant que le trafic n’accède au réseau virtuel Azure.

Workflow

Le trafic réseau provenant de l’Internet public suit le flux suivant :

1. Le client lance la connexion à l’adresse IP publique du Pare-feu Azure :
   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AzFWPIP
2. La demande à l’adresse IP publique du Pare-feu Azure est distribuée à une instance back-end du pare-feu, dans ce cas 192.168.100.7. Le Pare-feu Azure effectue l’opération DNAT sur le port web, généralement TCP 443, vers l’adresse IP privée de l’instance Application Gateway. Le Pare-feu Azure effectue également l’opération SNAT quand il effectue l’opération DNAT. Pour plus d’informations, consultez Problèmes connus du Pare-feu Azure :
   • Adresse IP source : 192.168.100.7 (adresse IP privée de l’instance Pare-feu Azure)
   • Adresse IP de destination : 192.168.200.4
3. Le service Application Gateway établit une nouvelle session entre l’instance gérant la connexion et l’un des serveurs principaux. L’adresse IP d’origine du client ne figure pas dans le paquet :
   • Adresse IP source : 192.168.200.7 (adresse IP privée de l’instance Application Gateway)
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : 192.168.100.7
4. La machine virtuelle répond au service Application Gateway, en inversant les adresses IP source et de destination :
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7
5. Le service Application Gateway répond à l’adresse IP source SNAT de l’instance Pare-feu Azure. Même si la connexion provient d’une instance Application Gateway spécifique telle que .7, le Pare-feu Azure voit l’adresse IP interne du service Application Gateway .4 en tant qu’adresse IP source :
   • Adresse IP source : 192.168.200.4
   • Adresse IP de destination : 192.168.100.7
6. Enfin, le Pare-feu Azure annule les opérations SNAT et DNAT, et répond au client :
   • Adresse IP source : AzFwPIP
   • Adresse IP de destination : ClientPIP

Même si le service Application Gateway n’a aucun écouteur configuré pour les applications, il a toujours besoin d’une adresse IP publique pour permettre à Microsoft de le gérer.

Clients locaux

Les conceptions précédentes présentent toutes des clients d’application provenant de l’Internet public. Les réseaux locaux accèdent également aux applications. La plupart des informations et des flux de trafic précédents sont les mêmes que pour les clients Internet, mais il existe des différences notables :

• Une passerelle VPN ou ExpressRoute se trouve devant le Pare-feu Azure ou Application Gateway.
• Le pare-feu d’applications web utilise l’adresse IP privée du service Application Gateway.
• Le Pare-feu Azure ne prend pas en charge l’opération DNAT pour les adresses IP privées. C’est pourquoi vous devez utiliser des UDR pour envoyer le trafic entrant vers le Pare-feu Azure à partir des passerelles VPN ou ExpressRoute.
• Veillez à vérifier les avertissements concernant le tunneling forcé pour le service Azure Application Gateway et pour le Pare-feu Azure. Même si votre charge de travail n’a pas besoin d’une connectivité sortante vers l’Internet public, vous ne pouvez pas injecter un itinéraire par défaut tel que 0.0.0.0/0 pour le service Application Gateway qui pointe vers le réseau local, au risque d’interrompre le trafic de contrôle. Pour le service Azure Application Gateway, l’itinéraire par défaut doit pointer vers l’Internet public.

Architecture

Le diagramme suivant montre la conception parallèle avec Azure Application Gateway et Pare-feu Azure. Les clients d’application proviennent d’un réseau local connecté à Azure via un VPN ou ExpressRoute :

Même si tous les clients sont situés dans un emplacement local ou dans Azure, Azure Application Gateway et le Pare-feu Azure doivent tous deux avoir des adresses IP publiques. Les adresses IP publiques permettent à Microsoft de gérer les services.

Topologie hub-and-spoke

Les conceptions illustrées dans cet article s’appliquent toujours dans une topologie hub-and-spoke. Les ressources partagées dans un réseau virtuel de hub central se connectent aux applications dans des réseaux virtuels spoke distincts par le biais d’appairages de réseaux virtuels.

Architecture

À propos de l’installation

Certaines considérations relatives à cette topologie sont les suivantes :

• Le Pare-feu Azure est déployé dans le réseau virtuel du hub central. Le diagramme ci-dessus montre la pratique de déploiement de la passerelle applicative dans le hub. Toutefois, les équipes d’applications gèrent souvent des composants tels que les passerelles d’application Azure ou les passerelles Gestion des API Azure. Dans ce cas, ces composants sont déployés dans les réseaux virtuels spoke.
• Portez une attention particulière aux UDR sur les réseaux en étoile : lorsqu’un serveur d’applications sur une étoile reçoit du trafic d’une instance de pare-feu Azure spécifique, comme l'adresse 192.168.100.7 dans les exemples précédents, il doit renvoyer le trafic à la même instance. Si un UDR sur l’étoile définit le tronçon suivant de trafic adressé au hub sur l’adresse IP du pare-feu Azure (192.168.100.4 dans les diagrammes ci-dessus), les paquets renvoyés peuvent se retrouver sur une autre instance de pare-feu Azure, provoquant ainsi un routage asymétrique. Assurez-vous que si vous avez des routes définies par l’utilisateur dans les réseaux virtuels spoke pour envoyer du trafic vers des services partagés au niveau du hub via le Pare-feu Azure, ces UDR n’incluent pas le préfixe du sous-réseau du Pare-feu Azure.
• La recommandation précédente s’applique également au sous-réseau Application Gateway et à toutes les autres appliances virtuelles réseau ou tous les proxys inverses susceptibles d’être déployés sur le réseau virtuel de hub.
• Vous ne pouvez pas définir le tronçon suivant pour les sous-réseaux Application Gateway ou Pare-feu Azure via des routes statiques avec le type de tronçon suivant Virtual Network. Ce type de tronçon suivant est uniquement valide dans le réseau virtuel local, et non avec les appairages de réseaux virtuels. Pour plus d’informations sur les routes définies par l’utilisateur et les types de tronçons suivants, consultez Routage du trafic de réseau virtuel.

Routage asymétrique

Le diagramme ci-dessous montre comment un réseau spoke renvoie le trafic SNAT à l’ALB d’un Pare-feu Azure. Cette configuration provoque un routage asymétrique :

Pour résoudre ce problème, définissez des routes définies par l’utilisateur (UDR) dans le réseau spoke sans le sous-réseau de Pare-feu Azure, mais uniquement avec les sous-réseaux où se trouvent les services partagés. Dans l’exemple, la route définie par l’utilisateur correcte dans le réseau spoke doit contenir uniquement 192.168.1.0/24. Elle ne doit pas contenir l’intégralité de 192.168.0.0/16, comme indiqué en rouge.

Intégration avec d’autres produits Azure

Vous pouvez intégrer le Pare-feu Azure et le service Azure Application Gateway avec d’autres produits et services Azure.

Passerelle Gestion des API

Intégrez des services de proxy inverse tels que la passerelle Gestion des API dans les conceptions précédentes pour offrir des fonctionnalités telles que la limitation des API ou le proxy d’authentification. L’intégration d’une passerelle Gestion des API n’a pas d’incidence notable sur les conceptions. La principale différence réside dans le fait qu’à la place du seul proxy inverse du service Application Gateway, deux proxys inverses sont chaînés l’un derrière l’autre.

Pour plus d’informations, consultez le Guide de conception pour intégrer le service Gestion des API et le service Application Gateway dans un réseau virtuel et le modèle d’application passerelles d’API pour les microservices.

Azure Kubernetes Service

Pour les charges de travail qui s’exécutent sur un cluster AKS, vous pouvez déployer Azure Application Gateway indépendamment du cluster. Vous pouvez également l’intégrer avec le cluster AKS à l’aide du Contrôleur d’entrée Azure Application Gateway. Lors de la configuration de certains objets aux niveaux Kubernetes (tels que les services et les entrées), Application Gateway s’adapte automatiquement sans nécessiter d’étapes manuelles supplémentaires.

Le Pare-feu Azure joue un rôle important dans la sécurité du cluster AKS. Il offre les fonctionnalités requises pour filtrer le trafic sortant du cluster AKS en fonction du nom de domaine complet (FQDN) et non simplement de l’adresse IP. Pour plus d’informations, consultez Contrôle du trafic de sortie pour les nœuds de cluster AKS.

Lorsque vous combinez Application Gateway et le Pare-feu Azure pour protéger un cluster AKS, l’idéal est d’utiliser l’option de conception parallèle. Application Gateway avec le pare-feu d’applications web traite les demandes de connexion entrantes pour les applications web dans le cluster. Le Pare-feu Azure autorise uniquement les connexions sortantes explicitement autorisées. Pour obtenir un exemple de l’option de conception parallèle, consultez Architecture de référence pour un cluster Azure Kubernetes Service (AKS).

Azure Front Door

La fonctionnalité Azure Front Door chevauche partiellement le service Azure Application Gateway. Par exemple, les deux services offrent les fonctionnalités de pare-feu d’applications web, de déchargement SSL et de routage basé sur l’URL. L’une des principales différences réside dans le fait que, quand le service Azure Application Gateway se trouve à l’intérieur d’un réseau virtuel, Azure Front Door est un service global décentralisé.

Parfois, vous pouvez simplifier la conception du réseau virtuel en remplaçant Application Gateway par un service Azure Front Door décentralisé. La plupart des conceptions décrites ici sont toujours valides, à l’exception de la possibilité de placer le Pare-feu Azure devant le service Azure Front Door.

Un cas d’usage intéressant consiste à utiliser le pare-feu Azure devant Application Gateway dans votre réseau virtuel. Comme décrit précédemment, l’en-tête X-Forwarded-For injecté par le service Application Gateway contient l’adresse IP de l’instance de pare-feu, et non l’adresse IP du client. Une solution de contournement consiste à utiliser Azure Front Door devant le pare-feu pour injecter l’adresse IP du client en tant qu’en-tête X-Forwarded-For avant que le trafic n’entre dans le réseau virtuel et n’atteigne le Pare-feu Azure. Une deuxième option consiste à sécuriser votre origine avec Private Link dans Azure Front Door Premium.

Pour plus d’informations sur les différences entre les deux services, ou sur les cas d’utilisation de chacun d’eux, consultez Questions fréquentes (FAQ) sur Azure Front Door.

Autres appliances virtuelles réseau

Les produits Microsoft ne sont pas les seuls à pouvoir implémenter le pare-feu d’applications web ou une fonctionnalité de pare-feu de nouvelle génération dans Azure. Un vaste éventail de partenaires Microsoft fournissent des appliances virtuelles réseau. Les concepts et conceptions sont essentiellement les mêmes que dans cet article, mais certains aspects importants méritent d’être pris en considération :

• Il se peut que des appliances virtuelles réseau partenaires de nouvelle génération offrent davantage de contrôle et de flexibilité pour les configurations NAT non prises en charge par le Pare-feu Azure, telles que DNAT à partir d’un site local ou DNAT à partir d’Internet sans SNAT.
• Les appliances virtuelles réseau gérées par Azure (comme Application Gateway et le Pare-feu Azure) réduisent la complexité par rapport à des appliances virtuelles réseau où les utilisateurs doivent gérer l’extensibilité et la résilience sur de nombreuses appliances.
• Lorsque vous utilisez des appliances virtuelles réseau dans Azure, utilisez des configurations actif/actif et de mise à l’échelle automatique de sorte que ces appliances ne constituent pas un goulet d’étranglement pour les applications qui s’exécutent dans le réseau virtuel.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Jose Moreno | Ingénieur client principal

Étapes suivantes

En savoir plus sur les technologies des composants :

• Qu’est-ce qu’Azure Application Gateway ?
• Qu’est-ce qu’un pare-feu Azure ?
• Qu’est-ce qu’Azure Front Door ?
• Azure Kubernetes Service
• Qu’est-ce que le réseau virtuel Azure ?
• Qu’est-ce que le pare-feu d’applications web Azure ?

Ressources associées

Explorer les architectures connexes :

• Implémenter un réseau hybride sécurisé
• Applications web gérées en toute sécurité
• Sécurisation de votre bot de canal Microsoft Teams et de votre application web derrière un pare-feu
• Portail de santé consommateur sur Azure
• Considérations de sécurité pour les applications IaaS hautement sensibles dans Azure
• SaaS mutualisé sur Azure
• Déploiement en entreprise avec App Services environnement
• Déploiement en entreprise hautement disponible avec App Services environnement
• Architecture de référence pour un cluster Azure Kubernetes Service (AKS)