paint-brush
WAF ne suffit plus : exploration des quatre piliers de la sécurité Web pour AWSpar@reblaze
304 lectures
304 lectures

WAF ne suffit plus : exploration des quatre piliers de la sécurité Web pour AWS

par Reblaze8m2023/07/20
Read on Terminal Reader

Trop long; Pour lire

Les pare-feu d'applications Web (WAF) sont depuis longtemps la principale solution de sécurité pour protéger les applications Web contre les attaques malveillantes. Pour assurer une sécurité Web complète, des mesures supplémentaires sont nécessaires pour compléter les capacités d'un WAF. Dans cet article, nous utilisons AWS comme exemple pour discuter des quatre piliers d'une sécurité Web robuste : WAF, DDoS Protection, API Security et Bot Management.
featured image - WAF ne suffit plus : exploration des quatre piliers de la sécurité Web pour AWS
Reblaze HackerNoon profile picture
0-item
1-item
2-item


Dans le paysage numérique actuel, la sécurité Web est de la plus haute importance pour les entreprises qui s'appuient sur des applications Web pour servir leurs clients et générer des revenus.


Les pare-feu d'applications Web (WAF) sont depuis longtemps la principale solution de sécurité pour protéger les applications Web contre les attaques malveillantes. Cependant, l'évolution actuelle du paysage des menaces exige une approche plus globale. Bien que les WAF excellent dans l'inspection et le filtrage des requêtes HTTP hostiles, ils peuvent ne pas être efficaces contre les attaques plus sophistiquées et ciblées. Pour assurer une sécurité Web complète, des mesures supplémentaires sont nécessaires pour compléter les capacités d'un WAF.


Dans cet article, nous discutons des quatre piliers d'une sécurité Web robuste, allant au-delà du WAF pour inclure la protection DDoS, la sécurité des API et la gestion des bots. Nous explorons les forces et les faiblesses de chacun, ce qui démontrera pourquoi une stratégie robuste inclut les quatre.


Aperçu du contenu

  • Utiliser AWS comme exemple
  • Pilier 1 : Pare-feu d'application Web (WAF)
  • Pilier 2 : Protection DDoS
  • Pilier 3 : Sécurité des API
  • Pilier 4 : Gestion des bots


Utiliser AWS comme exemple

Pour illustrer les concepts de cet article, nous nous concentrerons sur les organisations utilisant Services Web Amazon (AWS) , bien que les mêmes concepts s'appliquent également à Google Cloud et Microsoft Azure .


Pilier 1 : Pare-feu d'application Web (WAF)

Pourquoi c'est important : comme indiqué ci-dessus, un WAF est un composant essentiel de la sécurité Web, conçu pour inspecter et filtrer le trafic HTTP/HTTPS afin d'identifier et de bloquer les requêtes malveillantes. Les WAF jouent un rôle crucial dans la protection contre les attaques courantes des applications Web, telles que l'injection SQL et les scripts intersites (XSS).


Disponibilité sur AWS : Amazon propose un service WAF natif (AWS WAF), qui permet aux organisations de créer des règles et des politiques personnalisées pour la sécurité de la couche application. De nombreux WAF tiers peuvent également être utilisés pour filtrer les demandes entrantes pour les charges de travail AWS ; quelques-uns d'entre eux peuvent même s'exécuter en mode natif dans les environnements AWS.


Pourquoi ce n'est pas suffisant : bien qu'AWS WAF fournisse une base solide pour la sécurité des applications Web, il présente certaines limites. Tout d'abord, il se concentre principalement sur les modèles d'attaque connus, ce qui signifie qu'il peut ne pas être efficace contre les attaques zero-day ou les menaces émergentes. Deuxièmement, les WAF sont conçus pour identifier les menaces basées sur des requêtes hostiles, mais de nombreux types d'attaques sont basés sur des requêtes qui semblent bénignes. Troisièmement, comme pour de nombreux WAF, AWS WAF exige que les utilisateurs créent et maintiennent leurs propres politiques et ensembles de règles de sécurité, ce qui peut être difficile.


Répondre à ses limites : les organisations doivent envisager d'augmenter AWS WAF avec des mesures de sécurité supplémentaires (en plus des autres piliers décrits ci-dessous). Certains WAF tiers intègrent des flux de renseignements sur les menaces qui peuvent fournir des données sur les menaces en temps réel et des mécanismes de défense proactifs. Cela permet aux entreprises de garder une longueur d'avance sur les menaces émergentes et de renforcer leurs défenses contre l'évolution des vecteurs d'attaque.


De plus, la mise en œuvre d'algorithmes avancés d'analyse comportementale et d'apprentissage automatique peut améliorer les capacités WAF en détectant les anomalies et en identifiant de nouveaux modèles d'attaque. En tirant parti de ces technologies, les organisations peuvent améliorer la précision et l'efficacité de leur WAF, renforçant ainsi la sécurité globale de leurs applications Web.


Enfin, certains WAF tiers sont disponibles en tant que solutions de pare-feu d'applications Web entièrement gérées. Cela soulage les organisations clientes de la responsabilité de créer et de maintenir leurs propres politiques de sécurité (ce qui nécessite beaucoup de temps et d'expertise) car le fournisseur le fait pour elles.


Pilier 2 : Protection DDoS

Pourquoi c'est important : __Les attaques par déni de service distribué (DDoS) __constituent une menace importante pour les applications Web, avec le potentiel de submerger les serveurs et de perturber la disponibilité des services. L'extorsion DDoS est une tactique populaire parmi les pirates et peut être particulièrement efficace (pour les attaquants) pendant les périodes où les victimes reçoivent normalement des volumes élevés de trafic et de revenus.


Disponibilité sur AWS : AWS fournit une protection DDoS intégrée via AWS Shield, qui protège contre les attaques volumétriques les plus courantes et à grande échelle.


Pourquoi ce n'est pas suffisant : AWS Shield Standard est gratuit, mais il n'offre pas une protection complète contre les attaques DDoS (par exemple, il ne protège pas contre les attaques de niveau 7). La plupart des organisations devront acheter AWS Shield Advanced à la place, mais cela peut être coûteux (à un tarif de base de 3 000 USD par mois plus les frais de données et un engagement d'un an). Même dans ce cas, il a du mal à protéger les API et, à l'exception des zones hébergées par AWS Route 53, AWS Shield ne protège pas les ressources dans les déploiements hybrides/multi-cloud.


Enfin, AWS Shield est destiné à atténuer les attaques volumétriques simples. Il n'est pas conçu pour se défendre contre des tactiques plus sophistiquées telles que les attaques DDoS yo-yo, qui sont conçues pour infliger un maximum de dommages financiers à la victime tout en minimisant les ressources dépensées par l'attaquant.


Répondre à ses limites : les organisations peuvent envisager d'augmenter ou de remplacer AWS Shield par une solution d'atténuation DDoS qui exploite des algorithmes de détection avancés et une analyse du trafic. Ces solutions fournissent une surveillance et une atténuation en temps réel, permettant une identification et une neutralisation proactives des menaces DDoS en constante évolution. Ils auront souvent des structures à moindre coût (en particulier les solutions tout-en-un qui incluent la protection DDoS dans le cadre d'une plate-forme complète), et la plupart prendront en charge les architectures hybrides et multi-cloud.


En outre, comme indiqué ci-dessus, une solution entièrement gérée peut être utile pour vaincre les attaques sophistiquées telles que les yo-yos orchestrés par l'homme, l'épuisement des ressources (une tactique qui peut être utilisée contre le sans serveur) et d'autres stratégies, car l'équipe de sécurité du fournisseur surveiller et réagir aux incidents au fur et à mesure qu'ils surviennent.


Pilier 3 : Sécurité des API

Pourquoi c'est important : les API sont devenues un élément crucial pour une intégration et un échange de données transparents pour de nombreuses raisons, notamment la popularité du cloud computing, la prévalence des architectures de microservices, le nombre croissant d'applications mobiles, etc. À mesure que le trafic des API a augmenté, la sécurisation des API contre les activités hostiles est devenue d'une importance vitale.


Disponibilité sur AWS : AWS propose des services tels qu'AWS Identity and Access Management (IAM) et Amazon API Gateway. IAM permet aux organisations de gérer l'accès aux ressources AWS, tandis qu'API Gateway fournit des fonctionnalités d'authentification, d'autorisation et de gestion du trafic.


Pourquoi ce n'est pas suffisant : pour protéger leurs API, les utilisateurs d'AWS doivent utiliser AWS WAF avec API Gateway. Cela signifie que les limitations d'AWS WAF s'appliquent également à la sécurité des API. En fait, il y a en fait plus de limitations lorsqu'il est utilisé dans ce contexte. Par exemple, dans certaines situations, AWS WAF utilise des défis de navigateur et des CAPTCHA pour vérifier les demandes entrantes, mais ceux-ci ne peuvent pas être appliqués au trafic d'API.


Répondre à ses limites : les utilisateurs d'AWS peuvent augmenter les capacités de sécurité natives d'AWS avec d'autres outils. Certaines solutions de sécurité tierces incluent des fonctionnalités étendues pour protéger le trafic des API avec la même efficacité que le trafic des applications Web, non seulement pour filtrer les requêtes hostiles, mais également dans des capacités connexes telles que des contrôles d'accès granulaires et une visibilité et une journalisation complètes du trafic. Certains vont encore plus loin et tirent parti des opportunités de protection supplémentaire dans certaines situations, par exemple en fournissant un SDK pour renforcer davantage le trafic des applications mobiles.


Pilier 4 : Gestion des bots

Pourquoi c'est important : La prévalence des bots sur le Web représente un défi important pour les organisations. Alors que certains bots servent à des fins légitimes, d'autres sont déployés pour des activités malveillantes telles que la prise de contrôle de compte, le scraping de contenu et le credential stuffing. En moyenne, environ 38 % du trafic Web total est constitué de robots hostiles.


Les technologies de sécurité Web traditionnelles telles que les WAF ne sont pas conçues pour détecter les bots hostiles, car la plupart des formes de trafic automatisé se font passer pour des utilisateurs légitimes. Habituellement, les demandes individuelles semblent bénignes (et évitent ainsi le filtrage). Leurs objectifs malveillants ne se manifestent que dans leurs actions collectives. Par exemple, les robots de déni d'inventaire semblent être des clients légitimes effectuant des activités d'achat ; cependant, ces « clients » n'achètent jamais rien. Au lieu de cela, ils prennent des mesures qui rendent l'inventaire indisponible pour les clients légitimes (comme placer des articles dans des paniers d'achat, effectuer les étapes initiales des réservations de voyage, etc., mais ne jamais consommer les transactions).


Disponibilité sur AWS : Amazon propose AWS WAF Bot Control, un ensemble de règles gérées pour AWS WAF.


Pourquoi ce n'est pas suffisant : En tant que module complémentaire d'AWS WAF, Bot Control inclut les mêmes limitations que celles mentionnées ci-dessus. Cependant, ces problèmes sont amplifiés lorsque l'on essaie d'exclure les bots hostiles des applications Web et des API, car, parmi toutes les formes d'attaques Web, les plus complexes et les plus sophistiquées sont souvent menées par des bots. Par exemple, le manque de précision dans les capacités de limitation de débit d'AWS rend difficile le blocage complet des bots qui effectuent du bourrage d'informations d'identification et d'autres formes d'attaques ATO (prise de contrôle de compte). Une visibilité incomplète ou retardée du trafic peut empêcher les clients de comprendre pleinement l'activité des bots dans leurs propriétés Web ou d'affiner les politiques de sécurité pour réduire les fausses alarmes négatives et fausses positives. Devoir écrire et maintenir des politiques de sécurité compliquées augmente le risque d'erreur. Et ainsi de suite.


Ensuite, l'utilisation de Bot Control crée des frais d'utilisation supplémentaires. Lorsqu'ils sont combinés avec le coût d'AWS WAF, d'AWS Shield Advanced, d'AWS API Gateway, etc., les clients peuvent faire face à des frais mensuels assez élevés.


Enfin, le niveau de base (« commun ») d'AWS Bot Control s'appuie sur des méthodes simplistes pour identifier le trafic de bot (principalement l'agent utilisateur de la demande, et si l'adresse IP est ou non sur liste noire). Les auteurs de menaces peuvent facilement échapper à la détection basée sur ces critères. Pour obtenir une meilleure détection des bots, les organisations clientes doivent acheter le niveau supérieur ("Targeted Bots"), qui coûte encore plus cher (mais peut encore avoir des difficultés à identifier la dernière génération de bots évasifs).


Répondre à ses limites : en général, l'atténuation des bots hostiles peut être l'aspect le plus difficile du maintien d'une posture de sécurité robuste. Ainsi, des quatre piliers abordés dans cet article, c'est celui où il est le plus important de surmonter les limites inhérentes aux outils natifs d'AWS.


De nombreuses solutions de sécurité Web tierces incluent des capacités de gestion des robots qui dépassent celles d'Amazon Web Services. Ce n'est pas surprenant ; AWS commercialise l'accès aux ressources cloud et fournit des outils de sécurité uniquement pour encourager la consommation de ces ressources. À l'inverse, les fournisseurs de sécurité Web ont pour mission de créer des solutions de sécurité robustes et efficaces.


Lors de l'évaluation des solutions WAAP (protection des applications Web et des API) en termes de gestion des bots, les principales considérations sont celles qui ont déjà été discutées ci-dessus. Le meilleur solutions de gestion de robots permettra aux clients de définir avec précision des politiques de sécurité, de visualiser et de contrôler leur trafic en temps réel avec une visibilité totale, et de tirer parti de technologies puissantes telles que l'apprentissage automatique et l'analyse comportementale.


De plus, de nombreuses organisations auront besoin d'une option de gestion complète, afin de pouvoir configurer et maintenir leurs défenses de cybersécurité par une équipe de professionnels de la sécurité, plutôt que de demander au personnel interne de remplir ce rôle.


Conclusion

Alors qu'un pare-feu d'application Web est un composant essentiel de la sécurité Web, s'appuyer uniquement sur un WAF n'est plus suffisant dans le paysage des menaces d'aujourd'hui. En adoptant les quatre piliers de la sécurité Web (WAF, protection DDoS, sécurité des API et gestion des bots), les utilisateurs d'AWS peuvent établir une défense robuste et multicouche contre un large éventail de menaces.


\Alors qu'AWS fournit des outils de sécurité intégrés, il est essentiel de comprendre leurs limites et de les compléter par des mesures de sécurité externes adaptées à des menaces spécifiques. En adoptant cette approche globale, les organisations peuvent protéger efficacement leurs applications Web et API AWS et atténuer les risques dans l'environnement de menace moderne.