Pare-feu d’applications Web

Les pare-feu d’applications Web (WAF) représentent un type de technologie de proxy inverse qui fonctionne au niveau de la couche 7 de la pile OSI (Open Systems Interconnection). Ils sont généralement mis en œuvre pour protéger les applications et les services Web contre le trafic ou les utilisateurs malveillants. Un WAF est généralement déployé en tant que composant matériel ou logiciel ou en tant que service géré natif du Cloud. Il fonctionne principalement comme un proxy inverse, parfois dans une configuration 1:1 pour les systèmes back-end. Il peut aussi prendre en charge plusieurs systèmes back-end et plusieurs adresses IP ou noms d’hôte front-end.

Les WAF sont différents des proxys inverses classiques, car ils sont conçus pour protéger l’application back-end. Ils ne se contentent pas de transmettre les requêtes de manière transparente. Ils ont généralement une logique d’inspection des demandes (y compris l’URL de la requête, les en-têtes, l’emplacement source et le corps), en vue de détecter des contenus malveillants ou potentiellement malveillants. La plupart des WAF mettent en œuvre un ensemble de règles commun (défini par le fabricant ou une communauté) pour identifier les tentatives malveillantes courantes, telles que l’injection SQL, la falsification de requête côté serveur (SSRF) ou d’autres types de comportement. Les WAF peuvent également mettre en œuvre un comptage, pour limiter le nombre de requêtes émises sur une certaine période, se protéger contre les attaques par déni de service distribué (DoS) et filtrer l’accès pour bloquer les adresses IP provenant de certaines zones géographiques ou sources. Chacune de ces règles peut être activée ou désactivée individuellement, et le WAF peut implémenter et appliquer des centaines ou des milliers de ces règles à l’application protégée.

Deux modes peuvent, en principe, être configurés pour les WAF :

• Mode de détection : ce mode permet généralement au trafic de transiter par le WAF de manière transparente, mais consigne toutes les requêtes qui déclenchent une détection de règle. L’administrateur peut se référer à cette liste pour identifier les requêtes qui peuvent représenter du trafic valide et éventuellement désactiver ou ajuster cette règle pour s’assurer que les requêtes valides ne sont pas bloquées.
• Mode de protection : ce mode bloquera activement (en renvoyant une erreur HTTP ou un délai d’expiration) toute requête qui déclenche ces règles.

Surveillance du trafic entrant

La surveillance du trafic entrant fait référence à l’inspection et au filtrage des requêtes entrant sur un système, qu’elles proviennent de sources internes ou publiques. Bien que la surveillance du trafic entrant puisse désigner d’autres méthodes ou approches que les WAF, ces concepts sont souvent étroitement liés.

Utilisation des WAF pour accéder aux systèmes ArcGIS

Le logiciel ArcGIS utilise une grande variété de types de requêtes et de réponses HTTP, allant des requêtes GET, POST et OPTIONS aux corps de contenu volumineux, aux en-têtes uniques et à diverses méthodes d’authentification basée sur des jetons. Un WAF trop classique est susceptible de poser des problèmes pour les applications clientes d’un déploiement ArcGIS Enterprise.

Lors de l’implémentation ou de l’utilisation d’un WAF dans le cadre d’un déploiement ArcGIS, tenez compte des conseils suivants :

• Commencez en appliquant le mode de détection au trafic utilisateur réel : cela permet d’identifier les requêtes valides (représentant une activité utilisateur réelle et utile), mais qui seraient bloquées par le WAF si celui-ci était configuré en mode de protection.
• Consultez les consignes Esri existantes : Esri suggère un ensemble de paramètres de règle pour le produit Azure WAF. Vous pouvez vous en servir pour identifier d’autres règles potentiellement problématiques dans d’autres produits WAF.
• Testez, testez, testez : lorsque vous activez le mode de protection, testez un ensemble complet de processus (de la publication à l’interaction avec les données, en passant par le téléchargement des données), afin d’identifier les règles susceptibles d’être mal configurées. Par exemple, testez une requête de géotraitement synchrone de longue durée pour vous assurer que le délai d’expiration par défaut du système n’est pas trop court.
• Effectuez un dépannage au moyen de la procédure de tests 1:1 : lorsqu’une requête est bloquée ou renvoie une erreur via le WAF, testez d’abord la requête à l’aide d’un client HTTP par rapport à l’URL du back-end (derrière le WAF) pour vous assurer qu’il ne s’agit pas d’un problème système. Veillez ensuite à modifier la configuration du WAF pour autoriser la requête, si nécessaire.

Esri fournit un exemple détaillé de compatibilité des règles WAF, basé sur l’offre Azure WAF, qui permet d’identifier les règles ou les configurations qui peuvent causer des problèmes pour les déploiements ArcGIS et qui doivent être désactivées. Ce document est disponible dans ArcGIS Trust Center : ArcGIS Enterprise Web Application Filter Rules (identifiant de connexion ArcGIS requis).

Cet exemple inclut des règles spécifiques d’un fournisseur WAF particulier, mais peut vous aider à configurer les ensembles de règles WAF propres à une organisation à l’avenir. Gardez également à l’esprit que certaines fonctionnalités de l’application peuvent être bloquées par un WAF. Cela est acceptable s’il n’a jamais été prévu d’utiliser cette application ou ce service avec un système. Le fait que le trafic soit bloqué peut alors être considéré comme un faux problème. Au fur et à mesure que d’autres tests ou validations WAF seront effectués, d’autres ressources seront référencées sur cette page. À ce stade, l’ensemble de règles Azure WAF est le seul exemple détaillé disponible. Il n’en reste pas moins une bonne base pour configurer d’autres produits ou offres WAF de façon appropriée.