Zero-Trust dans le LAN : mise en œuvre pratique de la microsegmentation avec des règles de pare-feu et des VLANs

«Zero-Trust dans le LAN» peut sonner comme un grand projet, mais en pratique il s’agit surtout d’une chose : un nettoyage systématique des hypothèses de confiance implicites dans le réseau interne. Dans les LAN classiques, on suppose souvent que «l’intérieur est sûr», et c’est précisément ce que les attaquants exploitent après un premier accès : ils se déplacent latéralement (East-West-Traffic), scannent les services, détournent des sessions administratives ou tirent parti de ports de gestion ouverts. La microsegmention répond à ce risque en autorisant explicitement la communication dans le LAN au lieu de la tolérer de manière générale — typiquement via une combinaison de VLANs (segments logiques de couche 2) et de règles de pare-feu (Layer-3/4-règles, la plupart du temps à état (stateful)).

Ce billet propose une approche pragmatique pour les administrateurs et les System Engineers : prérequis, décisions d’architecture, pièges fréquents, étapes de vérification concrètes, mise en œuvre par phases et une stratégie de repli fiable. L’accent n’est pas mis sur les interfaces fournisseurs spécifiques, mais sur des mécanismes qui fonctionnent dans presque tous les environnements — que ce soit avec un pare-feu central, du routage au core, du L3-switching ou un pare-feu distribué en virtualisation.

Pourquoi la microsegmention dans le LAN échoue en pratique (et comment l’éviter)

Les causes les plus courantes d’échec des projets de segmentation ne sont pas techniques, mais liées au manque de préparation :

• Dépendances de services floues : personne ne sait de manière fiable quels systèmes doivent communiquer sur quels ports et à quel moment. Résultat : «Any/Any» comme solution de secours.
• Zones trop larges : «Serveurs», «Postes», «Management» — ça semble propre, mais c’est souvent trop vaste. Un poste compromis a alors encore trop de cibles accessibles.
• Absence de processus d’exploitation : sans journalisation, métriques et runbook de dépannage, chaque blocage devient une intervention d’urgence.
• Contournement par des exceptions : imprimantes, scanners, systèmes legacy, OT/IoT — au final, tout se voit accorder des permissions «temporairement» larges.

La contre-mesure est une approche itérative : d’abord visibilité (données de flux, logs de pare-feu), puis zonage, puis un passage progressif au «Default Deny» par segment avec des exceptions claires et documentées. Important : la microsegmention n’est pas un projet ponctuel, mais un modèle d’exploitation (cycle de vie des politiques, processus de changement, revue).

Clarifier les termes : VLAN, microsegmention, Zero Trust, zones

VLAN (Virtual LAN) sépare les domaines de broadcast au niveau de la couche 2. C’est un outil d’organisation et de montée en charge, mais pas une garantie de sécurité : dès qu’il y a routage entre VLANs (Inter-VLAN-Routing), une politique décide si le trafic est autorisé.

Microsegmention signifie un contrôle d’accès plus fin à l’intérieur du réseau interne. Cela peut se faire via des VLANs plus des pare-feux, via un pare-feu distribué (règles directement sur l’hyperviseur/hôte) ou via des pare-feux host-based. L’essentiel : le mouvement latéral est rendu plus difficile parce que les chemins standard font défaut.

Zero Trust est un principe de sécurité : aucune hypothèse de confiance implicite basée sur la position réseau. Dans le LAN, cela signifie concrètement : identité (qui), appareil/état (avec quoi), contexte (d’où) et privilège minimal (seulement ce qui est nécessaire). Les VLANs et les règles de pare-feu sont des outils pour la composante réseau.

Modèle de zones désigne la subdivision en zones de sécurité (par ex. Utilisateurs, Serveurs, Management, Sauvegarde, DMZ, OT) et des transitions définies avec des règles claires. En pratique, un bon modèle de zones est la condition préalable pour que la microsegmention n’aboutisse pas à des milliers d’autorisations individuelles.

Options d’architecture : où la politique s’applique-t-elle techniquement ?

Avant d’écrire des règles, clarifiez où l’application (enforcement) doit avoir lieu. Trois modèles sont courants en production :

1) Pare-feu central entre zones (classique)

Le routage inter-VLAN passe par un pare-feu (ou un cluster de pare-feu). Avantage : visibilité centrale, un jeu de règles, logs cohérents. Inconvénient : le trafic Est-Ouest peut générer du hairpinning (détour via le pare-feu) et impacter latence/débit. Pour de nombreuses infrastructures de taille moyenne, c’est néanmoins l’approche la plus stable pour démarrer.

2) Routage au niveau Core/L3-Switch + ACL/fonction pare-feu

Le Core route entre VLANs et applique des règles sous forme d’ACL. Avantage : très performant. Inconvénient : les ACL sont souvent moins pratiques que des politiques stateful (par ex. pas de retour automatique), la journalisation dépend de la plateforme et les modifications de politique sont sujettes aux erreurs. Convient pour des zones grossières, pour une vraie microsegmentation seulement avec un processus soigné.

3) Pare-feu distribué (virtualisation/SDN)

Les règles sont appliquées près de la charge de travail (par ex. sur l’hyperviseur). Avantage : très granulaire, évolue pour le trafic Est-Ouest sans goulot central. Inconvénient : dépendance accrue au stack de virtualisation/SDN, dépannage plus complexe (plus de couches), et les systèmes physiques doivent être traités séparément.

Prérequis : Ce que vous devez garantir avant le premier « Deny »

Pour que la segmentation ne devienne pas une source d’indisponibilités, ces bases sont déterminantes :

• Inventaire IP et VLAN propre : quels réseaux existent, à quoi servent-ils, qui y est connecté ? La documentation doit refléter la réalité.
• Résolution de noms et temps : DNS et NTP sont des services transverses. Si la microsegmentation bloque DNS/NTP, les pannes apparaissent aléatoires (connexions, certificats, Kerberos, monitoring). Planifiez explicitement ces flux.
• Source d’identité : pour beaucoup d’environnements, cela signifie AD/LDAP, RADIUS/TACACS+ pour l’accès réseau, éventuellement PKI. Il faut savoir clairement où s’effectue l’authentification.
• Observabilité : logs de pare-feu, données de flux (NetFlow/IPFIX/sFlow) ou à défaut statistiques de ports de switch. Sans télémétrie, il ne reste que l’essai-erreur.
• Processus de changement et de retour arrière : fenêtres de maintenance, responsables, voie de communication, accès d’urgence (out-of-band).

Conception pratique : zones, groupes de services et chemin vers la microsegmentation

Une approche pragmatique : « zones d’abord, microsegments ensuite » :

Étape 1 : Définir des zones grossières qui reflètent la réalité opérationnelle

Zones typiques dans les réseaux d’entreprise :

• Utilisateurs/Clients : postes des utilisateurs.
• Serveurs : serveurs applicatifs et d’infrastructure.
• Management : postes d’administration, jump hosts, réseaux de gestion (iLO/iDRAC, gestion des switches/pare-feu).
• Services partagés : DNS, NTP, PKI, logging, monitoring, serveurs de mise à jour, gestion de configuration.
• Sauvegarde/Stockage : serveurs de sauvegarde, dépôts, réseaux de stockage (séparés, souvent avec contraintes propres).
• DMZ/Exposé : systèmes avec interfaces externes.
• IoT/OT : dispositifs avec une base de sécurité faible (imprimantes, caméras, automatisation du bâtiment).

Important : chaque zone a besoin d’un « comportement par défaut » clair. Pour Zero Trust sur le LAN, l’objectif à moyen terme est un refus par défaut entre zones, avec des autorisations explicites. En phase de transition, on peut d’abord traiter le « Deny » uniquement en mode log/alerte (si la plateforme le permet) ou l’introduire via une zone pilote strictement limitée.

Étape 2 : Groupes de services plutôt que règles hôte-à-hôte

Dans les pare-feu, il est opérationnellement plus stable de travailler avec des groupes d’objets : “AD-Controller”, “DNS-Resolver”, “Monitoring”, “DB-Cluster”, “Jump-Hosts”. Cela réduit le nombre de règles, facilite les audits et rend les migrations ultérieures (changement d’IP, nouveaux serveurs) maîtrisables.

Un contrôle qualité pratique : si vous référencez 40 hôtes individuels pour une application, il manque probablement un concept d’architecture ou de nommage (par ex. VIP, Load Balancer, Service Discovery) — ou le périmètre est trop vaste.

Étape 3 : Commencer la micro-segmentation là où le risque et le bénéfice sont élevés

Il est recommandé de démarrer par :

• Accès de gestion : SMB/RDP/SSH/WinRM/interfaces d’administration HTTP uniquement depuis des Jump Hosts, pas depuis l’ensemble du réseau client.
• Actifs critiques : contrôleurs de domaine, référentiels de sauvegarde, PKI, coffre-fort de mots de passe — très RESTrictif, peu de flux autorisés.
• IoT/OT : « Ne peut communiquer qu’avec X et Y » est généralement facile à définir et réduit fortement la mobilité latérale.

Mise en œuvre concrète : VLANs, routage et politiques de pare-feu par étapes

La séquentialisation suivante est volontairement conservatrice, car elle limite les interruptions et permet l’apprentissage.

Étape A : Créer la structure VLAN sans modifier la communication

Vous pouvez déplacer les équipements progressivement vers de nouveaux VLANs, tant que le routage inter-VLAN permet les chemins existants. L’objectif est d’abord l’ordre et la visibilité. Portez attention à :

• Plages DHCP par VLAN, options 3 (passerelle) et 6 (DNS) correctes.
• Adressage IP : réseaux cohérents (p. ex. par zone/emplacement), marges pour la croissance.
• Trunks/VLAN natif : une mauvaise conception ici génère des « problèmes fantômes » (VLAN incorrect, fuites ARP). Vérifiez systématiquement ce qui est non tagué.

Si vous souhaitez rafraîchir les notions d’Access/Trunk/VLAN natif, prévoyez en interne un lien vers votre article de conception VLAN (utile également lors du dépannage).

Étape B : Politique d’abord en mode « observation » (logs/flux)

Avant de bloquer, vous devez savoir ce qui se passe réellement. Deux sources de données pragmatiques :

• Journaux du pare-feu pour le trafic inter-VLAN (si celui-ci est déjà routé via le pare-feu).
• Données de flux (NetFlow/IPFIX/sFlow) depuis le commutateur core ou de distribution — indiquent « qui parle avec qui, combien, à quelle fréquence ».

L’objectif est une matrice de communication (Zone A → Zone B, ports/protocoles, direction). Elle n’a pas besoin d’être parfaite, mais suffisante pour les premières règles.

Étape C : « Refus par défaut » par zone pilote avec règles explicites d’autorisation

Choisissez une zone au périmètre maîtrisé (p. ex. IoT ou un petit bloc de serveurs) et appliquez entre cette zone et le RESTe un refus par défaut. Ensuite, n’autorisez que les flux nécessaires, p. ex. DNS, NTP, Syslog/monitoring, mises à jour et destinations spécifiques à l’application.

Important : utilisez des règles stateful lorsque c’est possible. « Stateful » signifie que le pare-feu conserve l’état des connexions et autorise automatiquement le trafic de retour. Avec des ACL stateless, vous devez prendre en compte explicitement le sens inverse et les ports éphémères (ports clients dynamiques) — une source fréquente d’erreurs.

Autorisations minimales typiques souvent oubliées

Ces flux sont « invisiblement importants » dans de nombreux environnements. Lorsqu’ils manquent, les incidents paraissent aléatoires :

• DNS (UDP/TCP 53) vers les résolveurs prévus. TCP est pertinent pour les réponses volumineuses et les transferts de zone.
• NTP (UDP 123) vers des sources de temps internes. La dérive temporelle rompt Kerberos, les chaînes de certificats et la corrélation des logs.
• Authentification : selon l’architecture Kerberos (TCP/UDP 88), LDAP/LDAPS (389/636), SMB (445) pour certains chemins, éventuellement RADIUS (1812/1813).
• PKI/CRL/OCSP : la validation des certificats nécessite l’accès aux points de terminaison CRL/OCSP (internes ou externes). Sans cela, des erreurs TLS surviennent et donnent l’impression que l’application dysfonctionne.
• Gestion : SNMP (idéalement v3), WMI/WinRM/RDP/SSH uniquement depuis la zone de gestion, pas depuis les réseaux utilisateur.
• Monitoring/Logging : Syslog, communication des agents, exporters, selon la stack.

Le gain en sécurité ne vient pas d’une approche « tout ou rien », mais de la définition contrôlée et cohérente de ces chemins de base, plutôt que de les laisser ouverts implicitement.

Dépannage : si, après la segmentation, quelque chose ne fonctionne plus « soudainement »

La segmentation échoue rarement à cause du concept, mais en raison de l’absence d’une routine de diagnostic. Un parcours de vérification pragmatique :

1) Délimiter le problème : nom, IP, port, direction

Posez une question précise : « De source vers cible sur port/protocole, ça échoue. » Sans cette précision, vous perdez du temps sur des axes secondaires (DNS vs routage vs politique).

2) Vérifier le routage et le next-hop

Symptôme : les paquets contournent le point d’application des règles ou empruntent un chemin asymétrique (aller différent du retour). Le routage asymétrique est critique pour les firewalls stateful, car les paquets de retour ne correspondent alors pas au même état.

Sur un Linux-système, vous pouvez vérifier le chemin ainsi :

ip route get 10.20.30.40
ping -c 3 10.20.30.40
traceroute -n 10.20.30.40

Sur Windows, PowerShell est utile :

Test-NetConnection -ComputerName 10.20.30.40 -Port 443 -InformationLevel Detailed
tracert -d 10.20.30.40

3) Pare-feu : privilégiez les logs plutôt que les suppositions

Si vous utilisez un pare-feu central, la vérité la plus rapide se trouve dans le log : quelle règle matche ? Le paquet est-il droppé ? Un groupe d’objets manque-t-il ? Le trafic est-il « App-Identified » ou seulement basé sur le port ? Vérifiez si la session est effectivement établie ou si elle échoue au SYN (TCP) ou si les réponses UDP sont absentes.

Conseil pratique : activez pour les nouvelles policies une journalisation ciblée temporaire (pas globale), sinon les SIEM/systèmes de logs seront noyés de données.

4) Capture de paquets au bon endroit

Un tcpdump sur l’hôte est souvent plus rapide que toute hypothèse. Exemple : vérifier la résolution DNS :

sudo tcpdump -ni any host 10.10.10.53 and port 53

Si vous ne voyez que des requests mais pas de replies, il s’agit souvent d’une policy/routage/état. Si vous ne voyez rien du tout, c’est plutôt la firewall de l’hôte, une interface incorrecte ou une cible erronée (p. ex. un autre serveur DNS fourni par DHCP).

5) Pièges fréquents en exploitation de la segmentation

• Ports éphémères : les ports source des clients sont dynamiques. Les règles doivent en règle générale autoriser « Client → Server : dst port X », et non « src port X ».
• DNS sur TCP : utilisé pour des réponses plus volumineuses. Autoriser uniquement l’UDP ne suffit pas toujours.
• MTU/Fragmentation : de nouveaux chemins peuvent présenter une MTU différente. Bloquer l’ICMP (par ex. « Fragmentation needed ») casse le PMTUD.
• Hairpinning : le trafic Est-Ouest via un pare-feu central peut modifier les performances. Vérifiez le débit et la latence aux heures de pointe.
• Application multiple des contrôles : pare-feu réseau plus pare-feu hôte plus règles SDN – l’analyse des incidents requiert alors un ordre : d’abord l’hôte, ensuite le SDN, enfin le réseau.

Bonnes pratiques pour les règles de pare-feu en micro-segmentation

Certaines règles font la différence entre « complexe » et « fiable en exploitation » :

Transitions de zones explicites plutôt que « Any entre VLANs »

Rédigez les policies en fonction de vos zones et services, pas en fonction d’adresses IP individuelles. Exemple : « Client → Web-Frontend », « Web → App », « App → DB ». Ce n’est pas seulement de la sécurité, c’est aussi de la transparence architecturale.

Utiliser « Deny with log » de façon ciblée

Créez par zone pilote un journal clair des drops. À partir de ce corpus, vous construisez les règles Allow suivantes. Une fois stabilisé, réduisez la journalisation ou passez à l’échantillonnage/alerte afin que l’exploitation ne souffre pas de la charge de logs.

Définir les propriétaires de service et les fenêtres de changement

La micro-segmentation est une interface entre le réseau et l’exploitation applicative. Définissez qui demande les autorisations, qui les approuve et comment vous testez les changements. Sans cette gouvernance, une shadow IT apparaît sous la forme de « je l’ouvre temporairement vite fait ».

Hygiène des règles : dates d’expiration et revue

Les exceptions doivent comporter une date d’expiration (p. ex. 30/60/90 jours) puis être vérifiées activement. Dans de nombreux environnements, c’est le seul moyen de maintenir la base de règles maîtrisable à long terme.

Validation : étapes de vérification avant et après la bascule

Planifiez les tests comme un petit déploiement. Une checklist compacte :

• Connectivité : DNS, NTP, authentification (login), heartbeat de monitoring.
• Flux métier : les 3–5 parcours utilisateurs les plus critiques (p. ex. ouverture d’une application web, dépôt de fichiers, connexion client ERP, impression).
• Flux administratifs : RDP/SSH/WinRM uniquement via Jump Host, pas d’accès directs depuis la zone client.
• Journalisation : les drops sont visibles, mais le volume de logs reste maîtrisable.
• Performance : mesurer latence/débit sur les goulots d’étranglement (pare-feu, cœur), ne pas se baser uniquement sur une appréciation subjective.

Pour les symptômes d’erreurs TCP (SYN, retransmissions, timeouts), une analyse structurée avec Wireshark/pcaps est indiquée ; en interne, prévoyez un lien vers votre Wireshark-Howto dès que vous aurez intégré l’article dans le magazine.

Stratégie de retour (Rollback) : comment revenir en arrière en toute sécurité sans générer de chaos

Le rollback n’est pas du « on espère que ce ne sera pas nécessaire ». Définissez à l’avance des critères et des étapes clairs :

• Critère de rollback : p. ex. « connexion à l’application centrale impossible », « monitoring-heartbeat > X systèmes hors service », « téléphonie hors service ».
• Levier technique : désactiver un groupe de règles, rétablir l’ordre des politiques ou basculer un routage — si possible sans devoir reconfigurer à nouveau les VLANs.
• Seuil temporel : si pas de stabilisation après N minutes, rollback.
• Travail de suivi : sauvegarder les logs, documenter les flux affectés, puis compléter de manière ciblée les règles Allow.

Important pour la pratique : prévoyez des accès « Break-Glass » (p. ex. Out-of-Band-Management, accès console local, compte d’urgence), afin de ne pas vous retrouver exclu de la gestion du réseau par votre propre segmentation.

Quand les VLANs et les règles de pare-feu ne suffisent pas

Les VLANs et les politiques centrales constituent un solide point de départ, mais il y a des limites :

• Même zone, besoin élevé de protection : si plusieurs systèmes critiques sont dans le même VLAN, la segmentation VLAN n’empêche pas les attaques latérales au sein du segment. Dans ce cas, des micro-segments (plus de VLANs), un pare-feu distribué (Distributed Firewall) ou des règles basées sur l’hôte aident.
• Environnements dynamiques : les changements fréquents (p. ex. de nombreuses VM éphémères) bénéficient de politiques basées sur l’identité ou les tags (Workload-Tags), plutôt que d’un jeu de règles basé sur les IP.
• Authentification des appareils : pour déterminer réellement « qui a le droit d’accéder au réseau », le NAC (Network Access Control, p. ex. 802.1X) est pertinent. Sans NAC, le LAN reste vulnérable aux Rogue Devices, même si le trafic inter-zones est strict.

Dans de nombreuses entreprises, la feuille de route réaliste est : d’abord zones + politiques centrales, puis progressivement NAC/Device-Posture et des politiques Workload plus fines là où cela en vaut la peine.

Conclusion : le Zero-Trust dans le LAN est un modèle opérationnel, pas un Big Bang

Le Zero-Trust dans le LAN réussit si vous établissez la microsegmentation comme un processus contrôlé : découper proprement les zones, rendre les flux visibles, affiner les politiques par étapes et sécuriser l’exploitation avec le logging, des procédures de dépannage et un rollback. Les VLANs apportent de la structure, les règles de pare-feu apportent l’application — la combinaison est pragmatique tant que les chemins de routage sont clairs, que les services de base sont délibérément ouverts et que les exceptions ne deviennent pas la règle. Commencez petit, mesurez l’effet, et étendez les segments là où risque et bénéfice se rejoignent.