Notes d’architecture · · 2 min de lecture
Refuser par défaut, puis le prouver : segmenter un SI en deux vagues
Une segmentation ne vaut que si chaque flux autorisé est une règle possédée, et chaque flux interdit un test qui échoue. La décision ADR-002 du dossier : macro-segmentation d’abord, micro-segmentation ensuite, par criticité.
ADR-002, statut « proposé » : décision documentée, revue d’architecture à venir. Cas d’étude générique, aucune donnée client.
Le problème : un réseau plat se reconstitue tout seul
Le schéma 05 découpe le SI en cinq zones de confiance : z0 bordure exposée, z1 DMZ sacrifiable, z2 applications et API, z3 données et journaux, z4 administration et supervision. La règle est posée dans le schéma lui-même : aucun flux n’existe par défaut, chaque flèche correspond à une règle déclarée et possédée par une équipe.
Le piège est connu : segmenter sans inventaire préalable produit des listes d’exceptions qui reconstituent le réseau plat en six mois. D’où une contrainte de méthode : la segmentation commence par trente jours d’observation des flux réels, jamais par une table de règles théorique.
Trois options sur la table
- Macro-segmentation : cloisonnement par VLAN ou VRF et pare-feu entre zones. Rapide et lisible, mais une compromission à l’intérieur d’une zone atteint tout ce qui y réside.
- Micro-segmentation applicative : politique par service, maillage mTLS, règles journalisées. Elle réduit le rayon d’impact au service, mais suppose un inventaire de flux fiable et une PKI mature ; sans eux, elle produit justement la liste d’exceptions.
- Séquence hybride : la macro-segmentation tout de suite, la micro-segmentation ensuite, par ordre de criticité, une fois les flux observés.
La décision : deux vagues, par criticité
L’option hybride est retenue. La macro-segmentation protège immédiatement les frontières de zone, sans attendre d’observation. La micro-segmentation suit par criticité décroissante : d’abord z4, parce qu’elle administre toutes les autres, puis z3, qui porte les données et les journaux, enfin z2, service par service.
Le prix accepté : deux chantiers à piloter et un gel des exceptions entre les deux vagues. C’est ce gel qui empêche le réseau plat de revenir par la petite porte.
La preuve : un test de non-accès par règle
Dans la matrice de flux du dossier, chaque flux porte une source, une destination, un service, un propriétaire et un test attendu. Les flux autorisés se prouvent en passant ; les flux interdits se prouvent en échouant : « non-accès direct z0 vers z2 », ou « accès refusé sans session PAM » pour z4 -> z3.
Le banc d’essai de la page d’accueil rejoue cinq de ces tests sur les flux F-008 à F-011. Leur statut réel reste « test attendu » : ils sont décrits et outillés, pas encore exécutés sur une infrastructure. Un contrôle déclaré sans preuve datée n’est pas encore un contrôle.
Sur le terrain
Cinq ans chez Atos, dont trois en alternance, au CEA Saclay puis au Conseil régional d’Île-de-France : politiques pare-feu, ouvertures de flux, segmentation Stormshield, plus de dix grands comptes. Ce dossier prolonge ce terrain du côté de la décision.