Générateur de règles de groupe de sécurité AWS

Le Générateur de règles AWS Security Group crée des règles de security group EC2 à partir d'une entrée CSV structurée. Saisissez vos règles sous forme de lignes avec les colonnes direction, protocole, plage de ports, source/destination et description, et obtenez des commandes AWS CLI, des ressources Terraform aws_security_group_rule ou des snippets de template CloudFormation prêts pour des déploiements scriptés et reproductibles.

Comprendre les AWS Security Groups

Si vous exécutez des charges de travail sur AWS, les security groups sont le mécanisme principal de contrôle d'accès réseau pour vos instances EC2, bases de données RDS, fonctions Lambda et la plupart des autres ressources réseau. Contrairement aux firewalls traditionnels qui se placent devant votre réseau, les security groups sont attachés directement aux interfaces réseau et suivent vos instances partout -- si vous arrêtez et redémarrez une instance ou l'attachez à un autre sous-réseau, ses security groups l'accompagnent.

L'élément le plus important à comprendre concernant les AWS security groups est qu'ils sont stateful et fonctionnent en mode autorisation uniquement. Stateful signifie que si vous autorisez le trafic entrant sur le port 443, le trafic de retour de cette connexion est automatiquement autorisé indépendamment des règles sortantes. Le mode autorisation uniquement signifie qu'il n'y a pas d'action "deny" -- vous ne pouvez pas écrire une règle qui bloque explicitement une IP spécifique. Si une adresse IP ne correspond à aucune règle d'autorisation, elle est implicitement refusée. C'est fondamentalement différent d'iptables ou des Azure NSG où vous pouvez écrire des règles deny explicites, et cela signifie que les security groups sont mieux adaptés pour définir ce que vous voulez autoriser plutôt que ce que vous voulez bloquer. Pour les refus explicites, vous avez besoin des Network ACL au niveau du sous-réseau.

Gérer les security groups via la Console AWS fonctionne pour une poignée de règles, mais cela ne tient pas dans les environnements de production. Une application web trois-tiers typique peut avoir des security groups séparés pour le load balancer, les serveurs web, les serveurs d'application et la base de données -- chacun avec cinq à dix règles. Les modifications effectuées via la Console ne sont pas tracées, ne peuvent pas être revues avant le déploiement et sont difficiles à reproduire dans plusieurs environnements. Ce générateur permet un workflow Infrastructure as Code : définissez vos règles dans un tableur, générez des commandes CLI ou du code Terraform, révisez dans une pull request et déployez de manière cohérente sur les environnements de développement, staging et production.

Comment générer des règles AWS Security Group

1. Préparez vos données de règles au format CSV avec les colonnes : direction, protocole, plage de ports, source/destination et description.
2. Collez ou importez le CSV dans le générateur.
3. Sélectionnez le format de sortie : AWS CLI, Terraform HCL ou CloudFormation JSON/YAML.
4. Saisissez l'identifiant du security group cible (par ex. sg-0123456789abcdef0).
5. Copiez les commandes ou blocs de configuration générés pour le déploiement.

Format d'entrée CSV et sortie générée

Entrée CSV

direction,protocol,from_port,to_port,source,description
ingress,tcp,443,443,0.0.0.0/0,HTTPS from internet
ingress,tcp,22,22,10.0.0.0/8,SSH from internal
ingress,tcp,3306,3306,sg-0abcdef1234567890,MySQL from app tier
egress,tcp,443,443,0.0.0.0/0,HTTPS outbound
ingress,-1,-1,-1,sg-0abcdef1234567890,All traffic from app tier

Sortie AWS CLI

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0","Description":"HTTPS from internet"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":22,"ToPort":22,"IpRanges":[{"CidrIp":"10.0.0.0/8","Description":"SSH from internal"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"UserIdGroupPairs":[{"GroupId":"sg-0abcdef1234567890","Description":"MySQL from app tier"}]}]'

Sortie Terraform

resource "aws_security_group_rule" "https_from_internet" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "HTTPS from internet"
}

resource "aws_security_group_rule" "ssh_from_internal" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["10.0.0.0/8"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "SSH from internal"
}

Types de sources AWS Security Group

Quand utiliser le générateur AWS Security Group

• Mise en place de VPC -- générer toutes les règles de security group pour un nouveau déploiement VPC à partir d'un seul document de planification CSV.
• Automatisation de la conformité -- convertir des tableurs de politique de sécurité en commandes AWS CLI ou code Terraform exécutables.
• Cohérence multi-comptes -- générer des jeux de règles de security group identiques pour le déploiement sur les comptes de développement, staging et production.
• Migration depuis l'infrastructure on-premises -- traduire des règles iptables ou de firewall existantes au format AWS Security Group lors de la migration cloud.
• Audit et documentation -- exporter les règles existantes en CSV, les examiner, puis régénérer des configurations propres.

Fonctionnement des AWS Security Groups

Comportement stateful

Les AWS Security Groups sont stateful -- si vous autorisez le trafic entrant sur le port 443, le trafic de retour est automatiquement autorisé indépendamment des règles sortantes. Cela diffère d'iptables ou nftables où vous devez explicitement autoriser le trafic de retour ou utiliser le suivi de connexion.

Limites de règles

Chaque security group supporte jusqu'à 60 règles entrantes et 60 règles sortantes par défaut (ajustable via une demande d'augmentation de quota). Chaque bloc CIDR, référence de security group ou prefix list compte comme une règle. Utilisez l'Allowlist Builder pour minimiser le nombre d'entrées CIDR.

Evaluation

Toutes les règles d'un security group sont évaluées ensemble -- il n'y a pas d'ordre de priorité. Si une règle autorise le trafic, celui-ci est autorisé. Il n'y a pas d'action "deny" dans les security groups ; l'absence de règle allow correspondante constitue un refus implicite. Pour des règles deny explicites, utilisez plutôt les Network ACL.

Références de security groups

L'une des fonctionnalités les plus puissantes des AWS security groups est la possibilité de référencer d'autres security groups comme sources ou destinations. Au lieu de spécifier des blocs CIDR pour vos serveurs d'application, vous référencez l'identifiant du security group du tier applicatif. Cela signifie que lorsque vous ajoutez ou retirez des instances du tier applicatif, le security group de la base de données autorise ou révoque automatiquement l'accès sans aucune modification de règle.

Conseils pratiques pour les AWS Security Groups

L'erreur la plus courante dans la gestion des security groups est d'utiliser 0.0.0.0/0 (tout le trafic) trop libéralement. Dans la précipitation pour faire fonctionner les choses, les ingénieurs ouvrent SSH (port 22) vers 0.0.0.0/0 "temporairement" et oublient de le restreindre ensuite. AWS Security Hub et Config Rules peuvent détecter cela, mais la prévention est préférable à la détection. Utilisez les références de security groups pour la communication inter-tiers, restreignez SSH au security group de votre VPN ou bastion host, et limitez 0.0.0.0/0 aux ports qui ont véritablement besoin d'un accès public (typiquement uniquement les ports 80 et 443 sur les load balancers).

Lorsque vous travaillez avec Terraform, préférez les ressources aws_security_group_rule (que ce générateur produit) aux blocs ingress et egress inline dans une ressource aws_security_group. Les règles inline et les ressources de règles séparées entrent en conflit, et les ressources séparées sont plus faciles à gérer, réviser et appliquer conditionnellement. Elles évitent également le problème du "toutes les règles changent quand une seule change" que causent les blocs inline.

Les descriptions de règles ne sont pas optionnelles -- elles sont la documentation pour votre futur vous. AWS affiche les descriptions dans la Console, et elles apparaissent dans les audits de sécurité et les rapports de conformité. Chaque règle devrait répondre au "pourquoi" de cet accès : "SSH from VPN gateway" est mieux que "SSH" ou aucune description. Le générateur préserve les descriptions de votre CSV dans la sortie, alors prenez le temps d'en écrire des pertinentes.

Questions fréquentes

Que signifie le protocole -1 dans les AWS Security Groups ? Le protocole -1 signifie "tout le trafic" -- il correspond à TCP, UDP, ICMP et tous les autres protocoles IP. Lorsque vous utilisez le protocole -1, définissez également from_port et to_port à -1. C'est ainsi qu'AWS représente une règle "autoriser tout".

Peut-on référencer un security group dans un VPC différent ? Oui, pour les VPC appairés (peered). Utilisez l'identifiant complet du security group et assurez-vous que le VPC peering est configuré. Le générateur produit la référence GroupId ; pour les références inter-comptes, vous avez également besoin de l'identifiant du propriétaire du compte.

Comment gérer les blocs CIDR IPv4 et IPv6 ? Le générateur produit automatiquement des entrées IpRanges séparées (pour IPv4) et Ipv6Ranges (pour IPv6) en fonction du format d'adresse. Une règle pour 0.0.0.0/0 ne couvre que l'IPv4 ; ajoutez une règle séparée pour ::/0 pour couvrir l'IPv6.

Quelle est la différence entre les Security Groups et les Network ACL ? Les Security Groups sont stateful, au niveau de l'instance, et en mode autorisation uniquement. Les Network ACL sont stateless, au niveau du sous-réseau, et supportent les règles deny explicites. La plupart des configurations utilisent les Security Groups comme contrôle principal et les Network ACL pour une défense en profondeur supplémentaire.

Comment rester dans la limite de 60 règles ? Agrégez les blocs CIDR avec l'Allowlist Builder, utilisez les références de security groups au lieu d'IP individuelles pour la communication inter-tiers, et combinez les plages de ports quand c'est possible (par ex. from_port: 8000, to_port: 8080 au lieu de 80 règles individuelles). Vous pouvez également demander une augmentation de quota via la console AWS Service Quotas.

Puis-je générer des règles pour plusieurs security groups à la fois ? Le générateur cible un seul security group par exécution. Pour les configurations multi-groupes, exécutez-le une fois par security group avec les règles appropriées pour chaque tier. Cela correspond aux bonnes pratiques de séparation des préoccupations dans la conception des security groups.

Outils associés

• Azure NSG Rule Generator - Générer des règles Azure NSG à partir d'un CSV
• iptables Rule Generator - Générer des règles iptables à partir d'un CSV
• Allowlist Builder - Construire une allowlist CIDR minimale à partir d'une liste d'IP
• Blocklist Builder - Construire une blocklist CIDR minimale à partir d'une liste d'IP
• Rule Conflict Finder - Trouver les règles de firewall dupliquées, masquées ou en conflit