Segmentation & micro-segmentation réseau

Le concept en une phrase

Segmenter, c’est découper un système d’information en zones qui ne peuvent se parler qu’en traversant un point de contrôle — de sorte que chaque flux doive être déclaré pour exister.

Un réseau à plat, c’est une base australe où toutes les portes intérieures sont ouvertes : la salle des serveurs, l’atelier, le bureau du chef de mission et le local technique donnent tous sur le même couloir. Celui qui entre par la fenêtre la plus fragile a immédiatement accès à tout le bâtiment. Segmenter, c’est refermer les portes intérieures, et poser un poste de garde unique dans le couloir.

Les grands principes

1. Une zone, c’est un réseau — pas un dossier ni une étiquette

Une zone n’est pas une catégorie administrative : c’est un réseau distinct, matérialisé par trois choses solidaires — un sous-réseau IP, un support physique ou virtuel propre (un réseau interne, un VLAN, un câble), et une patte dédiée sur le pare-feu. Ce sont ces trois éléments ensemble qui rendent la frontière réelle : sans patte dédiée, le pare-feu ne voit rien passer et ne peut rien arbitrer.

Le SI TAAF de la base compte quatre zones défendues, plus un plan d’administration :

Zone	Sous-réseau	Ce qui y vit	Rôle
`z-front`	`10.42.40.0/24`	frontal web et applications exposées	seule zone joignable depuis le WAN
`z-back`	`10.42.10.0/24`	base de données et stockage objet	les données — ne sort jamais vers Internet
`z-services`	`10.42.0.0/24`	autorité de certification interne	la confiance interne, consommée par les autres
`z-soc`	`10.42.50.0/24`	puits de logs et visualisation	le plan d’analyse
`mgmt`	`192.168.56.0/24`	le poste de l’administrateur	plan d’administration, pas une zone défendue

La passerelle de chaque zone défendue est toujours en .1 — c’est la patte du pare-feu, et le seul chemin de sortie de la zone. Le plan d’adressage est unique et canonique en 10.42 : rien à calculer, rien à dériver. Le plan d’administration, lui, est délibérément ailleurs — en 192.168.56 — ce qui le distingue visuellement du SI segmenté.

flowchart TB
    WAN(("Internet"))
    GW["TAAF-GW-001 — OPNsense<br/>le point de contrôle unique"]
    MGMT["mgmt — 192.168.56.0/24<br/>poste de l'administrateur"]

    subgraph FRONT["z-front — 10.42.40.0/24"]
      WEB["TAAF-WEB-001<br/>10.42.40.10"]
    end
    subgraph BACK["z-back — 10.42.10.0/24"]
      DB["TAAF-DB-001<br/>10.42.10.30"]
    end
    subgraph SVC["z-services — 10.42.0.0/24"]
      CA["TAAF-SVC-001<br/>10.42.0.10"]
    end
    subgraph SOC["z-soc — 10.42.50.0/24"]
      MON["TAAF-MONITORING-001<br/>10.42.50.10"]
    end

    WAN -->|"80, 443"| GW
    MGMT --- GW
    GW --- FRONT
    GW --- BACK
    GW --- SVC
    GW --- SOC

2. La vraie raison de découper : le déplacement latéral

On croit souvent qu’on segmente « pour éviter de se faire pirater ». C’est faux, et c’est important de le dire : la segmentation n’empêche aucune intrusion. Le frontal web reste exposé, la vulnérabilité reste exploitable, le mot de passe faible reste faible.

Ce que la segmentation change, c’est ce qui se passe après. Une intrusion réelle se déroule en deux temps : d’abord une prise de pied — souvent sur la machine la plus exposée, celle qui a le moins de valeur — puis un déplacement vers ce qui intéresse vraiment l’attaquant : les données, les identités, les sauvegardes. C’est ce second temps que la segmentation attaque. On ne cherche pas à rendre la première machine imprenable, on cherche à ce que la prendre ne serve à rien.

Retenez la formulation utile en réunion : segmenter ne réduit pas la probabilité d’un incident, ça réduit son rayon.

La mécanique de ce déplacement — trafic nord-sud qui traverse les frontières, trafic est-ouest qui circule latéralement — est traitée en détail dans Pare-feu à état & flux réseau. Lisez-la : cette page-ci décide quelles zones existent, l’autre explique comment le pare-feu les fait respecter.

3. Macro-segmentation, micro-segmentation — et le choix assumé du module

Deux granularités, qui ne se posent pas au même endroit :

	Macro-segmentation	Micro-segmentation
Où	entre les zones	à l’intérieur d’une zone
Qui filtre	le pare-feu central	chaque hôte, pour lui-même
Question posée	`z-front` peut-il parler à `z-back` ?	ces deux machines de `z-back` peuvent-elles se parler ?

La micro-segmentation est ce qui étrangle un attaquant déjà entré dans une zone. Elle a un coût : autant de jeux de règles que d’hôtes, écrits dans autant d’endroits, avec autant d’occasions de diverger de l’intention.

Ce module a délibérément renoncé à la micro-segmentation par pare-feu local (le modèle précédent la portait via UFW sur chaque machine). La raison n’est pas que la micro-segmentation serait inutile — c’est un arbitrage pédagogique et opérationnel : un seul moteur de filtrage, donc un seul endroit où lire la vérité. Quand un flux tombe, il n’y a qu’une question à se poser et qu’un journal à ouvrir. Toute la construction, toute la preuve et tout le débogage passent par le pare-feu central.

Sachez malgré tout ce que ce choix vous coûte, parce que la question vous sera posée un jour : à l’intérieur d’une zone, rien ne sépare deux machines. Deux hôtes de z-back se parleraient librement sans que le pare-feu voie quoi que ce soit. Ici le risque est contenu par la sobriété du modèle — une zone, un hôte — mais dans un SI réel qui empile vingt serveurs par zone, ce trou est exactement là où l’attaquant travaille.

4. Default-deny — et le refus doit être loggé

Le principe qui tient tout le reste : tout ce qui n’est pas explicitement autorisé est refusé. On n’écrit jamais la liste de ce qu’on interdit — elle est infinie et on l’oubliera. On écrit la liste, courte, de ce qu’on ouvre, et la dernière règle de chaque interface refuse le reste.

La partie que tout le monde oublie est la seconde moitié : ce refus final doit être journalisé. Un block silencieux protège ; un block log protège et informe. La différence est considérable :

block seul — le paquet tombe, personne ne le sait, et le SI ne vous apprend rien.
block log — chaque tentative refusée devient une ligne exploitable. Un frontal qui essaie soudain d’atteindre le port 3000 du SOC, ou une machine de z-back qui tente de sortir vers Internet, ce n’est pas du bruit : c’est le premier signal d’une compromission.

Le refus est une donnée de détection, pas un déchet. Une architecture segmentée sans journalisation des refus se prive de son meilleur capteur — et elle en a déjà un, exactement à l’endroit où l’attaquant se cogne.

C’est ce qui fait le lien entre ce module et le SOC : les block log du pare-feu partent dans le puits de logs de z-soc, où ils deviennent des règles de détection.

5. La règle d’or — l’exemple canonique

Une seule ligne résume toute la discipline du module :

z-front → z-back sur le port 5432 — et rien d’autre.

Le frontal web a besoin de sa base de données PostgreSQL. Il n’a besoin de rien d’autre dans z-back. Donc il n’obtient rien d’autre.

La conséquence est concrète et se mesure : un attaquant qui prend le contrôle du frontal TAAF-WEB-001 (10.42.40.10) ne voit de TAAF-DB-001 (10.42.10.30) qu’un unique port ouvert. Pas d’administration, pas de partage, pas de scan fructueux. La surface qu’il espérait trouver n’existe simplement pas sur le fil. Avant la segmentation, un balayage de z-back depuis z-front renvoie tout en open ; après, tout est filtered sauf 5432. C’est la même machine, le même service, la même vulnérabilité applicative — et pourtant l’exploitation ne mène nulle part.

Le corollaire compte autant : toute autre ouverture est une exception, et une exception se déclare. Le stockage objet de z-back écoute bien sur 9000, mais ce port ne s’ouvre pas parce qu’il existe — il s’ouvre parce que quelqu’un a écrit une règle, l’a justifiée et en assume la conséquence. C’est la différence entre une architecture et un empilement d’accidents.

6. L’egress — une zone de données qui ne sort pas

On pense presque toujours le pare-feu dans le sens entrant : qui a le droit d’entrer chez moi. C’est la moitié du travail. L’autre moitié, c’est l’egress — qui a le droit de sortir, et vers où.

Dans le SI TAAF, z-back et z-services ne sortent pas vers Internet. Aucune règle ne les y autorise, donc le default-deny les arrête. Ce n’est pas une coquetterie de configuration, c’est de l’anti-exfiltration :

une base de données n’a aucune raison légitime d’initier une connexion vers l’extérieur ;
or l’exfiltration de données, le rappel vers un serveur de commande, le téléchargement d’une charge complémentaire — tout cela est du trafic sortant, depuis l’intérieur, initié par une machine déjà compromise ;
fermer l’egress transforme donc une compromission réussie en compromission stérile : l’attaquant est dedans, mais ses données ne sortent pas et son outillage n’entre pas.

Et grâce au principe précédent, chaque tentative de sortie laisse une ligne de block log. Une zone de données qui essaie soudain de joindre Internet est l’un des signaux les plus nets qu’un SI puisse produire.

7. L’isolation du SOC — un cul-de-sac, dans le bon sens

Le SOC est la zone qui voit tout. C’est précisément pour ça qu’elle doit être la plus contrainte : une supervision compromise, c’est un attaquant qui hérite d’un point de vue sur l’ensemble du SI — et, s’il peut en sortir, d’un tremplin vers toutes les zones qui lui font confiance.

La formulation à retenir est celle du contrat :

z-soc : un seul port entre — 3100, l’ingestion des logs — et rien ne sort.

Toutes les zones poussent leurs journaux vers le puits de logs de z-soc. C’est le seul flux entrant, et il va dans un seul sens : les agents de chaque zone émettent, le SOC reçoit. Le SOC, lui, n’initie aucune connexion — ni vers les zones, ni vers Internet. Il est un cul-de-sac : compromis, il n’est pas un pivot.

L’interface de visualisation (3000) n’est donc pas joignable depuis le SI : elle se consulte depuis le plan d’administration. La détection se regarde depuis l’admin, jamais depuis la zone qu’elle surveille.

flowchart LR
    F["z-front"] -->|"3100"| SOC["z-soc — 10.42.50.0/24<br/>puits de logs"]
    B["z-back"] -->|"3100"| SOC
    S["z-services"] -->|"3100"| SOC
    SOC --x OUT["toute autre destination<br/>zones et WAN"]

8. Zone ≠ hôte — deux objets, deux vocabulaires

Confusion permanente en début de module, et elle coûte des heures de débogage : une zone n’est pas une machine.

Objet	Ce que c’est	Forme du nom	Exemple
Zone	le réseau : un sous-réseau, un support, une patte de pare-feu	`z-<zone>`	`z-back` — `10.42.10.0/24`
Hôte	la machine qui vit dans ce réseau	`TAAF-<RÔLE>-<NNN>`	`TAAF-DB-001` — `10.42.10.30`

z-back est l’adresse, TAAF-DB-001 est l’occupant. Une zone peut contenir plusieurs hôtes ; un hôte appartient à une seule zone. Le nom de la machine — dans l’hyperviseur comme dans son hostname — porte toujours la forme TAAF-*, jamais z-*.

Ce n’est pas de la coquetterie de nommage : les deux vocabulaires ne servent pas au même raisonnement. Les règles de pare-feu se pensent en zones (« z-front vers z-back sur 5432 »), parce qu’une règle doit survivre au remplacement d’une machine. Le diagnostic, lui, se fait en hôtes (« TAAF-DB-001 ne répond pas »). Confondre les deux, c’est écrire des règles qui pointent vers une IP fixe et qui tombent au premier redéploiement.

Le rôle et la zone ne coïncident pas non plus : TAAF-MONITORING-001 porte le rôle de supervision et habite la zone z-soc. Le rôle décrit ce que la machine fait, la zone décrit où elle est défendue.

Où ça intervient dans TAAF

TP1 — Segmentation & pare-feu — le cœur pratique. Vous construisez les quatre zones derrière OPNsense, puis vous écrivez vous-même la matrice de flux qui applique tout ce qui précède. Cette matrice est votre livrable, pas une donnée qu’on vous fournit : le contrat pose les invariants, à vous d’en déduire les règles et de les justifier ligne à ligne.
Pare-feu à état & flux réseau — le complément direct. Stateless vs stateful, table d’état, nord-sud vs est-ouest : tout le mécanisme d’application des frontières qu’on définit ici.
VPN IPsec — la suite, en Phase 2. Le tunnel transporte le trafic vers le site distant ; la segmentation décide qui a le droit d’en faire quoi à l’arrivée. Un tunnel ne dispense jamais de cloisonner derrière.
La preuve, pas l’affirmation — la segmentation se démontre. Un balayage de ports avant et après, depuis une zone vers une autre, et les journaux de refus consultés dans le SOC : c’est ainsi qu’on vérifie qu’une architecture fait ce qu’elle prétend.
Le piège du câblage partagé — deux machines rattachées au même segment physique se parlent sans jamais traverser le pare-feu. La segmentation a l’air de fonctionner, le schéma est beau, et rien ne filtre. Le support d’une zone fait partie de sa définition, au même titre que son sous-réseau.
Convention de nommage — la forme TAAF-<RÔLE>-<NNN> des hôtes, à ne pas confondre avec les noms de zone.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches. Croisez-les : une vidéo pour l’intuition, un guide ANSSI pour la rigueur, une doc officielle pour la pratique.

Comprendre (intuition)

Practical Networking (practicalnetworking.net) : l’explication visuelle de référence du filtrage et des architectures en zones (en anglais, très clair).
Xavki — réseau & sécurité (chaîne YouTube) : tutoriels en français, du concept à la pratique.
Blog de Stéphane Robert (blog.stephane-robert.info) : la référence francophone infra/réseau/sécurité.

Faire (mise en œuvre)

Documentation OPNsense — interfaces et pare-feu (docs.opnsense.org) : la création des pattes de zone et l’écriture des règles du TP1.

Approfondir (rigueur & normes)

ANSSI — cloisonnement & interconnexion des SI (cyber.gouv.fr) : les recommandations françaises sur le découpage en zones de confiance (cherchez « cloisonnement » ou « interconnexion »).
ANSSI — la défense en profondeur appliquée aux SI (cyber.gouv.fr) : le principe des couches indépendantes dont la segmentation est une déclinaison.
NIST SP 800-207 — Zero Trust Architecture (csrc.nist.gov) : ce qu’on fait quand la frontière de zone ne suffit plus.
CISA — Zero Trust Maturity Model (cisa.gov) : le pilier réseau et les paliers de maturité de la segmentation.

À chercher par vous-même : « network segmentation zones de confiance », « lateral movement », « default deny egress filtering », « data exfiltration prevention », « blast radius », « micro-segmentation », « log everything you block ».