Pare-feu Azure et Application Gateway pour les réseaux virtuels

Application Gateway Azure

Pare-feu Azure

Azure Front Door

Réseau virtuel Azure

Pare-feu d’applications web Azure

Pour sécuriser les charges de travail d’application Azure, utilisez des mesures de protection telles que l’authentification et le chiffrement dans les applications elles-mêmes. Vous pouvez ajouter des couches de sécurité aux réseaux virtuels qui hébergent les applications. Ces couches de sécurité aident à protéger les flux entrants de l’application contre une utilisation inattendue. Ils limitent également les flux sortants vers Internet aux points de terminaison requis par votre application. Cet article décrit réseau virtuel Azure services de sécurité tels qu’Azure DDoS Protection, pare-feu Azure et Azure Application Gateway. Il décrit également quand utiliser chaque service et les options de conception réseau qui les combinent.

• protection DDoS, combinée aux meilleures pratiques de conception d’application, fournit des fonctionnalités d’atténuation DDoS améliorées qui améliorent la défense contre les attaques DDoS. Vous devez activer la protection DDoS sur chaque réseau virtuel de périmètre.

• pare-feu Azure est un pare-feu managé de nouvelle génération qui fournit fonctionnalités de traduction d’adresses réseau (NAT). Le Pare-feu Azure filtre les paquets basés sur les adresses IP et les ports TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol). Il peut filtrer le trafic à l’aide d’attributs basés sur des applications, tels que HTTP(S) et SQL. Le Pare-feu Azure applique également des informations sur les menaces Microsoft pour aider à identifier les adresses IP malveillantes. Pour plus d’informations, consultez documentation sur le Pare-feu Azure.

• Pare-feu Azure Premium inclut toutes les fonctionnalités du Pare-feu Azure Standard, en plus des fonctionnalités telles que l’inspection de la sécurité de la couche de transport (TLS) et le système de détection et de prévention des intrusions (IDPS).

• Application Gateway est un équilibreur de charge de trafic web managé et un proxy inverse complet HTTP(S) qui peut effectuer le chiffrement et le déchiffrement SSL (Secure Socket Layer). Application Gateway 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 Azure pour inspecter le trafic web et détecter les attaques au niveau de la couche HTTP. Pour plus d’informations, consultez documentation Application Gateway.

• de pare-feu d’applications web est un ajout facultatif à Application Gateway. Il inspecte les requêtes HTTP et empêche les attaques de couche web, telles que l’injection SQL et le script intersite. Pour plus d’informations, consultez documentation sur le pare-feu d’applications web.

Ces services Azure se complètent. Selon vos besoins, l’utilisation d’un service peut mieux convenir à vos charges de travail. Toutefois, vous pouvez utiliser ces services ensemble pour fournir une protection optimale aux couches réseau et application. Utilisez l’arbre de décision suivant et les exemples de cet article pour choisir la meilleure option de sécurité pour le réseau virtuel de votre application.

Pare-feu Azure et Application Gateway utilisent différentes technologies pour sécuriser différents types de flux de données.

Flux d’application	Peut être filtré par le Pare-feu Azure	Peut être filtré par le pare-feu d’applications web sur Application Gateway
Trafic HTTP(S) à partir d’un site local ou d’Internet vers Azure (entrant)	Oui	Oui
Trafic HTTP(S) d’Azure vers un site local ou Internet (sortant)	Oui	Non
Trafic non HTTP(S) (entrant ou sortant)	Oui	Non

La conception peut varier pour chaque application en fonction des flux réseau dont elle a besoin. Le diagramme suivant fournit un arbre de décision simplifié qui vous aide à choisir l’approche recommandée pour votre application. Ce choix varie selon que l’application est publiée via HTTP(S) ou un autre protocole.

Cet article décrit les conceptions largement recommandées présentées dans le diagramme de flux et les conceptions adaptées aux scénarios moins courants :

• Pare-feu Azure uniquement: Utiliser cette conception lorsqu’il n’existe aucune application web dans le réseau virtuel. Il contrôle à la fois le trafic entrant vers les applications et le trafic sortant.

• Application Gateway uniquement: Utilisez cette conception lorsque seules les applications web se trouvent dans le réseau virtuel et groupes de sécurité réseau (NSG) fournissent un filtrage de sortie suffisant. Le Pare-feu Azure fournit des fonctionnalités qui peuvent aider à empêcher plusieurs scénarios d’attaque, tels que l’exfiltration de données et IDPS. Par conséquent, la conception Application Gateway uniquement n’est généralement pas recommandée. Elle n’est donc pas incluse dans le graphique de flux précédent.

• Pare-feu Azure et Application Gateway en parallèle: Utilisez cette conception lorsque vous souhaitez qu’Application Gateway protège les applications HTTP(S) contre les attaques web et le Pare-feu Azure pour protéger toutes les autres charges de travail et filtrer le trafic sortant. Pare-feu Azure et Application Gateway en parallèle sont une conception courante.

• Application Gateway devant le Pare-feu Azure: Utilisez cette conception lorsque vous souhaitez qu’Azure Firewall inspecte tout le trafic, le Pare-feu d’applications web pour protéger le trafic web et l’application pour identifier l’adresse IP source du client. Avec l’inspection du Pare-feu Azure Premium et TLS, cette conception prend également en charge le scénario SSL de bout en bout.

• Pare-feu Azure devant application Gateway: Utilisez cette conception lorsque vous souhaitez qu’Azure Firewall inspecte et filtre le trafic avant qu’il n’atteigne Application Gateway. Étant donné que le Pare-feu Azure ne déchiffre pas le trafic HTTPS, ses fonctionnalités ajoutées à Application Gateway sont limitées. Ce scénario n’est pas documenté dans le graphique de flux précédent.

Les variantes de ces conceptions fondamentales sont décrites plus loin dans cet article et incluent :

• clients d’application locaux.
• réseaux hub-and-spoke.
• implémentations d’Azure Kubernetes Service (AKS).

Vous pouvez ajouter d’autres services de proxy inverse, comme une passerelle Gestion des API Azure ou Azure Front Door. Vous pouvez également remplacer les ressources Azure par des appliances virtuelles réseau non-Microsoft .

Remarque

Dans les scénarios suivants, une machine virtuelle Azure est utilisée comme exemple de charge de travail d’application web. Ces scénarios sont également valides pour d’autres types de charge de travail, tels que des conteneurs ou Azure Web Apps. Pour les configurations qui incluent des points de terminaison privés, tenez compte des recommandations dans scénarios de pare-feu Azure pour inspecter le trafic destiné à un point de terminaison privé.

Conception pare-feu Azure uniquement

S’il n’existe aucune charge de travail basée sur le web dans le réseau virtuel qui peut tirer parti du pare-feu d’applications web, vous pouvez utiliser la conception pare-feu Azure uniquement. La conception de cet exemple est simple, mais vous pouvez passer en revue le flux de paquets pour mieux comprendre les conceptions plus complexes. Dans cette conception, tout le trafic entrant est envoyé au Pare-feu Azure via des itinéraires définis par l’utilisateur (UDR) pour les connexions à partir d’un réseau local 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 illustré dans le diagramme suivant. Les UDR dirigent le trafic sortant à partir de réseaux virtuels Azure vers le Pare-feu Azure, comme indiqué dans la boîte de dialogue suivante.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	N/A	Oui
Trafic HTTP(S) d’Azure vers Internet ou local	N/A	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	N/A	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	N/A	Oui

Le Pare-feu Azure n’inspecte pas le trafic HTTP(S) entrant. Mais il peut appliquer des règles de couche 3 et 4 et des règles d’application de nom de domaine complet (FQDN). Le Pare-feu Azure inspecte le trafic HTTP(S) sortant, en fonction du niveau pare-feu Azure et de la configuration de l’inspection TLS :

• Pare-feu Azure Standard inspecte uniquement les attributs de couche 3 et 4 des paquets dans les règles réseau et l’en-tête HTTP 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 (comme l’agent utilisateur) et l’activation de l’inspection TLS pour une analyse approfondie des paquets. Toutefois, le pare-feu Azure n’est pas identique au pare-feu d’applications web. Si vous avez des charges de travail web dans votre réseau virtuel, nous vous recommandons d’utiliser le pare-feu d’applications web.

L’exemple de procédure pas à pas de paquets suivant montre comment un client accède à une application hébergée par une machine virtuelle à partir de l’Internet public. Le diagramme inclut une seule machine virtuelle par souci de simplicité. Pour une disponibilité et une scalabilité plus élevées, il existe 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 des connexions sortantes à partir de la machine virtuelle du sous-réseau de l’application à l’aide de l’UDR.

• Dans cet exemple, le Pare-feu Azure déploie automatiquement plusieurs instances avec l’adresse IP frontale 192.168.100.4 et les adresses internes dans la plage 192.168.100.0/26. Normalement, ces instances ne sont pas visibles par l’administrateur Azure. Toutefois, il peut être utile de les connaître pour résoudre les problèmes réseau.

• Si le trafic provient d’un réseau privé virtuel local (VPN) ou d'passerelle Azure ExpressRoute au lieu d’Internet, le client démarre la connexion à l’adresse IP de la machine virtuelle. Elle ne démarre pas la connexion à l’adresse IP du pare-feu, et le pare-feu ne fait pas de nat source par défaut.

Architecture

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

Flux de travail

1. Le client démarre la connexion à l’adresse IP publique du Pare-feu Azure.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AzFwPIP

2. La demande adressée à l’adresse IP publique du Pare-feu Azure est distribuée à une instance principale du pare-feu, qui est 192.168.100.7 dans cet exemple. La règle DNAT (Destination Network Address Translation) pare-feu Azure traduit l’adresse IP de destination en adresse IP de l’application à l’intérieur du réseau virtuel. Le Pare-feu Azure implémente également traduction d’adresses réseau source (SNAT) sur le paquet s’il utilise 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 d’application, ce qui inverse les adresses IP source et de destination. Le flux entrant ne nécessite pas d’UDR, car l’adresse IP source est l’adresse IP du pare-feu Azure. L’UDR dans le diagramme pour 0.0.0.0/0 concerne les connexions sortantes afin de s’assurer que les paquets 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. 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

Conception Application Gateway uniquement

Cette conception décrit le scénario où seules les applications web existent dans le réseau virtuel, et l’inspection du trafic sortant avec des groupes de sécurité réseau est suffisante pour protéger les flux sortants vers Internet.

Remarque

Nous vous déconseillons cette conception, car l’utilisation du Pare-feu Azure pour contrôler les flux sortants, au lieu de s’appuyer uniquement sur des groupes de sécurité réseau, permet d’éviter les scénarios d’attaque tels que l’exfiltration de données. Avec le Pare-feu Azure, vous pouvez vous assurer que vos charges de travail envoient uniquement des données à une liste approuvée d’URL. En outre, les groupes de sécurité réseau fonctionnent uniquement au niveau de la couche 3 et de la couche 4 et ne prennent pas en charge les noms de domaine complets.

La principale différence par rapport à la conception précédente du Pare-feu Azure est que Application Gateway ne sert pas d’appareil de routage avec NAT. Au lieu de cela, il fonctionne comme un proxy d’application inverse complet. Cette approche signifie qu’Application Gateway arrête la session web du client et établit une session distincte avec l’un de ses serveurs principaux. Les connexions HTTP(S) entrantes à partir d’Internet sont envoyées à l’adresse IP publique d’Application Gateway, et les connexions d’Azure ou locales utilisent l’adresse IP privée de la passerelle. Le trafic de retour à partir des machines virtuelles Azure suit le routage de réseau virtuel standard vers Application Gateway. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article. Les flux Internet sortants des machines virtuelles Azure accèdent directement à Internet.

Le tableau suivant récapitule les flux de trafic.

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	N/A
Trafic HTTP(S) d’Azure vers Internet ou local	Non	N/A
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	N/A
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	N/A

Architecture

L’exemple de procédure pas à pas de paquet suivant montre comment un client accède à l’application hébergée par la machine virtuelle à partir de l’Internet public.

Flux de travail

1. Le client démarre la connexion à l’adresse IP publique d’Application Gateway.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AppGwPIP

2. La demande adressée à l’adresse IP publique Application Gateway est distribuée à une instance principale de la passerelle, qui est 192.168.200.7 dans cet exemple. L’instance Application Gateway qui reçoit la requête arrête la connexion du client et établit une nouvelle connexion avec l’un des back-ends. Le serveur principal voit l’instance Application Gateway comme l’adresse IP source. Application Gateway insère un en-tête HTTP X-Forwarded-For avec l’adresse IP du client d’origine.

   • Adresse IP source, qui est l’adresse IP privée de l’instance Application Gateway : 192.168.200.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : ClientPIP

3. La machine virtuelle répond à la demande d’application et inverse les adresses IP source et de destination. La machine virtuelle peut atteindre Application Gateway. Elle n’a donc pas besoin d’un UDR.

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

4. L’instance Application Gateway répond au client.

   • Adresse IP source : AppGwPIP
   • Adresse IP de destination : ClientPIP

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

• Dans cet exemple, l’adresse IP 192.168.200.7 est l’une des instances déployées automatiquement par le service Application Gateway. Il a l’adresse IP frontale interne et privée 192.168.200.4. Ces instances individuelles sont normalement invisibles pour l’administrateur Azure. Mais notez la différence peut être utile, par exemple lorsque vous résolvez 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 au lieu de l’adresse IP publique.

Remarque

Pour plus d’informations sur l’en-tête X-Forwarded-For et sur la façon de conserver le nom d’hôte sur une demande, consultez Conserver l’hôte HTTP d’origine.

Pare-feu Azure et Application Gateway en conception parallèle

En raison de sa simplicité et de sa flexibilité, il est souvent préférable d’exécuter Application Gateway et le Pare-feu Azure en parallèle.

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

Les connexions HTTP(S) entrantes à partir d’Internet doivent être envoyées à l’adresse IP publique d’Application Gateway. Les connexions HTTP(S) à partir d’Azure ou locales doivent être envoyées à son adresse IP privée. Le routage de réseau virtuel standard envoie les paquets d’Application Gateway aux machines virtuelles de destination et à partir des machines virtuelles de destination vers Application Gateway. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article.

Pour les connexions non HTTP(S) entrantes, le trafic doit cibler l’adresse IP publique du Pare-feu Azure s’il provient de l’Internet public. Le trafic doit être envoyé via le Pare-feu Azure par des UDR s’il provient d’autres réseaux virtuels Azure ou de réseaux locaux. Tous les flux sortants des machines virtuelles Azure sont transférés vers le Pare-feu Azure par des UDR.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	Non
Trafic HTTP(S) d’Azure vers Internet ou local	Non	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	Oui

Cette conception fournit un filtrage de sortie beaucoup plus granulaire que l’utilisation uniquement de groupes de sécurité réseau. Par exemple, si les applications ont besoin d’une connectivité à un compte de stockage Azure spécifique, vous pouvez utiliser des filtres basés sur un nom de domaine complet. Avec les filtres basés sur le nom de domaine complet, les applications n’envoient pas de données à des comptes de stockage non autorisés. Si vous utilisez uniquement des groupes de sécurité réseau, vous ne pouvez pas empêcher ce scénario. Cette conception est souvent utilisée lorsque le trafic sortant nécessite un filtrage basé sur un nom de domaine complet. Un scénario est lorsque vous limiter le trafic de sortie à partir d’un cluster AKS.

Architectures

Le diagramme suivant illustre le flux de trafic pour les connexions HTTP(S) entrantes à partir d’un client extérieur.

Le diagramme suivant illustre le flux de trafic pour les connexions sortantes des machines virtuelles réseau vers Internet. Un exemple consiste à se connecter à des systèmes principaux ou à obtenir des mises à jour du système d’exploitation.

Les étapes de flux de paquets pour chaque service sont les mêmes que dans les options de conception autonomes précédentes.

Application Gateway devant la conception du pare-feu Azure

Cette conception est expliquée plus en détail dans réseau de confiance zéro pour les applications web avec pare-feu Azure et Application Gateway. Cet article se concentre sur la comparaison avec les autres options de conception. Dans cette topologie, le trafic web entrant transite à la fois pare-feu Azure et pare-feu d’applications web. Le pare-feu d’applications web offre une protection au niveau de la couche application web. Le Pare-feu Azure sert de point de journalisation et de contrôle central et inspecte le trafic entre Application Gateway et les serveurs principaux. Dans cette conception, Application Gateway et pare-feu Azure ne s’assoient pas en parallèle, mais s’assoient devant l’autre.

Avec pare-feu Azure Premium, cette conception peut prendre en charge les scénarios de bout en bout, où le pare-feu Azure applique l’inspection TLS pour effectuer des IDPS sur le trafic chiffré entre Application Gateway et le serveur principal web.

Cette conception convient aux applications qui doivent identifier les adresses IP sources du client entrantes. Par exemple, il peut être utilisé pour traiter du contenu spécifique à la géolocalisation ou pour la journalisation. Application Gateway devant la conception du 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 cet en-tête. Pour plus d’informations, consultez fonctionnement d’une passerelle d’application.

Les connexions HTTP(S) entrantes à partir d’Internet doivent être envoyées à l’adresse IP publique d’Application Gateway. Les connexions HTTP(S) à partir d’Azure ou locales doivent être envoyées à son adresse IP privée. À partir d’Application Gateway, les UDR garantissent que les paquets sont routés via le Pare-feu Azure. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article.

Pour les connexions non HTTP(S) entrantes, le trafic doit cibler l’adresse IP publique du Pare-feu Azure s’il provient de l’Internet public. Le trafic doit être envoyé via le Pare-feu Azure par des UDR s’il provient d’autres réseaux virtuels Azure ou de réseaux locaux. Tous les flux sortants des machines virtuelles Azure sont transférés vers le Pare-feu Azure par des UDR.

Un aspect important de cette conception est que Le Pare-feu Azure Premium voit le trafic avec une adresse IP source à partir du sous-réseau 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/12ou 100.64.0.0/10), le Pare-feu Azure Premium traite le trafic d’Application Gateway comme interne et n’applique pas de règles IDPS pour le trafic entrant. Par conséquent, nous vous recommandons de modifier les préfixes privés IDPS dans la stratégie de pare-feu Azure. Cette modification garantit que le sous-réseau Application Gateway n’est pas considéré comme une source interne, ce qui permet aux signatures IDPS entrantes et sortantes d’être appliquées au trafic. Vous trouverez plus d’informations sur les instructions de règle IDPS du pare-feu Azure et les préfixes d’adresses IP privées pour IDPS dans règles IDPS du pare-feu Azure.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	Oui
Trafic HTTP(S) d’Azure vers Internet ou local	Non	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	Oui

Pour le trafic web d’un site local ou d’Internet vers Azure, le Pare-feu Azure inspecte les flux que le Pare-feu d’applications web autorise. Selon que Application Gateway chiffre le trafic principal, qui est le trafic d’Application Gateway vers les serveurs d’applications, différents scénarios peuvent se produire :

• Application Gateway chiffre le trafic en suivant les principes de confiance zéro comme chiffrement TLS de bout en bout, et le Pare-feu Azure reçoit le trafic chiffré. Le Pare-feu Azure Standard peut toujours appliquer des règles d’inspection, telles que le filtrage de couche 3 et de couche 4 dans les règles réseau ou le filtrage FQDN dans les règles d’application, à l’aide de l’en-tête SNI (Server Name Indication) TLS. pare-feu Azure Premium offre une visibilité plus approfondie avec l’inspection TLS, telle que le filtrage basé sur l’URL.

• Si Application Gateway envoie du trafic non chiffré aux serveurs d’applications, le Pare-feu Azure voit le trafic entrant en texte clair. L’inspection TLS n’est pas nécessaire dans le Pare-feu Azure.

• Si IDPS est activé dans le Pare-feu Azure, il vérifie que l’en-tête de l’hôte HTTP correspond à l’adresse IP de destination. Pour effectuer cette vérification, elle a besoin de la résolution de noms pour le nom de domaine complet spécifié dans l’en-tête de l’hôte. Cette résolution de noms peut être effectuée à l’aide de zones privées Azure DNS et des paramètres DNS du pare-feu Azure par défaut . Elle peut également être obtenue avec des serveurs DNS personnalisés qui doivent être configurés dans les paramètres du Pare-feu Azure. Si vous n’avez pas d’accès administratif au réseau virtuel sur lequel le Pare-feu Azure est déployé, cette dernière méthode est votre seule option. L’un des exemples est celui des instances de pare-feu Azure déployées dans des hubs sécurisés par Azure Virtual WAN.

Architecture

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

Flux de travail

Le trafic réseau à partir de l’Internet public suit ce flux :

1. Le client démarre la connexion à l’adresse IP publique d’Application Gateway.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AppGwPIP

2. La demande adressée à l’adresse IP publique Application Gateway est distribuée à une instance principale de la passerelle, qui est 192.168.200.7 dans cet exemple. L’instance Application Gateway arrête la connexion du client et établit une nouvelle connexion avec l’un des back-ends. L’UDR à 192.168.1.0/24 dans le sous-réseau Application Gateway transfère le paquet au Pare-feu Azure et conserve l’adresse IP de destination à l’application web.

   • Adresse IP source, qui est l’adresse IP privée de l’instance Application Gateway : 192.168.200.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : ClientPIP

3. Le Pare-feu Azure n’applique pas SNAT au trafic, car le trafic passe à une adresse IP privée. Il transfère le trafic à la machine virtuelle de l’application si les règles l’autorisent. Pour plus d’informations, consultez Plages d’adresses IP privées SNAT du Pare-feu Azure. Toutefois, si le trafic atteint une règle d’application dans le pare-feu, la charge de travail voit l’adresse IP source de l’instance de pare-feu spécifique qui a traité le paquet, car le Pare-feu Azure proxies la connexion.

   • Adresse IP source si le trafic est autorisé par une règle de réseau pare-feu Azure et est l’adresse IP privée de l’une des instances Application Gateway : 192.168.200.7
   • Adresse IP source si le trafic est autorisé par une règle d’application pare-feu Azure et est l’adresse IP privée de l’une des instances du Pare-feu Azure : 192.168.100.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : ClientPIP

4. La machine virtuelle répond à la demande, ce qui inverse à la fois les adresses IP source et de destination. L’UDR pour 192.168.200.0/24 capture le paquet renvoyé à Application Gateway, le redirige vers le Pare-feu Azure et conserve l’adresse IP de destination vers Application Gateway.

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

5. Là encore, le pare-feu Azure n’applique pas SNAT au trafic, car il accède à une adresse IP privée et transfère le trafic vers Application Gateway.

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

6. 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, que l’UDR pour 0.0.0.0/0 définit.

En guise de variante de cette conception, vous pouvez configurer la DNAT privée dans le Pare-feu Azure afin que la charge de travail de l’application voit les adresses IP des instances du Pare-feu Azure comme source et qu’aucune UDR n’est requise. L’adresse IP source des clients d’application est déjà conservée dans l’en-tête HTTP X-Forwarded-For par Application Gateway. Par conséquent, si le Pare-feu Azure applique DNAT au trafic, aucune information n’est perdue. Pour plus d’informations, consultez Filtrer le trafic Internet entrant ou intranet avec la stratégie de pare-feu Azure DNAT à l’aide du portail Azure.

Pare-feu Azure devant la conception d’Application Gateway

Cette conception permet au Pare-feu Azure de filtrer et d’ignorer le trafic malveillant avant d’atteindre 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 sortant, quel que soit le protocole. Il existe trois modes dans lesquels vous pouvez configurer théoriquement le Pare-feu Azure :

• Pare-feu Azure avec des règles DNAT : Pare-feu Azure échange uniquement les adresses IP au niveau de la couche d’adresses IP, mais il ne traite pas la charge utile. Par conséquent, elle ne modifie pas les en-têtes HTTP.

• Pare-feu Azure avec des règles d’application et l’inspection TLS désactivée : Pare-feu Azure peut examiner l’en-tête SNI dans TLS, mais il ne le déchiffre pas. Une nouvelle connexion TCP est créée du pare-feu au tronçon suivant. Dans cet exemple, il s’agit d’Application Gateway.

• Pare-feu Azure avec des règles d’application et une inspection TLS activée : Pare-feu Azure examine le contenu des paquets et les déchiffre. Il sert de proxy HTTP et peut définir les en-têtes HTTP X-Forwarded-For pour conserver l’adresse IP. Toutefois, il présente un certificat auto-généré au client. Pour les applications basées sur Internet, l’utilisation d’un certificat auto-généré n’est pas une option, car un avertissement de sécurité est envoyé aux clients d’application à partir de leur navigateur.

Dans les deux premières options, qui sont les seules options valides pour les applications basées sur Internet, le Pare-feu Azure applique SNAT au trafic entrant sans définir l’en-tête X-Forwarded-For. Par conséquent, l’application ne peut pas voir l’adresse IP d’origine des requêtes HTTP. Pour les tâches d’administration, telles que la résolution des problèmes, vous pouvez obtenir l’adresse IP du client réelle pour une connexion spécifique en la mettant en corrélation avec les journaux SNAT du Pare-feu Azure.

Les avantages de ce scénario sont limités, car, sauf si vous utilisez l’inspection TLS et que vous présentez des certificats auto-générés aux clients, le Pare-feu Azure voit uniquement le trafic chiffré qui passe à Application Gateway. Ce scénario est généralement possible uniquement pour les applications internes. Toutefois, il peut y avoir des scénarios où cette conception est préférée. Un scénario est si un autre pare-feu d’applications web existe précédemment dans le réseau (par exemple, avec azure Front Door), qui peut capturer l’adresse IP source d’origine dans l’en-tête HTTP X-Forwarded-For. Vous pouvez également préférer cette conception si de nombreuses adresses IP publiques sont requises, car Application Gateway prend en charge une seule adresse IP.

Les flux entrants HTTP(S) à partir de l’Internet public doivent cibler l’adresse IP publique du Pare-feu Azure. Le Pare-feu Azure dnat et SNAT les paquets vers l’adresse IP privée d’Application Gateway. À partir d’autres réseaux virtuels Azure ou réseaux locaux, le trafic HTTP(S) doit être envoyé à l’adresse IP privée Application Gateway et transféré via le Pare-feu Azure avec des UDR. Le routage de réseau virtuel standard garantit que le retour du trafic des machines virtuelles Azure revient à Application Gateway et à partir d’Application Gateway vers le Pare-feu Azure si des règles DNAT ont été utilisées. Pour le trafic provenant d’un site local ou d’Azure, utilisez des UDR dans le sous-réseau Application Gateway. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article. Tout le trafic sortant des machines virtuelles Azure vers Internet est envoyé via le Pare-feu Azure par des UDR.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	Oui
Trafic HTTP(S) d’Azure vers Internet ou local	Non	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	Oui

Pour le trafic HTTP(S) entrant, le Pare-feu Azure ne déchiffre généralement pas le trafic. Il applique plutôt 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 applique la SNAT aux 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 d’entrer dans le réseau virtuel Azure.

Flux de travail

Le trafic réseau à partir de l’Internet public suit ce flux :

1. Le client démarre la connexion à l’adresse IP publique du Pare-feu Azure.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AzFWPIP

2. La demande adressée à l’adresse IP publique du Pare-feu Azure est distribuée à une instance principale du pare-feu, qui est 192.168.100.7 dans cet exemple. Le Pare-feu Azure applique DNAT au port web, généralement TCP 443, à l’adresse IP privée de l’instance Application Gateway. Le Pare-feu Azure applique également SNAT lorsque vous effectuez DNAT. Pour plus d’informations, consultez Problèmes connus du Pare-feu Azure.

   • Adresse IP source, qui est l’adresse IP privée de l’instance de pare-feu Azure : 192.168.100.7
   • Adresse IP de destination : 192.168.200.4

3. Application Gateway établit une nouvelle session entre l’instance qui gère la connexion et l’un des serveurs principaux. L’adresse IP d’origine du client n’est pas dans le paquet.

   • Adresse IP source, qui est l’adresse IP privée de l’instance Application Gateway : 192.168.200.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : 192.168.100.7

4. La machine virtuelle répond à Application Gateway, ce qui inverse les adresses IP source et de destination :

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

5. Application Gateway répond à l’adresse IP source SNAT de l’instance de pare-feu Azure. Le Pare-feu Azure voit l’adresse IP interne d’Application Gateway, .4, comme adresse IP source, même si la connexion provient d’une instance Application Gateway spécifique comme .7.

   • Adresse IP source : 192.168.200.4
   • Adresse IP de destination : 192.168.100.7

6. Le Pare-feu Azure annule SNAT et DNAT et répond au client.

   • Adresse IP source : AzFwPIP
   • Adresse IP de destination : ClientPIP

Application Gateway a besoin d’une adresse IP publique pour que Microsoft puisse la gérer, même si aucun écouteur n’est configuré pour les applications.

Remarque

Un itinéraire par défaut vers 0.0.0.0/0 dans le sous-réseau Application Gateway qui pointe vers le Pare-feu Azure n’est pas pris en charge, car il interrompt le trafic du plan de contrôle requis par Application Gateway pour fonctionner correctement.

Clients locaux

Les conceptions précédentes montrent tous les clients d’application entrants à partir 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 quelques différences notables :

• Une passerelle VPN ou une passerelle ExpressRoute se trouve devant le Pare-feu Azure ou Application Gateway.

• Le pare-feu d’applications web utilise l’adresse IP privée d’Application Gateway.

• Le Pare-feu Azure ne prend pas en charge DNAT pour les adresses IP privées. Vous devez donc utiliser des UDR pour envoyer du trafic entrant au Pare-feu Azure à partir des passerelles VPN ou ExpressRoute.

• Veillez à vérifier les mises en garde autour de de tunneling forcé pour Application Gateway et pour pare-feu Azure. Même si votre charge de travail n’a pas besoin de connectivité sortante à l’Internet public, vous ne pouvez pas injecter un itinéraire par défaut comme 0.0.0.0/0 pour Application Gateway qui pointe vers le réseau local, car il interrompt le trafic. Pour Application Gateway, l’itinéraire par défaut doit pointer vers l’Internet public.

Architecture

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

Même si tous les clients se trouvent localement ou dans Azure, Application Gateway et pare-feu Azure doivent avoir des adresses IP publiques. Ces adresses IP publiques permettent à Microsoft de gérer les services.

Topologie hub-and-spoke

Les conceptions de cet article s’appliquent à une topologie hub-and-spoke. Les ressources partagées d’un réseau virtuel hub central se connectent aux applications dans des réseaux virtuels spoke distincts via des peerings de réseaux virtuels.

Architecture

• Le Pare-feu Azure est déployé dans le réseau virtuel hub central. Le diagramme précédent montre comment déployer Application Gateway dans le hub. Les équipes d’applications gèrent souvent des composants tels que les passerelles Application Gateway ou gestion des API. Dans ce scénario, ces composants sont déployés dans les réseaux virtuels spoke.

• Portez une attention particulière aux UDR dans les réseaux spoke. Lorsqu’un serveur d’applications dans un spoke reçoit le trafic d’une instance de pare-feu Azure spécifique, comme l’adresse IP 192.168.100.7 dans les exemples précédents, il doit renvoyer le trafic vers la même instance. Si un UDR dans le spoke définit le tronçon suivant du trafic adressé au hub vers l’adresse IP du Pare-feu Azure (192.168.100.4 dans les diagrammes précédents), les paquets de retour peuvent se retrouver sur une autre instance du Pare-feu Azure. Cette situation provoque un routage asymétrique. Si vous avez des UDR dans les réseaux virtuels spoke, veillez à envoyer le trafic aux services partagés dans le 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 à d’autres appliances virtuelles réseau ou proxys inverses qui peuvent être déployés dans le réseau virtuel hub.

• Vous ne pouvez pas définir le tronçon suivant pour les sous-réseaux Application Gateway ou Pare-feu Azure via des itinéraires statiques avec un type de tronçon suivant de Virtual Network. Ce type de tronçon suivant est valide uniquement dans le réseau virtuel local et non dans les peerings de réseaux virtuels. Pour plus d’informations sur les UDR et les types de tronçons suivants, consultez routage du trafic de réseau virtuel.

Routage asymétrique

Le diagramme suivant montre comment un spoke renvoie le trafic SNAT à l’équilibreur de charge Azure du Pare-feu Azure. Cette configuration provoque le routage asymétrique.

Pour résoudre ce problème, définissez les UDR dans le spoke sans le sous-réseau du Pare-feu Azure et avec uniquement les sous-réseaux où se trouvent les services partagés. Dans le diagramme précédent, l’UDR correct dans le spoke ne doit contenir que 192.168.1.0/24. Elle ne doit pas contenir la plage entière 192.168.0.0/16, marquée en rouge.

Intégration à d’autres produits Azure

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

Passerelle de gestion des API

Intégrez des services de proxy inverse comme passerelle gestion des API dans les conceptions précédentes pour fournir des fonctionnalités telles que la limitation d’API ou le proxy d’authentification. L’intégration de la passerelle Gestion des API n’affecte pas considérablement les conceptions. La principale différence est que au lieu du proxy inverse Application Gateway unique, il existe deux proxys inverses chaînés les uns derrière les autres.

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

AKS

Pour les charges de travail qui s’exécutent sur un cluster AKS, vous pouvez déployer Application Gateway indépendamment du cluster. Vous pouvez également l’intégrer au cluster AKS à l’aide du contrôleur d’entrée Application Gateway . Lorsque vous configurez des objets spécifiques aux niveaux Kubernetes, tels que les services et les ingresses, Application Gateway s’adapte automatiquement sans avoir besoin d’étapes manuelles supplémentaires.

Le Pare-feu Azure joue un rôle important dans la sécurité du cluster AKS. Il fournit la fonctionnalité requise pour filtrer le trafic de sortie à partir du cluster AKS en fonction du nom de domaine complet, et non seulement de l’adresse IP. Pour plus d’informations, consultez Limiter le trafic réseau avec le Pare-feu Azure dans AKS.

Lorsque vous combinez Application Gateway et le Pare-feu Azure pour protéger un cluster AKS, il est préférable d’utiliser l’option de conception parallèle. Application Gateway avec le pare-feu d’applications web traite les demandes de connexion entrantes aux applications web du cluster. Le Pare-feu Azure autorise uniquement les connexions sortantes explicitement autorisées. Pour plus d’informations sur l’option de conception parallèle, consultez architecture de base de référence pour un cluster AKS.

Azure Front Door - Service de passerelle réseau de Microsoft

Azure Front Door dispose de fonctionnalités qui se chevauchent avec Application Gateway dans plusieurs domaines. Les deux services fournissent un pare-feu d’applications web, un déchargement SSL et un routage basé sur l’URL. Toutefois, une différence clé réside dans le fait qu’Application Gateway fonctionne au sein d’un réseau virtuel, Azure Front Door est un service global décentralisé.

Vous pouvez parfois simplifier la conception du réseau virtuel en remplaçant Application Gateway par une instance Azure Front Door décentralisée. La plupart des conceptions décrites dans cet article s’appliquent toujours, à l’exception de l’option permettant de placer le Pare-feu Azure devant Azure Front Door.

Un scénario consiste à utiliser le Pare-feu Azure devant Application Gateway dans votre réseau virtuel. Application Gateway injecte l’en-tête X-Forwarded-For avec 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 entre dans le réseau virtuel et atteigne le Pare-feu Azure. Vous pouvez également sécuriser votre origine avec Azure Private Link dans Azure Front Door Premium.

Pour plus d’informations sur les différences entre les deux services, ou quand utiliser chacun d’eux, consultez Forum aux questions sur Azure Front Door.

Autres appliances virtuelles réseau

Les produits Microsoft ne sont pas le seul choix d’implémenter le pare-feu d’applications web ou les fonctionnalités de pare-feu de nouvelle génération dans Azure. Un large éventail de partenaires Microsoft fournissent des appliances virtuelles réseau. Les concepts et les conceptions sont essentiellement les mêmes que dans cet article, mais il existe quelques considérations importantes :

• Les appliances virtuelles réseau partenaires pour le pare-feu de nouvelle génération peuvent fournir davantage de contrôle et de flexibilité pour les configurations NAT que le Pare-feu Azure ne prend pas en charge. Les exemples incluent 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 aux appliances virtuelles où les utilisateurs doivent gérer l’extensibilité et la résilience sur de nombreuses appliances.

• Lorsque vous utilisez des appliances virtuelles virtuelles réseau dans Azure, utilisez actif-actif et la mise à l’échelle automatique des configurations de afin que ces appliances ne soient pas un goulot d’étranglement pour les applications qui s’exécutent dans le réseau virtuel.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Jose Moreno | Ingénieur client principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

En savoir plus sur les technologies de composant :

• Qu’est-ce qu’Application Gateway ?
• Qu’est-ce qu’Azure Firewall ?
• Qu’est-ce qu’Azure Front Door ?
• AKS
• Qu’est-ce que le réseau virtuel ?
• Qu’est-ce que le pare-feu d’applications web ?
• Architecture de référence pour un cluster AKS

Ressources associées

Explorez les architectures associées :

• Implémenter un réseau hybride sécurisé
• applications web gérées en toute sécurité
• logiciel multilocataire en tant que service sur Azure
• déploiement Entreprise à l’aide d’App Service Environment
• déploiement d’entreprise à haute disponibilité à l’aide d’App Service Environment

Pour sécuriser les charges de travail d’application Azure, utilisez des mesures de protection telles que l’authentification et le chiffrement dans les applications elles-mêmes. Vous pouvez ajouter des couches de sécurité aux réseaux virtuels qui hébergent les applications. Ces couches de sécurité aident à protéger les flux entrants de l’application contre une utilisation inattendue. Ils limitent également les flux sortants vers Internet aux points de terminaison requis par votre application. Cet article décrit réseau virtuel Azure services de sécurité tels qu’Azure DDoS Protection, pare-feu Azure et Azure Application Gateway. Il décrit également quand utiliser chaque service et les options de conception réseau qui les combinent.

• protection DDoS, combinée aux meilleures pratiques de conception d’application, fournit des fonctionnalités d’atténuation DDoS améliorées qui améliorent la défense contre les attaques DDoS. Vous devez activer la protection DDoS sur chaque réseau virtuel de périmètre.

• pare-feu Azure est un pare-feu managé de nouvelle génération qui fournit fonctionnalités de traduction d’adresses réseau (NAT). Le Pare-feu Azure filtre les paquets basés sur les adresses IP et les ports TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol). Il peut filtrer le trafic à l’aide d’attributs basés sur des applications, tels que HTTP(S) et SQL. Le Pare-feu Azure applique également des informations sur les menaces Microsoft pour aider à identifier les adresses IP malveillantes. Pour plus d’informations, consultez documentation sur le Pare-feu Azure.

• Pare-feu Azure Premium inclut toutes les fonctionnalités du Pare-feu Azure Standard, en plus des fonctionnalités telles que l’inspection de la sécurité de la couche de transport (TLS) et le système de détection et de prévention des intrusions (IDPS).

• Application Gateway est un équilibreur de charge de trafic web managé et un proxy inverse complet HTTP(S) qui peut effectuer le chiffrement et le déchiffrement SSL (Secure Socket Layer). Application Gateway 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 Azure pour inspecter le trafic web et détecter les attaques au niveau de la couche HTTP. Pour plus d’informations, consultez documentation Application Gateway.

• de pare-feu d’applications web est un ajout facultatif à Application Gateway. Il inspecte les requêtes HTTP et empêche les attaques de couche web, telles que l’injection SQL et le script intersite. Pour plus d’informations, consultez documentation sur le pare-feu d’applications web.

Ces services Azure se complètent. Selon vos besoins, l’utilisation d’un service peut mieux convenir à vos charges de travail. Toutefois, vous pouvez utiliser ces services ensemble pour fournir une protection optimale aux couches réseau et application. Utilisez l’arbre de décision suivant et les exemples de cet article pour choisir la meilleure option de sécurité pour le réseau virtuel de votre application.

Pare-feu Azure et Application Gateway utilisent différentes technologies pour sécuriser différents types de flux de données.

Flux d’application	Peut être filtré par le Pare-feu Azure	Peut être filtré par le pare-feu d’applications web sur Application Gateway
Trafic HTTP(S) à partir d’un site local ou d’Internet vers Azure (entrant)	Oui	Oui
Trafic HTTP(S) d’Azure vers un site local ou Internet (sortant)	Oui	Non
Trafic non HTTP(S) (entrant ou sortant)	Oui	Non

La conception peut varier pour chaque application en fonction des flux réseau dont elle a besoin. Le diagramme suivant fournit un arbre de décision simplifié qui vous aide à choisir l’approche recommandée pour votre application. Ce choix varie selon que l’application est publiée via HTTP(S) ou un autre protocole.

Cet article décrit les conceptions largement recommandées présentées dans le diagramme de flux et les conceptions adaptées aux scénarios moins courants :

• Pare-feu Azure uniquement: Utiliser cette conception lorsqu’il n’existe aucune application web dans le réseau virtuel. Il contrôle à la fois le trafic entrant vers les applications et le trafic sortant.

• Application Gateway uniquement: Utilisez cette conception lorsque seules les applications web se trouvent dans le réseau virtuel et groupes de sécurité réseau (NSG) fournissent un filtrage de sortie suffisant. Le Pare-feu Azure fournit des fonctionnalités qui peuvent aider à empêcher plusieurs scénarios d’attaque, tels que l’exfiltration de données et IDPS. Par conséquent, la conception Application Gateway uniquement n’est généralement pas recommandée. Elle n’est donc pas incluse dans le graphique de flux précédent.

• Pare-feu Azure et Application Gateway en parallèle: Utilisez cette conception lorsque vous souhaitez qu’Application Gateway protège les applications HTTP(S) contre les attaques web et le Pare-feu Azure pour protéger toutes les autres charges de travail et filtrer le trafic sortant. Pare-feu Azure et Application Gateway en parallèle sont une conception courante.

• Application Gateway devant le Pare-feu Azure: Utilisez cette conception lorsque vous souhaitez qu’Azure Firewall inspecte tout le trafic, le Pare-feu d’applications web pour protéger le trafic web et l’application pour identifier l’adresse IP source du client. Avec l’inspection du Pare-feu Azure Premium et TLS, cette conception prend également en charge le scénario SSL de bout en bout.

• Pare-feu Azure devant application Gateway: Utilisez cette conception lorsque vous souhaitez qu’Azure Firewall inspecte et filtre le trafic avant qu’il n’atteigne Application Gateway. Étant donné que le Pare-feu Azure ne déchiffre pas le trafic HTTPS, ses fonctionnalités ajoutées à Application Gateway sont limitées. Ce scénario n’est pas documenté dans le graphique de flux précédent.

Les variantes de ces conceptions fondamentales sont décrites plus loin dans cet article et incluent :

• clients d’application locaux.
• réseaux hub-and-spoke.
• implémentations d’Azure Kubernetes Service (AKS).

Vous pouvez ajouter d’autres services de proxy inverse, comme une passerelle Gestion des API Azure ou Azure Front Door. Vous pouvez également remplacer les ressources Azure par des appliances virtuelles réseau non-Microsoft .

Remarque

Dans les scénarios suivants, une machine virtuelle Azure est utilisée comme exemple de charge de travail d’application web. Ces scénarios sont également valides pour d’autres types de charge de travail, tels que des conteneurs ou Azure Web Apps. Pour les configurations qui incluent des points de terminaison privés, tenez compte des recommandations dans scénarios de pare-feu Azure pour inspecter le trafic destiné à un point de terminaison privé.

Conception pare-feu Azure uniquement

S’il n’existe aucune charge de travail basée sur le web dans le réseau virtuel qui peut tirer parti du pare-feu d’applications web, vous pouvez utiliser la conception pare-feu Azure uniquement. La conception de cet exemple est simple, mais vous pouvez passer en revue le flux de paquets pour mieux comprendre les conceptions plus complexes. Dans cette conception, tout le trafic entrant est envoyé au Pare-feu Azure via des itinéraires définis par l’utilisateur (UDR) pour les connexions à partir d’un réseau local 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 illustré dans le diagramme suivant. Les UDR dirigent le trafic sortant à partir de réseaux virtuels Azure vers le Pare-feu Azure, comme indiqué dans la boîte de dialogue suivante.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	N/A	Oui
Trafic HTTP(S) d’Azure vers Internet ou local	N/A	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	N/A	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	N/A	Oui

Le Pare-feu Azure n’inspecte pas le trafic HTTP(S) entrant. Mais il peut appliquer des règles de couche 3 et 4 et des règles d’application de nom de domaine complet (FQDN). Le Pare-feu Azure inspecte le trafic HTTP(S) sortant, en fonction du niveau pare-feu Azure et de la configuration de l’inspection TLS :

• Pare-feu Azure Standard inspecte uniquement les attributs de couche 3 et 4 des paquets dans les règles réseau et l’en-tête HTTP 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 (comme l’agent utilisateur) et l’activation de l’inspection TLS pour une analyse approfondie des paquets. Toutefois, le pare-feu Azure n’est pas identique au pare-feu d’applications web. Si vous avez des charges de travail web dans votre réseau virtuel, nous vous recommandons d’utiliser le pare-feu d’applications web.

L’exemple de procédure pas à pas de paquets suivant montre comment un client accède à une application hébergée par une machine virtuelle à partir de l’Internet public. Le diagramme inclut une seule machine virtuelle par souci de simplicité. Pour une disponibilité et une scalabilité plus élevées, il existe 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 des connexions sortantes à partir de la machine virtuelle du sous-réseau de l’application à l’aide de l’UDR.

• Dans cet exemple, le Pare-feu Azure déploie automatiquement plusieurs instances avec l’adresse IP frontale 192.168.100.4 et les adresses internes dans la plage 192.168.100.0/26. Normalement, ces instances ne sont pas visibles par l’administrateur Azure. Toutefois, il peut être utile de les connaître pour résoudre les problèmes réseau.

• Si le trafic provient d’un réseau privé virtuel local (VPN) ou d'passerelle Azure ExpressRoute au lieu d’Internet, le client démarre la connexion à l’adresse IP de la machine virtuelle. Elle ne démarre pas la connexion à l’adresse IP du pare-feu, et le pare-feu ne fait pas de nat source par défaut.

Architecture

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

Flux de travail

1. Le client démarre la connexion à l’adresse IP publique du Pare-feu Azure.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AzFwPIP

2. La demande adressée à l’adresse IP publique du Pare-feu Azure est distribuée à une instance principale du pare-feu, qui est 192.168.100.7 dans cet exemple. La règle DNAT (Destination Network Address Translation) pare-feu Azure traduit l’adresse IP de destination en adresse IP de l’application à l’intérieur du réseau virtuel. Le Pare-feu Azure implémente également traduction d’adresses réseau source (SNAT) sur le paquet s’il utilise 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 d’application, ce qui inverse les adresses IP source et de destination. Le flux entrant ne nécessite pas d’UDR, car l’adresse IP source est l’adresse IP du pare-feu Azure. L’UDR dans le diagramme pour 0.0.0.0/0 concerne les connexions sortantes afin de s’assurer que les paquets 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. 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

Conception Application Gateway uniquement

Cette conception décrit le scénario où seules les applications web existent dans le réseau virtuel, et l’inspection du trafic sortant avec des groupes de sécurité réseau est suffisante pour protéger les flux sortants vers Internet.

Remarque

Nous vous déconseillons cette conception, car l’utilisation du Pare-feu Azure pour contrôler les flux sortants, au lieu de s’appuyer uniquement sur des groupes de sécurité réseau, permet d’éviter les scénarios d’attaque tels que l’exfiltration de données. Avec le Pare-feu Azure, vous pouvez vous assurer que vos charges de travail envoient uniquement des données à une liste approuvée d’URL. En outre, les groupes de sécurité réseau fonctionnent uniquement au niveau de la couche 3 et de la couche 4 et ne prennent pas en charge les noms de domaine complets.

La principale différence par rapport à la conception précédente du Pare-feu Azure est que Application Gateway ne sert pas d’appareil de routage avec NAT. Au lieu de cela, il fonctionne comme un proxy d’application inverse complet. Cette approche signifie qu’Application Gateway arrête la session web du client et établit une session distincte avec l’un de ses serveurs principaux. Les connexions HTTP(S) entrantes à partir d’Internet sont envoyées à l’adresse IP publique d’Application Gateway, et les connexions d’Azure ou locales utilisent l’adresse IP privée de la passerelle. Le trafic de retour à partir des machines virtuelles Azure suit le routage de réseau virtuel standard vers Application Gateway. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article. Les flux Internet sortants des machines virtuelles Azure accèdent directement à Internet.

Le tableau suivant récapitule les flux de trafic.

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	N/A
Trafic HTTP(S) d’Azure vers Internet ou local	Non	N/A
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	N/A
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	N/A

Architecture

L’exemple de procédure pas à pas de paquet suivant montre comment un client accède à l’application hébergée par la machine virtuelle à partir de l’Internet public.

Flux de travail

1. Le client démarre la connexion à l’adresse IP publique d’Application Gateway.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AppGwPIP

2. La demande adressée à l’adresse IP publique Application Gateway est distribuée à une instance principale de la passerelle, qui est 192.168.200.7 dans cet exemple. L’instance Application Gateway qui reçoit la requête arrête la connexion du client et établit une nouvelle connexion avec l’un des back-ends. Le serveur principal voit l’instance Application Gateway comme l’adresse IP source. Application Gateway insère un en-tête HTTP X-Forwarded-For avec l’adresse IP du client d’origine.

   • Adresse IP source, qui est l’adresse IP privée de l’instance Application Gateway : 192.168.200.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : ClientPIP

3. La machine virtuelle répond à la demande d’application et inverse les adresses IP source et de destination. La machine virtuelle peut atteindre Application Gateway. Elle n’a donc pas besoin d’un UDR.

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

4. L’instance Application Gateway répond au client.

   • Adresse IP source : AppGwPIP
   • Adresse IP de destination : ClientPIP

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

• Dans cet exemple, l’adresse IP 192.168.200.7 est l’une des instances déployées automatiquement par le service Application Gateway. Il a l’adresse IP frontale interne et privée 192.168.200.4. Ces instances individuelles sont normalement invisibles pour l’administrateur Azure. Mais notez la différence peut être utile, par exemple lorsque vous résolvez 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 au lieu de l’adresse IP publique.

Remarque

Pour plus d’informations sur l’en-tête X-Forwarded-For et sur la façon de conserver le nom d’hôte sur une demande, consultez Conserver l’hôte HTTP d’origine.

Pare-feu Azure et Application Gateway en conception parallèle

En raison de sa simplicité et de sa flexibilité, il est souvent préférable d’exécuter Application Gateway et le Pare-feu Azure en parallèle.

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

Les connexions HTTP(S) entrantes à partir d’Internet doivent être envoyées à l’adresse IP publique d’Application Gateway. Les connexions HTTP(S) à partir d’Azure ou locales doivent être envoyées à son adresse IP privée. Le routage de réseau virtuel standard envoie les paquets d’Application Gateway aux machines virtuelles de destination et à partir des machines virtuelles de destination vers Application Gateway. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article.

Pour les connexions non HTTP(S) entrantes, le trafic doit cibler l’adresse IP publique du Pare-feu Azure s’il provient de l’Internet public. Le trafic doit être envoyé via le Pare-feu Azure par des UDR s’il provient d’autres réseaux virtuels Azure ou de réseaux locaux. Tous les flux sortants des machines virtuelles Azure sont transférés vers le Pare-feu Azure par des UDR.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	Non
Trafic HTTP(S) d’Azure vers Internet ou local	Non	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	Oui

Cette conception fournit un filtrage de sortie beaucoup plus granulaire que l’utilisation uniquement de groupes de sécurité réseau. Par exemple, si les applications ont besoin d’une connectivité à un compte de stockage Azure spécifique, vous pouvez utiliser des filtres basés sur un nom de domaine complet. Avec les filtres basés sur le nom de domaine complet, les applications n’envoient pas de données à des comptes de stockage non autorisés. Si vous utilisez uniquement des groupes de sécurité réseau, vous ne pouvez pas empêcher ce scénario. Cette conception est souvent utilisée lorsque le trafic sortant nécessite un filtrage basé sur un nom de domaine complet. Un scénario est lorsque vous limiter le trafic de sortie à partir d’un cluster AKS.

Architectures

Le diagramme suivant illustre le flux de trafic pour les connexions HTTP(S) entrantes à partir d’un client extérieur.

Le diagramme suivant illustre le flux de trafic pour les connexions sortantes des machines virtuelles réseau vers Internet. Un exemple consiste à se connecter à des systèmes principaux ou à obtenir des mises à jour du système d’exploitation.

Les étapes de flux de paquets pour chaque service sont les mêmes que dans les options de conception autonomes précédentes.

Application Gateway devant la conception du pare-feu Azure

Cette conception est expliquée plus en détail dans réseau de confiance zéro pour les applications web avec pare-feu Azure et Application Gateway. Cet article se concentre sur la comparaison avec les autres options de conception. Dans cette topologie, le trafic web entrant transite à la fois pare-feu Azure et pare-feu d’applications web. Le pare-feu d’applications web offre une protection au niveau de la couche application web. Le Pare-feu Azure sert de point de journalisation et de contrôle central et inspecte le trafic entre Application Gateway et les serveurs principaux. Dans cette conception, Application Gateway et pare-feu Azure ne s’assoient pas en parallèle, mais s’assoient devant l’autre.

Avec pare-feu Azure Premium, cette conception peut prendre en charge les scénarios de bout en bout, où le pare-feu Azure applique l’inspection TLS pour effectuer des IDPS sur le trafic chiffré entre Application Gateway et le serveur principal web.

Cette conception convient aux applications qui doivent identifier les adresses IP sources du client entrantes. Par exemple, il peut être utilisé pour traiter du contenu spécifique à la géolocalisation ou pour la journalisation. Application Gateway devant la conception du 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 cet en-tête. Pour plus d’informations, consultez fonctionnement d’une passerelle d’application.

Les connexions HTTP(S) entrantes à partir d’Internet doivent être envoyées à l’adresse IP publique d’Application Gateway. Les connexions HTTP(S) à partir d’Azure ou locales doivent être envoyées à son adresse IP privée. À partir d’Application Gateway, les UDR garantissent que les paquets sont routés via le Pare-feu Azure. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article.

Pour les connexions non HTTP(S) entrantes, le trafic doit cibler l’adresse IP publique du Pare-feu Azure s’il provient de l’Internet public. Le trafic doit être envoyé via le Pare-feu Azure par des UDR s’il provient d’autres réseaux virtuels Azure ou de réseaux locaux. Tous les flux sortants des machines virtuelles Azure sont transférés vers le Pare-feu Azure par des UDR.

Un aspect important de cette conception est que Le Pare-feu Azure Premium voit le trafic avec une adresse IP source à partir du sous-réseau 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/12ou 100.64.0.0/10), le Pare-feu Azure Premium traite le trafic d’Application Gateway comme interne et n’applique pas de règles IDPS pour le trafic entrant. Par conséquent, nous vous recommandons de modifier les préfixes privés IDPS dans la stratégie de pare-feu Azure. Cette modification garantit que le sous-réseau Application Gateway n’est pas considéré comme une source interne, ce qui permet aux signatures IDPS entrantes et sortantes d’être appliquées au trafic. Vous trouverez plus d’informations sur les instructions de règle IDPS du pare-feu Azure et les préfixes d’adresses IP privées pour IDPS dans règles IDPS du pare-feu Azure.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	Oui
Trafic HTTP(S) d’Azure vers Internet ou local	Non	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	Oui

Pour le trafic web d’un site local ou d’Internet vers Azure, le Pare-feu Azure inspecte les flux que le Pare-feu d’applications web autorise. Selon que Application Gateway chiffre le trafic principal, qui est le trafic d’Application Gateway vers les serveurs d’applications, différents scénarios peuvent se produire :

• Application Gateway chiffre le trafic en suivant les principes de confiance zéro comme chiffrement TLS de bout en bout, et le Pare-feu Azure reçoit le trafic chiffré. Le Pare-feu Azure Standard peut toujours appliquer des règles d’inspection, telles que le filtrage de couche 3 et de couche 4 dans les règles réseau ou le filtrage FQDN dans les règles d’application, à l’aide de l’en-tête SNI (Server Name Indication) TLS. pare-feu Azure Premium offre une visibilité plus approfondie avec l’inspection TLS, telle que le filtrage basé sur l’URL.

• Si Application Gateway envoie du trafic non chiffré aux serveurs d’applications, le Pare-feu Azure voit le trafic entrant en texte clair. L’inspection TLS n’est pas nécessaire dans le Pare-feu Azure.

• Si IDPS est activé dans le Pare-feu Azure, il vérifie que l’en-tête de l’hôte HTTP correspond à l’adresse IP de destination. Pour effectuer cette vérification, elle a besoin de la résolution de noms pour le nom de domaine complet spécifié dans l’en-tête de l’hôte. Cette résolution de noms peut être effectuée à l’aide de zones privées Azure DNS et des paramètres DNS du pare-feu Azure par défaut . Elle peut également être obtenue avec des serveurs DNS personnalisés qui doivent être configurés dans les paramètres du Pare-feu Azure. Si vous n’avez pas d’accès administratif au réseau virtuel sur lequel le Pare-feu Azure est déployé, cette dernière méthode est votre seule option. L’un des exemples est celui des instances de pare-feu Azure déployées dans des hubs sécurisés par Azure Virtual WAN.

Architecture

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

Flux de travail

Le trafic réseau à partir de l’Internet public suit ce flux :

1. Le client démarre la connexion à l’adresse IP publique d’Application Gateway.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AppGwPIP

2. La demande adressée à l’adresse IP publique Application Gateway est distribuée à une instance principale de la passerelle, qui est 192.168.200.7 dans cet exemple. L’instance Application Gateway arrête la connexion du client et établit une nouvelle connexion avec l’un des back-ends. L’UDR à 192.168.1.0/24 dans le sous-réseau Application Gateway transfère le paquet au Pare-feu Azure et conserve l’adresse IP de destination à l’application web.

   • Adresse IP source, qui est l’adresse IP privée de l’instance Application Gateway : 192.168.200.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : ClientPIP

3. Le Pare-feu Azure n’applique pas SNAT au trafic, car le trafic passe à une adresse IP privée. Il transfère le trafic à la machine virtuelle de l’application si les règles l’autorisent. Pour plus d’informations, consultez Plages d’adresses IP privées SNAT du Pare-feu Azure. Toutefois, si le trafic atteint une règle d’application dans le pare-feu, la charge de travail voit l’adresse IP source de l’instance de pare-feu spécifique qui a traité le paquet, car le Pare-feu Azure proxies la connexion.

   • Adresse IP source si le trafic est autorisé par une règle de réseau pare-feu Azure et est l’adresse IP privée de l’une des instances Application Gateway : 192.168.200.7
   • Adresse IP source si le trafic est autorisé par une règle d’application pare-feu Azure et est l’adresse IP privée de l’une des instances du Pare-feu Azure : 192.168.100.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : ClientPIP

4. La machine virtuelle répond à la demande, ce qui inverse à la fois les adresses IP source et de destination. L’UDR pour 192.168.200.0/24 capture le paquet renvoyé à Application Gateway, le redirige vers le Pare-feu Azure et conserve l’adresse IP de destination vers Application Gateway.

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

5. Là encore, le pare-feu Azure n’applique pas SNAT au trafic, car il accède à une adresse IP privée et transfère le trafic vers Application Gateway.

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

6. 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, que l’UDR pour 0.0.0.0/0 définit.

En guise de variante de cette conception, vous pouvez configurer la DNAT privée dans le Pare-feu Azure afin que la charge de travail de l’application voit les adresses IP des instances du Pare-feu Azure comme source et qu’aucune UDR n’est requise. L’adresse IP source des clients d’application est déjà conservée dans l’en-tête HTTP X-Forwarded-For par Application Gateway. Par conséquent, si le Pare-feu Azure applique DNAT au trafic, aucune information n’est perdue. Pour plus d’informations, consultez Filtrer le trafic Internet entrant ou intranet avec la stratégie de pare-feu Azure DNAT à l’aide du portail Azure.

Pare-feu Azure devant la conception d’Application Gateway

Cette conception permet au Pare-feu Azure de filtrer et d’ignorer le trafic malveillant avant d’atteindre 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 sortant, quel que soit le protocole. Il existe trois modes dans lesquels vous pouvez configurer théoriquement le Pare-feu Azure :

• Pare-feu Azure avec des règles DNAT : Pare-feu Azure échange uniquement les adresses IP au niveau de la couche d’adresses IP, mais il ne traite pas la charge utile. Par conséquent, elle ne modifie pas les en-têtes HTTP.

• Pare-feu Azure avec des règles d’application et l’inspection TLS désactivée : Pare-feu Azure peut examiner l’en-tête SNI dans TLS, mais il ne le déchiffre pas. Une nouvelle connexion TCP est créée du pare-feu au tronçon suivant. Dans cet exemple, il s’agit d’Application Gateway.

• Pare-feu Azure avec des règles d’application et une inspection TLS activée : Pare-feu Azure examine le contenu des paquets et les déchiffre. Il sert de proxy HTTP et peut définir les en-têtes HTTP X-Forwarded-For pour conserver l’adresse IP. Toutefois, il présente un certificat auto-généré au client. Pour les applications basées sur Internet, l’utilisation d’un certificat auto-généré n’est pas une option, car un avertissement de sécurité est envoyé aux clients d’application à partir de leur navigateur.

Dans les deux premières options, qui sont les seules options valides pour les applications basées sur Internet, le Pare-feu Azure applique SNAT au trafic entrant sans définir l’en-tête X-Forwarded-For. Par conséquent, l’application ne peut pas voir l’adresse IP d’origine des requêtes HTTP. Pour les tâches d’administration, telles que la résolution des problèmes, vous pouvez obtenir l’adresse IP du client réelle pour une connexion spécifique en la mettant en corrélation avec les journaux SNAT du Pare-feu Azure.

Les avantages de ce scénario sont limités, car, sauf si vous utilisez l’inspection TLS et que vous présentez des certificats auto-générés aux clients, le Pare-feu Azure voit uniquement le trafic chiffré qui passe à Application Gateway. Ce scénario est généralement possible uniquement pour les applications internes. Toutefois, il peut y avoir des scénarios où cette conception est préférée. Un scénario est si un autre pare-feu d’applications web existe précédemment dans le réseau (par exemple, avec azure Front Door), qui peut capturer l’adresse IP source d’origine dans l’en-tête HTTP X-Forwarded-For. Vous pouvez également préférer cette conception si de nombreuses adresses IP publiques sont requises, car Application Gateway prend en charge une seule adresse IP.

Les flux entrants HTTP(S) à partir de l’Internet public doivent cibler l’adresse IP publique du Pare-feu Azure. Le Pare-feu Azure dnat et SNAT les paquets vers l’adresse IP privée d’Application Gateway. À partir d’autres réseaux virtuels Azure ou réseaux locaux, le trafic HTTP(S) doit être envoyé à l’adresse IP privée Application Gateway et transféré via le Pare-feu Azure avec des UDR. Le routage de réseau virtuel standard garantit que le retour du trafic des machines virtuelles Azure revient à Application Gateway et à partir d’Application Gateway vers le Pare-feu Azure si des règles DNAT ont été utilisées. Pour le trafic provenant d’un site local ou d’Azure, utilisez des UDR dans le sous-réseau Application Gateway. Pour plus d’informations, consultez la procédure pas à pas du paquet plus loin dans cet article. Tout le trafic sortant des machines virtuelles Azure vers Internet est envoyé via le Pare-feu Azure par des UDR.

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

Couler	Passe par Application Gateway/Pare-feu d’applications web	Passe par le pare-feu Azure
Trafic HTTP(S) à partir d’Internet ou localement vers Azure	Oui	Oui
Trafic HTTP(S) d’Azure vers Internet ou local	Non	Oui
Trafic non HTTP(S) à partir d’Internet ou localement vers Azure	Non	Oui
Trafic non HTTP(S) d’Azure vers Internet ou local	Non	Oui

Pour le trafic HTTP(S) entrant, le Pare-feu Azure ne déchiffre généralement pas le trafic. Il applique plutôt 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 applique la SNAT aux 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 d’entrer dans le réseau virtuel Azure.

Flux de travail

Le trafic réseau à partir de l’Internet public suit ce flux :

1. Le client démarre la connexion à l’adresse IP publique du Pare-feu Azure.

   • Adresse IP source : ClientPIP
   • Adresse IP de destination : AzFWPIP

2. La demande adressée à l’adresse IP publique du Pare-feu Azure est distribuée à une instance principale du pare-feu, qui est 192.168.100.7 dans cet exemple. Le Pare-feu Azure applique DNAT au port web, généralement TCP 443, à l’adresse IP privée de l’instance Application Gateway. Le Pare-feu Azure applique également SNAT lorsque vous effectuez DNAT. Pour plus d’informations, consultez Problèmes connus du Pare-feu Azure.

   • Adresse IP source, qui est l’adresse IP privée de l’instance de pare-feu Azure : 192.168.100.7
   • Adresse IP de destination : 192.168.200.4

3. Application Gateway établit une nouvelle session entre l’instance qui gère la connexion et l’un des serveurs principaux. L’adresse IP d’origine du client n’est pas dans le paquet.

   • Adresse IP source, qui est l’adresse IP privée de l’instance Application Gateway : 192.168.200.7
   • Adresse IP de destination : 192.168.1.4
   • en-tête X-Forwarded-For : 192.168.100.7

4. La machine virtuelle répond à Application Gateway, ce qui inverse les adresses IP source et de destination :

   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7

5. Application Gateway répond à l’adresse IP source SNAT de l’instance de pare-feu Azure. Le Pare-feu Azure voit l’adresse IP interne d’Application Gateway, .4, comme adresse IP source, même si la connexion provient d’une instance Application Gateway spécifique comme .7.

   • Adresse IP source : 192.168.200.4
   • Adresse IP de destination : 192.168.100.7

6. Le Pare-feu Azure annule SNAT et DNAT et répond au client.

   • Adresse IP source : AzFwPIP
   • Adresse IP de destination : ClientPIP

Application Gateway a besoin d’une adresse IP publique pour que Microsoft puisse la gérer, même si aucun écouteur n’est configuré pour les applications.

Remarque

Un itinéraire par défaut vers 0.0.0.0/0 dans le sous-réseau Application Gateway qui pointe vers le Pare-feu Azure n’est pas pris en charge, car il interrompt le trafic du plan de contrôle requis par Application Gateway pour fonctionner correctement.

Clients locaux

Les conceptions précédentes montrent tous les clients d’application entrants à partir 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 quelques différences notables :

• Une passerelle VPN ou une passerelle ExpressRoute se trouve devant le Pare-feu Azure ou Application Gateway.

• Le pare-feu d’applications web utilise l’adresse IP privée d’Application Gateway.

• Le Pare-feu Azure ne prend pas en charge DNAT pour les adresses IP privées. Vous devez donc utiliser des UDR pour envoyer du trafic entrant au Pare-feu Azure à partir des passerelles VPN ou ExpressRoute.

• Veillez à vérifier les mises en garde autour de de tunneling forcé pour Application Gateway et pour pare-feu Azure. Même si votre charge de travail n’a pas besoin de connectivité sortante à l’Internet public, vous ne pouvez pas injecter un itinéraire par défaut comme 0.0.0.0/0 pour Application Gateway qui pointe vers le réseau local, car il interrompt le trafic. Pour Application Gateway, l’itinéraire par défaut doit pointer vers l’Internet public.

Architecture

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

Même si tous les clients se trouvent localement ou dans Azure, Application Gateway et pare-feu Azure doivent avoir des adresses IP publiques. Ces adresses IP publiques permettent à Microsoft de gérer les services.

Topologie hub-and-spoke

Les conceptions de cet article s’appliquent à une topologie hub-and-spoke. Les ressources partagées d’un réseau virtuel hub central se connectent aux applications dans des réseaux virtuels spoke distincts via des peerings de réseaux virtuels.

Architecture

• Le Pare-feu Azure est déployé dans le réseau virtuel hub central. Le diagramme précédent montre comment déployer Application Gateway dans le hub. Les équipes d’applications gèrent souvent des composants tels que les passerelles Application Gateway ou gestion des API. Dans ce scénario, ces composants sont déployés dans les réseaux virtuels spoke.

• Portez une attention particulière aux UDR dans les réseaux spoke. Lorsqu’un serveur d’applications dans un spoke reçoit le trafic d’une instance de pare-feu Azure spécifique, comme l’adresse IP 192.168.100.7 dans les exemples précédents, il doit renvoyer le trafic vers la même instance. Si un UDR dans le spoke définit le tronçon suivant du trafic adressé au hub vers l’adresse IP du Pare-feu Azure (192.168.100.4 dans les diagrammes précédents), les paquets de retour peuvent se retrouver sur une autre instance du Pare-feu Azure. Cette situation provoque un routage asymétrique. Si vous avez des UDR dans les réseaux virtuels spoke, veillez à envoyer le trafic aux services partagés dans le 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 à d’autres appliances virtuelles réseau ou proxys inverses qui peuvent être déployés dans le réseau virtuel hub.

• Vous ne pouvez pas définir le tronçon suivant pour les sous-réseaux Application Gateway ou Pare-feu Azure via des itinéraires statiques avec un type de tronçon suivant de Virtual Network. Ce type de tronçon suivant est valide uniquement dans le réseau virtuel local et non dans les peerings de réseaux virtuels. Pour plus d’informations sur les UDR et les types de tronçons suivants, consultez routage du trafic de réseau virtuel.

Routage asymétrique

Le diagramme suivant montre comment un spoke renvoie le trafic SNAT à l’équilibreur de charge Azure du Pare-feu Azure. Cette configuration provoque le routage asymétrique.

Pour résoudre ce problème, définissez les UDR dans le spoke sans le sous-réseau du Pare-feu Azure et avec uniquement les sous-réseaux où se trouvent les services partagés. Dans le diagramme précédent, l’UDR correct dans le spoke ne doit contenir que 192.168.1.0/24. Elle ne doit pas contenir la plage entière 192.168.0.0/16, marquée en rouge.

Intégration à d’autres produits Azure

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

Passerelle de gestion des API

Intégrez des services de proxy inverse comme passerelle gestion des API dans les conceptions précédentes pour fournir des fonctionnalités telles que la limitation d’API ou le proxy d’authentification. L’intégration de la passerelle Gestion des API n’affecte pas considérablement les conceptions. La principale différence est que au lieu du proxy inverse Application Gateway unique, il existe deux proxys inverses chaînés les uns derrière les autres.

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

AKS

Pour les charges de travail qui s’exécutent sur un cluster AKS, vous pouvez déployer Application Gateway indépendamment du cluster. Vous pouvez également l’intégrer au cluster AKS à l’aide du contrôleur d’entrée Application Gateway . Lorsque vous configurez des objets spécifiques aux niveaux Kubernetes, tels que les services et les ingresses, Application Gateway s’adapte automatiquement sans avoir besoin d’étapes manuelles supplémentaires.

Le Pare-feu Azure joue un rôle important dans la sécurité du cluster AKS. Il fournit la fonctionnalité requise pour filtrer le trafic de sortie à partir du cluster AKS en fonction du nom de domaine complet, et non seulement de l’adresse IP. Pour plus d’informations, consultez Limiter le trafic réseau avec le Pare-feu Azure dans AKS.

Lorsque vous combinez Application Gateway et le Pare-feu Azure pour protéger un cluster AKS, il est préférable d’utiliser l’option de conception parallèle. Application Gateway avec le pare-feu d’applications web traite les demandes de connexion entrantes aux applications web du cluster. Le Pare-feu Azure autorise uniquement les connexions sortantes explicitement autorisées. Pour plus d’informations sur l’option de conception parallèle, consultez architecture de base de référence pour un cluster AKS.

Azure Front Door - Service de passerelle réseau de Microsoft

Azure Front Door dispose de fonctionnalités qui se chevauchent avec Application Gateway dans plusieurs domaines. Les deux services fournissent un pare-feu d’applications web, un déchargement SSL et un routage basé sur l’URL. Toutefois, une différence clé réside dans le fait qu’Application Gateway fonctionne au sein d’un réseau virtuel, Azure Front Door est un service global décentralisé.

Vous pouvez parfois simplifier la conception du réseau virtuel en remplaçant Application Gateway par une instance Azure Front Door décentralisée. La plupart des conceptions décrites dans cet article s’appliquent toujours, à l’exception de l’option permettant de placer le Pare-feu Azure devant Azure Front Door.

Un scénario consiste à utiliser le Pare-feu Azure devant Application Gateway dans votre réseau virtuel. Application Gateway injecte l’en-tête X-Forwarded-For avec 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 entre dans le réseau virtuel et atteigne le Pare-feu Azure. Vous pouvez également sécuriser votre origine avec Azure Private Link dans Azure Front Door Premium.

Pour plus d’informations sur les différences entre les deux services, ou quand utiliser chacun d’eux, consultez Forum aux questions sur Azure Front Door.

Autres appliances virtuelles réseau

Les produits Microsoft ne sont pas le seul choix d’implémenter le pare-feu d’applications web ou les fonctionnalités de pare-feu de nouvelle génération dans Azure. Un large éventail de partenaires Microsoft fournissent des appliances virtuelles réseau. Les concepts et les conceptions sont essentiellement les mêmes que dans cet article, mais il existe quelques considérations importantes :

• Les appliances virtuelles réseau partenaires pour le pare-feu de nouvelle génération peuvent fournir davantage de contrôle et de flexibilité pour les configurations NAT que le Pare-feu Azure ne prend pas en charge. Les exemples incluent 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 aux appliances virtuelles où les utilisateurs doivent gérer l’extensibilité et la résilience sur de nombreuses appliances.

• Lorsque vous utilisez des appliances virtuelles virtuelles réseau dans Azure, utilisez actif-actif et la mise à l’échelle automatique des configurations de afin que ces appliances ne soient pas un goulot d’étranglement pour les applications qui s’exécutent dans le réseau virtuel.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Jose Moreno | Ingénieur client principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

En savoir plus sur les technologies de composant :

• Qu’est-ce qu’Application Gateway ?
• Qu’est-ce qu’Azure Firewall ?
• Qu’est-ce qu’Azure Front Door ?
• AKS
• Qu’est-ce que le réseau virtuel ?
• Qu’est-ce que le pare-feu d’applications web ?
• Architecture de référence pour un cluster AKS

Ressources associées

Explorez les architectures associées :

• Implémenter un réseau hybride sécurisé
• applications web gérées en toute sécurité
• logiciel multilocataire en tant que service sur Azure
• déploiement Entreprise à l’aide d’App Service Environment
• déploiement d’entreprise à haute disponibilité à l’aide d’App Service Environment