Security Groups OUTSCALE : pare-feu virtuel stateful

Les Security Groups sont le pare-feu virtuel d’OUTSCALE — la première ligne de défense réseau attachée à chaque ressource (VM, NIC, load balancer). 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

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.

Comportement par défaut

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 :

É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`

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.

Pourquoi privilégier SG-to-SG

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.

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	(rien — la base n’initie pas de connexion)	—

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`

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

# 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

# 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

# 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"

Bonnes pratiques (par pilier Security)

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

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

Security Groups sous l’angle Well-Architected

Security — défense en profondeur

Les Security Groups sont la première ligne 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.

Prochaines étapes

Réseau — IGW, NAT, EIP, bastion Connecter le Net à Internet et organiser les accès humains via bastion.

Réseau — design Net + Subnets Architecture multi-AZ et tiers public / privé / data, prérequis aux Security Groups.

EIM identité et accès EIM pour qui peut piloter les SG ; SG pour ce qui peut traverser le réseau.

Outils CLI OUTSCALE oapi-cli pour scripter la création de SG et leurs règles.