Gouvernance d'AWS WAF à grande échelle

Les grandes entreprises, dont plusieurs équipes développent et exploitent leurs propres applications Web ou API, utilisent des outils et des processus visant à garantir la cohérence des contrôles de sécurité entre les équipes, afin d'éviter d'exposer les points de terminaison dont les protections sont faibles ou inexistantes. AWS Firewall Manager est un outil que les entreprises peuvent utiliser pour gérer les déploiements AWS WAF et Shield Advanced à grande échelle.

Firewall Manager vous permet de définir des politiques AWS WAF ou Shield Advanced qui sont déployées automatiquement sur vos ressources exposées au public, telles que les distributions CloudFront, les ALB ou les passerelles d'API. Une politique se compose des éléments suivants :

• Un champ d'application définissant où il s'applique : à quel type de ressources (CloudFront, ALB, etc.)? inclure ou exclure des ressources avec des balises spécifiques ? quels comptes ou unités organisationnelles inclure ou exclure ?
• Règles définissant les groupes de règles WAF à appliquer, s'il faut activer la journalisation de manière centralisée et s'il faut ajouter des protections Shield Advanced.
• Une Action définissant ce qu'il convient de faire lorsqu'une ressource est trouvée dans le champ d'application d'une politique. Par exemple, vous pouvez appliquer automatiquement les règles de politique ou simplement les signaler. Lors d'un déploiement initial de Firewall Manager, il est recommandé de démarrer sans correction automatique, afin d'identifier les ressources nécessitant une gestion manuelle avec un impact minimal sur les applications existantes. Lorsqu'un niveau de confiance plus élevé est atteint, vous pouvez faire passer Firewall Manager en mode correction automatique.

Pour utiliser Firewall Manager, considérez d'abord ses prérequis. Notez qu'AWS Config est l'un des prérequis de Firewall Manager. Pour optimiser le coût d'AWS Config, s'il est uniquement activé pour utiliser Firewall Manager, limitez les types de ressources à enregistrer aux ressources pertinentes pour votre scénario (par exemple, WAF, CloudFront Distribution, équilibreur de charges, etc.). Notez également que les politiques sont des constructions régionales (par exemple, vous avez besoin d'une politique globale pour CloudFront et d'une politique régionale dans chaque région où vous disposez de ressources régionales telles que des ALB et des passerelles d'API). Envisagez cette solution AWS pour faciliter le déploiement des politiques de Firewall Manager au sein des AWS Organizations.

Lorsque vous créez une politique WAF, Firewall Manager déploie une WebACL WAF avec les règles WAF de la politique dans les comptes AWS compris dans le champ d'application de la politique. Dans une politique WAF, vous pouvez définir deux types de groupes de règles qui sont ajoutés à la WebACL déployée par Firewall Manager :

• Un premier groupe de règles, qui sera évalué avant toute autre règle.
• Un dernier groupe de règles, qui sera évalué à la fin.

Cela vous permet de donner à une équipe de sécurité centrale la possibilité de gérer des groupes de règles communes dans l'ensemble de votre organisation, tout en donnant à vos équipes d'application la possibilité d'ajouter des règles personnalisées pertinentes pour leur application, entre le premier et le dernier groupe de règles communes. Étant donné que les règles d'AWS WAF sont évaluées par ordre, le premier groupe de règles communes est évalué avant toute autre règle, suivi des règles créées par les équipes d'application et enfin du dernier groupe de règles communes.

Vous pouvez créer un pipeline CI/CD pour mettre à jour les groupes de règles WAF courants dans la politique AWS WAF sur le compte administratif AWS, qui est ensuite déployé par Firewall Manager dans votre organisation en quelques minutes. Découvrez dans ce blog comment OLX a déployé une politique WAF centrale à l'aide d'un pipeline CI/CD, avec un système de journalisation centralisé.

Firewall Manager est un outil flexible qui vous permet d'établir différentes stratégies de gouvernance de la sécurité en fonction des exigences de votre organisation. Dans toute gouvernance de sécurité centralisée, vous devez trouver un compromis entre la mesure dans laquelle vous appliquez les règles de manière centralisée pour augmenter les niveaux de protection et la mesure dans laquelle vous souhaitez gérer les faux positifs causés par des règles communes déployées de manière centralisée.

Si vos équipes d'application sont hautement autonomes et que vous souhaitez éviter de gérer les faux positifs, créez une politique WAF centralisée unique qui répond aux menaces critiques. Par exemple, vous pouvez créer des règles WAF basées sur des limites de débit assorties de seuils élevés, associées à des listes d'adresses IP malveillantes hautement fiables et à des règles de blocage géographique pour les pays sous embargo. Vous pouvez également activer Shield Advanced et activer l'atténuation DDoS automatique des attaques au niveau de la couche applicative. Ces règles ont tendance à générer très peu de faux positifs, mais elles sont efficaces pour protéger contre les inondations HTTP. En outre, lorsque des vulnérabilités Zero Day critiques et à fort impact sont découvertes, vous pouvez appliquer des mesures d'atténuation de manière centralisée à l'aide du groupe de règles communes WAF déployé.

Il est recommandé de créer un wiki interne pour vos équipes d'application, avec des conseils sur les bonnes pratiques pour ajouter des règles WAF personnalisées dans leur WebACL, en fonction de leur application. Par exemple, aidez-les à ajouter des protections contre les attaques SQLi et XSS si leur application est vulnérable à de telles attaques.

Si vous souhaitez étendre votre couverture de sécurité centrale à un plus large éventail de menaces, renforcez vos groupes de règles communes centraux, mais donnez aux équipes chargées des applications la possibilité de gérer les faux positifs de manière autonome. Pour implémenter ce modèle de gouvernance WAF, placez vos règles communes dans le premier groupe de règles de la politique WAF en mode comptage. Ces règles n'émettront que des étiquettes, que vous pourrez utiliser dans le dernier groupe de règles de la politique WAF pour bloquer les demandes correspondant à ces étiquettes.

Si vos équipes d'application rencontrent des faux positifs, elles peuvent créer des règles d'exclusion à l'aide des étiquettes émises par vos règles. Pour illustrer cela à l'aide d'un exemple, imaginons le scénario dans lequel les règles Amazon Managed Rules (AMR) pour la protection contre SQLi sont ajoutées en mode comptage au premier groupe de règles. Dans le dernier groupe de règles, une règle bloque les demandes portant l'étiquette label_matched=”SQLi_BODY” émises par l'AMR susmentionné. Si l'AMR introduit un faux positif dans une application sur une URL spécifique (url=”/form1”), l'équipe de l'application peut créer une règle d'exclusion dans la WebACL qui atténue ce faux positif (par ex. SI url=”/form1” ET label_matched=”SQLi_BODY” alors AUTORISER). L'action d'autorisation de la règle est terminée, ce qui signifie qu'AWS WAF cessera d'évaluer les règles de blocage suivantes.

Pour apporter des modifications à cette politique sans affecter les applications existantes, envisagez de créer une réplique de cette politique qui sera utilisée dans des environnements de test par les équipes d'application. Les deux politiques doivent avoir des champs d'application qui s'excluent mutuellement. Par exemple, la politique de production s'applique à toutes les distributions CloudFront, à l'exception de celles dotées d'une balise intermédiaire, et la politique de production s'applique à toutes les distributions CloudFront dotées de la balise intermédiaire. Pour la plupart des mises à jour, vous pouvez d'abord les intégrer à la politique de préparation, puis en informer toutes les équipes d'application à l'aide d'une rubrique SNS. Une fois informées d'un changement, les équipes d'application testent la nouvelle version de la politique dans leur environnement de test, qui peut être automatisé, et gèrent les faux positifs si nécessaire. Ensuite, après un délai convenu, l'équipe centrale diffuse la modification de la politique de production. Les mises à jour critiques qui ne peuvent pas être appliquées en une semaine, telles que les protections contre Log4j CVE, peuvent être appliquées immédiatement au détriment de certains faux positifs temporaires, jusqu'à ce que les équipes d'application gèrent les exceptions.

Si vous souhaitez appliquer une base de sécurité cohérente tout en permettant une certaine personnalisation par les administrateurs de compte. Cet article décrit les étapes à suivre pour concevoir et mettre en œuvre une politique de base de sécurité gérée de manière centralisée. Il détaille également les meilleures pratiques pour tester et déployer la politique.

Si vous avez les mêmes exigences qu'auparavant, mais que vous souhaitez réduire la charge cognitive liée au renforcement de la sécurité des applications pour les équipes chargées des applications, envisagez de créer un catalogue de politiques pour les différents types d'applications présents dans votre organisation. Par exemple, vous pouvez avoir un catalogue avec deux politiques :

• Première politique : recommandée pour protéger les applications basées sur Wordpress
• Deuxième politique : recommandée pour protéger les applications PHP avec une base de données SQL. Vous pouvez créer deux versions de cette politique, avec des niveaux de sensibilité de blocage différents. Les équipes d'application peuvent ainsi choisir celle qui répond à leurs exigences de sécurité (niveau de paranoïa) et à leur volonté de gérer les faux positifs.
  
  

Le champ d'application de chaque politique est définie par une balise spécifique (par exemple wordpress pour la première politique et LAMP_HIGH/LAMP_LOW pour la deuxième politique). Les équipes d'application consultent le catalogue des politiques disponibles et appliquent la balise de la politique souhaitée à leurs ressources. Firewall Manager associe automatiquement les WebACL WAF à leurs ressources.

Notez qu'avec cette approche, vous pouvez gérer les faux positifs et échelonner les modifications de la même manière que celle décrite dans la section précédente.

Au niveau de votre application, vous pouvez utiliser des signaux personnalisés pour identifier les comportements anormaux, en fonction des attentes de votre application. Par exemple, vous pouvez vous attendre à ce que les utilisateurs naviguent dans votre application dans un certain ordre, ou vous ne vous attendez probablement pas à ce qu'un utilisateur commande certains produits depuis/vers certains pays en fonction de son adresse enregistrée. En utilisant de tels signaux, vous pouvez automatiser votre réponse à l'aide d'AWS WAF, par exemple en bloquant ou en contestant les demandes CAPTCHA provenant d'adresses IP présentant un comportement suspect au niveau de l'application. Pour commencer à utiliser le concept d'automatisation du WAF basé sur les signaux des applications, consultez les exemples de cette solution AWS.

Les automatisations avancées incluent :

• La consommation d'événements à haut risque émis par Cognito lors du processus de connexion/d'inscription.
• La consommation d'événements à haut risque identifiés par Fraud Detector. Amazon Fraud Detector utilise le machine learning (ML) et met à contribution 20 ans d'expertise en détection de fraude d'Amazon Web Services (AWS) et d'Amazon.com pour identifier automatiquement les pratiques cybernétiques douteuses réalisés par des humains ou des bots en temps réel. Fraud Detector permet de détecter les fraudes en analysant le comportement des utilisateurs au niveau de l'application, en utilisant vos propres données historiques de fraude pour entraîner, tester et déployer des modèles de machine learning personnalisés pour la détection des fraudes adaptés à votre cas d'utilisation.

Si vous préférez déléguer complètement la gestion du WAF des équipes d'application à votre équipe de sécurité centrale, créez une politique dédiée pour chaque équipe d'application, avec un champ d'application qui ne s'applique qu'à leurs comptes AWS. Dans ce scénario, vous devez créer des processus pour la configuration initiale et des canaux de communication entre les équipes chargées des applications et votre équipe de sécurité centrale pour des opérations telles que la gestion des faux positifs.

• Livre blanc : Exemples de gouvernance tirés du livre blanc sur les Directives pour l'implémentation d'AWS WAF
• Présentation d'AWS re:Inforce 2024 : comment Twilio gère les politiques AWS WAF à grande échelle
• Trouver des partenaires de livraison AWS WAF
• Blog : Modèles opérationnels pour la gouvernance de la sécurité des applications Web dans AWS