AWS Firewall Manager, WAF et Network Firewall : qui gère quelle règle

AWS Firewall Manager gère des politiques, il n'inspecte aucun trafic. Aucun paquet ne le traverse, aucune requête HTTP n'est bloquée par lui : c'est le plan de contrôle qui crée, audite et répare les web ACL AWS WAF, les pare-feux Network Firewall, les security groups et les abonnements Shield Advanced dans tous les comptes d'une organisation AWS. Les trois services situés en dessous font le blocage réel, chacun à un endroit différent du chemin réseau, et l'essentiel de la confusion vient de le lire comme un quatrième pare-feu.

Firewall Manager est-il un pare-feu ?

Non, et son nom est la première cause du malentendu. AWS Firewall Manager vit entièrement hors du chemin de données. Vous décrivez une intention, une fois, sous forme de politique : tout load balancer exposé à Internet porte le core rule set d'AWS, tout VPC de ces unités d'organisation route vers un endpoint Network Firewall, aucun security group n'autorise le port 22 depuis n'importe où. Firewall Manager retrouve ensuite les ressources concernées dans tous les comptes et aligne la réalité sur la politique.

Les ressources qu'il produit sont parfaitement ordinaires. Une web ACL créée par une politique Firewall Manager est une web ACL AWS WAF normale, facturée et journalisée comme les autres, et elle continue de filtrer si la politique disparaît. C'est le bon modèle mental : Firewall Manager répond à « est-ce que chaque endpoint public de chaque compte porte le socle », question qu'aucun pare-feu ne peut poser sur lui-même, tandis que les pare-feux répondent à « cette requête précise passe-t-elle ».

Où s'attache AWS WAF, et que bloque-t-il ?

AWS WAF est le filtre de couche 7. Il s'attache aux distributions CloudFront, aux Application Load Balancers, aux stages API Gateway et aux API AppSync, et il lit la requête HTTP : méthode, chemin, en-têtes, query string, corps. C'est ainsi qu'il arrête injection SQL, cross-site scripting, credential stuffing et débits abusifs, invisibles depuis la couche 4 où une requête vers le port 443 n'est qu'une requête vers le port 443.

Ce qu'il ne voit jamais compte tout autant. Pas de TCP brut, aucun protocole non HTTP, et surtout aucun trafic sortant : il n'inspecte que ce qui arrive sur les endpoints auxquels vous l'avez attaché. La forme du coût, un montant mensuel par web ACL et par règle plus une facturation par million de requêtes, explique pourquoi éparpiller de petites web ACL compte par compte coûte plus en frais fixes qu'une conception mutualisée. Nous avons détaillé ces frontières de blocage dans notre article WAF, Network Firewall et security groups.

Que voit Network Firewall que WAF ne verra jamais ?

AWS Network Firewall vit à l'intérieur du VPC. Vous déployez des endpoints de pare-feu, un par zone de disponibilité à couvrir, et vos tables de routage y dirigent le trafic pour qu'il traverse physiquement l'appliance. Il filtre aux couches 3 et 4 avec des groupes de règles stateful, et les signatures compatibles Suricata lui permettent de reconnaître des noms de domaine et le SNI TLS : c'est ce qui en fait le seul service de la liste capable d'empêcher une instance compromise d'appeler le domaine d'un attaquant sur le port 443.

C'est aussi le plus facile à déployer pour rien. Une stack serverless dont rien ne traverse un subnet que vous contrôlez ne lui donne rien à inspecter, et un petit VPC isolé justifie rarement la facturation horaire par endpoint plus le tarif au gigaoctet inspecté, dus même sans trafic. Le montage qui se rentabilise est un VPC d'inspection mutualisé entre plusieurs workloads, soit la même discussion de routage que NAT gateway contre VPC endpoints : la sortie réseau est l'endroit où les factures VPC se fabriquent en silence.

Que faut-il avant que Firewall Manager puisse imposer quoi que ce soit ?

Trois prérequis, aucun optionnel. Les comptes doivent appartenir à une organisation AWS avec toutes les fonctionnalités activées. Un compte administrateur délégué doit être désigné pour Firewall Manager, afin que le compte de gestion ne soit pas celui qui opère la sécurité au quotidien. Et AWS Config doit tourner dans chaque compte et chaque région couverts, car c'est par Config que Firewall Manager découvre les ressources et évalue la conformité.

Une politique n'a de sens qu'à partir de là. Elle se soumet via l'API fms, et le contenu des règles voyage sous forme de chaîne JSON imbriquée dans le corps JSON, détail qui fait échouer la plupart des premières tentatives d'automatisation.

{
  "PolicyName": "socle-waf-org",
  "ResourceType": "ResourceTypeList",
  "ResourceTypeList": [
    "AWS::ElasticLoadBalancingV2::LoadBalancer",
    "AWS::CloudFront::Distribution"
  ],
  "RemediationEnabled": false,
  "IncludeMap": { "ORGUNIT": ["ou-ab12-11111111", "ou-ab12-22222222"] },
  "ResourceTags": [{ "Key": "exposition", "Value": "public" }],
  "ExcludeResourceTags": false,
  "SecurityServicePolicyData": {
    "Type": "WAFV2",
    "ManagedServiceData": "{\"type\":\"WAFV2\",\"defaultAction\":{\"type\":\"ALLOW\"},\"preProcessRuleGroups\":[{\"ruleGroupType\":\"ManagedRuleGroup\",\"overrideAction\":{\"type\":\"COUNT\"},\"managedRuleGroupIdentifier\":{\"vendorName\":\"AWS\",\"managedRuleGroupName\":\"AWSManagedRulesCommonRuleSet\"}}],\"postProcessRuleGroups\":[]}"
  }
}

Trois champs méritent l'attention. IncludeMap restreint la portée à des unités d'organisation plutôt qu'à tous les comptes, les ResourceTags affinent encore la sélection des ressources, et RemediationEnabled à false laisse la politique en simple rapport. Le ManagedServiceData, lui, est un document JSON sérialisé en chaîne : construisez-le avec un sérialiseur, jamais à la main.

Quels types de politiques, et que signifie la remédiation ?

Firewall Manager propose un catalogue fermé de types de politiques : AWS WAF, Shield Advanced, Network Firewall, DNS Firewall de Route 53 Resolver, politiques de security groups en trois variantes (une politique commune qui pousse un groupe partagé, un audit de contenu qui signale ou retire les règles interdites, un audit d'usage qui supprime les groupes inutilisés), politiques de network ACL, et pare-feux d'éditeurs tiers. Vous n'écrivez pas de logique libre : vous choisissez un type et vous le configurez.

La remédiation est l'interrupteur qui transforme un rapport en contrôle. Désactivée, la politique évalue son périmètre et liste les ressources non conformes : utile, inoffensif, et la seule manière raisonnable de commencer. Activée, Firewall Manager crée la web ACL manquante, l'associe au load balancer qu'une équipe produit a lancé une heure plus tôt, et sur les politiques d'audit de security groups il supprime les règles fautives. Lancez chaque nouvelle politique en mode rapport, lisez ce qu'elle aurait modifié, puis activez la remédiation.

Firewall Manager, WAF, Network Firewall et security groups : le comparatif

Quatre services, un tableau. Lisez la première ligne avant tout le reste : c'est elle qui tranche le débat, puisque trois de ces services inspectent le trafic et le quatrième gouverne les trois autres.

Un compte AWS unique a-t-il besoin de Firewall Manager ?

Presque jamais. Avec un compte et une équipe, la web ACL est déjà dans votre code d'infrastructure, les security groups sont relus dans la même pull request que les ressources qu'ils protègent, et votre pipeline joue déjà le rôle de gestionnaire de politiques. Ajouter Firewall Manager, c'est ajouter une organisation dont vous n'aviez pas besoin, un compte administrateur délégué, AWS Config partout, et un second plan de contrôle capable de modifier en silence des ressources que vos templates croient posséder.

Le tableau s'inverse dès que les comptes se multiplient et que vous cessez de tous les contrôler. Quand des équipes produit créent leurs propres load balancers, quand une usine à comptes en distribue de nouveaux chaque mois, ou quand un auditeur veut la preuve que chaque endpoint public porte le même groupe de règles managé, aucune discipline de templates ne démontre la couverture. C'est là que Firewall Manager se paie, et le tarif mensuel par politique et par ressource de la page de tarification Firewall Manager paraît alors modeste face à l'alternative. Ce compromis, et les choix qui l'entourent, font l'objet de notre guide des décisions AWS.

Check-list de décision

• Un compte, une équipe : faites l'impasse sur Firewall Manager, gardez WAF et security groups dans votre code d'infrastructure.
• Une organisation dont vous ne contrôlez pas tous les comptes : Firewall Manager, avec administrateur délégué.
• Vérifiez qu'AWS Config tourne dans chaque compte et chaque région concernés avant d'écrire la moindre politique.
• Démarrez chaque politique remédiation désactivée, lisez le rapport de non-conformité, puis activez-la.
• Endpoint HTTP public : AWS WAF. Contrôle du sortant par domaine : Network Firewall. Aucun ne remplace l'autre.
• Les security groups restent stricts dans tous les cas : ils sont gratuits et c'est la seule couche présente sur chaque interface.