Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

VPC Security Group

cloud

Définition

Un Security Group AWS est un pare-feu virtuel stateful contrôlant le trafic réseau entrant et sortant d'une ressource AWS (instance EC2, RDS, Lambda dans un VPC, interface réseau). Contrairement aux Network ACLs (stateless), les Security Groups maintiennent un état de connexion : si une connexion entrante est autorisée, les réponses sortantes correspondantes sont automatiquement autorisées, et vice versa. Les Security Groups fonctionnent au niveau de l'interface réseau (ENI - Elastic Network Interface). Chaque ressource dans un VPC est associée à un ou plusieurs Security Groups (jusqu'à 5 par défaut). Les règles d'un Security Group définissent des autorizations (Allow seulement - il n'existe pas de règle Deny explicite dans un Security Group, tout trafic non autorisé est implicitement bloqué). Une règle de Security Group spécifie : le protocole (TCP, UDP, ICMP, ou All), le port ou la plage de ports, et la source/destination (CIDR IPv4/IPv6, un autre Security Group ID, ou un Prefix List). L'utilisation du Security Group ID d'un autre SG comme source est une fonctionnalité puissante permettant de définir des relations de confiance entre ressources sans dépendre d'adresses IP (dynamiques dans un environnement auto-scaling). Les erreurs de configuration de Security Groups sont parmi les plus fréquentes dans les environnements AWS. Les Security Groups ouverts à 0.0.0.0/0 sur des ports sensibles (22/SSH, 3389/RDP, 1433/SQL Server, 3306/MySQL) exposent directement les ressources à Internet. AWS Config, Security Hub et les outils CSPM détectent ces configurations dangereuses. Les bonnes pratiques incluent : principe du moindre privilège (n'autoriser que les flux strictement nécessaires), utiliser des Security Group IDs plutôt que des CIDRs pour les communications inter-services, supprimer les règles sortantes (outbound) permissives par défaut pour les ressources sensibles, et auditer régulièrement les Security Groups inutilisés ou redondants.

Règles d'entrée et de sortie

Définissez des règles restrictives dans les deux sens. Les règles d'entrée (inbound) contrôlent ce qui peut initier des connexions vers la ressource. Les règles de sortie (outbound) contrôlent où la ressource peut se connecter. Par défaut AWS autorise tout le trafic sortant : restreignez les règles outbound pour les instances sensibles (bases de données, serveurs contenant des données critiques) pour limiter l'exfiltration en cas de compromission.

Segmentation par couches

Implémentez une architecture multi-tier avec des Security Groups par couche : SG-Web (n'accepte que HTTP/HTTPS depuis Internet ou un ALB), SG-App (n'accepte que le trafic depuis SG-Web sur le port applicatif), SG-DB (n'accepte que le trafic depuis SG-App sur le port de la base de données). Cette segmentation contient les mouvements latéraux : une compromission de la couche web ne permet pas d'accès direct à la base de données.

Audit des Security Groups

Utilisez AWS Config (règle restricted-ssh, restricted-common-ports) et Security Hub pour détecter les Security Groups ouverts. L'outil Prowler scanne tous les Security Groups et liste ceux avec des règles trop permissives. Pour les Security Groups inutilisés, AWS Config dispose de la règle ec2-security-group-attached-to-eni-periodic qui détecte les SG non attachés à des ressources actives.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis