Introduire la Segmentation Est-Ouest dans un Réseau en Production

Le point de départ : une coquille dure, un intérieur mou

L’entreprise avait une solide protection nord-sud : des pare-feu de bordure inspectant tout ce qui entrait et sortait du réseau. À l’interne, rien. Chaque VRF pouvait joindre tous les autres par simple routage, si bien qu’un seul poste de travail compromis se trouvait à un saut des serveurs, des interfaces de gestion et de tous les autres départements. C’est le classique modèle coquille dure, intérieur mou, et il échoue exactement au moment où cela compte : après la première intrusion, quand le mouvement latéral décide de la gravité de l’incident.

Les audits révèlent régulièrement où cela mène : des conceptions de VRF trop permissives où des segments internes peuvent joindre bien plus qu’ils ne le devraient sans jamais traverser un pare-feu (l’article sur l’audit réseau couvre ce mode de défaillance). Ce projet est le remède : placer un point d’inspection au milieu du réseau, entre les VRF, et faire émerger la politique des preuves plutôt que des suppositions.

La conception

L’architecture est un pare-feu de segmentation interne : une paire haute disponibilité d’appliances Cisco Secure Firewall série 4100 exécutant Threat Defense (FTD), gérée centralement par Firewall Management Center (FMC), insérée comme point de passage obligé du routage entre les VRF.

Les décisions de conception clés :

• Le pare-feu devient la passerelle inter-VRF. Au lieu que les VRF échangent leurs routes directement, le trafic inter-VRF est dirigé à travers la paire de pare-feu. Chaque VRF correspond à une interface et une zone de sécurité, si bien que la politique s’écrit en termes de zones, ce qui reste lisible quand le réseau grandit.
• La symétrie est non négociable. L’inspection à état meurt sur les chemins asymétriques, donc le routage a été conçu pour garantir que les deux directions de chaque flux inter-VRF traversent la même paire de pare-feu. Cela a guidé la conception haute disponibilité (actif/passif avec bascule à état) et les métriques de routage autour.
• Le trafic intra-VRF ne touche jamais le pare-feu. La segmentation s’applique là où existe une frontière de sécurité. Garder le trafic de même VRF dans la fabrique a évité de transformer le pare-feu en goulot d’étranglement accidentel pour les flux est-ouest de stockage et de sauvegarde qui ne franchissent aucune frontière.

Phase un : tout permettre, tout journaliser

Dès le premier jour, la paire de pare-feu est entrée en service avec des politiques tout-permis et une journalisation complète des connexions. Délibérément. Personne, pas même les propriétaires d’applications, ne sait réellement ce qui parle à quoi dans un réseau qui n’a jamais eu d’application de règles internes. Activer des règles de blocage à partir d’un schéma sur tableau blanc, c’est ainsi qu’on fait tomber la paie un mardi.

Pendant plusieurs semaines, les pare-feu n’ont fait qu’observer. Les événements de connexion remontaient de FMC vers notre pile d’analyse de journaux (les vues d’analyse de FMC pour les pivots rapides, avec export des événements vers le SIEM pour les requêtes sur fenêtres longues), et nous en avons tiré une matrice de flux : pour chaque paire de VRF, quelles sources, destinations, ports et applications communiquent réellement, à quelle fréquence et à quel volume.

Cette phase a fait remonter l’archéologie habituelle : dépendances non documentées, serveurs appelant des services que plus personne ne possédait, travaux de sauvegarde traversant des frontières que personne n’attendait, et une poignée de flux qui étaient simplement des erreurs de configuration héritées plutôt que des besoins d’affaires.

Phase deux : transformer les flux en politique

De la matrice de flux, nous avons généré des ensembles de règles candidats par paire de VRF : des permissions restreintes aux sources, destinations et services observés, regroupées par application plutôt qu’une ligne par flux. Chaque ensemble candidat est ensuite passé en revue avec l’équipe sécurité, flux par flux : conserver, restreindre ou supprimer. Cette revue est l’endroit où la segmentation se produit réellement. Le pare-feu ne fait qu’appliquer le résultat.

Le déploiement s’est étalé sur une série de fenêtres de maintenance, une frontière de VRF à la fois, avec le même garde-fou chaque nuit : déployer les permissions restreintes avec, en dessous, une règle de blocage en mode surveillance d’abord, guetter les correspondances que la matrice de flux aurait manquées, puis passer en application avec un retour arrière testé et prêt. Comme chaque règle remontait à du trafic observé, les nuits de bascule ont été calmes. La partie effrayante avait déjà eu lieu dans les données.

L’inspection nouvelle génération, réglée plutôt que poussée à fond

Le trafic passant désormais par un point d’inspection, nous avons activé les fonctions qui justifient un pare-feu plutôt qu’une ACL :

• Prévention d’intrusion avec des politiques Snort 3 sur les flux inter-VRF, en partant de la base équilibrée sécurité-connectivité et en ajustant les ensembles de règles par paire de zones selon ce qui vit réellement derrière chaque frontière.
• Déchiffrement TLS sélectif là où la valeur d’inspection le justifiait, avec une gestion explicite de non-déchiffrement pour les applications à certificats épinglés et les catégories où le déchiffrement casse le client ou le modèle de confiance.
• Chemins rapides en préfiltrage pour les flux volumineux de confiance comme les sauvegardes et la réplication de stockage, afin que les flux éléphants contournent l’inspection profonde délibérément au lieu de la dégrader pour tout le monde.

Chaque fonction a été mesurée avant et après activation contre des budgets de latence et de débit convenus avec les équipes applicatives. Un projet de segmentation qui ralentit l’entreprise se fait annuler politiquement même s’il n’est jamais annulé techniquement, donc le réglage de performance a été traité comme partie intégrante du travail de sécurité, pas comme une réflexion après coup.

Ce qui a changé

Le réseau est passé d’une seule frontière de sécurité (la bordure) à des frontières appliquées entre chaque segment interne. Le mouvement latéral exige désormais soit un flux autorisé, journalisé et inspecté, soit un contournement de pare-feu, ce qui est beaucoup plus exigeant que « être à l’intérieur ». Tout aussi précieux : l’organisation dispose maintenant d’une carte vivante de son propre trafic interne, et d’une base de politiques où chaque règle existe parce que quelqu’un a vu le flux et décidé qu’elle devait exister. Les conversations de conformité ont raccourci aussi. « Montrez-nous comment vous restreignez l’accès interne au segment sensible » est devenu une capture d’écran au lieu d’une réunion.

La méthode est la partie réutilisable : insérer le point de passage en mode passif, observer jusqu’à ce que les données cessent de surprendre, réviser avec les responsables du risque, puis appliquer par petites étapes réversibles. Elle transforme la segmentation d’un acte de foi en une séquence de changements ennuyeux et sûrs, et l’ennuyeux est exactement ce qu’on veut placer entre un attaquant et tout le reste.