Web Application Firewall pour les réseaux Azure

Azure Web Application Firewall (WAF) protège vos applications web contre les attaques de couche HTTP courantes telles que l’injection SQL, les scripts intersites (XSS) et la traversée de chemin d’accès. Contrairement à Pare-feu Azure, qui inspecte le trafic des couches 3 à 7 pour les menaces au niveau du réseau, WAF fonctionne uniquement au niveau de la couche 7 et comprend la sémantique HTTP, notamment les en-têtes de requête, les chaînes de requête, les corps de requête et les cookies. Déployez WAF en tant que stratégie attachée à Azure Application Gateway (régional) ou Azure Front Door (périphérie globale) pour faire correspondre l’étendue de protection à l’architecture de votre application. Web Application Firewall est l’un des trois services principaux de sécurité réseau Azure, aux côtés d’Pare-feu Azure et Azure DDoS Protection.

Présentation de cet article

Cet article traite de la protection de la couche HTTP à l’aide de Azure Web Application Firewall. Vous apprendrez à propos de :

  • Comparaison de plateforme entre waf sur Application Gateway v2 et WAF sur Azure Front Door.
  • Ensembles de règles basés sur OWASP, y compris l’ensemble de règles par défaut (DRS) et le jeu de règles de base (CRS).
  • Mode de détection par rapport au mode prévention et quand utiliser chacun d’eux.
  • Options de portée de la stratégie WAF : associations globales, par site et par écouteur.
  • Règles personnalisées pour la limitation de débit, le filtrage géographique et la logique propre à l’application.
  • Distinction entre waf (HTTP de couche 7) et Pare-feu Azure (couches 3 à 7 réseau).

Qui a besoin de cet article

Déployez WAF lorsque vos charges de travail répondent à un ou plusieurs des critères suivants :

  • Applications web publiques : Vos applications acceptent le trafic HTTP/HTTPS entrant à partir d’Internet, les exposant aux OWASP 10 principales vulnérabilités, notamment les attaques par injection, les abus d’authentification rompus et les tentatives d’exposition aux données sensibles.
  • Exigences de conformité : Les frameworks réglementaires tels que PCI DSS (Payment Card Industry Data Security Standard) imposent un pare-feu d’applications web devant toute application qui traite les données de carte de paiement.
  • Protection des API : Vos API sont accessibles publiquement et nécessitent une protection contre la contrebande de demandes, les charges utiles surdimensionnées et les attaques au niveau du protocole que les pare-feu réseau n’inspectent pas.
  • Atténuation des bots : Vous devez classer et contrôler le trafic automatisé, bloquer les bots malveillants tout en autorisant les analyseurs légitimes et les services de surveillance.

Les organisations qui n’ont besoin que du filtrage du trafic au niveau du réseau (IP, port et protocole) sans inspection des requêtes HTTP doivent utiliser à la place Pare-feu Azure ou groupes de sécurité réseau.

Priorité au lift-and-shift : de nombreuses applications internes réhébergées n'ont pas de trafic d'entrée Internet et n'ont donc pas besoin de WAF. Ajoutez WAF uniquement lorsque vous exposez une application web à Internet pendant ou après la migration.

Priorité à la modernisation : protégez les applications web destinées aux clients avec un WAF sur Azure Front Door pour les applications mondiales, ou sur Application Gateway pour les applications monorégionales, conformément à votre choix entre Front Door et Traffic Manager pour la diffusion.

Priorité aux environnements intercloud : placez un WAF de couche 7 sur Application Gateway dans le spoke pour les applications web publiques migrées, et alignez les protections web des autres clouds (comme Google Cloud Armor) sur Azure WAF.

Comparaison des plateformes Azure WAF

Azure WAF est disponible sur deux plateformes. Chaque plateforme intègre l’inspection WAF à un point différent dans le flux de trafic.

Diagramme montrant Azure Web Application Firewall architecture avec les options de déploiement Application Gateway et Front Door

Capacité WAF sur Application Gateway v2 WAF sur Azure Front Door
Étendue du déploiement Régional (région Azure unique) Mondial (plus de 192 PoP Edge dans le monde)
Point d’inspection Une fois le trafic atteint votre région Au niveau du PoP Edge, avant que le trafic n'atteigne l'origine
Jeux de règles pris en charge DRS 2.2, DRS 2.1, CRS 3.2 DRS 2.2, DRS 2.1, DRS 2.0
Règles personnalisées ✔ ✔
Protection des bots ✔ ✔ (Niveau Premium uniquement)
Limitation de débit de données ✔ ✔
Geo-filtering ✔ ✔
Stratégie par site ✔ (par écouteur, par chemin) ✔ (par point de terminaison)
Ensembles de règles managés ✔ ✔ (Niveau Premium uniquement ; Standard prend uniquement en charge les règles personnalisées)
Inspection du corps des demandes Jusqu’à 128 Ko (configurable) Jusqu’à 128 Ko (configurable)
prise en charge de l’origine Private Link N/A (intégré à App Gateway) ✔ (connectivité d’origine privée)
Idéal pour Applications à région unique, équilibrage de charge L7 + WAF Applications multirégions, accélération globale + WAF

Note

Azure Front Door a deux niveaux : Standard et Premium. Les ensembles de règles gérés (y compris DRS et la protection contre les bots) sont disponibles uniquement avec Front Door Premium. Front Door Standard prend uniquement en charge les règles personnalisées. Front Door (classique) prend uniquement en charge DRS 1.1 ou version antérieure.

Comment choisir votre plateforme WAF

Utilisez les critères de décision suivants :

  • Choisissez WAF sur Application Gateway lorsque votre application se déploie dans une seule région et que vous utilisez déjà Application Gateway pour l’équilibrage de charge de couche 7, l’arrêt TLS ou le routage basé sur le chemin. WAF ajoute une inspection HTTP en ligne sans introduire de saut de service supplémentaire.
  • Choisissez WAF sur Azure Front Door lorsque votre application s’étend sur plusieurs régions, nécessite un équilibrage de charge global ou bénéficie de l’accélération du réseau de distribution de contenu (CDN). Front Door WAF inspecte le trafic au point de présence (PoP) Edge le plus proche. Le service bloque les requêtes malveillantes avant de traverser le Azure principal pour atteindre votre origine. Cette approche réduit l’exposition de la surface d’attaque et absorbe les attaques volumétriques de couche 7 à la périphérie.
  • Choisissez les deux (couches) lorsqu’une application multirégion fournie par Front Door nécessite également des stratégies WAF régionales qui diffèrent pour chaque back-end. Front Door offre une protection globale de première ligne, tandis que le WAF Application Gateway applique des règles personnalisées spécifiques à une région plus proche de la charge de travail.

Considérations relatives à la conception

Priorité de conception WAF pour le lift-and-shift

  • N’utilisez pas de WAF pour les charges de travail réhébergées à usage interne uniquement qui ne reçoivent aucun trafic entrant depuis Internet ; réévaluez ce choix lorsque vous exposez une application sur Internet.
  • Lorsque vous exposez une application web, commencez par exécuter le WAF en mode Détection afin d'établir une base de référence du trafic, puis passez en mode Prévention après avoir éliminé les faux positifs.
  • Utilisez Application Gateway WAF pour une application web monorégionale réhébergée que vous avez déjà placée derrière Application Gateway pour le routage de couche 7.
  • Réutilisez l’intention de vos règles de protection web locales (par exemple, la couverture OWASP) comme stratégie de démarrage.

Moderniser l’approche de conception du WAF

  • Exécutez waf en mode Prévention à partir du démarrage pour les applications orientées client et adoptez le dernier ensemble de règles managées afin que la couverture effectue le suivi automatique des nouvelles menaces OWASP.
  • Activez la gestion des bots pour séparer les analyseurs légitimes de l’automatisation malveillante par rapport à vos applications publiques.
  • Gérez la stratégie WAF en tant que code afin que les back-ends régionaux actifs restent synchronisés via votre pipeline de déploiement.
  • Associez le WAF en périphérie au pare-feu du hub pour une défense en profondeur, et activez la remise sur la facturation du WAF d’Application Gateway en activant la protection DDoS Network Protection sur le réseau virtuel (VNet).

Accent sur la conception d’un WAF multi-cloud

  • Héberger un WAF de couche 7 sur Application Gateway dans le réseau virtuel spoke afin que le trafic web public soit inspecté sans attacher d’adresses IP publiques directement aux machines virtuelles.
  • Faites correspondre les protections web existantes provenant d’autres fournisseurs de cloud (par exemple, AWS WAF ou Google Cloud Armor) aux ensembles de règles managées d’Azure WAF afin de conserver la même couverture.
  • Inspectez les communications publiques via le WAF, et conservez l'inspection du trafic est-ouest et du transit intercloud sur le pare-feu du hub Virtual WAN.
  • Pendant le basculement, exécutez d'abord le WAF en mode Détection (apprentissage), puis activez la prévention une fois les modèles de trafic légitime confirmés.

Prerequisites

Avant de déployer Azure Web Application Firewall, vérifiez que vous disposez des points suivants :

  • Ressource Application Gateway v2 ou Azure Front Door : WAF se déploie en tant que stratégie attachée à l’une de ces plateformes. Vous devez disposer d’une instance Application Gateway v2 existante ou d’un profil Azure Front Door provisionné avant de créer et d’associer une stratégie WAF.
  • Charge de travail HTTP/HTTPS publique : Votre application doit recevoir le trafic HTTP/HTTPS entrant. WAF inspecte la sémantique au niveau des requêtes et ne fournit aucun avantage pour les charges de travail non HTTP ou les services purement internes.
  • Présentation des modèles de trafic HTTP : La connaissance des modèles de requête normaux de votre application (en-têtes, paramètres de requête et contenu du corps) vous permet de configurer des exclusions et de régler des règles pour réduire les faux positifs pendant la transition du mode détection-prévention.

Ensembles de règles et traitement des règles

WAF utilise des ensembles de règles pour détecter des modèles malveillants dans les requêtes HTTP. La compréhension de la hiérarchie de règles et de l’ordre de traitement vous aide à paramétrer waf pour vos applications spécifiques.

Ensembles de règles managés

Microsoft gère les ensembles de règles managés en fonction des modèles CRS (OWASP Core Rule Set). L’ensemble de règles recommandé pour les nouveaux déploiements est DRS 2.2 (ensemble de règles par défaut). DRS 2.2 s’appuie sur OWASP CRS 3.3.4 et ajoute des signatures de Microsoft Threat Intelligence.

Ensemble de règles Basé sur Support de la plateforme Recommendation
DRS 2.2 OWASP CRS 3.3.4 + Microsoft Threat Intel App Gateway v2, Front Door Premium Recommandé pour les nouveaux déploiements
DRS 2.1 OWASP CRS 3.3 App Gateway v2, Front Door Premium Génération précédente ; pris en charge sur les deux plateformes
DRS 2.0 OWASP CRS 3.2 Front Door Premium uniquement Pris en charge ; version N-2 de Front Door
CRS 3.2 OWASP CRS 3.2 App Gateway v2 uniquement Prise en charge ; utiliser DRS 2.2 pour les nouveaux déploiements

Les ensembles de règles DRS et CRS utilisent l'évaluation des anomalies. Chaque règle de correspondance contribue à un score au lieu de bloquer immédiatement la requête. Lorsque le score d’anomalie cumulé dépasse un seuil configurable, le WAF prend des mesures (blocage ou journalisation). Cette approche réduit les faux positifs par rapport au blocage de règles individuelles, car une seule correspondance de faible confiance ne déclenche pas l'application de la règle.

Règles personnalisées

Les règles personnalisées s’exécutent avant les règles gérées et utilisent des numéros de priorité pour contrôler l’ordre d’évaluation (nombre inférieur = priorité supérieure). Utilisez des règles personnalisées pour :

  • Limitation du taux de requêtes : Limitez le nombre de requêtes pour chaque adresse IP cliente sur une période donnée afin de contrer les attaques par bourrage d’identifiants et par force brute.
  • Filtrage géographique : Autorisez ou refusez le trafic en fonction du pays ou de la région d’origine du client.
  • Listes d’autorisation IP et listes de refus : Autorisez les adresses IP partenaires connues ou bloquez les acteurs malveillants connus avant l’évaluation des règles gérées.
  • Inspection de l’en-tête de la demande : Appliquez des exigences spécifiques à l’application, telles que les clés API obligatoires ou les types de contenu attendus.

Ensemble de règles de protection anti-bot

Les deux plateformes offrent un ensemble de règles de protection de bot qui catégorise le trafic automatisé en bons bots (moteurs de recherche vérifiés), les bots incorrects (scanneurs malveillants connus) et les bots inconnus. Configurez des actions pour chaque catégorie : autorisez de bons bots, bloquez les bots incorrects et défiez les bots inconnus avec une limitation de débit ou CAPTCHA.

Mode de détection vs. mode de prévention

Les stratégies WAF fonctionnent dans l’un des deux modes qui déterminent la façon dont le système gère les demandes correspondantes :

Mode Behavior Cas d’utilisation
Détection Journalise les demandes correspondantes, mais ne les bloque pas. Les demandes continuent vers le back-end. Déploiement initial et réglage des règles. Surveillez quelles règles se déclenchent sans affecter le trafic de production.
Prévention Bloque les requêtes correspondantes et renvoie une réponse HTTP 403. Enregistre la demande bloquée. Charges de travail de production une fois le réglage des règles terminé. Protection active contre les attaques.
  1. Déployer en mode détection : Activez WAF avec l’ensemble de règles choisi en mode détection. Acheminer le trafic de production via le WAF.
  2. Analysez les journaux : Passez en revue les journaux WAF pour identifier les faux positifs. Déterminez les règles qui se déclenchent sur le trafic légitime de l'application.
  3. Créer des exclusions : Pour les règles qui génèrent des faux positifs, définissez des exclusions qui spécifient les champs de requête (en-têtes, cookies et paramètres de requête) à ignorer pour des règles spécifiques.
  4. Basculez vers le mode Prévention : Après 1 à 2 semaines de journaux de détection propres avec des taux de faux positifs acceptables, basculez vers le mode prévention pour le blocage actif.
  5. Surveillance continue : continuez à surveiller les journaux après le passage en mode Prévention. De nouvelles fonctionnalités d’application ou modifications d’API peuvent introduire de nouveaux modèles faux positifs.

Important

Exécutez toujours des charges de travail de production en mode Prévention. Le mode de détection ne fournit aucune protection. Il journalise uniquement les attaques potentielles. Utilisez le mode détection uniquement pendant la phase de paramétrage initiale ou lorsque vous résolvez un problème spécifique faux positif.

Portée et association de la politique WAF

Une stratégie WAF est une ressource Azure autonome qui contient votre sélection de mode, la configuration de l’ensemble de règles, les règles personnalisées et les exclusions. Associez la stratégie à une ou plusieurs cibles pour contrôler l’étendue de protection.

Portée de la stratégie WAF d’Application Gateway

Sur Application Gateway, associez une stratégie WAF à trois niveaux de granularité :

  • Global (à l'échelle de la passerelle) : la stratégie s'applique à tous les écouteurs et à toutes les règles de chemin d'Application Gateway. Utilisez l’étendue globale lorsque toutes les applications derrière la passerelle partagent les mêmes exigences de protection.
  • Niveau de l’écouteur : Une autre stratégie WAF s’applique à un écouteur spécifique (nom d’hôte et combinaison de ports). Utilisez la portée au niveau de l’écouteur lorsque plusieurs applications partagent une passerelle, mais nécessitent des ajustements des règles ou des exclusions différents.
  • Au niveau des règles de chemin : une stratégie WAF s'applique à une règle de chemin d'URL spécifique au sein d'un écouteur. Utilisez la portée des règles de chemin d’accès pour un contrôle granulaire des applications avec une sensibilité variable des back-ends.

Lorsque plusieurs étendues s'appliquent à une même demande, la stratégie la plus spécifique prévaut : une règle de chemin remplace une règle au niveau de l'écouteur, qui elle-même remplace une règle globale.

Étendue de la stratégie WAF Front Door

Sur Front Door, les stratégies WAF sont associées au niveau du point de terminaison ou de la route. Chaque point de terminaison Front Door peut avoir sa propre stratégie WAF. Cette approche permet d’activer des profils de protection spécifiques à l’application au sein d’une seule instance Front Door.

Partage de stratégies entre les ressources

Partagez une stratégie WAF unique sur plusieurs instances Application Gateway ou points de terminaison Front Door. Azure Firewall Manager offre une visibilité et une gestion centralisées sur toutes vos stratégies WAF, quelle que soit la plateforme. Utilisez des stratégies partagées lorsque plusieurs ressources nécessitent une protection identique pour simplifier la gestion et maintenir une posture de sécurité cohérente.

Distinction de Pare-feu Azure

WAF et Pare-feu Azure protègent différentes couches de la pile réseau et remplissent des rôles complémentaires. Déployez les deux pour la défense en profondeur.

Attribute pare-feu pour applications web Pare-feu Azure
Couche OSI Couche 7 (HTTP/HTTPS uniquement) Couches 3 à 7 (réseau et application)
Type de trafic Requêtes HTTP/HTTPS entrantes vers des applications web Toutes les directions de trafic (nord-sud, est-ouest)
Focus d’inspection Sémantique HTTP : en-têtes, corps, cookies, URI Adresses IP, ports, protocoles, noms de domaine complets, URL
Moteur de règles Correspondance de motifs basée sur les règles OWASP + notation des anomalies Règles réseau, règles d’application, règles NAT
Modèle de déploiement Intégré à App Gateway ou Front Door Autonome dans le sous-réseau hub avec routage UDR
Attaques classiques bloquées Injection SQL, XSS, CSRF, traversée de chemin Analyse des ports, rappels C2, exfiltration DNS

Utilisez WAF pour la protection des applications HTTP et Pare-feu Azure pour l’inspection centralisée du trafic réseau. Dans une architecture hub-spoke, le trafic d’Internet vers une application web transite généralement par Pare-feu Azure (pour l’inspection au niveau du réseau et DNAT), puis via Application Gateway avec WAF (pour l’inspection de la couche HTTP). Consultez Pare-feu Azure et l’inspection du trafic pour le composant au niveau du réseau.

Considérations relatives à la sécurité

Les pratiques de sécurité suivantes vous aident à bénéficier de la protection la plus optimale à partir du WAF :

  • Mode de prévention en production : Ne laissez jamais les charges de travail en production en mode détection. Le mode de détection offre de la visibilité, mais aucune application des règles, laissant les applications exposées aux attaques.
  • Le réglage des règles est en cours : Les applications évoluent. Les nouveaux points de terminaison, paramètres et types de contenu d’API peuvent déclencher des faux positifs dans les ensembles de règles existants. Passez en revue régulièrement les journaux WAF après les déploiements.
  • Intégration à Log Analytics : Envoyez les journaux de diagnostic du WAF vers un espace de travail Log Analytics. Utilisez le classeur WAF afin de visualiser les requêtes bloquées, les règles déclenchées et la répartition des scores d’anomalie.
  • DDoS et WAF ensemble : WAF protège contre les attaques d’application de couche 7, mais n’atténue pas les attaques DDoS de couche réseau volumetrice. Associez le WAF à Azure DDoS Protection pour une protection complète de la pile.
  • Verrouillage de l’origine : Lorsque vous utilisez Front Door WAF, configurez votre origine pour accepter le trafic uniquement à partir de l’étiquette de service Front Door. Sans verrouillage d’origine, les attaquants peuvent contourner Front Door et envoyer des demandes directement à votre adresse IP d’origine.
  • Protection des données sensibles : Les journaux WAF peuvent contenir des données de requête. Configurez les règles de nettoyage des journaux pour masquer les champs sensibles (en-têtes d’autorisation, cookies ou contenu du corps de la requête) dans les journaux de diagnostic du WAF.

Les articles suivants couvrent les rubriques de sécurité réseau associées :

Learn more

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Étape suivante de votre parcours lift-and-shift :

Configurez la surveillance de votre réseau migré : validez la connectivité et les performances après la configuration de votre pare-feu d’applications web.

Ensuite, dans votre parcours de modernisation :

Activez la protection DDoS pour les points de terminaison publics : protégez vos ressources IP publiques contre les attaques par déni de service distribués.

Prochaine étape de votre parcours multi-cloud :

Déployez vos applications migrées : associez les équilibreurs de charge d’AWS et de Google Cloud à leurs équivalents dans Azure pour vos charges de travail multicloud.

  • Last updated on