Segmentation réseau : pourquoi les projets échouent

La segmentation est le seul contrôle qui limite réellement la propagation latérale d’une attaque. Tout le monde le sait. Et pourtant, c’est le projet qu’on retrouve le plus souvent à l’arrêt, à 40 % d’avancement, depuis dix-huit mois.

Les raisons ne sont presque jamais techniques. Elles sont de méthode, de gouvernance et de séquencement. Voici ce qu’on observe sur le terrain, et comment structurer le projet autrement.

Pourquoi le sujet est revenu sur la table

Le cloisonnement réseau figure explicitement dans les référentiels que vous devrez tôt ou tard produire.

• ISO/IEC 27002:2022 traite le sujet en mesure 8.22 « Cloisonnement des réseaux », en complément de 8.20 (sécurité des réseaux) et 8.21 (sécurité des services réseau).
• Le guide d’hygiène informatique de l’ANSSI place le cloisonnement parmi ses mesures structurantes, au même rang que la gestion des comptes à privilèges.
• PCI DSS en fait un levier direct de réduction de périmètre : segmenter correctement retire des systèmes du champ d’audit, avec un impact budgétaire immédiat.
• La directive NIS 2 ne cite pas la segmentation nommément, mais son article 21 impose la sécurité des réseaux et la continuité d’activité, dont le cloisonnement est un moyen évident.

Autrement dit, le sujet n’est plus une bonne pratique d’architecte. C’est une preuve à produire.

Erreur n° 1 : commencer par le découpage au lieu des flux

Le réflexe classique consiste à dessiner les zones d’abord : bureautique, serveurs, industriel, DMZ, administration, partenaires. Le schéma est propre, il passe en comité de direction, et il se heurte au réel dès la première application de règles.

Parce qu’un découpage ne vaut rien tant qu’on ne sait pas quels flux existent réellement entre les machines. Et cette connaissance, dans la majorité des systèmes d’information que nous auditons, n’existe nulle part. Elle est répartie entre trois personnes, dont une est partie il y a deux ans.

La séquence qui fonctionne est l’inverse :

1. Instrumenter d’abord. Journalisation des flux en production, sans blocage, pendant une période couvrant au minimum un cycle métier complet — arrêté comptable, clôture, campagne saisonnière.
2. Analyser ce qui circule vraiment, y compris les flux que personne n’assume.
3. Dessiner les zones à partir de l’observation, pas de l’organigramme.

Compter quatre à huit semaines d’observation n’est pas du temps perdu. C’est le temps qu’on ne passera pas à débloquer des incidents en production.

Erreur n° 2 : personne n’ose basculer en blocage

Une fois les règles écrites, il faut passer du mode « autoriser et journaliser » au mode « refuser par défaut ». C’est là que 80 % des projets s’arrêtent.

Le mécanisme est simple à comprendre si l’on se met à la place du responsable réseau. S’il coupe correctement, personne ne le remarque. S’il coupe mal, une chaîne de production ou un flux de facturation s’arrête et cela lui retombe dessus. Le rapport bénéfice-risque personnel est défavorable, et la bascule se reporte indéfiniment.

Tant que la décision reste portée par la seule équipe technique, elle ne se prend pas. Elle doit être arbitrée au niveau qui assume l’indisponibilité — direction des systèmes d’information ou direction générale — et cet arbitrage doit être écrit, daté et assorti d’une fenêtre de bascule.

Une phrase suffit : « La bascule en blocage de la zone X est décidée pour le [date] ; le risque d’interruption est accepté ; le retour arrière est possible en moins de N minutes. » Sans ce document, rien ne bouge.

Erreur n° 3 : le règlement grossit plus vite qu’il ne se nettoie

Sur les parcs que nous reprenons, il n’est pas rare de trouver plusieurs milliers de règles de filtrage, dont une part substantielle n’a plus été traversée depuis des années. Règles temporaires devenues permanentes, objets pointant vers des adresses réattribuées depuis, doublons issus de migrations successives, règles « any-any » posées un soir d’incident et jamais retirées.

Ce n’est pas un problème d’esthétique. Un règlement que plus personne ne comprend est un règlement que plus personne n’ose modifier — et la segmentation se fige définitivement.

Avant d’ajouter des zones, il faut savoir quelles règles sont réellement utilisées. Cela se mesure : compteurs de hits, date de dernière utilisation, analyse d’ombrage entre règles. C’est un travail d’outillage, pas de relecture humaine. Aucune équipe ne relit trois mille règles.

Erreur n° 4 : traiter toutes les zones en parallèle

Les projets qui aboutissent avancent par périmètre complet, pas par phase globale. Une zone, jusqu’au bout, bascule en blocage comprise, avant de passer à la suivante.

Un projet qui traite cinq zones en parallèle jusqu’à l’étape 3 sur 5 n’atteint jamais l’étape 5. Il produit beaucoup de documentation et aucune réduction de risque.

L’ordre recommandé : commencer par la zone dont la compromission ferait le plus de dégâts et dont les flux sont les mieux connus. En général l’administration et les comptes à privilèges. C’est aussi la zone où le gain est le plus immédiat en cas d’intrusion.

Ce que font les projets qui réussissent

Un propriétaire métier par zone. Quelqu’un capable de dire « ce flux n’existe plus » sans convoquer une réunion. Sans ce rôle, chaque question de flux prend deux semaines.

Un mécanisme de dérogation rapide. Si obtenir une ouverture prend quinze jours, les équipes contourneront la segmentation — tunnels, rebonds, exceptions permanentes. Vous aurez financé une architecture que personne ne respecte. Un circuit d’urgence en moins de 24 heures, tracé et à durée limitée, coûte moins cher que le contournement généralisé.

Une revue périodique inscrite au calendrier. Semestrielle au minimum, avec retrait effectif des règles non utilisées. Sans cela, vous refaites le même nettoyage dans trois ans.

Une mesure de l’avancement en risque, pas en pourcentage. « 60 % des règles écrites » ne veut rien dire. « La zone d’administration est en blocage » veut dire quelque chose.

Et le Zero Trust dans tout ça

Le modèle décrit par le NIST dans sa publication SP 800-207 pousse la logique plus loin : plus de zone de confiance implicite, vérification à chaque accès, décision par identité et contexte plutôt que par emplacement réseau.

C’est une direction pertinente. Mais dans les organisations que nous accompagnons, elle vient après la segmentation, pas à sa place. Une entreprise incapable de cloisonner trois zones ne déploiera pas un modèle où chaque flux est évalué individuellement.

Se dire « on ne fait pas de segmentation, on fera du Zero Trust » est, dans les faits, une façon de ne rien faire pendant deux ans.

Sources

• ANSSI — Guide d’hygiène informatique
• NIST SP 800-207 — Zero Trust Architecture
• ISO/IEC 27002:2022, mesures 8.20 à 8.22 (sécurité et cloisonnement des réseaux)

Aller plus loin

Nous intervenons sur ces projets en conception comme en reprise d’existant, en sécurité réseau périmétrique. Quand le règlement est devenu ingérable, le préalable est une remise à plat des politiques de filtrage. Selon que le besoin est cadré ou non, ces missions se font au forfait ou en régie.