- Objectif principal
- Empêcher les déplacements latéraux d'attaquants
- Trafic ciblé
- Est-ouest (entre charges de travail internes)
- Approches
- Réseau · host-based · identity-based · service mesh
- Intègre
- Zero Trust — complète ZTNA
- Exigée par
- PCI DSS · HIPAA · implicitement NIS2 et DORA
01 — DéfinitionQu'est-ce que la micro-segmentation ?
La micro-segmentation est une technique de sécurité qui consiste à découper un environnement IT en segments très fins, puis à contrôler explicitement les flux autorisés entre ces segments. À l'inverse d'une segmentation traditionnelle par VLAN et sous-réseaux (zones de plusieurs dizaines ou centaines de machines), la micro-segmentation isole :
- Chaque charge de travail (VM, conteneur, serveur physique).
- Chaque application ou tier applicatif (front, back, base de données).
- Parfois chaque processus sur une machine (micro-segmentation granulaire).
L'objectif principal est de contenir la propagation latérale (lateral movement) d'un attaquant qui a compromis un premier point d'accès. Sans micro-segmentation, la plupart des attaques sophistiquées suivent un schéma classique :
- Compromission initiale (phishing, exploit de vulnérabilité, compte volé).
- Installation d'un point de contrôle sur une première machine.
- Reconnaissance interne (scan du réseau, énumération des comptes).
- Déplacement latéral vers d'autres machines plus sensibles.
- Élévation de privilèges, accès aux cibles finales (données, Active Directory, sauvegardes).
- Action finale (exfiltration, ransomware, destruction).
La micro-segmentation intervient sur les étapes 3 à 5 en rendant le déplacement latéral impossible ou très visible.
Le concept s'inscrit pleinement dans la démarche Zero Trust : aucune machine n'a confiance par défaut dans ses voisines simplement parce qu'elles sont dans le même sous-réseau. Toute communication doit être explicitement autorisée, quelle que soit la localisation.
Dans un réseau classique, compromettre une machine revient souvent à avoir accès à tout un département. Avec la micro-segmentation bien déployée, compromettre une machine ne donne accès qu'à elle-même.
02 — ContexteLe problème du trafic est-ouest
Trafic nord-sud vs trafic est-ouest
Deux axes de circulation existent dans un système d'information :
- Trafic nord-sud : entre l'intérieur et l'extérieur (utilisateurs vers applications, applications vers Internet). C'est le trafic que les pare-feu périphériques inspectent depuis 30 ans.
- Trafic est-ouest : entre les machines internes (serveur web vers serveur de base de données, VM vers VM, conteneur vers conteneur). Historiquement peu contrôlé car considéré comme « dans la zone de confiance ».
Le déséquilibre historique
Dans un datacenter moderne, le trafic est-ouest représente typiquement 70% à 85% des flux réseau totaux. Pourtant, la majorité des investissements sécurité allaient historiquement sur le périmètre nord-sud. Ce déséquilibre a été massivement exploité par les attaquants : une fois passé le périmètre (phishing, exploitation d'une vulnérabilité), le déplacement latéral est très rapide.
Les grands ransomwares ont prouvé le problème
- NotPetya (2017) : propagation latérale massive via EternalBlue et comptes cachés, ravage mondial de Maersk, Merck, FedEx, Mondelez.
- WannaCry (2017) : exploitation de SMB en déplacement latéral, paralysant le NHS britannique.
- Vagues ransomware 2019-2024 : compromission initiale par phishing, propagation latérale via SMB, RDP, Active Directory. Les rapports annuels Sophos et Coveware montrent que 90%+ des ransomwares impliquent un mouvement latéral significatif avant l'action finale.
Dans la quasi-totalité de ces cas, une micro-segmentation bien déployée aurait limité la propagation à quelques machines au lieu de centaines ou milliers.
Évolution des infrastructures
Les infrastructures modernes rendent la segmentation réseau classique insuffisante :
- Virtualisation : des dizaines de VM sur un même hôte physique, partageant des VLAN.
- Conteneurs et Kubernetes : des centaines de pods par cluster, communications très dynamiques.
- Cloud public : ressources élastiques, adresses IP éphémères, topologie réseau mouvante.
- Applications distribuées : microservices, APIs internes, maillages complexes.
Impossible de maintenir des politiques de pare-feu figées sur IP/VLAN dans ce contexte. La micro-segmentation moderne s'appuie sur l'identité des charges de travail et non sur leur position réseau.
03 — ApprochesTrois grandes techniques
1. Micro-segmentation réseau (SDN-based)
Cette approche utilise des technologies réseau logicielles (SDN — Software-Defined Networking) pour créer des zones isolées avec des politiques de filtrage fines. Les hyperviseurs, commutateurs virtuels et contrôleurs SDN appliquent les règles au niveau de chaque VM ou segment.
Exemples : VMware NSX, Cisco ACI, Nutanix Flow, Arista CloudVision. Groupes de sécurité AWS, Azure NSG, GCP Firewall Rules jouent un rôle similaire dans les environnements cloud public natifs.
Avantages : performant, transparent pour les charges de travail, bien adapté aux environnements virtualisés massivement déployés. Inconvénients : dépendance à l'hyperviseur ou au SDN, couverture limitée aux environnements gérés par ces technologies.
2. Micro-segmentation host-based (agents)
Chaque charge de travail (VM, serveur physique, parfois conteneur) reçoit un agent qui applique les politiques de filtrage localement, au niveau du système d'exploitation. L'approche est indépendante du réseau sous-jacent et fonctionne aussi bien on-premise, dans le cloud, en hybride.
Exemples : Illumio (pionnier), Akamai Guardicore (ex-Guardicore Centra), Zscaler Workload Communications (ex-AirGap), Cisco Secure Workload (ex-Tetration).
Avantages : couverture hétérogène, visibilité extrême sur les flux applicatifs, politiques basées sur l'identité de la charge de travail. Inconvénients : un agent à déployer et maintenir sur chaque machine, coût de licence par hôte, performance à surveiller sur les systèmes très chargés.
3. Identity-based et service mesh
Approche moderne native des environnements cloud et microservices. L'identité d'un service est portée par des certificats X.509 ou des tokens (SPIFFE/SPIRE) et chaque appel entre services est vérifié cryptographiquement.
Les service meshes (Istio, Linkerd, Consul Connect, AWS App Mesh, Cilium Service Mesh) implémentent cette approche dans les environnements Kubernetes. Les communications inter-services sont chiffrées en mTLS et autorisées sur la base de politiques d'identité.
Avantages : natif cloud et conteneurs, indépendant du réseau, applique le principe Zero Trust jusqu'aux microservices. Inconvénients : limité aux environnements qui l'adoptent (pas pour le legacy), complexité opérationnelle significative, expertise équipe requise.
Combinaison dans la pratique
Une organisation avec un SI hétérogène combine souvent les trois approches :
- SDN / groupes de sécurité pour la segmentation macro et les environnements virtualisés.
- Agents host-based pour les applications legacy, les serveurs physiques et les bases de données.
- Service mesh pour les applications cloud-natives en conteneurs.
Cette combinaison offre la meilleure couverture, au prix d'une complexité opérationnelle plus grande.
04 — Cas d'usageOù la micro-segmentation crée de la valeur
Limitation d'un ransomware en cours
Cas d'usage le plus cité. Avec micro-segmentation déployée, un ransomware qui a compromis un poste utilisateur ne peut pas se propager aux serveurs de fichiers, aux bases de données, aux sauvegardes. Les politiques autorisent uniquement les flux légitimes documentés. Le chiffrement reste localisé au poste initial.
Isolation des environnements critiques
Séparer strictement :
- Les environnements de production et les environnements de développement.
- Les données à caractère personnel soumises au RGPD des autres flux.
- Les environnements cartes bancaires (PCI DSS) du reste du SI.
- Les systèmes industriels (OT/ICS) de l'IT classique.
- Les postes administrateurs (PAW) des postes utilisateurs standards.
Protection de l'Active Directory
L'Active Directory est la cible finale de la majorité des attaques avancées. Le durcir par micro-segmentation est une pratique recommandée :
- Les contrôleurs de domaine ne communiquent qu'entre eux et avec les services autorisés.
- Aucun poste utilisateur ne peut lancer directement des outils d'administration (PowerShell Remoting, WMI) vers les DC.
- Les flux de réplication AD sont limités aux ports et pairs légitimes.
Conformité PCI DSS et HIPAA
Ces référentiels exigent une isolation stricte des environnements hébergeant des données de paiement (PCI) ou de santé (HIPAA). Historiquement réalisée par réseaux physiques dédiés, elle peut aujourd'hui être réalisée par micro-segmentation logicielle, acceptée par les auditeurs et beaucoup moins coûteuse.
Migration et modernisation
Pendant une migration d'applications (on-premise vers cloud, datacenter vers datacenter, monolithe vers microservices), la micro-segmentation permet :
- Cartographie initiale des dépendances inter-applications souvent mal documentées.
- Politiques de filtrage stables indépendantes de l'environnement.
- Détection des communications résiduelles non migrées.
Applications multi-tenants
Isolation fine entre tenants d'une même application (clients d'un SaaS hébergé chez vous, filiales d'un groupe sur la même plateforme). Chaque tenant a ses politiques de flux, ses règles, son isolation logique, sans multiplier les infrastructures physiques.
Environnements cloud-natives
Dans Kubernetes, la micro-segmentation via NetworkPolicies, service mesh et admission controllers permet de contrôler précisément les communications entre services, entre namespaces, entre clusters. Indispensable pour les plateformes critiques avec de nombreux microservices.
05 — ActeursPrincipales solutions du marché
Leaders historiques host-based
- Illumio : pionnier du domaine, référence sur les grandes entreprises, visualisation claire des flux.
- Akamai Guardicore Centra : forte présence mid-market et grandes entreprises, acquis par Akamai en 2021.
- Cisco Secure Workload (ex-Tetration) : historiquement positionné haut de gamme, fortement lié à l'écosystème Cisco.
- Zscaler Workload Communications (acquisition AirGap en 2024) : intégration dans la plateforme Zero Trust Zscaler.
Approches réseau et SDN
- VMware NSX : référence pour les environnements vSphere virtualisés, micro-segmentation au niveau hyperviseur.
- Cisco ACI : fabric SDN avec micro-segmentation intégrée.
- Nutanix Flow : micro-segmentation pour Nutanix AHV.
- Arista CloudVision + MSS : approche datacenter moderne.
Cloud public natif
- AWS : Security Groups, Network ACL, VPC Lattice pour la segmentation applicative.
- Azure : Network Security Groups, Azure Firewall, Application Security Groups.
- Google Cloud : Firewall Rules, Service-to-service authentication.
- Oracle Cloud : Network Security Groups.
Cloud-natif et conteneurs
- Cilium : solution basée sur eBPF, référence Kubernetes moderne, intègre du service mesh.
- Istio : service mesh le plus répandu pour Kubernetes.
- Linkerd : service mesh plus léger et accessible.
- Calico : NetworkPolicies Kubernetes avancées.
- HashiCorp Consul Connect : mTLS et service mesh indépendant de Kubernetes.
Plateformes intégrées émergentes
- Microsoft Defender for Cloud : micro-segmentation adaptative pour Azure et environnements hybrides.
- Palo Alto Prisma Cloud : approche holistique incluant micro-segmentation cloud.
- Wiz, Orca Security : CNAPP qui intègrent de la visibilité et des recommandations de segmentation.
Critères de sélection
- Couverture des environnements (on-premise, cloud, conteneurs, legacy).
- Qualité de la cartographie automatique des flux.
- Facilité de création et gestion des politiques.
- Mode d'observation/simulation avant application.
- Intégration avec l'IAM, les outils de conformité, le SIEM.
- Performance et empreinte des agents.
- Modèle tarifaire (par hôte, par CPU, par workload).
06 — DéploiementDémarche progressive
- Déployer la solution en mode observation uniquement sur le périmètre cible.
- Collecter les flux applicatifs pendant plusieurs semaines (cycles métier complets, batchs nocturnes, clôtures mensuelles).
- Identifier et documenter les communications : légitimes, inattendues, douteuses, obsolètes.
- Cartographier les applications et leurs dépendances.
- Ce travail révèle typiquement des centaines voire des milliers de flux non documentés — précieuses informations.
- Grouper les charges de travail par tags métier et techniques : application, environnement (prod/preprod/dev), zone (DMZ/interne), criticité, conformité (PCI/santé/RH).
- Ces tags deviennent la base des politiques — pas l'adresse IP ou le VLAN.
- Valider la cohérence avec les métiers et les architectes.
- Mettre en place une gouvernance du tagging (qui, quand, comment).
- Définir les politiques par tags plutôt que par IP.
- Commencer par des politiques larges (par environnement, par zone) puis affiner.
- Utiliser les suggestions automatiques de l'outil pour les cas simples.
- Documenter chaque politique avec sa justification métier.
- Toujours laisser en place un mode « monitor » qui détecte sans bloquer avant l'application.
- Activer l'application des politiques par vagues : par application, par environnement, par criticité croissante.
- Commencer par les environnements moins critiques (dev, recette) avant la production.
- Pour chaque vague : plan de communication, support renforcé, fenêtre de surveillance étendue.
- Procédures de rollback rapides en cas de blocage de flux légitime.
- Durée typique d'un déploiement complet pour une ETI : 12 à 24 mois.
- Intégration des logs dans le SIEM et le XDR.
- Cas d'usage de détection : tentatives de connexion bloquées, scans internes, comportements anormaux.
- Enrichissement des politiques avec les signaux de threat intelligence.
- Revues périodiques des politiques (trimestrielles pour les environnements critiques).
- Automation de la maintenance via API (déploiement applicatif, rotation de services).
- Convergence avec les autres briques Zero Trust : ZTNA, IAM, EDR.
- Politiques dynamiques qui intègrent la posture des charges de travail, les alertes, les signaux contextuels.
- Micro-segmentation granulaire au niveau processus pour les environnements les plus sensibles.
- Exercices périodiques (Red Team, simulations) pour valider l'efficacité.
07 — PiègesBonnes pratiques et erreurs classiques
Ne pas sous-estimer la cartographie
L'erreur la plus fréquente : vouloir définir les politiques « à partir de la documentation existante ». Cette documentation est presque toujours incomplète : les applications ont évolué, des flux ont été ajoutés sans documenter, des dépendances obscures existent depuis des années. Seule une cartographie automatique par observation donne la réalité des flux.
Partir de politiques trop larges et affiner
Contre-intuitif mais efficace : commencer par des politiques très permissives (par environnement) puis les durcir progressivement. Essayer de définir tout de suite des politiques ultra-fines entraîne des centaines de règles ingérables qui cassent des flux légitimes au premier déploiement.
Impliquer les équipes applicatives tôt
Les équipes sécurité seules ne peuvent pas définir les politiques. Les propriétaires d'applications connaissent les flux légitimes, les cas d'usage métier, les dépendances cachées. Leur implication dès la phase de cartographie est essentielle. Sinon, la définition des politiques devient un goulot d'étranglement.
Prévoir le cycle de vie applicatif
Une fois déployée, la micro-segmentation doit évoluer avec les applications : nouvelles versions, nouveaux microservices, migrations, déploiements continus. L'intégration dans les pipelines CI/CD et les politiques « as-code » évite que la micro-segmentation devienne un frein à l'agilité.
Mesurer l'efficacité
Métriques à suivre :
- Pourcentage d'hôtes couverts (agents installés, enrollment).
- Nombre de flux bloqués / observés / autorisés.
- Tentatives de connexions internes atypiques détectées.
- Temps moyen de résolution d'un blocage légitime.
- Réduction mesurée de la surface d'attaque (nombre de chemins possibles entre segments).
Tester régulièrement par Red Team
La micro-segmentation s'évalue en conditions réelles : exercices Red Team ciblés, tests d'intrusion internes, simulations de ransomware qui tentent de se propager. Si la propagation latérale est triviale, la micro-segmentation est mal configurée, quelle que soit la sophistication de l'outil.
Attention à la charge opérationnelle
La micro-segmentation ajoute des politiques à gérer, des incidents à traiter (flux bloqués légitimes), une gouvernance à maintenir. Sous-estimer cette charge est une erreur classique : prévoir 1 à 2 ETP dédiés pour une grande entreprise pendant la phase de déploiement, puis environ un demi-ETP en régime de croisière.
Articuler avec les autres démarches
La micro-segmentation s'articule avec l'IAM (qui peut faire quoi), le chiffrement (quelles données protéger), la supervision (détecter les violations), la réponse à incident (isoler dynamiquement une charge de travail compromise). Une démarche isolée est moins efficace qu'une démarche coordonnée dans une feuille de route globale Zero Trust.
08 — FAQQuestions fréquentes
Micro-segmentation et pare-feu traditionnels sont-ils incompatibles ?
Non, complémentaires. Les pare-feu périmétriques continuent de contrôler le trafic nord-sud et d'appliquer des fonctions avancées (IPS, antivirus, filtrage URL, inspection TLS). La micro-segmentation s'occupe spécifiquement du trafic est-ouest, souvent avec des politiques plus simples mais plus nombreuses. Les deux couches cohabitent dans une architecture moderne.
Faut-il segmenter tout le SI ?
Pas forcément tout de suite. Une démarche pragmatique cible en priorité : les environnements contenant des données sensibles (conformité), les applications critiques au métier, l'infrastructure d'identité (Active Directory, IdP), les sauvegardes, les outils d'administration. Le reste peut être couvert dans des vagues ultérieures, ou rester dans une segmentation macro si le risque est plus faible.
Quel retour sur investissement attendre ?
Le ROI principal est la réduction du coût d'un incident cyber majeur. Le coût moyen d'un ransomware en 2024 dépassait 4 millions de dollars (IBM Cost of a Data Breach Report). La micro-segmentation réduit typiquement le périmètre impacté d'un facteur 5 à 10, ce qui représente des économies majeures. Autres ROI : réduction du coût de conformité (PCI DSS notamment), visibilité qui permet d'optimiser l'infrastructure, facilitation des migrations.
La micro-segmentation peut-elle casser des applications ?
Oui, si elle est mal déployée. Des politiques trop strictes activées sans phase d'observation peuvent bloquer des flux légitimes et casser des applications en production. La démarche progressive (observation → simulation → application par vagues) minimise ce risque. Les outils modernes proposent des modes « learning » ou « monitor-only » précisément pour éviter ce piège.
Quelle différence avec les NetworkPolicies Kubernetes ?
Les NetworkPolicies Kubernetes sont une forme native de micro-segmentation limitée à l'intérieur d'un cluster, basées sur les labels et namespaces. Elles sont efficaces mais ne couvrent que l'environnement Kubernetes. Une plateforme de micro-segmentation d'entreprise (Illumio, Akamai Guardicore) couvre des environnements beaucoup plus larges : Kubernetes, VM, serveurs physiques, cloud, legacy. Beaucoup d'organisations utilisent les deux conjointement : NetworkPolicies pour l'intérieur des clusters, plateforme unifiée pour la vision globale et les flux inter-environnements.