Réseau de confiance zéro pour les applications web avec pare-feu Azure et Application Gateway

Ce guide décrit une stratégie d’implémentation de sécurité confiance zéro pour les applications web pour l’inspection et le 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. Lisez d’autres documents confiance zéro pour plus d’aspects du déploiement de votre application en toute sécurité, comme l’authentification. Dans le cadre de cet article, une approche multicouche fonctionne mieux, où la sécurité réseau constitue 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 des modèles qui indiquent une attaque au niveau de la couche 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 les 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 pour optimiser la sécurité, dans laquelle Azure Application Gateway agit avant le Pare-feu Azure Premium. Le diagramme suivant illustre ce modèle :

Télécharger 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 l’ajout facultatif pare-feu d’applications web Azure.

• 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 libère.

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

  • inspection TLS (Transport Layer Security) déchiffre et examine les paquets.
  • fonctionnalités de détection et de protection des intrusions vérifiez les paquets pour une intention malveillante.

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

  • Chiffre les paquets
  • Utilise un service DNS (Domain Name System) pour déterminer la machine virtuelle d’application
  • Transfère les paquets à la machine virtuelle de l’application

Différents moteurs d’inspection de 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. Parmi les exemples d’attaques, citons l’injection de code SQL et le script intersite. Pour plus d’informations sur les règles et le jeu de règles principal Open Web Application Security Project (OWASP), consultez groupes de règles CRS du pare-feu d’applications web et règles.
• Le Pare-feu Azure Premium utilise des règles génériques de détection et de prévention des intrusions. Ces règles permettent d’identifier les fichiers malveillants et d’autres menaces qui ciblent des applications web.

Cette architecture prend en charge différents types de conception de réseau, que cet article décrit :

• Réseaux hub-and-spoke traditionnels
• Réseaux qui utilisent Azure Virtual WAN en tant que plateforme
• Réseaux qui utilisent Azure Route Server pour simplifier le routage dynamique

Pare-feu Azure Premium et résolution de noms

Lors de la vérification du trafic malveillant, le Pare-feu Azure Premium vérifie que l’en-tête de l’hôte HTTP correspond à l’adresse IP du paquet et au port TCP. Par exemple, supposons 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 de l’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. Au lieu de cela, les en-têtes contiennent des noms qui correspondent au certificat numérique du serveur. Dans ce cas, le Pare-feu Azure Premium utilise DNS pour résoudre le nom d’en-tête de l’hôte en adresse IP. La conception du réseau détermine la solution DNS qui convient le mieux, comme décrit les sections ultérieures.

Certificats numériques

Le diagramme suivant montre les noms communs (CN) et les autorités de certification (AUTORITÉS de certification) utilisées par les sessions et certificats TLS de l’architecture :

Connexions TLS

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

Des clients à Application Gateway

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

Depuis Application Gateway vers le 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 Azure Firewall 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 Pare-feu Azure Premium gèrent les certificats différemment des uns des autres, car leurs rôles diffèrent :

• Application Gateway est un proxy web inverse . Il protège les serveurs web contre les clients malveillants en interceptant les requêtes HTTP et HTTPS. Vous déclarez chaque serveur protégé qui se trouve dans le pool principal d’Application Gateway avec son adresse IP ou son nom de domaine complet. Les clients légitimes doivent pouvoir 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 que tout client TLS acceptera.
• Le Pare-feu Azure Premium est un proxy web transférer ou, simplement, un proxy web. Il protège les clients contre les 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 qu’ils approuvent cette autorité de certification privée. Dans cette architecture, Le Pare-feu Azure Premium protège les demandes d’Application Gateway vers le 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 en fonction de la topologie de votre conception réseau, les sections suivantes détaillent les spécificités des exemples de topologie Hub-and-Spoke, Virtual WAN et Route Server. Toutefois, certains aspects sont communs à toutes les topologies :

• Azure Application Gateway se comporte toujours en tant que proxy, et le Pare-feu Azure Premium fonctionne également quand il est configuré pour l’inspection TLS : les sessions TLS des clients seront arrêtées par Application Gateway et les nouvelles sessions TLS seront générées vers le Pare-feu Azure. Le Pare-feu Azure reçoit et met fin aux sessions TLS sources de la passerelle Application Gateway et crée de nouvelles sessions TLS vers les charges de travail. Ce fait a des implications pour la configuration IDPS du Pare-feu Azure Premium, les sections ci-dessous contiennent plus d’informations sur ce sujet.
• La charge de travail verra les connexions provenant de l’adresse IP du 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 de la passerelle Application Gateway vers la charge de travail est généralement envoyé au Pare-feu Azure à l’aide de mécanismes de routage Azure, soit avec des itinéraires User-Defined configurés dans le sous-réseau d’Application Gateway, soit avec des itinéraires injectés par Azure Virtual WAN ou Azure Route Server. Bien que la définition explicite de l’adresse IP privée du Pare-feu Azure dans le pool principal d’Application Gateway soit possible, il n’est techniquement pas recommandé, car il enlève certaines des fonctionnalités du Pare-feu Azure, telles que l’équilibrage de charge et l’exactitude.

Les sections suivantes décrivent 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 hub et des composants spécifiques à l’application dans les spokes. Dans la plupart des systèmes, le Pare-feu Azure Premium est une ressource partagée. Toutefois, le pare-feu d’applications web peut être un appareil réseau partagé ou un composant spécifique à l’application. Pour les raisons suivantes, il est généralement préférable de traiter Application Gateway comme composant d’application et de le déployer dans un réseau virtuel spoke :

• Il peut être difficile de résoudre les alertes de pare-feu d’applications web. Vous avez généralement besoin d’une connaissance approfondie de l’application pour déterminer si les messages qui déclenchent ces alarmes sont légitimes.
• Si vous traitez Application Gateway comme une ressource partagée, vous pouvez dépasser 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 se présenter 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.
• Lier la zone au réseau virtuel qui contient le Pare-feu Azure Premium.
• Assurez-vous qu’un enregistrement A existe pour la valeur utilisée par Application Gateway pour le trafic et pour les vérifications d’intégrité.

Le diagramme suivant montre le flux de paquets quand 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 clients et les examine. Si les paquets passent une 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 transite par le biais d’un réseau privé virtuel de site à site (VPN) ou d’ExpressRoute. Dans ce scénario, le trafic atteint d’abord une passerelle de réseau virtuel dans le hub. Le reste du flux réseau est identique au cas précédent.

1. Un client local se connecte à la passerelle de réseau virtuel.
2. La passerelle transfère les paquets clients à Application Gateway.
3. Application Gateway examine les paquets. S’ils passent une 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 réseau virtual WAN dans cette architecture. Ce composant offre de nombreux avantages. Par exemple, il élimine le besoin d’UDR gérés par l’utilisateur dans les réseaux virtuels spoke. Vous pouvez définir des itinéraires statiques dans des tables de routage de hub virtuel à la place. 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 principaux résultats sont les suivants :

• Vous ne pouvez pas lier des zones privées DNS à un hub virtuel, car Microsoft gère les hubs virtuels. En tant que propriétaire de l’abonnement, vous n’avez pas d’autorisations pour lier des zones DNS privées. Par conséquent, vous ne pouvez pas associer une zone privée DNS au hub 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 pour utiliser des serveurs DNS personnalisés.
  • Déployez les serveurs dans un réseau virtuel de services partagés que vous vous connectez au réseau étendu virtuel.
  • Lier 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 uniquement utiliser Virtual WAN pour programmer des itinéraires dans un spoke si le préfixe est plus court (moins spécifique) que le préfixe du réseau virtuel. Par exemple, dans les diagrammes ci-dessus, le réseau virtuel spoke a le préfixe 172.16.0.0/16 : dans ce cas, Virtual WAN ne peut pas injecter un itinéraire qui correspond au préfixe de réseau virtuel (172.16.0.0/16) ou à l’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 lorsque Application Gateway et le serveur web de destination se trouvent dans le même réseau virtuel : Virtual WAN ne peut pas forcer le trafic entre Application Gateway et le serveur web à passer par 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 de la passerelle 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 provient d’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 clients vers Application Gateway.
3. Application Gateway examine les paquets. S’ils passent une 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 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 que le hub publie sur les réseaux virtuels spoke. Plus précisément, Application Gateway v2 prend uniquement en charge 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 gérer Application Gateway. Si votre hub virtuel publie une route 0.0.0.0/0, empêchez cette route de se propager vers le sous-réseau Application Gateway en effectuant l’une des étapes suivantes :

• Créez une table de routage avec un itinéraire pour 0.0.0.0/0 et un type de tronçon suivant de 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 de réseau virtuel.

Topologie du serveur de routage

route Server offre un autre moyen d’injecter automatiquement des itinéraires dans des spokes. Avec cette fonctionnalité, vous évitez la surcharge administrative liée à la maintenance des tables de routage. Le serveur de routage combine les variantes virtual WAN et hub-and-spoke :

• Avec le serveur de routage, les clients gèrent les réseaux virtuels hub. Par conséquent, vous pouvez lier le réseau virtuel hub à une zone privée DNS.
• Le serveur de routage a la même limitation 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 de réseau virtuel. En raison de cette limitation, Application Gateway et le serveur web de destination doivent se trouver dans différents réseaux virtuels.

Le diagramme suivant montre le flux de paquets lorsque le serveur de routage simplifie le routage dynamique. Notez ces points :

• Le serveur de routage requiert actuellement l’appareil qui injecte les itinéraires pour les envoyer via le protocole BGP (Border Gateway Protocol). Étant donné qu’Azure Firewall Premium ne prend pas en charge BGP, utilisez une appliance virtuelle réseau tierce (NVA) à la place.
• La fonctionnalité de l’appliance virtuelle réseau dans le hub détermine si votre implémentation a besoin de DNS.

1. Un client local se connecte à la passerelle de réseau virtuel.
2. La passerelle transfère les paquets clients à Application Gateway.
3. Application Gateway examine les paquets. S’ils passent une inspection, le sous-réseau Application Gateway transfère les paquets à un ordinateur back-end. Un itinéraire dans le sous-réseau ApplicationGateway injecté par le serveur de routage transférerait le trafic vers 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 de la machine virtuelle par le serveur de routage 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 lorsque vous utilisez le serveur de routage. Si vous publiez l’itinéraire 0.0.0.0/0, il peut se propager au sous-réseau Application Gateway. Mais Application Gateway ne prend pas en charge cet itinéraire. Dans ce cas, configurez une table de routage pour le sous-réseau Application Gateway. Incluez un itinéraire pour 0.0.0.0/0 et un type de tronçon suivant de Internet dans cette table.

Adresses IP privées et IDPS

Comme expliqué dans règles IDPS du pare-feu Azure, le Pare-feu Azure Premium décidera des règles IDPS à appliquer en fonction des adresses IP source et de destination des paquets. Le Pare-feu Azure traite les adresses IP privées par défaut dans les plages RFC 1918 (10.0.0.0/8, 192.168.0.0/16 et 172.16.0.0/12) et la plage RFC 6598 (100.64.0.0/10) comme internes. Par conséquent, si comme dans les diagrammes de cet article, Application Gateway est déployé dans un sous-réseau de l’une de ces plages (172.16.0.0/24 dans les exemples ci-dessus), Le Pare-feu Azure Premium envisage le trafic entre Application Gateway et la charge de travail pour qu’elle soit interne, et seules les signatures IDPS marquées pour être appliquées au trafic interne ou à tout trafic seront utilisées. Les signatures IDPS marquées pour ê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 les règles de signature entrante IDPS à appliquer au trafic entre Application Gateway et la charge de travail consiste à placer Application Gateway dans un sous-réseau avec un préfixe en dehors des plages privées. Vous n’avez pas nécessairement besoin d’utiliser des adresses IP publiques pour ce sous-réseau, mais vous pouvez personnaliser les adresses IP traitées par le Pare-feu Azure Premium comme internes pour IDPS. Par exemple, si votre organisation n’utilise pas la plage de 100.64.0.0/10, vous pouvez éliminer cette plage de la liste des préfixes internes pour IDPS (voir plages d’ADRESSES IP privées Premium pare-feu Azure pour plus d’informations sur la façon de procéder) 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 une confiance zéro
• routage du trafic de réseau virtuel
• fonctionnement d’une passerelle Application Gateway

Ressources associées

• [Sécuriser et régir les charges de travail avec segmentation au niveau du réseau][Sécuriser et régir les charges de travail avec segmentation au niveau du réseau]
• Implémenter un réseau hybride sécurisé
• topologie de réseau hub-spoke dans Azure
• topologie de réseau hub-spoke avec azure Virtual WAN