Security Groups OUTSCALE : pare-feu virtuel stateful

Les Security Groups sont le pare-feu virtuel d'OUTSCALE : le filtrage s'applique au niveau de chaque ressource qui les porte (VM, NIC, load balancer), donc avant que le trafic n'atteigne le système invité. Ils sont stateful, ce qui simplifie radicalement les règles à écrire par rapport aux ACL classiques : autoriser un flux entrant suffit, le retour est automatiquement permis. Cette page pose les concepts fondamentaux, les patterns courants, et les antipatterns à éviter, avec des exemples oapi-cli validés sur la spec OpenAPI officielle. Page tagguée pour le pilier Security du Well-Architected Framework.

Ce que vous allez apprendre

• Le mécanisme stateful des Security Groups et pourquoi il change la donne par rapport aux pare-feu classiques.
• Distinguer les règles inbound et outbound, et savoir quand chacune s'applique.
• Appliquer le pattern SG-to-SG (référencer un autre SG comme source ou destination) plutôt que de manipuler des CIDR.
• Créer un Security Group et y ajouter des règles via oapi-cli.
• Repérer les antipatterns classiques : 0.0.0.0/0 sur SSH, SG par défaut laissé permissif, règles trop larges.

Prérequis

• Avoir lu Réseau, design Net + Subnets, un Security Group s'attache à des ressources qui vivent dans un Net.
• Connaître le vocabulaire OUTSCALE ↔ AWS (SG ≈ Security Group AWS).
• Notions de filtrage réseau : ports, protocoles (TCP/UDP/ICMP), notation CIDR.
• oapi-cli configuré (cf. Outils CLI).

Security Group en deux phrases

Un Security Group est un ensemble de règles de filtrage que vous attachez à une ou plusieurs ressources (VM, NIC, load balancer). Il définit quel trafic réseau est autorisé à entrer (Inbound) ou à sortir (Outbound) de chaque ressource qui le porte.

À la différence d'un pare-feu classique, un Security Group OUTSCALE est stateful : si vous autorisez une connexion entrante TCP sur le port 443, le trafic de retour de cette connexion est automatiquement autorisé sans avoir à écrire une règle outbound symétrique.

Le mécanisme stateful, ce que ça change

Sur un pare-feu stateless (par exemple, des Network ACL traditionnelles), il faut écrire deux règles pour chaque flux :

• une règle entrante qui autorise le paquet d'arrivée ;
• une règle sortante qui autorise le paquet de retour, sur le même port et la même IP.

Sur un Security Group stateful, une seule règle suffit. Le SG mémorise les connexions actives (tracking de session) et autorise automatiquement les paquets de retour. Cela simplifie radicalement la configuration et réduit les erreurs typiques des pare-feu stateless (oubli d'une règle de retour).

Conséquence pratique : vous écrivez vos règles en pensant « qui peut entrer » (inbound) et « qui peut sortir » (outbound) au sens initiation de connexion : pas au sens « chaque paquet ».

Inbound vs Outbound, quand chacun s'applique

Le champ Flow d'une règle ne prend que deux valeurs, Inbound ou Outbound, et il détermine dans quel sens la connexion est initiée. Sur un pare-feu stateful, ce sens est le seul critère qui compte : le trafic de retour n'a jamais besoin de sa propre règle. La confusion classique consiste à créer une règle outbound pour « laisser revenir » la réponse d'une requête entrante, ce qui n'apporte rien.

Règles Inbound

Les règles inbound filtrent les connexions entrantes vers les ressources qui portent le SG. Exemples typiques :

• Autoriser HTTP (port 80) ou HTTPS (port 443) depuis Internet (0.0.0.0/0) sur un load balancer public.
• Autoriser SSH (port 22) depuis l'IP du bureau ou d'un VPN d'entreprise, jamais 0.0.0.0/0.
• Autoriser PostgreSQL (port 5432) depuis le SG du backend, vers le SG de la base de données.

Par défaut, aucune connexion entrante n'est autorisée, vous devez explicitement déclarer chaque flux nécessaire.

Règles Outbound

Les règles outbound filtrent les connexions sortantes initiées par les ressources qui portent le SG. Exemples typiques :

• Autoriser le trafic HTTPS (port 443) vers Internet pour récupérer des paquets de mises à jour ou appeler des APIs externes.
• Restreindre la sortie d'une base de données (tier data) à uniquement le tier backend : la base ne doit pas appeler Internet directement.
• Bloquer l'outbound vers Internet sur les ressources sensibles, en autorisant uniquement les flux vers des SG internes connus.

Outbound, uniquement dans un Net

Les règles Outbound ne sont supportées que pour les Security Groups dans un Net. C'est une raison structurelle de toujours mettre les ressources dans un Net (et pas dans un environnement « hors Net »), ce qui est de toute façon le seul mode actif sur OUTSCALE en 2026.

Comportement par défaut

Un Security Group fraîchement créé n'est pas neutre : il applique déjà une politique, et elle n'est pas la même dans les deux sens. C'est un point à vérifier avant d'attacher le SG à une ressource, sous peine de croire à un filtrage sortant qui n'existe pas. Quand vous créez un Security Group dans un Net :

• Inbound : aucune règle par défaut → tout est bloqué en entrée.
• Outbound : généralement une règle par défaut autorise tout le trafic sortant. À examiner et à durcir selon le besoin.

Anatomie d'une règle

Une règle de Security Group se compose de quatre éléments, et il n'existe pas de champ « action » : toute règle présente est une autorisation. Il n'y a donc rien à écrire pour interdire un flux, il suffit de ne pas l'autoriser, ce qui explique qu'un SG ne contienne jamais de règle de refus. Les quatre éléments à renseigner :

Élément	Valeurs possibles	Exemple
Flow	Inbound ou Outbound	Inbound
IpProtocol	tcp, udp, icmp, ou -1 (tous protocoles)	tcp
FromPortRange / ToPortRange	Plage de ports (entiers)	443 / 443 (port unique HTTPS)
Source / destination	IpRange (CIDR) ou SecurityGroupNameToLink (référence à un autre SG)	203.0.113.42/32 ou sg-backend

Glissez pour voir

Le couple source / destination est important : vous pouvez autoriser un flux soit depuis une plage IP soit depuis un autre SG. Le pattern SG-to-SG est généralement préférable pour les flux internes.

Le pattern SG-to-SG

Pour les flux entre tiers d'une même architecture (par exemple, backend → database), référencer un autre SG comme source plutôt que de manipuler des CIDR offre plusieurs avantages. La règle ne désigne alors plus des adresses, mais une appartenance : toute ressource portant le SG source est autorisée, quelle que soit son adresse IP du moment.

Pourquoi privilégier SG-to-SG

Trois bénéfices se cumulent, et ils se renforcent avec la durée de vie de l'infrastructure : plus les VM sont remplacées, redimensionnées ou déplacées, plus l'écart se creuse avec une politique écrite en CIDR.

Avantage	Détail
Robuste aux changements d'IP	Quand le backend ajoute une nouvelle VM ou que sa plage CIDR évolue, le SG-to-SG continue de fonctionner sans modification.
Lisible	« Le SG database autorise PostgreSQL depuis le SG backend » se lit naturellement.
Auditable	Un audit de sécurité peut tracer les flux par référence de SG, sans avoir à reconstituer les CIDR à la main.

Glissez pour voir

Exemple concret

Supposons trois Security Groups :

• sg-frontend, attaché aux frontaux web.
• sg-backend, attaché aux serveurs applicatifs.
• sg-database, attaché aux bases de données.

Les flux à autoriser :

SG cible	Flow	Protocole / Port	Source / Destination
sg-frontend	Inbound	TCP/443	0.0.0.0/0 (Internet)
sg-backend	Inbound	TCP/8080	sg-frontend (SG-to-SG)
sg-database	Inbound	TCP/5432	sg-backend (SG-to-SG)
sg-backend	Outbound	TCP/5432	sg-database (SG-to-SG)
sg-database	Outbound	aucune	la base n'initie aucune connexion sortante

Glissez pour voir

Cette structure rend le flux des données explicite : le frontend peut être atteint depuis Internet uniquement en HTTPS, le backend ne reçoit que du frontend, la base ne reçoit que du backend, et la base ne peut pas initier de connexion sortante. Une compromission du frontend reste contenue au tier backend, et la base reste protégée.

Créer un Security Group via oapi-cli

La création se fait en deux temps : CreateSecurityGroup crée le conteneur vide, CreateSecurityGroupRule y ajoute les règles une par une. Un SG sans aucune règle inbound est parfaitement valide et bloque tout le trafic entrant, il n'y a donc pas d'état intermédiaire dangereux entre les deux appels. Les exemples ci-dessous reprennent le sg-backend de l'architecture à trois tiers.

Créer le Security Group dans un Net

CreateSecurityGroup exige SecurityGroupName et Description. Pour créer le SG dans un Net (mode standard), passer aussi NetId.

oapi-cli CreateSecurityGroup \
  --SecurityGroupName "sg-backend" \
  --Description "Backend application servers - tier privé" \
  --NetId "vpc-12345678"
# La réponse contient le SecurityGroupId (par exemple "sg-87654321")

Tagger ensuite le SG via CreateTags, comme pour les autres ressources OUTSCALE.

Ajouter une règle Inbound depuis un CIDR

Pour un port unique, FromPortRange et ToPortRange portent la même valeur. Le masque /32 restreint l'autorisation à une seule adresse.

# Autoriser SSH (port 22) depuis l'IP du bureau uniquement
oapi-cli CreateSecurityGroupRule \
  --SecurityGroupId "sg-87654321" \
  --Flow "Inbound" \
  --IpProtocol "tcp" \
  --FromPortRange 22 \
  --ToPortRange 22 \
  --IpRange "203.0.113.42/32"

Ajouter une règle Inbound depuis un autre Security Group

SecurityGroupNameToLink remplace IpRange : les deux paramètres désignent la source et ne se combinent pas dans une même règle.

# Autoriser le port applicatif 8080 depuis sg-frontend vers sg-backend
oapi-cli CreateSecurityGroupRule \
  --SecurityGroupId "sg-87654321" \
  --Flow "Inbound" \
  --IpProtocol "tcp" \
  --FromPortRange 8080 \
  --ToPortRange 8080 \
  --SecurityGroupNameToLink "sg-frontend"

Ajouter une règle Outbound restrictive

Seul le champ Flow change par rapport à une règle entrante ; SecurityGroupNameToLink désigne cette fois la destination autorisée.

# Autoriser uniquement les sorties vers PostgreSQL sur sg-database
oapi-cli CreateSecurityGroupRule \
  --SecurityGroupId "sg-87654321" \
  --Flow "Outbound" \
  --IpProtocol "tcp" \
  --FromPortRange 5432 \
  --ToPortRange 5432 \
  --SecurityGroupNameToLink "sg-database"

Aller en Terraform pour les SG productifs

La séquence CLI ci-dessus est utile pour explorer et comprendre la mécanique. Pour des SG en production avec plusieurs dizaines de règles, Terraform rend le code lisible (on voit l'ensemble des règles d'un SG dans un seul bloc), versionné et reproductible. Sujet du Volet 3, Industrialiser (IaC).

Bonnes pratiques (par pilier Security)

Les sept points suivants sont ceux qui ressortent systématiquement d'une revue de configuration réseau. Ils ne coûtent rien à appliquer dès la conception, et beaucoup à rattraper une fois l'infrastructure en place, car chaque règle trop large finit par être invoquée par un service qui en dépend sans le savoir. Traitez-les comme une grille de relecture avant toute mise en production.

1. Toujours Allow explicite, jamais Allow *

Aucune règle qui autorise tous les ports ou tous les protocoles vers 0.0.0.0/0. Chaque règle identifie un flux précis (port, protocole, source). Cette discipline est ce qui transforme un SG en outil de défense réelle plutôt qu'en simple décoration.

2. SSH (port 22) jamais ouvert sur 0.0.0.0/0

C'est l'antipattern le plus dangereux. SSH ouvert au monde entier expose à des attaques par force brute en continu. Limiter à :

• L'IP fixe du bureau si elle est stable.
• L'IP du VPN d'entreprise.
• Le SG du bastion si l'accès SSH passe par un bastion (pattern recommandé, détaillé dans la page IGW, NAT, EIP, bastion).

3. SG-to-SG pour les flux internes

Préférer SecurityGroupNameToLink à des CIDR pour les flux entre tiers (frontend → backend → database). Cela rend les règles robustes aux changements d'adressage et auditables par lecture directe.

4. Restreindre l'outbound, surtout sur les ressources sensibles

Le filtrage outbound est souvent négligé, mais il limite drastiquement les conséquences d'une compromission. Une base de données qui n'a pas le droit d'initier de connexion sortante ne peut pas exfiltrer des données vers un attaquant externe.

5. Un SG par rôle, pas un SG par VM

Créer un SG par rôle organisationnel (sg-frontend, sg-backend, sg-database) et attacher le SG à toutes les ressources qui jouent ce rôle. Pas un SG par VM individuelle, la duplication rend l'audit impossible.

6. Documenter le but de chaque SG dans Description

Le champ Description est obligatoire à la création. L'utiliser pour expliquer clairement le rôle du SG : « Backend application servers - tier privé - autorise 8080 depuis sg-frontend » est mille fois plus utile que « backend » seul.

7. Auditer régulièrement

Lister les SG et leurs règles régulièrement (par exemple chaque trimestre) pour repérer les règles obsolètes (port d'un service qui n'existe plus, IP d'un ancien VPN). Un SG est un objet vivant qui s'encrasse si personne ne nettoie.

Antipatterns à éviter

Ces six configurations sont fonctionnelles : elles laissent passer le trafic, les applications marchent, rien n'alerte. C'est précisément ce qui les rend durables, elles survivent à toutes les revues tant que personne ne se demande ce qui se passerait en cas de compromission. Chaque ligne du tableau associe la mauvaise habitude à son coût réel et à la pratique qui la remplace.

Antipattern	Conséquence	Discipline correcte
0.0.0.0/0 sur SSH	Attaques brute force permanentes, compromission probable	IP du bureau, du VPN, ou du SG bastion
Un seul SG « par défaut » tout ouvert	Aucune protection effective	Un SG par rôle, règles ciblées
Règles avec IpProtocol: -1 (tous protocoles)	Surface d'attaque maximale	Spécifier le protocole précis (tcp/udp/icmp)
CIDR pour les flux internes	Cassé dès que l'adressage change	SG-to-SG via SecurityGroupNameToLink
Outbound complètement ouvert	Exfiltration possible en cas de compromission	Restreindre aux flux nécessaires (DB → backend uniquement)
Pas de Description	Impossible d'auditer le rôle d'un SG	Description claire et à jour

Glissez pour voir

Security Groups sous l'angle Well-Architected

Les Security Groups alimentent deux piliers du Well-Architected Framework, et pas seulement celui auquel on pense. Le pilier Security est le plus évident : ils matérialisent le moindre privilège au niveau réseau. Le pilier Operational Excellence l'est moins, mais un SG lisible est un SG qu'une équipe d'astreinte peut auditer sous pression sans se tromper.

Security, défense en profondeur

Les Security Groups filtrent au plus près des ressources, à l'entrée et à la sortie de chaque interface réseau : c'est le niveau le plus fin de la défense en profondeur réseau. Combinés à la séparation par tiers (Subnets public / privé / data, voir page Réseau, design Net + Subnets), ils matérialisent dans le filtrage les frontières logiques de l'architecture.

Les questions clés du pilier Security adressées par les SG :

• Qui peut atteindre quelle ressource, sur quels ports ?, règles inbound explicites.
• Quelles ressources peuvent appeler l'extérieur ?, règles outbound restrictives.
• Que se passe-t-il si une ressource du tier public est compromise ?, le SG du tier privé refuse les connexions venant de partout sauf du SG public, le SG du tier data refuse tout sauf le SG privé.

Operational Excellence, lisibilité et audit

Les SG bien nommés (par rôle), avec une Description claire et un usage systématique du SG-to-SG, donnent une lisibilité naturelle des flux autorisés. Un audit peut être conduit en lisant simplement les règles, sans avoir à corréler des CIDR avec leur signification.

L'industrialisation IaC (Terraform) renforce cette lisibilité, un fichier .tf montre toutes les règles d'un SG d'un seul coup d'œil.

À retenir

• Un Security Group est un pare-feu virtuel stateful attaché à des ressources OUTSCALE, une seule règle suffit pour autoriser un flux dans les deux sens.
• Les règles Inbound filtrent les connexions entrantes ; les règles Outbound filtrent les connexions sortantes (uniquement disponibles dans un Net).
• Une règle est définie par Flow + IpProtocol + FromPortRange/ToPortRange + source/destination (CIDR ou autre SG).
• Le pattern SG-to-SG (SecurityGroupNameToLink) est préférable pour les flux internes, robuste aux changements d'adressage, lisible, auditable.
• Antipattern numéro 1 : SSH ouvert sur 0.0.0.0/0, toujours restreindre à une IP fixe, un VPN ou un SG bastion.
• Un SG par rôle, pas un SG par VM. Description claire sur chaque SG.
• Restreindre l'outbound sur les ressources sensibles (bases de données, secrets) limite l'impact d'une compromission.

Pour aller plus loin

• Calcul, instances TINA et sizing : Les VM auxquelles ces groupes de sécurité s'attachent, et le dimensionnement qui va avec.
• Référence Terraform sur OUTSCALE : Versionner les règles de filtrage au lieu de les ajouter à la main, avec revue avant application.
• Pilier Security : Le pattern de référence croisée entre groupes replacé dans une posture de sécurité complète.

Ressources externes

• About Security Groups, Documentation OUTSCALE
• Creating a Security Group
• Adding or Removing Rules from a Security Group
• Référence des erreurs API OUTSCALE

×

📖 Voir la documentation →