En novembre 2020, AWS a annoncé le lancement d'AWS Network Firewall. Cette multiplication des pare-feu finit par semer la confusion : j'ai donc rédigé cet article pour y mettre de l'ordre.
Nous commencerons par comparer les pare-feu AWS et les systèmes de défense réseau similaires, en détaillant les cas d'usage de chacun, les attaques contre lesquelles ils protègent et les règles qu'ils utilisent pour détecter les menaces.
Nous illustrerons ensuite tout cela par un récit qui montre les cas d'usage que vous rencontrerez à mesure que votre application monte en charge et gagne en importance économique.
Quand utiliser chaque service de pare-feu AWS
Nous partons du bas, depuis l'infrastructure de plus bas niveau, et nous remontons : c'est en général ainsi que vous devriez bâtir vos défenses.
Security Groups
Les Security Groups protègent les Elastic Network Interfaces, généralement rattachées à des instances EC2, mais aussi à d'autres services comme RDS ou Lambda dans un VPC. Ils peuvent par exemple bloquer les connexions SSH non autorisées. Ils filtrent les accès en fonction des ports source et destination ainsi que des plages d'IP. Définissez des Security Groups, en n'autorisant que les accès strictement nécessaires, dès la création de vos instances.
Network ACLs
Les Network ACL protègent les sous-réseaux, par exemple contre des connexions non autorisées à une base de données depuis n'importe où via le serveur backend. Comme les Security Groups, elles filtrent les accès selon les ports source et destination et les plages d'IP. Définissez des NACL lorsque vous segmentez vos systèmes en sous-réseaux par fonction, ce qu'il convient de faire dès la définition de vos tiers. Avec les NACL, les sous-systèmes peuvent accéder aux autres selon leur rôle dans l'architecture, dès lors que les sous-réseaux ont été définis en conséquence.
Kubernetes Network Policies
Les Kubernetes Network Policies protègent les applications déployées sur Elastic Kubernetes Service. Comme les Security Groups et les NACL, elles filtrent les accès selon les ports source et destination et les plages d'IP. Mais elles peuvent aussi exploiter les labels Kubernetes, ce qui permet un contrôle d'accès fonctionnel à granularité fine. Définissez ces Network Policies dès que vous créez un ensemble de services Kubernetes, sauf dans les cas les plus simples.
Network Firewalls
Les Network Firewalls protègent l'ensemble des réseaux d'une organisation, par exemple contre des bots de type cheval de Troie qui exfiltrent des données. Ils filtrent les accès en s'appuyant sur des jeux de règles standard téléchargeables. Comme pour les Security Groups et les NACL, ces jeux de règles incluent des signatures définies par les ports source et destination et les plages d'IP. Mais ils peuvent aussi recourir à l'inspection profonde de paquets, et donc bloquer en fonction des domaines, des URL et des protocoles (à condition que TLS soit terminé avant le Network Firewall). Ajoutez des Network Firewalls lorsque vous avez besoin de politiques cohérentes de détection et de prévention d'intrusion à l'échelle de toute l'organisation.
AWS Shield Standard
AWS Shield Standard protège les applications web et les API contre les attaques DDoS. Il filtre selon les schémas de trafic HTTP(S), notamment la fréquence et la source des appels. Activez AWS Shield Standard sur toute application web publique présentant un enjeu métier. (C'est gratuit, et activé par défaut sur certaines ressources.)
AWS Shield Advanced
AWS Shield Advanced offre les mêmes fonctions que la version Standard, avec en plus une supervision renforcée, le remboursement des coûts liés aux attaques et, surtout, une équipe d'experts humains. Il vaut la peine d'envisager AWS Shield Advanced pour toute application web critique pour l'activité, en mettant en balance le coût d'Advanced par rapport à Standard.
Web Application Firewall
Web Application Firewall (WAF) protège les applications web contre le Cross-Site Scripting, l'injection SQL, les Insecure Direct Object References et d'autres vulnérabilités de la liste OWASP. Il détecte et bloque les accès en s'appuyant sur des signatures définies par des motifs présents dans les en-têtes ou le corps d'une requête HTTP(S). Envisagez WAF pour vous protéger pendant que vous corrigez des vulnérabilités applicatives connues, ou si vous utilisez des applications vulnérables dont le code vous échappe, ou encore si vous estimez que votre code présente peu de vulnérabilités mais que vous souhaitez une protection supplémentaire par sécurité.
Des instances avec Security Groups, des sous-réseaux avec NACL, une organisation multi-réseaux avec Network Firewall. AWS Shield contre les DDoS et WAF protègent les points d'entrée.
Petite histoire des pare-feu
Pour illustrer comment on adopte différents pare-feu à mesure qu'une application grandit, voici un récit construit autour de cas d'usage.
Pat se lance dans le développement d'une application web pour sa startup. Un brin old-school, elle décide de déployer une seule instance EC2 pour un simple proof of concept. Elle met en place un Security Group qui sert de pare-feu au niveau de l'instance, en autorisant l'accès uniquement sur les ports 80 et 443 — pour les requêtes HTTP/S — et sur le port 22 pour la plage d'IP de son bureau, afin de pouvoir administrer la machine en SSH. Son instance est ainsi protégée contre les accès des attaquants sur des ports autres que 80 ou 443 et tout accès SSH depuis des adresses IP non autorisées est bloqué.
Son proof of concept est déjà sécurisé, à ce stade précoce, contre de nombreux types d'attaques. Mais à mesure qu'elle complexifiera le réseau et l'application, et que celle-ci gagnera en importance financière, elle aura besoin de défenses supplémentaires.
Pour aller au-delà du simple proof of concept et bâtir une application n-tier robuste, elle met en place une base de données et sépare les serveurs frontend et backend. Chaque tier reçoit son propre sous-réseau. Elle configure des Network Access Control Lists (NACL) comme pare-feu d'entrée de sous-réseau, en autorisant les requêtes HTTP/S à atteindre le sous-réseau frontend, le frontend à accéder au backend, le backend à accéder à la base de données — et rien d'autre.
La scalabilité a ses limites ; et même si l'application tient le coup sous la charge, une attaque DDoS ferait exploser la facture. Elle ajoute donc AWS Shield Standard, qui est gratuit. Cela suffit pour une protection DDoS correcte. Bien plus tard, quand l'application aura considérablement grandi et sera devenue une source de revenus majeure, le coût d'AWS Shield Advanced pourra se justifier. La version Advanced offre surtout l'accès à une équipe d'opérations qualifiée d'AWS — un rappel utile pour la sécurité en général : la menace, ce sont des esprits brillants qui inventent en permanence de nouvelles façons de vous attaquer ; il vous faut donc, en face, des esprits brillants qui trouvent en permanence la bonne manière de vous défendre.
Pat porte ensuite l'application sur Elastic Kubernetes Service pour faciliter l'orchestration et la gestion. Ici, la Kubernetes Network Policy définit les restrictions sur les services Kubernetes autorisés à en contacter d'autres, et permet un contrôle d'accès fonctionnel à granularité plus fine que ce qu'on pouvait obtenir avec des sous-réseaux.
Les tests d'intrusion menés sur l'application révèlent diverses vulnérabilités issues de la liste OWASP, dont des Insecure Direct Object References, du Cross-Site Scripting et des injections SQL. Pat et son équipe de développement ajoutent alors AWS Web Application Firewall, tout en priorisant les correctifs nécessaires et l'effort de sécurité à long terme au sein de l'équipe.
Enfin, le grand jour arrive : Exit ! La startup est rachetée par un grand groupe. L'application devient alors un élément d'un portefeuille applicatif plus vaste, et le réseau s'intègre à une infrastructure complexe, avec plusieurs VPC et des réseaux on-premises gérés par différentes entités de l'organisation. Pour assurer la protection de l'ensemble, le groupe a défini des politiques réseau cohérentes à l'échelle de l'organisation. AWS Network Firewall est ajouté pour restreindre les accès au moyen de jeux de règles défensifs standard définis par ports, adresses IP, domaines, URL et protocoles. Cela protège non seulement contre les mêmes attaques que les Security Groups et les Network ACL, mais détecte et prévient aussi les intrusions par bots de type cheval de Troie ou par pirates humains qui exécutent du code dans le réseau pour corrompre ou exfiltrer des données.
Les grandes organisations exigent une approche centralisée pour gérer leurs ressources et leurs politiques — un système ne vaut que par son maillon le plus faible. AWS Firewall Manager est mis en place pour piloter Network Firewalls, WAF et autres systèmes, et maintenir une protection cohérente à l'échelle de l'organisation.
J'espère que cela aura permis d'y voir plus clair parmi les nombreux pare-feu d'AWS. Si vous avez des questions, n'hésitez pas à les poser en commentaires.
— —
Merci à mon collègue, le Dr Artem Shchodro, pour ses précieux commentaires.