Aller au contenu

AWS Mis à jour le 2026-07-04

Recueil de groupes de sécurité EC2 : les règles dont une vraie pile web a besoin

Un recueil pratique de groupes de sécurité EC2 : les règles entrantes et sortantes exactes pour un répartiteur de charge, un étage applicatif et un étage base de données, avec des références de groupes plutôt que des plages IP.

Une pile web de production sur EC2 a besoin d’étonnamment peu de règles de groupes de sécurité : le répartiteur de charge accepte 80/443 depuis Internet, l’étage applicatif accepte son port depuis le groupe de sécurité du répartiteur seulement, et la base de données accepte son port depuis le groupe de l’étage applicatif seulement. Le patron qui fait fonctionner tout ça, c’est de référencer des groupes de sécurité au lieu de plages IP — l’appartenance suit l’instance, alors les règles continuent de fonctionner quand les instances montent en charge, se remplacent ou changent d’IP. Tout ce qui dépasse ce noyau est soit une exception précise et documentée, soit un trou que quelqu’un a oublié de fermer.

Ce qui se passe

Un groupe de sécurité est un pare-feu à états attaché à une interface réseau élastique. À états, ça veut dire que le trafic de retour est permis automatiquement — on n’écrit jamais de règle pour les réponses, seulement pour qui peut initier. Toutes les règles sont des permissions; ce qui n’est pas permis est jeté. Plusieurs groupes sur une instance fusionnent en une seule liste effective de permissions. (Pour savoir où finissent les groupes de sécurité et où commencent les NACL, voir groupes de sécurité vs NACL.)

L’erreur de conception derrière la plupart des comptes en désordre, c’est d’écrire les règles contre des adresses IP. Les IP d’instances changent à chaque remplacement; les règles par CIDR pourrissent en une liste que personne n’ose supprimer. Référencer un ID de groupe (sg-...) comme source signifie « toute interface qui porte ce groupe », ce qui est exactement l’intention : « les serveurs applicatifs, peu importe lesquels aujourd’hui, peuvent atteindre la base de données ».

Voici le recueil de base pour une pile web derrière un ALB :

  • sg-alb — entrant : TCP 443 depuis 0.0.0.0/0 (et TCP 80 depuis 0.0.0.0/0 seulement si vous redirigez vers HTTPS au niveau du listener). Rien d’autre.
  • sg-app — entrant : le port applicatif (disons TCP 8080) avec sg-alb comme source. Si les instances se parlent entre elles (grappe, gossip), ajoutez le port nécessaire avec sg-app lui-même comme source.
  • sg-db — entrant : TCP 5432 (ou 3306) avec sg-app comme source. Rien d’autre, jamais — pas même l’IP du bureau.
  • sg-redis — entrant : TCP 6379 depuis sg-app, si vous roulez ElastiCache ou un hôte de cache.
  • Aucune règle SSH nulle part. L’accès interactif passe par SSM Session Manager, qui n’a besoin d’aucun port entrant. Si vous devez garder le 22, limitez-le au groupe d’un bastion ou au CIDR d’un VPN — jamais 0.0.0.0/0.

Sortant : le tout-permis par défaut est acceptable pour la plupart des étages applicatifs, mais le groupe de la base de données est un bon endroit pour resserrer la sortie, puisqu’une base de données n’a pas d’affaire à initier des connexions vers Internet.

Quoi vérifier en premier

  • Quelque chose d’ouvert à 0.0.0.0/0 à part le 80/443 du répartiteur? Un port 22, 3306, 5432, 6379, 9200 ou 3389 ouvert au monde, c’est le constat qui compte le plus.
  • Des règles avec des sources CIDR à l’intérieur du VPC là où une référence de groupe s’imposerait — signe que le patron n’a jamais été adopté.
  • Des groupes inutilisés et le groupe par défaut en service. Le groupe par défaut du VPC permet tout le trafic depuis lui-même, ce qui aplatit silencieusement vos étages si des instances le portent.
  • Les descriptions de règles. Une règle sans description est une règle que personne n’osera jamais supprimer.
  • Des groupes proches du quota de règles (60 règles entrantes par groupe par défaut, ajustable) — un indice qu’un groupe fait cinq jobs.

Comment vérifier

Trouvez chaque règle ouverte au monde dans le compte :

aws ec2 describe-security-group-rules \
  --filters Name=cidr-ipv4,Values=0.0.0.0/0 \
  --query 'SecurityGroupRules[?IsEgress==`false`].[GroupId,IpProtocol,FromPort,ToPort]' \
  --output table

Exportez l’ensemble complet des règles d’un groupe précis :

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

Trouvez les groupes attachés à rien (candidats à la suppression) :

aws ec2 describe-network-interfaces \
  --query 'NetworkInterfaces[].Groups[].GroupId' --output text | tr '\t' '\n' | sort -u > /tmp/used.txt
aws ec2 describe-security-groups --query 'SecurityGroups[].GroupId' --output text | tr '\t' '\n' | sort -u > /tmp/all.txt
comm -13 /tmp/used.txt /tmp/all.txt

Dans la console, EC2 > Security Groups > (groupe) > Inbound rules montre les sources; VPC > Security > Security groups montre les mêmes données côté VPC. Pour tester la réalité plutôt que l’intention, VPC > Reachability Analyzer confirme si un chemin de l’ALB vers une instance existe vraiment. La documentation EC2 couvre la sémantique des règles au complet.

L’approche

  1. Créez un groupe par rôle, nommé pour le rôle (web-prod-alb, web-prod-app, web-prod-db), pas par instance et pas un méga-groupe pour tout.
  2. Câblez les étages par référence de groupe. Source sg-alb sur le port applicatif, source sg-app sur le port de la base. Supprimez les équivalents par CIDR une fois que le trafic confirme que les références fonctionnent.
  3. Enlevez le SSH d’Internet le jour même. Activez Session Manager, vérifiez qu’une session s’ouvre, puis supprimez la règle du port 22. Ce seul changement enlève la surface d’attaque la plus balayée qu’un parc EC2 possède.
  4. Écrivez une description sur chaque règle — « santé + trafic ALB », « app vers Postgres », avec une référence de billet. Les descriptions sont un champ natif des règles; servez-vous-en.
  5. Sortez le groupe de sécurité par défaut des charges de travail. Gardez-le vide de règles pour qu’un attachement accidentel n’accorde rien.
  6. Resserrez la sortie sur l’étage de données. Les bases et les caches n’ont de sortant que là où le besoin est démontré (dépôts d’OS via un mandataire, ou rien).
  7. Mettez les groupes en IaC pour qu’un changement de règle soit un diff révisé, et que la dérive des modifications en console soit détectable.

Quand c’est le mauvais choix

Le câblage par référence de groupe suppose que tout vit dans le même VPC ou dans des VPC appairés de la même région (les références inter-VPC fonctionnent via l’appairage, pas via Transit Gateway). Si le trafic arrive à travers un NAT ou une appliance pare-feu tierce, le groupe source est invisible et vous revoilà aux CIDR — documentez pourquoi. Et ne poussez pas la micro-segmentation au-delà de l’utile : quinze groupes pour une application à trois étages ajoute de la surface d’audit, pas de la sécurité.

Erreurs fréquentes

  • Ouvrir le port applicatif à 0.0.0.0/0 « temporairement » pour déboguer l’ALB et ne jamais le refermer — la référence de groupe de l’ALB était mal configurée, et le monde entier est devenu le contournement.
  • Permettre le port de la base depuis tout le CIDR du VPC, ce qui inclut en douce les bastions, les exécuteurs CI et tout ce sur quoi un attaquant met le pied.
  • Oublier les règles instance-à-instance pour les applications en grappe, ce qui apparaît comme une découverte de nœuds capricieuse plutôt qu’un blocage évident.
  • Confondre les groupes à états avec les NACL sans états et ajouter aux groupes de sécurité des règles entrantes inutiles sur les ports éphémères.

Prévention

  • Un audit planifié (règles gérées AWS Config comme restricted-ssh, ou un script hebdomadaire) qui signale toute règle ouverte au monde hors du groupe de l’ALB.
  • Une alerte sur les événements CloudTrail AuthorizeSecurityGroupIngress touchant les groupes de production.
  • Un ménage trimestriel des groupes inutilisés — moins de groupes, moins d’endroits où cacher une mauvaise règle.
  • Une convention de nommage imposée en révision d’IaC, pour que la vocation d’un groupe se lise dans son nom.

Une disposition serrée de groupes de sécurité est un des après-midis les plus rentables qu’on puisse investir dans un compte AWS : trois étages, des références de groupes, pas de SSH depuis Internet, des descriptions partout. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.