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

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

• Azure DDoS Protection, combinée aux bonnes pratiques de conception d’application, fournit des fonctionnalités d’atténuation DDoS améliorées pour fournir une défense accrue contre les attaques DDoS. Vous devez activer azure DDOS Protection sur n’importe quel réseau virtuel de périmètre.
• pare-feu Azure est un pare-feu de nouvelle génération managé qui offre traduction d’adresses réseau (NAT). Le Pare-feu Azure base le filtrage des paquets sur les adresses IP (Internet Protocol) et les ports TCP/UDP (Transmission Control Protocol) ou sur les attributs HTTP(S) ou SQL basés sur l’application. Le Pare-feu Azure applique également le renseignement sur les menaces Microsoft pour identifier les adresses IP malveillantes. Pour plus d’informations, consultez la documentation pare-feu Azure.
• pare-feu Azure Premium inclut toutes les fonctionnalités du Pare-feu Azure Standard et d’autres fonctionnalités, telles que l’inspection TLS et le système de détection et de protection des intrusions (IDPS).
• Azure Application Gateway est un équilibreur de charge de trafic web managé et un proxy inverse http(S) complet 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 pour inspecter le trafic web et détecter les attaques au niveau de la couche HTTP. Pour plus d’informations, consultez la documentation Application Gateway.
• pare-feu d’applications web Azure (WAF) est un ajout facultatif à Azure Application Gateway. Il fournit une inspection des requêtes HTTP et empêche les attaques malveillantes au niveau de la couche web, telles que l’injection SQL ou le script intersite. Pour plus d’informations, consultez la documentation web Application Firewall.

Ces services Azure sont complémentaires. L’une ou l’autre peut être optimale pour vos charges de travail, ou vous pouvez les utiliser ensemble pour une protection optimale à la fois sur les couches réseau et application. Utilisez l’arbre de décision suivant et les exemples de cet article pour déterminer la meilleure option de sécurité pour le réseau virtuel de votre application.

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

Selon le flux réseau requis par une application, la conception peut être différente par application. Le diagramme suivant offre un arbre de décision simplifié qui permet de choisir l’approche recommandée pour une application. La décision dépend de la publication de l’application via HTTP(S) ou d’un autre protocole :

Cet article aborde les conceptions largement recommandées à partir du diagramme de flux, et d’autres qui s’appliquent dans des scénarios moins courants :

• Pare-feu Azure seul, 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 seul, quand 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. Les fonctionnalités fournies par le Pare-feu Azure peuvent empêcher de nombreux scénarios d’attaque (tels que l’exfiltration de données, IDPS, etc.). En raison de cette raison, le scénario Application Gateway seul n’est généralement pas recommandé et n’est donc pas documenté et n’est donc pas dans le graphique de flux ci-dessus.
• Pare-feu Azure et Application Gateway en parallèle, qui est l’une des conceptions les plus courantes. Utilisez cette combinaison lorsque vous souhaitez qu’Azure Application Gateway protège les applications HTTP(S) contre les attaques web et le Pare-feu Azure pour protéger toutes les autres charges de travail et filtrer le trafic sortant.
• Application Gateway devant le Pare-feu Azure, lorsque vous souhaitez que le Pare-feu Azure inspecte tout le trafic, waf protège le trafic web et l’application pour connaître 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, lorsque vous souhaitez qu’Azure Firewall inspecte et filtre le trafic avant qu’il atteigne Application Gateway. Étant donné que le Pare-feu Azure ne déchiffre pas le trafic HTTPS, la fonctionnalité qu’il ajoute à Application Gateway est limitée. Ce scénario n’est pas documenté dans le diagramme de flux ci-dessus.

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

• 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 ou Azure Front Door. Vous pouvez également remplacer les ressources Azure par des appliances virtuelles réseau tierces.

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 WAF, vous pouvez utiliser le Pare-feu Azure uniquement. La conception dans ce cas est simple, mais l’examen du flux de paquets vous aidera à 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 virtuel 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 le montre le diagramme ci-dessous. Le trafic sortant à partir de réseaux virtuels Azure est envoyé au pare-feu via des UDR, comme indiqué dans la boîte de dialogue ci-dessous.

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

Le Pare-feu Azure n’inspecte pas le trafic HTTP(S) entrant. Mais il sera en mesure d’appliquer des règles de couche 3 & 4 et des règles d’application basées sur un nom de domaine complet. Le pare-feu Azure inspecte le trafic HTTP(S) sortant en fonction du niveau pare-feu Azure et indique si vous configurez l’inspection TLS :

• Le Pare-feu Azure Standard inspecte uniquement les attributs de couche 3 & 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 (tels que le User-Agent) et l’activation de l’inspection TLS pour une analyse approfondie des paquets. Le Pare-feu Azure n’est pas équivalent à un pare-feu d’applications web. Si vous avez des charges de travail web dans votre réseau virtuel, l’utilisation du WAF est vivement recommandée.

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, vous disposez de plusieurs instances d’application derrière un équilibreur de charge. Dans cette conception, le Pare-feu Azure inspecte les connexions entrantes à partir de l’Internet public et les connexions sortantes à partir de la machine virtuelle du sous-réseau d’application à l’aide de l’UDR.

• Le service pare-feu Azure déploie plusieurs instances sous les couvertures, ici avec l’adresse IP frontale 192.168.100.4 et les adresses internes de la plage 192.168.100.0/26. Ces instances individuelles sont normalement invisibles pour l’administrateur Azure. Mais notez que la différence est utile dans certains cas, par exemple lors de la résolution des problèmes réseau.
• Si le trafic provient d’un réseau privé virtuel 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 n’effectue aucune NAT source par défaut.

Architecture

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

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, dans ce cas 192.168.100.7. La règle DNAT (Destination NAT) du 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 naTs sources (SNAT) le paquet s’il effectue DNAT. Pour plus d’informations, consultez Problèmes connus du Pare-feu Azure. La machine virtuelle voit les adresses IP suivantes dans le paquet entrant :
   • Adresse IP source : 192.168.100.7
   • Adresse IP de destination : 192.168.1.4
3. La machine virtuelle répond à la demande d’application, en inversant les adresses IP source et de destination. Le flux entrant ne nécessite pas de itinéraire défini par l’utilisateur (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 est destiné aux connexions sortantes, pour vous 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. Enfin, le Pare-feu Azure annule les opérations SNAT et DNAT et remet la réponse au client :
   • Adresse IP source : AzFwPIP
   • Adresse IP de destination : ClientPIP

Application Gateway uniquement

Cette conception couvre la situation 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.

La principale différence par rapport à la conception précédente avec uniquement le Pare-feu Azure est que la passerelle Application Gateway ne fait pas office d’appareil de routage avec NAT. Il se comporte comme un proxy d’application inverse complet. Autrement dit, 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 doivent être envoyées à l’adresse IP publique de l’Application Gateway, aux connexions d’Azure ou locales à l’adresse IP privée de la passerelle. Le retour du trafic à partir des machines virtuelles Azure suit le routage standard du réseau virtuel vers Application Gateway (consultez la procédure pas à pas plus loin pour plus d’informations). Les flux Internet sortants à partir de machines virtuelles Azure vont directement à Internet.

Le tableau suivant récapitule les flux de trafic :

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’Azure 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, dans ce cas 192.168.200.7. 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 : 192.168.200.7 (adresse IP privée de l’instance Application Gateway)
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : ClientPIP
3. La machine virtuelle répond à la demande d’application, en inversant les adresses IP source et de destination. La machine virtuelle sait déjà comment 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. Enfin, l’instance Application Gateway répond au client :
   • Adresse IP source : AppGwPIP
   • Adresse IP de destination : ClientPIP

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

• L’adresse IP 192.168.200.7 est l’une des instances que le service Azure Application Gateway déploie sous les couvertures, ici avec l’adresse IP frontale interne et privée 192.168.200.4. Ces instances individuelles sont normalement invisibles pour l’administrateur Azure. Mais notez que la différence est utile dans certains cas, par exemple lors de la résolution des problèmes réseau.

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

Pare-feu et Application Gateway en parallèle

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

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

Les connexions HTTP(S) entrantes à partir d’Internet doivent être envoyées à l’adresse IP publique des connexions Application Gateway, HTTP(S) d’Azure ou locales à son adresse IP privée. Le routage de réseau virtuel standard envoie les paquets de la passerelle Application Gateway aux machines virtuelles de destination, ainsi que des machines virtuelles de destination vers Application Gateway (voir la procédure pas à pas plus loin pour plus d’informations). 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), ou il sera 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 :

Cette conception offre un filtrage de sortie beaucoup plus granulaire que les 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 nom de domaine complet (FQDN)filtres basés sur des noms de domaine. Avec les filtres basés sur un nom de domaine complet, les applications n’envoient pas de données à des comptes de stockage non autorisés. Ce scénario n’a pas pu être empêché uniquement en utilisant des groupes de sécurité réseau. Cette conception est souvent utilisée lorsque le trafic sortant nécessite un filtrage basé sur un nom de domaine complet. Par exemple, lorsque limiter le trafic de sortie à partir d’un cluster Azure Kubernetes Services.

Architectures

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

diagramme

Le diagramme suivant illustre le flux de trafic pour les connexions sortantes des machines virtuelles réseau vers Internet. L’un des exemples 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 avant le pare-feu

Cette conception est expliquée plus en détail dans réseau de confiance zéro pour les applications web avec le Pare-feu Azure et application Gateway, ce document 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 WAF. Le PARE-feu d’applications web fournit une protection au niveau de la couche d’application web. Le Pare-feu Azure agit comme un point de journalisation et de contrôle central, et inspecte le trafic entre application Gateway et les serveurs principaux. Le Pare-feu Application Gateway et Azure ne sont pas assis en parallèle, mais l’un après l’autre.

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

Cette conception convient aux applications qui doivent connaître les adresses IP sources du client entrantes, par exemple pour traiter du contenu spécifique à la géolocalisation ou pour la journalisation. Application Gateway devant le Pare-feu Azure capture l’adresse IP source du paquet entrant dans le en-tête X transféré pour, 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 des connexions Application Gateway, HTTP(S) d’Azure ou locales à l’adresse IP privée. À partir des UDR Application Gateway, assurez-vous que les paquets sont routés via le Pare-feu Azure (consultez la procédure pas à pas plus loin pour plus d’informations). 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), ou il sera 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.

Une remarque importante de cette conception est que Le Pare-feu Azure Premium verra 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/12 ou 100.64.0.0/10), le Pare-feu Azure Premium traite le trafic à partir de La passerelle Application Gateway comme interne et n’applique pas de règles IDPS pour le trafic entrant. 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. Par conséquent, il est recommandé de modifier les préfixes privés IDPS dans la stratégie de pare-feu Azure afin que le sous-réseau Application Gateway ne soit pas considéré comme une source interne, pour appliquer des signatures IDPS entrantes et sortantes au trafic.

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

Pour le trafic web depuis un site local ou Internet vers Azure, le Pare-feu Azure inspecte les flux que le WAF a déjà autorisés. Selon que la passerelle Application Gateway chiffre le trafic principal (le trafic de la passerelle Application Gateway vers les serveurs d’applications), vous aurez différents scénarios potentiels :

1. Application Gateway chiffre le trafic suivant les principes de confiance zéro (chiffrement TLS de bout en bout), et le pare-feu Azure reçoit le trafic chiffré. Toutefois, Le Pare-feu Azure Standard pourra appliquer des règles d’inspection, telles que le filtrage de couche 3 & 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.
2. 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.
3. Si IDPS est activé dans le Pare-feu Azure, il vérifie que l’en-tête hôte HTTP correspond à l’adresse IP de destination. À cet effet, il aura 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 obtenue avec les zones privées Azure DNS et les paramètres DNS par défaut du Pare-feu Azure à l’aide d’Azure DNS. Elle peut également être obtenue avec des serveurs DNS personnalisés qui doivent être configurés dans les paramètres du Pare-feu Azure. (Pour plus d’informations, consultez paramètres DNS du pare-feu Azure.) S’il n’existe pas d’accès administratif au réseau virtuel où le Pare-feu Azure est déployé, cette dernière méthode est la seule possibilité. L’un des exemples est le déploiement de pare-feu Azure dans virtual WAN Secured Hubs.

Architecture

Pour le reste des flux (trafic entrant non HTTP(S) 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’Azure 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, dans ce cas 192.168.200.7. 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, tout en préservant l’adresse IP de destination de l’application web :
   • Adresse IP source : 192.168.200.7 (adresse IP privée de l’instance Application Gateway)
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : ClientPIP
3. Le Pare-feu Azure ne s’adresse pas 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 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 proxy la connexion :
   • Adresse IP source si le trafic est autorisé par une règle de réseau de pare-feu Azure : 192.168.200.7 (adresse IP privée de l’une des instances Application Gateway).
   • Adresse IP source si le trafic est autorisé par une règle d’application pare-feu Azure : 192.168.100.7 (adresse IP privée de l’une des instances de pare-feu Azure).
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : ClientPIP
4. La machine virtuelle répond à la requête, en inversant les adresses IP source et de destination. L’UDR pour 192.168.200.0/24 capture le paquet renvoyé à Application Gateway et le redirige vers le Pare-feu Azure, tout en conservant l’adresse IP de destination vers Application Gateway.
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7
5. Ici encore, le Pare-feu Azure ne s’adresse pas au trafic, car il va à 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. Enfin, l’instance Application Gateway répond au client :
   • Adresse IP source : AppGwPIP
   • Adresse IP de destination : ClientPIP

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

Application Gateway après le pare-feu

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. Toutefois, le pare-feu Azure SNATs le trafic entrant, de sorte que l’application n’aura pas de visibilité sur l’adresse IP d’origine des requêtes HTTP. Du point de vue de l’administration, par exemple à des fins de résolution des problèmes, vous pouvez obtenir l’adresse IP réelle du client pour une connexion spécifique en la mettant en corrélation avec les journaux SNAT du Pare-feu Azure.

Ce scénario présente un avantage limité, car le pare-feu Azure voit uniquement le trafic chiffré vers Application Gateway. Il peut y avoir des scénarios où cette conception est préférée. Un cas est si un autre WAF est antérieur au 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. Ou la conception est préférable si de nombreuses adresses IP publiques sont requises.

Les flux entrants HTTP(S) à partir de l’Internet public doivent cibler l’adresse IP publique du Pare-feu Azure, et le Pare-feu Azure va DNAT (et SNAT) les paquets à l’adresse IP privée de l’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 d’Application Gateway et transféré via le Pare-feu Azure avec des UDR. Le routage de réseau virtuel standard s’assure que le retour du trafic des machines virtuelles Azure revient à Application Gateway, et du pare-feu Application Gateway au pare-feu Azure si des règles DNAT ont été utilisées. Pour le trafic provenant des UDR locaux ou Azure dans le sous-réseau Application Gateway doit être utilisé (consultez la procédure pas à pas plus loin pour plus d’informations). Tout le trafic sortant des machines virtuelles Azure vers Internet sera envoyé via le Pare-feu Azure par des UDR.

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

Pour le trafic HTTP(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 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 SNATs les paquets à mesure qu’ils entrent dans le réseau virtuel. Pour éviter ce problème, utilisez azure Front Door devant le pare-feu. Azure Front Door injecte l’adresse IP du client en tant qu’en-tête HTTP avant 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, dans ce cas 192.168.100.7. Le Pare-feu Azure DNATs le port web, généralement TCP 443, vers l’adresse IP privée de l’instance Application Gateway. Pare-feu Azure effectue également des SNAT lors de l’exécution de DNAT. Pour plus d’informations, consultez problèmes connus du Pare-feu Azure:
   • Adresse IP source : 192.168.100.7 (adresse IP privée de l’instance de pare-feu Azure)
   • 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 : 192.168.200.7 (adresse IP privée de l’instance Application Gateway)
   • Adresse IP de destination : 192.168.1.4
   • En-tête X-Forwarded-For : 192.168.100.7
4. La machine virtuelle répond à Application Gateway, en inversant les adresses IP source et de destination :
   • Adresse IP source : 192.168.1.4
   • Adresse IP de destination : 192.168.200.7
5. Application Gateway répond à l’adresse IP source SNAT de l’instance de pare-feu Azure. Même si la connexion provient d’une instance Application Gateway spécifique comme .7, le Pare-feu Azure voit l’adresse IP interne de l’application Gateway .4 comme adresse IP source :
   • Adresse IP source : 192.168.200.4
   • Adresse IP de destination : 192.168.100.7
6. Enfin, le Pare-feu Azure annule SNAT et DNAT et répond au client :
   • Adresse IP source : AzFwPIP
   • Adresse IP de destination : ClientPIP

Même si Application Gateway n’a pas d’écouteurs configurés pour les applications, il a toujours besoin d’une adresse IP publique pour que Microsoft puisse le gérer.

Clients locaux

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

• Une passerelle VPN ou une passerelle ExpressRoute se trouve devant le Pare-feu Azure ou Application Gateway.
• WAF utilise l’adresse IP privée de La passerelle Application Gateway.
• Le Pare-feu Azure ne prend pas en charge DNAT pour les adresses IP privées. C’est pourquoi vous devez utiliser des UDR pour envoyer le 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 le Azure Application Gateway et pour le pare-feu Azure . Même si votre charge de travail n’a pas besoin de connectivité sortante vers 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, ou vous allez interrompre le trafic. Pour Azure Application Gateway, l’itinéraire par défaut doit pointer vers l’Internet public.

Architecture

Le diagramme suivant montre la conception parallèle d’Azure 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, Azure Application Gateway et le Pare-feu Azure doivent avoir des adresses IP publiques. Les adresses IP publiques permettent à Microsoft de gérer les services.

Topologie hub-and-spoke

Les conceptions de cet article s’appliquent toujours dans 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

Considérations

Voici quelques considérations à prendre en compte pour cette topologie :

• Le Pare-feu Azure est déployé dans le réseau virtuel hub central. Le diagramme ci-dessus montre la pratique de déploiement de La passerelle Application Gateway dans le hub. Les équipes d’applications gèrent souvent des composants tels qu’Azure Application Gateways ou des passerelles de gestion des API Azure. Dans ce cas, ces composants sont déployés dans les réseaux virtuels spoke.
• 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 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 ci-dessus), les paquets de retour peuvent se retrouver sur une autre instance de pare-feu Azure, provoquant un routage asymétrique. Assurez-vous que si vous avez des UDR dans les réseaux virtuels spoke pour envoyer du 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 à toutes les 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 itinéraires définis par l’utilisateur et les types de tronçons suivants, consultez routage du trafic de réseau virtuel.

Routage asymétrique

Le diagramme ci-dessous montre comment un spoke renvoie le trafic SNATted vers l’ALB d’un 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, mais uniquement avec les sous-réseaux où se trouvent les services partagés. Dans l’exemple, l’UDR correct dans le spoke ne doit contenir que 192.168.1.0/24. Il ne doit pas contenir tout le 192.168.0.0/16, comme marqué en rouge.

Intégration à d’autres produits Azure

Vous pouvez intégrer le Pare-feu Azure et Azure 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 d’une passerelle Gestion des API ne modifie 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.

Azure Kubernetes Service

Pour les charges de travail s’exécutant sur un cluster AKS, vous pouvez déployer Azure Application Gateway indépendamment du cluster. Vous pouvez également l’intégrer au cluster AKS à l’aide du contrôleur d’entrée Azure Application Gateway . Lors de la configuration de certains objets aux niveaux Kubernetes (tels que les services et les 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 offre la fonctionnalité requise pour filtrer le trafic de sortie à partir du cluster AKS en fonction du nom de domaine complet, pas seulement de l’adresse IP. Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster AKS.

Lorsque vous combinez Application Gateway et le Pare-feu Azure pour protéger un cluster AKS, il est préférable d’utiliser l’option de conception parallèle. Application Gateway avec waf traite les demandes de connexion entrantes aux applications web du cluster. Le Pare-feu Azure autorise uniquement les connexions sortantes explicitement autorisées. Consultez architecture de référence pour un cluster Azure Kubernetes Service (AKS) pour obtenir un exemple d’option de conception parallèle.

Azure Front Door

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

Vous pouvez parfois simplifier la conception de réseau virtuel en remplaçant Application Gateway par une instance Azure Front Door décentralisée. La plupart des conceptions décrites ici restent valides, à l’exception de la possibilité de placer le pare-feu Azure devant Azure Front Door.

Un cas d’usage intéressant consiste à utiliser le Pare-feu Azure devant Application Gateway dans votre réseau virtuel. Comme décrit précédemment, l’en-tête X-Forwarded-For injecté par Application Gateway contiendra 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 atteint le Pare-feu Azure. Une deuxième option consiste à sécuriser votre origine avec Private Link dans Azure Front Door Premium.

Pour plus d’informations sur les différences entre les deux services, ou 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 (NVA). 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 offrir davantage de contrôle et de flexibilité pour les configurations NAT non prises en charge par le Pare-feu Azure. 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 pare-feu Azure) réduisent la complexité, par rapport aux appliances virtuelles virtuelles où les utilisateurs doivent gérer la scalabilité et la résilience entre de nombreuses appliances.
• Lorsque vous utilisez des appliances virtuelles virtuelles réseau dans Azure, utilisez active-active et la mise à l’échelle automatique des configurations de. Ces appliances ne sont donc pas un goulot d’étranglement pour les applications s’exécutant dans le réseau virtuel.

Contributeurs

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

Auteur principal :

• Jose Moreno | Ingénieur client principal

Étapes suivantes

En savoir plus sur les technologies de composant :

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

Ressources associées

Explorez les architectures associées :

• Implémenter un réseau hybride sécurisé
• applications web gérées en toute sécurité
• Sécurisation de votre bot de canal Microsoft Teams et de votre application web derrière un pare-feu
• considérations relatives à la sécurité pour les applications IaaS hautement sensibles dans Azure
• SaaS multilocataire sur Azure
• déploiement Entreprise à l’aide de l’environnement App Services
• déploiement d’entreprise à haute disponibilité à l’aide de l’environnement App Services
• architecture de base de référence pour un cluster Azure Kubernetes Service (AKS)