Filtrer le trafic Scaleway : groupes de sécurité, NACL et pare-feu système

Chez Scaleway, trois mécanismes différents filtrent trois flux différents, et c'est la première chose à mettre au clair. Un groupe de sécurité ne protège que le trafic public d'une Instance. Une Network ACL ne filtre qu'entre Private Networks d'un même VPC. À l'intérieur d'un Private Network, rien ne filtre, sauf le pare-feu du système. Cette leçon situe chaque mécanisme avec ses plafonds, vous fait poser une NACL réelle en IPv4 et en IPv6, vous montre les quatre pièges du CLI qui font perdre une soirée, et vous fait provoquer la panne qu'une règle de retour oubliée produit, pour que vous sachiez la reconnaître.

Ce que vous allez apprendre

• Situer chaque mécanisme de filtrage sur le flux qu'il traite réellement.
• Créer un groupe de sécurité et comprendre son caractère stateful ou stateless.
• Poser une Network ACL avec une politique par défaut restrictive.
• Écrire la règle de retour qu'un filtrage stateless exige.
• Diagnostiquer un blocage causé par la NACL plutôt que par l'application.

Qui filtre quoi, exactement ?

Le tableau ci-dessous est la carte à mémoriser. La plupart des blocages inexpliqués viennent d'une confusion entre ces lignes : on cherche la cause dans un mécanisme qui, par construction, ne voit même pas le flux en question.

Le flux	Choix du filtre	Ce qui ne le voit pas
Internet vers une Instance, et retour	groupe de sécurité	la NACL, qui ignore le trafic public
Entre deux Private Networks d'un même VPC	Network ACL	le groupe de sécurité, qui ne voit que le public
Entre deux ressources du même Private Network	rien, sauf le pare-feu du système	groupe de sécurité et NACL, tous les deux
Vers un autre VPC ou vers l'extérieur du VPC	routage, peering, Public Gateway	ce sont des chemins, pas des filtres

Glissez pour voir

La troisième ligne est celle qui surprend. Deux Instances attachées au même Private Network se parlent librement, sur tous les ports, et aucun réglage Scaleway n'y change rien. Si vous voulez restreindre ce trafic, c'est nftables, ufw ou l'équivalent sur la machine qui s'en charge. Le corollaire est une règle de conception : placez dans des Private Networks distincts ce que vous voulez pouvoir séparer, sinon vous n'aurez jamais de point de contrôle.

Que filtre un groupe de sécurité ?

Un groupe de sécurité est un pare-feu attaché à des Instances, et il ne s'occupe que du trafic public. Il vit dans une zone de disponibilité précise : seules les Instances de la même zone peuvent y être rattachées, ce qui signifie qu'une architecture sur deux zones demande deux groupes équivalents.

Créez-en un, vous n'aurez besoin d'aucune Instance pour cela :

scw instance security-group create name=lab-front zone=fr-par-1

Regardez maintenant ce que Scaleway a réellement posé comme réglages par défaut, car c'est là que se joue la suite :

scw instance security-group list zone=fr-par-1 -o json \
  | python3 -c 'import sys,json; [print(g["name"], "| stateful:", g["stateful"], "| entrant:", g["inbound_default_policy"]) for g in json.load(sys.stdin)]'

La sortie doit afficher votre groupe avec stateful: True et une politique entrante accept. Ces deux valeurs par défaut méritent d'être changées avant toute mise en service : une politique entrante en accept laisse tout entrer, et c'est le contraire de ce qu'on veut sur une machine exposée. Côté quotas, une Organisation peut tenir 99 999 groupes mais seulement 500 règles : c'est le nombre de règles, pas de groupes, qu'il faut tenir à l'œil.

Stateful ou stateless : la question qui décide de vos règles

Un groupe stateful suit les connexions : si la demande sort, la réponse revient, sans règle supplémentaire. Un groupe stateless évalue chaque paquet isolément, et il vous faut alors écrire la règle de retour à la main.

	Stateful	Stateless
Suivi de connexion	oui	non
Trafic de retour	autorisé automatiquement	à autoriser explicitement
Nombre de règles	moitié moins	le double
Comportement en cas d'oubli	ça marche	ça marche « dans un sens seulement »

Glissez pour voir

Vérifiez ce réglage, ne le supposez pas

La documentation Scaleway indique que le groupe créé automatiquement dans une zone où vous démarrez votre première Instance est stateless, alors qu'un groupe que vous créez vous-même est stateful. Sur un compte existant, la mesure peut donner autre chose : le groupe par défaut y était stateful lors de la rédaction de cette page. Les groupes de sécurité des serveurs Elastic Metal, eux, ne peuvent pas être stateful.

La leçon n'est pas de retenir une valeur, c'est de regarder la vôtre :

scw instance security-group list zone=fr-par-1 -o json \
  | python3 -c 'import sys,json; [print(g["name"], g["stateful"]) for g in json.load(sys.stdin)]'

Un symptôme trahit un groupe stateless mal réglé : la machine sort bien, mais aucune réponse ne revient. Une mise à jour de paquets qui reste bloquée sans message est le cas typique.

Dernier réglage à connaître : les ports SMTP sortants 25, 465 et 587 sont bloqués par défaut, chez Scaleway comme chez la plupart des fournisseurs, pour éviter que des machines compromises servent à envoyer du courrier indésirable. Si votre application doit envoyer des messages, ce n'est donc pas un défaut de configuration de votre côté.

Le déblocage passe par deux conditions que la documentation officielle pose clairement. D'abord, votre compte doit avoir terminé la vérification d'identité (la page des quotas le dit en une ligne : « SMTP allowed : validate your identity »). Ensuite, la case se coche en console uniquement : côté API et CLI, l'argument correspondant, enable-default-security, est documenté comme en lecture seule, et le rendre modifiable demande l'ouverture d'un ticket au support. Un script qui prétendrait débloquer SMTP tout seul se heurtera donc à un mur.

Que filtre une Network ACL ?

Chaque VPC possède une Network ACL, et elle est vide au départ. Vide signifie que rien ne filtre : le routage géré fait circuler le trafic entre tous vos Private Networks sans restriction. C'est confortable pour démarrer et insuffisant dès que deux environnements cohabitent.

Les Network ACL sont disponibles en version stable depuis le 3 juin 2026, et administrables depuis la console comme depuis l'API et le CLI. Si vous avez lu ailleurs qu'elles étaient réservées à l'API, l'information a vieilli : au 8 septembre 2026, quatre pages de la documentation officielle (concepts, FAQ, référence des NACL, référence du routage) portent encore la mention « Public Beta, API only », que le changelog du 3 juin et le how-to console du 19 mai 2026 démentent. L'écart a été signalé au dépôt de documentation.

1. Créez un VPC et deux Private Networks aux plages distinctes

   VPC_ID=$(scw vpc vpc create name=lab-filtrage region=fr-par -o json \
     | python3 -c 'import sys,json; print(json.load(sys.stdin)["id"])')
   
   scw vpc private-network create name=pn-app vpc-id=$VPC_ID \
     subnets.0=172.16.8.0/22 region=fr-par
   scw vpc private-network create name=pn-data vpc-id=$VPC_ID \
     subnets.0=172.16.20.0/22 region=fr-par

2. Regardez l'état initial de la liste

   scw vpc rule get vpc-id=$VPC_ID is-ipv6=false region=fr-par

   La sortie doit afficher une liste de règles vide et une politique par défaut à accept. Autrement dit : tout passe.

3. Posez une règle et une politique par défaut restrictive

   L'objectif : que l'étage applicatif joigne PostgreSQL sur l'étage de données, et rien d'autre.

   scw vpc rule set vpc-id=$VPC_ID region=fr-par is-ipv6=false default-policy=drop \
     rules.0.protocol=TCP \
     rules.0.source=172.16.8.0/22 rules.0.src-port-low=0 rules.0.src-port-high=65535 \
     rules.0.destination=172.16.20.0/22 rules.0.dst-port-low=5432 rules.0.dst-port-high=5432 \
     rules.0.action=accept rules.0.description="app vers postgres" \
     rules.1.protocol=TCP \
     rules.1.source=172.16.20.0/22 rules.1.src-port-low=5432 rules.1.src-port-high=5432 \
     rules.1.destination=172.16.8.0/22 rules.1.dst-port-low=0 rules.1.dst-port-high=65535 \
     rules.1.action=accept rules.1.description="retour postgres vers app"

4. Relisez pour vérifier ce qui a été enregistré

   scw vpc rule get vpc-id=$VPC_ID is-ipv6=false region=fr-par

   Vous devez retrouver deux règles et default_policy: drop. Si vous n'en voyez qu'une, relisez la commande précédente : c'est le piège de la section suivante.

Pourquoi deux règles pour un seul besoin ? Parce que les Network ACL sont stateless : elles n'ont aucune mémoire des connexions en cours. La première règle laisse partir la requête vers le port 5432 ; sans la seconde, la réponse de PostgreSQL est évaluée comme un paquet neuf, ne correspond à aucune règle, et tombe dans la politique par défaut drop. Votre application attend alors une réponse qui ne viendra jamais, et le symptôme est une expiration, pas un refus.

Notez la construction de la règle de retour : la source y est le port 5432, la destination est ouverte sur tous les ports. C'est l'inverse exact de l'aller, et c'est ce que « stateless » veut dire concrètement.

Ouvrir toute la plage de destination est le réglage le plus permissif possible, et il fait le travail. Pour resserrer, l'exemple officiel Scaleway limite le retour aux ports éphémères, 32768-65535, ceux que le client utilise pour recevoir sa réponse. Remplacez rules.1.dst-port-low=0 par rules.1.dst-port-low=32768 et vous fermez tout le bas de la plage sans rien casser. En console, une case « Create inverse rule » crée la règle de retour d'un clic ; en CLI, on l'écrit.

Les quatre pièges du CLI

Ces quatre comportements ont tous été rencontrés en lab avec scw 2.56.3. Aucun n'est documenté à l'endroit où on le cherche, et le dernier peut coûter une configuration entière.

`rule set` remplace la liste, il n'y ajoute rien

C'est le piège le plus coûteux, et son nom l'annonce sans que personne ne le lise ainsi. scw vpc rule set écrase l'intégralité de la liste par ce que vous lui passez, parce que l'API sous-jacente s'appelle SetACL et remplace, par conception.

Mesuré en lab : deux règles posées, puis une seule commande set avec une seule règle, et il ne reste qu'une règle. La seconde n'a pas été conservée, elle a été supprimée sans avertissement ni confirmation.

La conséquence pratique est sérieuse : ajouter une règle à une NACL existante impose de repasser toutes les règles déjà en place dans la même commande. Une NACL de production se gère donc depuis un fichier ou depuis du code d'infrastructure, jamais à la main en ligne de commande. Avant toute modification, prenez une copie :

scw vpc rule get vpc-id=$VPC_ID is-ipv6=false region=fr-par -o json > nacl-avant.json

Les trois autres coûtent moins cher, mais font perdre du temps :

• is-ipv6 est obligatoire sur get. Sans lui, la commande échoue sur missing required argument 'is-ipv6'. L'aide l'annonce d'ailleurs : dans scw vpc rule get -h, les arguments sans crochets sont requis, seul [region=fr-par] en porte. Conséquence à retenir : il n'existe pas de lecture « des deux listes à la fois ».
• Les quatre champs de port sont obligatoires sur chaque règle. Même quand seul le port de destination vous intéresse, il faut fournir src-port-low et src-port-high. Le refus vient du CLI lui-même, qui valide avant d'appeler l'API : la requête ne part même pas. Utilisez 0 et 65535 pour dire « n'importe quel port source ».
• La forme du JSON change d'une commande à l'autre. security-group create renvoie un objet enveloppé dans une clé security_group, alors que get et list renvoient l'objet à plat. Un script qui parcourt les deux doit traiter les deux formes, sinon il tombe sur un KeyError déroutant. Reproduit le 2026-09-08 avec les versions 2.56.3 et 2.62.0, et signalé au dépôt de la CLI.

Le point aveugle IPv6

Chaque VPC possède en réalité deux Network ACL indépendantes : une pour IPv4, une pour IPv6. Elles ne communiquent pas, et régler l'une ne touche jamais l'autre.

Vérifiez-le sur votre VPC, juste après avoir posé vos règles IPv4 :

scw vpc rule get vpc-id=$VPC_ID is-ipv6=true region=fr-par

La liste IPv6 est restée vide, avec une politique par défaut à accept. Vous venez donc de verrouiller IPv4 tout en laissant IPv6 entièrement ouvert entre vos Private Networks. Comme les Private Networks Scaleway reçoivent un préfixe IPv6 en plus de leur plage IPv4, ce n'est pas un cas théorique.

Toute règle IPv4 doit avoir son équivalent IPv6, et cela vaut aussi pour la politique par défaut. Posez au minimum la politique :

scw vpc rule set vpc-id=$VPC_ID region=fr-par is-ipv6=true default-policy=drop \
  rules.0.protocol=ANY rules.0.source=::/0 rules.0.src-port-low=0 rules.0.src-port-high=65535 \
  rules.0.destination=::/0 rules.0.dst-port-low=0 rules.0.dst-port-high=65535 \
  rules.0.action=drop rules.0.description="tout bloquer en IPv6 en attendant les regles"
scw vpc rule get vpc-id=$VPC_ID is-ipv6=true region=fr-par

La seconde commande doit afficher default_policy: drop et votre règle. C'est fastidieux, c'est voulu, et c'est exactement le genre d'oubli qu'un audit relève.

Que ne peut pas filtrer une Network ACL ?

Certains flux échappent volontairement aux Network ACL, parce que les bloquer casserait le fonctionnement de la plateforme. Les connaître évite de chercher pendant une heure pourquoi une règle « ne s'applique pas ».

Sont hors de portée : le DNS Scaleway, le DHCP, les métadonnées d'Instance, les points de terminaison de métadonnées des tâches Kapsule, et l'activation de licence Windows sur Elastic Metal et Instances.

Côté volume, les quotas sont larges : 255 règles IPv4 et 255 règles IPv6 par VPC. Si vous les approchez, le problème n'est pas le quota, c'est le découpage réseau, qu'il vaut mieux revoir.

Provoquer la panne, pour apprendre à la lire

Un filtrage se comprend beaucoup mieux quand on l'a cassé volontairement. L'exercice prend deux minutes et vous apprend le symptôme, qui est la seule chose utile le jour où l'incident n'est pas prévu.

1. Cassez la règle de retour

   Reposez la NACL avec la règle d'aller seulement, en gardant la politique par défaut à drop :

   scw vpc rule set vpc-id=$VPC_ID region=fr-par is-ipv6=false default-policy=drop \
     rules.0.protocol=TCP \
     rules.0.source=172.16.8.0/22 rules.0.src-port-low=0 rules.0.src-port-high=65535 \
     rules.0.destination=172.16.20.0/22 rules.0.dst-port-low=5432 rules.0.dst-port-high=5432 \
     rules.0.action=accept rules.0.description="aller seul"

2. Prédisez le symptôme avant de le constater

   Une connexion de l'étage applicatif vers PostgreSQL va-t-elle échouer immédiatement, ou attendre ? Écrivez votre réponse avant de lire la suivante.

3. Le symptôme est une expiration, pas un refus

   Le paquet d'aller passe, PostgreSQL répond, et la réponse est jetée silencieusement. Le client attend jusqu'à son délai d'expiration. C'est ce qui rend ce défaut si difficile à diagnostiquer : un refus dit « quelque chose bloque », une expiration laisse croire à une lenteur ou à une panne du service distant.

4. Retenez la méthode de diagnostic

   Devant une expiration entre deux Private Networks, la NACL est le premier suspect, et la question à se poser n'est jamais « ai-je autorisé ce flux » mais « ai-je autorisé le retour de ce flux ».

Nettoyer

Les VPC, Private Networks, Network ACL et groupes de sécurité ne coûtent rien, mais on ne laisse pas traîner un lab. On supprime les Private Networks avant le VPC, sans quoi la suppression du VPC est refusée.

scw vpc private-network delete private-network-id=VOTRE_PN_APP region=fr-par
scw vpc private-network delete private-network-id=VOTRE_PN_DATA region=fr-par
scw vpc vpc delete vpc-id=$VPC_ID region=fr-par
scw instance security-group delete VOTRE_SG_ID zone=fr-par-1

Vérifiez le retour à zéro, c'est le seul contrôle qui vaut :

scw vpc vpc list region=fr-par
scw instance security-group list zone=fr-par-1

Le groupe nommé Default security group est généré automatiquement par Scaleway dans chaque zone où vous créez une Instance : laissez-le en place. Le CLI refuse de toute façon de supprimer un groupe encore rattaché à une ressource, avec le message group is in use. you cannot delete it..

Limites, quotas et plafonds

Ces valeurs viennent de la page des Network ACL, des concepts Instances, de la page des quotas d'Organisation (validée le 2025-10-29) et du lab du 2026-09-08.

Plafond	Valeur	Source
Règles de Network ACL	255 IPv4 et 255 IPv6 par VPC	doc Network ACL
Listes par VPC	2, IPv4 et IPv6, indépendantes	doc Network ACL, lab
Groupes de sécurité par Organisation	99 999	quotas d'Organisation
Règles de groupes de sécurité	500	quotas d'Organisation
Portée d'un groupe de sécurité	une zone ; ne filtre que le trafic public	concepts Instances
Stateful	groupe créé par vous : stateful par défaut (mesuré) ; Elastic Metal : jamais stateful	lab, concepts Instances
Ports SMTP sortants	25, 465, 587 bloqués tant que l'identité n'est pas vérifiée ; déblocage en console uniquement	quotas, doc groupes de sécurité
Flux hors de portée des NACL	DNS, DHCP, métadonnées, Kapsule, licences Windows	doc Network ACL
Champs obligatoires par règle CLI	protocole, source, 4 ports, destination, action ; is-ipv6 et default-policy	aide de scw vpc rule set
Coût	0 € pour les trois mécanismes	FAQ VPC, grille

Glissez pour voir

Antipatterns à éviter

Ces erreurs ne produisent aucun message : le trafic passe alors qu'il ne devrait pas, ou expire alors qu'il devrait passer.

Antipattern	Conséquence	Discipline
Laisser la politique entrante d'un groupe à accept	tout entre sur la machine exposée	inbound-default-policy=drop et des règles explicites
Poser la NACL IPv4 et oublier l'IPv6	verrou d'un côté, porte ouverte de l'autre	chaque règle et chaque politique en deux exemplaires
Ajouter une règle par rule set à la main	la liste précédente disparaît	copie JSON avant, puis liste complète, ou code d'infrastructure
Chercher à filtrer deux machines du même Private Network par NACL	impossible par construction	réseaux distincts, ou pare-feu système
Écrire une règle d'aller sans règle de retour	expiration silencieuse	règle inverse systématique, source et destination permutées
Débloquer SMTP par script	argument en lecture seule, ticket au support	vérification d'identité, puis case en console

Glissez pour voir

Le filtrage sous l'angle Well-Architected

Security : trois filtres, deux exemplaires, zéro angle mort

Ce flux est-il vu par un filtre ? Public : le groupe de sécurité. Entre réseaux : la NACL, en IPv4 et en IPv6. Dans un réseau : personne. La discipline est une politique par défaut en drop partout où elle existe, un découpage en Private Networks qui crée les points de contrôle, et une règle de retour pour chaque règle d'aller, parce que la NACL est stateless.

Operational Excellence : une NACL se gère en code

Peut-on relire et rejouer ce filtrage ? Oui, si les règles vivent dans un fichier versionné et sont posées par une seule commande rule set complète, ou par Terraform. La discipline est une copie JSON avant chaque changement, une description sur chaque règle, et un test de panne volontaire après la première mise en production.

Pièges courants

Le tableau se lit par la colonne Symptôme : c'est ce que vous voyez à l'écran, message exact compris quand il y en a un ; la colonne Cause dit ce qui se passe réellement, et la colonne Solution la commande ou le geste qui débloque.

Symptôme	Cause	Solution
Le trafic sort mais rien ne revient	filtrage stateless sans règle de retour	ajouter la règle inverse, source et destination permutées
Une règle NACL disparue après un ajout	rule set remplace toute la liste	repasser toutes les règles, ou gérer la NACL en code
missing required argument 'is-ipv6'	rule get exige le type d'adresse	ajouter is-ipv6=false ou is-ipv6=true
missing required argument 'rules.0.src-port-low'	les quatre champs de port sont obligatoires	mettre 0 et 65535 pour « tous les ports source »
IPv4 verrouillé, trafic quand même possible	la NACL IPv6 est restée vide et en accept	dupliquer chaque règle avec is-ipv6=true
Deux machines du même réseau se parlent malgré la NACL	la NACL ne filtre pas à l'intérieur d'un Private Network	séparer en deux Private Networks, ou filtrer sur la machine
Une règle sur le DNS ou les métadonnées reste sans effet	ces flux sont hors de portée des NACL	s'appuyer sur IAM et sur la configuration de l'Instance
KeyError: 'security_group' dans un script	create enveloppe l'objet, get et list non	traiter les deux formes de sortie
group is in use. you cannot delete it.	le groupe est encore rattaché à une Instance	détacher ou supprimer l'Instance d'abord

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Trois mécanismes, trois flux distincts : groupe de sécurité pour le trafic public, Network ACL entre Private Networks, pare-feu système à l'intérieur d'un Private Network ; les trois sont gratuits.
• Rien ne filtre entre deux ressources du même Private Network. Ce qui doit pouvoir être séparé se place dans des réseaux distincts.
• Un groupe de sécurité vit dans une zone de disponibilité : deux zones, deux groupes à tenir cohérents ; 500 règles par Organisation.
• Vérifiez le caractère stateful de vos groupes, ne le supposez pas : un groupe stateless laisse sortir et bloque le retour ; ceux d'Elastic Metal ne sont jamais stateful.
• Les Network ACL sont stables et disponibles en console depuis le 3 juin 2026, malgré quatre pages de doc en retard (signalées).
• Une NACL vide laisse tout passer ; la politique par défaut d'une liste vide est accept ; 255 règles par version d'IP.
• Les NACL sont stateless : chaque flux autorisé demande sa règle de retour, source et destination permutées.
• scw vpc rule set écrase la liste entière. Sauvegardez avant de modifier, et gérez la NACL en code dès que la production est concernée.
• IPv4 et IPv6 ont deux listes indépendantes. Verrouiller l'une laisse l'autre grande ouverte.
• DNS, DHCP et métadonnées ne se filtrent pas par NACL ; SMTP sortant est bloqué jusqu'à la vérification d'identité, et se débloque en console seulement.

Pour aller plus loin

• IAM : donner le droit minimal à une CI : Le jeu VPCFullAccess limité à un projet, pour qu'une identité de déploiement pose la NACL de son réseau et pas des autres.

Ressources externes

Les pages officielles sur lesquelles cette leçon s'appuie, avec ce qu'on y cherche ; leur champ de validation date chaque fait cité.

• Understanding Network ACLs : priorité des règles, statelessness, flux hors de portée, quotas de 255 règles.
• How to use Network ACLs : la procédure console, écran par écran, avec la case « Create inverse rule ».
• Groupes de sécurité des Instances : réglages stateful, SMTP et politiques par défaut.
• Instances concepts : groupes stateful et stateless, et la note sur le filtrage interne à un Private Network.

×

📖 Voir la documentation →