L'Importance Cruciale des Pare-feux et des Security Groups dans les Infrastructures Cloud
Security Groups et Pare-feux : Ma Première Ligne de Défense
Quand je prends en charge une nouvelle infrastructure cloud, la première chose que je vérifie, ce sont les security groups. C'est systématique, et les résultats sont souvent alarmants. Sur les 10 derniers audits AWS que j'ai réalisés, 7 avaient au moins un security group avec une règle 0.0.0.0/0 sur un port qui n'aurait jamais dû être exposé à Internet.
Les Erreurs Classiques Que Je Rencontre
La Base de Données Accessible depuis Internet
Chez un éditeur de logiciels que j'ai audité, la base PostgreSQL RDS avait un security group qui autorisait le port 5432 depuis 0.0.0.0/0. La raison ? Un développeur avait besoin d'y accéder depuis chez lui et avait ouvert le port "temporairement". Six mois plus tard, la règle était toujours là.
Le SSH Ouvert au Monde
Des instances EC2 avec le port 22 ouvert à 0.0.0.0/0, sans clé SSH renforcée, sans fail2ban. Dans les logs, des milliers de tentatives de connexion par jour avec des dictionnaires de mots de passe. C'est une invitation aux attaquants.
Les Security Groups Partagés
Un seul security group pour tous les services : le frontend, le backend, la base de données, le cache Redis. Résultat : chaque service a accès à tout, ce qui viole le principe du moindre privilège et élargit la surface d'attaque.
Mon Approche : Defense in Depth
Ma stratégie de sécurité réseau repose sur plusieurs couches complémentaires.
Couche 1 : VPC et Subnets
L'architecture VPC est le fondement. Je sépare systématiquement les subnets publics (load balancers, NAT gateways) des subnets privés (instances, bases de données). Les bases de données sont toujours dans des subnets privés sans route vers Internet.
Couche 2 : Security Groups
Chaque composant a son propre security group avec des règles minimales. Le security group de la base de données n'autorise que le port PostgreSQL depuis le security group du backend. Le security group du backend n'autorise que le port HTTP depuis le security group du load balancer.
Sur le projet AWS multi-compte que j'ai architecturé avec 25 modules Terraform, chaque module crée ses propres security groups avec des références croisées. Le tout est versionné et auditable.
Couche 3 : NetworkPolicies Kubernetes
Dans Kubernetes, les security groups cloud ne suffisent pas. Par défaut, tous les pods peuvent communiquer entre eux. Les NetworkPolicies ajoutent une couche de contrôle au niveau du cluster.
Chez un client dans la Défense, j'ai mis en place une politique deny-all par défaut sur chaque namespace, puis des règles explicites pour chaque flux autorisé. Chaque communication inter-services est documentée et validée.
Couche 4 : WAF
Pour les applications web, un WAF (Web Application Firewall) ajoute une protection contre les attaques applicatives : SQL injection, XSS, DDoS layer 7. Sur AWS, j'utilise AWS WAF avec des règles managées et des règles custom adaptées au contexte du client.
L'Automatisation : La Clé
Les security groups ne doivent jamais être gérés manuellement dans la console AWS. Tout passe par Terraform. Chaque modification est une pull request, revue par un pair, et tracée dans Git. Chez un de mes clients, un développeur avait ouvert un port manuellement dans la console. Notre pipeline Terraform de drift detection l'a détecté et nous avons pu corriger en quelques minutes.
Les pare-feux et les security groups sont des outils simples en apparence, mais leur configuration correcte est ce qui sépare une infrastructure sécurisée d'une passoire.