Un Security Group (SG) est un pare-feu virtuel stateful, attaché à une ressource (au niveau de son ENI) — instance EC2, RDS, Lambda en VPC, etc. C’est la première ligne de défense au niveau instance.
Caractéristiques
| Propriété | Valeur |
|---|---|
| Niveau d’application | La ressource (via son ENI), pas le subnet |
| État | Stateful — si le paquet entre, la réponse sort automatiquement, pas besoin de règle explicite pour le retour |
| Type de règles | Allow uniquement — impossible d’écrire un Deny explicite |
| Évaluation | Toutes les règles sont évaluées, la plus permissive l’emporte (pas de notion de priorité/ordre) |
| Référencement | Une règle peut cibler une IP/CIDR ou un autre Security Group — utile pour autoriser tout le trafic entre deux groupes de ressources sans connaître leurs IP |
Bonnes pratiques
- Toujours restreindre au strict nécessaire (principe du moindre privilège) — un SG trop ouvert (
0.0.0.0/0sur tous les ports) est l’une des causes de compromission les plus fréquentes. - Référencer un Security Group plutôt qu’une IP quand la cible est elle-même dans AWS (ex. autoriser le SG de l’ALB plutôt qu’une plage d’IP).
- Un SG par rôle applicatif (ex.
sg-web,sg-db) plutôt qu’un SG générique partagé par toute l’infrastructure.
En relation avec
- Réseau AWS — comparaison complète Security Group vs NACL
- Network ACL (NACL) — la seconde ligne de défense, au niveau subnet
- ENI (Elastic Network Interface) — c’est sur l’ENI qu’un Security Group est réellement attaché
- Firewall Rules — équivalent GCP (système à une seule couche)