Réseau Confiance Zéro pour les applications web avec le pare-feu Azure et Application Gateway

Ce guide décrit une stratégie d’implémentation de la sécurité Confiance Zéro pour les applications web à des fins d’inspection et de chiffrement. Le paradigme de confiance zéro inclut de nombreux autres concepts, tels que la vérification constante de l’identité des acteurs ou la réduction de la taille des zones de confiance implicites au minimum. Cet article fait référence au composant de chiffrement et d’inspection d’une architecture de confiance zéro pour le trafic entrant à partir de l’Internet public. Consultez d’autres documents traitant de la confiance zéro pour découvrir plus d’aspects du déploiement sécurisé de votre application, tels que l’authentification. Pour les besoins de cet article, une approche multicouche fonctionne le mieux, la sécurité réseau constituant l’une des couches du modèle de confiance zéro. Dans cette couche, les appliances réseau inspectent les paquets pour s’assurer que seul le trafic légitime atteint les applications.

En règle générale, différents types d’appliances réseau inspectent différents aspects des paquets réseau :

• Les pare-feu d’applications web recherchent les modèles qui indiquent une attaque au niveau de la couche d’application web.
• Les pare-feu de nouvelle génération peuvent également rechercher des menaces génériques.

Dans certains cas, vous pouvez combiner différents types d’appliances de sécurité réseau pour augmenter la protection. Un guide distinct, Pare-feu et Application Gateway pour réseaux virtuels, décrit les modèles de conception que vous pouvez utiliser pour organiser les différentes appliances. Ce document se concentre sur un modèle courant d’optimisation de la sécurité, dans lequel Azure Application Gateway agit avant le pare-feu Azure Premium. Le diagramme suivant illustre ce modèle :

Téléchargez un fichier Visio de cette architecture.

Cette architecture utilise le protocole TLS (Transport Layer Security) pour chiffrer le trafic à chaque étape.

• Un client envoie des paquets à Application Gateway, un équilibreur de charge. Il s’exécute avec pare-feu Azure Web Application Firewall facultatif.

• Application Gateway déchiffre les paquets et recherche les menaces pour les applications web. S’il ne trouve aucune menace, il utilise des principes de confiance zéro pour chiffrer les paquets. Ensuite, il les met en production.

• Le pare-feu Azure Premium exécute des vérifications de sécurité :

  • L’inspection de la sécurité de la couche de transport (TLS) déchiffre et examine les paquets.
  • Les fonctionnalités de détection et de protection des intrusions recherchent dans les paquets toute intention malveillante.

• Si les paquets réussissent les tests, le pare-feu Azure Premium effectue les étapes suivantes :

  • Il chiffre les paquets
  • Il utilise un service DNS (Domain Name System) pour déterminer l’ordinateur virtuel de l’application
  • Il transfère les paquets à la machine virtuelle de l’application

Divers moteurs d’inspection dans cette architecture garantissent l’intégrité du trafic :

• Le pare-feu d’applications web utilise des règles pour empêcher les attaques au niveau de la couche web. Exemples d’attaques : injection de code SQL et scripting inter-site. Pour plus d’informations sur les règles et les groupes de règles principales d’OWASP (Open Web Application Security Project), consultez Règles et groupes de règles CRS de pare-feu d’applications web.
• Le pare-feu Azure Premium utilise des règles de détection et de prévention des intrusions génériques. Ces règles permettent d’identifier les fichiers malveillants et autres menaces ciblant les applications web.

Cette architecture prend en charge différents types de conception de réseau, traités dans cet article :

• Réseaux Hub-and-Spoke traditionnels
• Réseaux utilisant Azure Virtual WAN comme plateforme
• Réseaux utilisant un serveur de routes Azure pour simplifier le routage dynamique

Pare-feu Azure Premium et résolution de noms

Lors de la recherche de trafic malveillant, le pare-feu Azure Premium vérifie que l’en-tête de l’hôte HTTP correspond à l’adresse IP et au port TCP du paquet. Supposons, par exemple, qu’Application Gateway envoie des paquets web à l’adresse IP 172.16.1.4 et au port TCP 443. La valeur de l’en-tête d’hôte HTTP doit être résolue en cette adresse IP.

Les en-têtes d’hôte HTTP ne contiennent généralement pas d’adresses IP. Ils contiennent plutôt des noms qui correspondent au certificat numérique du serveur. Dans ce cas, le pare-feu Azure Premium utilise le DNS pour résoudre le nom de l’en-tête d’hôte en une adresse IP. La conception du réseau détermine la solution DNS qui fonctionne le mieux, comme décrit dans les sections ultérieures.

Certificats numériques

Le diagramme suivant montre les noms communs et les autorités de certification utilisés par les sessions et certificats TLS de l’architecture :

Connexions TLS

Cette architecture contient trois connexions TLS distinctes. Les certificats numériques valident chacune d’elles :

Des clients à Application Gateway

Dans Application Gateway, vous déployez le certificat numérique que les clients voient. Une autorité de certification connue comme DigiCert ou Let's Encrypt émet généralement un tel certificat.

D’Application Gateway au pare-feu Azure Premium

Pour déchiffrer et inspecter le trafic TLS, le pare-feu Azure Premium génère dynamiquement des certificats. Le pare-feu Azure Premium se présente également à Application Gateway en tant que serveur web. Une autorité de certification privée signe les certificats générés par le pare-feu Azure Premium. Pour plus d’informations, consultez Certificats du Pare-feu Azure Premium. Application Gateway doit valider ces certificats. Dans les paramètres HTTP de l’application, vous configurez l’autorité de certification racine utilisée par le pare-feu Azure Premium.

Du pare-feu Azure Premium au serveur web

Le Pare-feu Azure Premium établit une session TLS avec le serveur web de destination. Le Pare-feu Azure Premium vérifie qu’une autorité de certification connue signe les paquets TLS du serveur web.

Rôles de composant

Application Gateway et le pare-feu Azure Premium gèrent les certificats différemment les uns des autres, car leurs rôles diffèrent :

• Application Gateway est un proxy web inverse. Il protège les serveurs web des clients malveillants en interceptant les requêtes HTTP et HTTPS. Vous déclarez chaque serveur protégé dans le pool principal d’Application Gateway avec son adresse IP ou le nom de domaine complet. Les clients légitimes doivent être en mesure d’accéder à chaque application. Vous configurez donc Application Gateway avec un certificat numérique signé par une autorité de certification publique. Utilisez une autorité de certification acceptée par n’importe quel client TLS.
• Le pare-feu Azure Premium est un proxy web de transfert ou simplement un proxy web. Il protège les clients des serveurs web malveillants en interceptant les appels TLS des clients protégés. Lorsqu’un client protégé effectue une requête HTTP, le proxy de transfert emprunte l’identité du serveur web cible en générant des certificats numériques et en les présentant au client. Le pare-feu Azure Premium utilise une autorité de certification privée, qui signe les certificats générés dynamiquement. Vous configurez les clients protégés pour approuver cette autorité de certification privée. Dans cette architecture, le pare-feu Azure Premium protège les demandes d’Application Gateway au serveur web. Application Gateway approuve l’autorité de certification privée utilisée par le pare-feu Azure Premium.

Routage et transfert de trafic

Le routage sera légèrement différent selon la topologie de votre réseau. Les sections suivantes détaillent les particularités des topologies de type Hub-and-Spoke, Virtual WAN et Serveur de routes. Certains aspects sont cependant communs à toutes les topologies :

• Azure Application Gateway se comporte toujours comme un proxy, et le Pare-feu Azure Firewall Premium également lorsqu'il est configuré pour l'inspection TLS : les sessions TLS des clients sont interrompues par Application Gateway, et de nouvelles sessions TLS sont créées vers le Pare-feu Azure. Le Pare-feu Azure reçoit et met fin aux sessions TLS provenant d'Application Gateway, et crée de nouvelles sessions TLS vers les charges de travail. Ceci a des répercussions sur la configuration IDPS du Pare-feu Azure Premium. Les sections suivantes contiennent plus d'informations à ce sujet.
• La charge de travail voit les connexions provenant de l’adresse IP de sous-réseau du Pare-feu Azure. L’adresse IP du client d’origine est conservée dans l’en-tête HTTP X-Forwarded-For inséré par Application Gateway.
• Le trafic entre Application Gateway et la charge de travail est généralement envoyé au Pare-feu Azure au moyen de mécanismes de routage Azure, soit avec des routes définies par l'utilisateur configurées dans le sous-réseau d'Application Gateway, soit avec des routes injectées par Azure Virtual WAN ou le Serveur de routes Azure. Bien qu'il soit possible de définir explicitement l'adresse IP privée du Pare-feu Azure dans le pool backend d'Application Gateway, ce n'est pas recommandé d'un point de vue technique, car certaines fonctionnalités du Pare-feu Azure, comme l'équilibrage de la charge et l'adhérence, sont supprimées.

Les sections suivantes abordent en détail certaines des topologies les plus courantes utilisées avec le Pare-feu Azure et Application Gateway.

Topologie hub-and-spoke

En règle générale, une conception Hub-and-Spoke déploie des composants réseau partagés dans le réseau virtuel du hub et des composants spécifiques aux applications dans les spokes. Dans la plupart des systèmes, le pare-feu Azure Premium est une ressource partagée. Mais le pare-feu d’applications web peut être un périphérique réseau partagé ou un composant propre à l’application. Pour les raisons suivantes, il est généralement préférable de traiter Application Gateway comme un composant d’application et de le déployer dans un réseau virtuel spoke :

• Il peut être difficile de résoudre les problèmes d’alertes du pare-feu d’applications web. Vous avez généralement besoin d’une connaissance approfondie de l’application pour décider si les messages qui déclenchent ces alarmes sont légitimes.
• Si vous traitez Application Gateway comme une ressource partagée, vous risquez de dépasser les limites d’Azure Application Gateway.
• Vous pouvez rencontrer des problèmes de contrôle d’accès en fonction du rôle si vous déployez Application Gateway dans le hub. Cette situation peut survenir lorsque les équipes gèrent différentes applications, mais utilisent la même instance d’Application Gateway. Chaque équipe a ensuite accès à l’ensemble de la configuration d’Application Gateway.

Avec les architectures Hub-and-Spoke traditionnelles, les zones privées DNS offrent un moyen simple d’utiliser DNS :

• Configurez une zone privée DNS.
• Liez la zone au réseau virtuel qui contient le pare-feu Azure Premium.
• Assurez-vous qu’il existe un enregistrement A pour la valeur qu’Application Gateway utilise pour le trafic et les contrôles d’intégrité.

Le diagramme suivant illustre le flux de paquets lorsqu’Application Gateway se trouve dans un réseau virtuel spoke. Dans ce cas, un client se connecte à partir de l’Internet public.

1. Un client envoie une demande à un serveur web.
2. Application Gateway intercepte les paquets client et les examine. Si les paquets réussissent l’inspection, Application Gateway envoie le paquet à la machine virtuelle principale. Lorsque le paquet atteint Azure, un itinéraire défini par l’utilisateur (UDR) dans le sous-réseau Application Gateway transfère les paquets au Pare-feu Azure Premium.
3. Le pare-feu Azure Premium exécute des vérifications de sécurité sur les paquets. S’ils réussissent les tests, le pare-feu Azure Premium transfère les paquets à la machine virtuelle de l’application.
4. La machine virtuelle répond et définit l’adresse IP de destination sur Application Gateway. Un UDR dans le sous-réseau de machine virtuelle redirige les paquets vers le Pare-feu Azure Premium.
5. Le pare-feu Azure Premium transfère les paquets à Application Gateway.
6. Application Gateway répond au client.

Le trafic peut également arriver à partir d’un réseau local au lieu de l’Internet public. Le trafic circule via un réseau privé virtuel (VPN) de site à site ou via ExpressRoute. Dans ce scénario, le trafic atteint en premier une passerelle de réseau virtuel dans le hub. Le reste du flux réseau est le même que dans le cas précédent.

1. Un client local se connecte à la passerelle de réseau virtuel.
2. La passerelle transfère les paquets client à Application Gateway.
3. Application Gateway examine les paquets. S’ils réussissent l’inspection, un UDR dans le sous-réseau Application Gateway transfère les paquets au pare-feu Azure Premium.
4. Le pare-feu Azure Premium exécute des vérifications de sécurité sur les paquets. S’ils réussissent les tests, le pare-feu Azure Premium transfère les paquets à la machine virtuelle de l’application.
5. La machine virtuelle répond et définit l’adresse IP de destination sur Application Gateway. Un UDR dans le sous-réseau de machine virtuelle redirige les paquets vers le Pare-feu Azure Premium.
6. Le pare-feu Azure Premium transfère les paquets à Application Gateway.
7. Application Gateway envoie les paquets à la passerelle de réseau virtuel.
8. La passerelle répond au client.

Topologie Virtual WAN

Vous pouvez également utiliser le service de mise en réseau Virtual WAN dans cette architecture. Ce composant offre de nombreux avantages. Par exemple, il élimine la nécessité d’un UDR géré par l’utilisateur dans des réseaux virtuels spoke. Vous pouvez plutôt définir des itinéraires statiques dans des tables de route de hub virtuel. La programmation de chaque réseau virtuel que vous connectez au hub contient ensuite ces itinéraires.

Lorsque vous utilisez Virtual WAN comme plateforme de mise en réseau, deux différences majeures apparaissent :

• Vous ne pouvez pas lier de zones privées DNS à un hub virtuel, car Microsoft gère les hubs virtuels. En tant que propriétaire de l’abonnement, vous ne disposez pas des autorisations nécessaires pour lier des zones DNS privées. Par conséquent, vous ne pouvez pas associer une zone DNS privée au concentrateur sécurisé qui contient le pare-feu Azure Premium. Pour implémenter la résolution DNS pour le pare-feu Azure Premium, utilisez plutôt des serveurs DNS :

  • Configurez les Paramètres DNS du Pare-feu Azure de manière à utiliser des serveurs DNS personnalisés.
  • Déployez les serveurs dans un réseau virtuel de services partagés que vous connectez au WAN virtuel.
  • Liez une zone privée DNS au réseau virtuel des services partagés. Les serveurs DNS peuvent ensuite résoudre les noms utilisés par Application Gateway dans les en-têtes d’hôte HTTP. Pour plus d’informations, consultez Paramètres DNS du Pare-feu Azure.

• Vous pouvez utiliser Virtual WAN pour programmer des routes dans un réseau spoke seulement si le préfixe est plus court (moins spécifique) que le préfixe du réseau virtuel. Par exemple, dans le diagramme ci-dessus, le réseau spoke du réseau virtuel a le préfixe 172.16.0.0/16 : dans ce cas, Virtual WAN ne peut pas injecter une route qui correspond au préfixe de réseau virtuel (172.16.0.0/16) ou à un des sous-réseaux (172.16.0.0/24, 172.16.1.0/24). En d’autres termes, Virtual WAN ne peut pas attirer le trafic entre deux sous-réseaux qui se trouvent dans le même réseau virtuel. Cette limitation devient évidente lorsqu’Application Gateway et le serveur web de destination se trouvent dans le même réseau virtuel : le WAN virtuel ne peut pas forcer le trafic entre Application Gateway et le serveur web à traverser le pare-feu Azure Premium (une solution de contournement consiste à configurer manuellement les itinéraires définis par l’utilisateur dans les sous-réseaux d’Application Gateway et du serveur web).

Le diagramme suivant montre le flux de paquets dans un cas qui utilise Virtual WAN. Dans ce cas, l’accès à Application Gateway est effectué par un réseau local. Un VPN de site à site ou ExpressRoute connecte ce réseau à Virtual WAN. L’accès à partir d’Internet est similaire.

1. Un client local se connecte au VPN.
2. Le VPN transfère les paquets client à Application Gateway.
3. Application Gateway examine les paquets. S’ils réussissent l’inspection, le sous-réseau Application Gateway transfère les paquets au pare-feu Azure Premium.
4. Le pare-feu Azure Premium demande la résolution DNS à partir d’un serveur DNS dans le réseau virtuel des services partagés.
5. Le serveur DNS répond à la demande de résolution.
6. Le pare-feu Azure Premium exécute des vérifications de sécurité sur les paquets. S’ils réussissent les tests, le pare-feu Azure Premium transfère les paquets à la machine virtuelle de l’application.
7. La machine virtuelle répond et définit l’adresse IP de destination sur Application Gateway. Le sous-réseau d’Application Gateway redirige les paquets vers le Pare-feu Azure Premium.
8. Le pare-feu Azure Premium transfère les paquets à Application Gateway.
9. Application Gateway envoie les paquets au VPN.
10. Le VPN répond au client.

Avec cette conception, vous devrez peut-être modifier le routage publié par le concentrateur sur les réseaux virtuels spoke. Plus précisément, Application Gateway v2 ne prend en charge qu’un itinéraire 0.0.0.0/0 qui pointe vers Internet. Les itinéraires avec cette adresse qui ne pointent pas vers Internet interrompent la connectivité requise par Microsoft pour la gestion d’Application Gateway. Si votre hub virtuel publie un itinéraire 0.0.0.0/0, empêchez ce routage de se propager vers le sous-réseau Application Gateway en exécutant l’une des étapes suivantes :

• Créez une table de route avec un itinéraire pour 0.0.0.0/0 et un type de tronçon suivant Internet. Associez cet itinéraire au sous-réseau dans lequel vous déployez Application Gateway.
• Si vous déployez Application Gateway dans un spoke dédié, désactivez la propagation de l’itinéraire par défaut dans les paramètres de la connexion au réseau virtuel.

Topologie Serveur de routes

Le serveur de routes offre une autre façon d’injecter des itinéraires automatiquement dans les spokes. Avec cette fonctionnalité, vous évitez la surcharge administrative liée à la gestion des tables de route. Le serveur de routes associe les variantes de Virtual WAN et Hub-and-Spoke :

• Avec le serveur de routes, les clients gèrent les réseaux virtuels du hub. Par conséquent, vous pouvez lier le réseau virtuel du hub à une zone privée DNS.
• Le serveur de routes a la même restriction que Virtual WAN concernant les préfixes d’adresses IP. Vous ne pouvez injecter des itinéraires dans un spoke que si le préfixe est plus court (moins spécifique) que le préfixe du réseau virtuel. En raison de cette limitation, Application Gateway et le serveur web de destination doivent se trouver dans des réseaux virtuels différents.

Le diagramme suivant illustre le flux de paquets lorsque le serveur de routes simplifie le routage dynamique. Prenez note des points suivants :

• Le serveur de routes exige actuellement que l’appareil qui injecte les itinéraires les envoie via Border Gateway Protocol (BGP). Étant donné que le pare-feu Azure Premium ne prend pas en charge le protocole BGP, utilisez plutôt une appliance virtuelle réseau tierce.
• Les fonctionnalités de l’appliance virtuelle réseau dans le hub déterminent si votre implémentation requiert DNS.

1. Un client local se connecte à la passerelle de réseau virtuel.
2. La passerelle transfère les paquets client à Application Gateway.
3. Application Gateway examine les paquets. S’ils réussissent l’inspection, le sous-réseau Application Gateway transfère les paquets à une machine backend. Un itinéraire dans le sous-réseau ApplicationGateway injecté par Serveur de routes Azure transmet le trafic à une appliance virtuelle réseau.
4. L’appliance virtuelle réseau exécute des vérifications de sécurité sur les paquets. S’ils réussissent les tests, l’appliance virtuelle réseau transfère les paquets à la machine virtuelle de l’application.
5. La machine virtuelle répond et définit l’adresse IP de destination sur Application Gateway. Un itinéraire injecté dans le sous-réseau d’ordinateurs virtuels par Serveur de routes redirige les paquets vers l’appliance virtuelle réseau.
6. L’appliance virtuelle réseau transfère les paquets à Application Gateway.
7. Application Gateway envoie les paquets à la passerelle de réseau virtuel.
8. La passerelle répond au client.

Comme avec Virtual WAN, vous devrez peut-être modifier le routage si vous utilisez le serveur de routes. Si vous publiez l’itinéraire 0.0.0.0/0, il peut se propager vers le sous-réseau Application Gateway. Mais Application Gateway ne prend pas en charge cet itinéraire. Dans ce cas, configurez une table de route pour le sous-réseau Application Gateway. Incluez une table de route pour 0.0.0.0/0 et un type de tronçon suivant Internet à cette table.

IDPS et adresses IP privées

Comme expliqué dans les Règles IDPS du Pare-feu Azure, le Pare-feu Azure Premium décide des règles IDPS à appliquer en fonction des adresses IP source et de destination des paquets. Par défaut, le Pare-feu Azure considère les adresses IP privées situées dans les plages RFC 1918 (10.0.0.0/8, 192.168.0.0/16 et 172.16.0.0/12) et RFC 6598 (100.64.0.0/10) comme étant internes. Par conséquent, si, comme dans les diagrammes de cet article, Application Gateway est déployé dans un sous-réseau situé dans l'une de ces plages (172.16.0.0/24 dans les exemples ci-dessus), le Pare-feu Azure Premium considérera que le trafic entre Application Gateway et la charge de travail est interne, et seules les signatures IDPS marquées comme devant être appliquées au trafic interne ou à n'importe quel trafic seront utilisées. Les signatures IDPS marquées comme devant être appliquées au trafic entrant ou sortant ne seront pas appliquées au trafic entre Application Gateway et la charge de travail.

Le moyen le plus simple de forcer Application des règles de signature IDPS au trafic entrant entre Application Gateway et la charge de travail est de placer Application Gateway dans un sous-réseau dont le préfixe se trouve en dehors des plages privées. Vous n'avez pas nécessairement besoin d'utiliser des adresses IP publiques pour ce sous-réseau, vous pouvez également personnaliser les adresses IP que le Pare-feu Azure Premium considère comme internes pour l'IDPS. Par exemple, si votre organisation n'utilise pas la plage 100.64.0.0/10, vous pouvez éliminer celle-ci de la liste des préfixes internes pour l'IDPS (voir Plages IPDS privées du Pare-feu Azure Premium pour en savoir plus sur cette procédure) et déployer Application Gateway dans un sous-réseau configuré avec une adresse IP dans 100.64.0.0/10.

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

• Sécuriser les réseaux avec la Confiance Zéro
• Routage du trafic de réseau virtuel
• Fonctionnement d’une passerelle applicative

Ressources associées

• Sécuriser et gouverner les charges de travail avec une segmentation au niveau réseau
• Implémenter un réseau hybride sécurisé
• Topologie réseau hub-and-spoke dans Azure
• Topologie réseau hub-and-spoke avec Azure Virtual WAN