Sur le principe, la micro-segmentation a pour finalité de « découper » une infrastructure de réseau en micro-réseaux, en se fondant uniquement sur des critères logiciels et/ou de virtualisation. Contrairement à un VLAN, qui a toujours une forte granularité, la téléphonie IP, par exemple, distinguée des postes de travail « normaux », la micro-segmentation intervient à un niveau très fin, celui d’un serveur ou d’un groupe restreint d’utilisateurs. Grâce aux techniques logicielles SDN et VXLAN, elle définit une architecture non contrainte par les aspects physiques du réseau, qui « colle » parfaitement aux besoins. Elle permet donc de « protéger » un îlot fonctionnel de ressources, qu’elle isole en termes de sécurité et de performances. Contrairement aux VLAN classiques décrits au niveau 2 OSI (hors VXLAN), la micro-segmentation exploite les protocoles définis entre les niveaux 3 à 7.

Mais elle est surtout très adaptée aux protections dites est-ouest, à l’intérieur des pares-feux, dans une même structure physique, alors que les techniques habituelles de segmentation sont de type nord-sud et protègent l’infrastructure des attaques venues de l’extérieur, au-delà des pares-feux.

Incontestablement, la micro-segmentation est une très bonne solution pour complémenter les infrastructures courantes de protection en les étendant aux réseaux internes.

Le besoin

Il est simple à appréhender. Prenons l’exemple de la RH (Ressources Humaines). Dans une entreprise moyenne, celle-ci dispose sans doute d’un serveur Web, par lequel elle vante ses mérites et cherche à attirer les candidatures. Elle dispose aussi d’un serveur de fichiers dédié, dans lequel sont regroupés les dossiers des employés et d’un certain nombre de serveurs, dans lesquels sont implémentés des services spécifiques, comme le BI, la paie, etc.

Dans une organisation classique sans segmentation, ces ressources sont éclatées dans des sous-réseaux différents, pour des questions de protection, alors que ce découpage n’a jamais empêché les criminels de pénétrer les installations, dans une DMZ générique où elles côtoient celles des autres départements et des serveurs d’applications, où là aussi elles côtoient la logistique industrielle, la gestion des stocks et la gestion clients. Qui n’ont que peu à voir avec elle.

Cette organisation est un fourre-tout, inadapté aux besoins, car trop global et sans intérêt, eu égard aux vrais besoins sécuritaires et de performances.

Car en fait, les ressources RH n’ont en général besoin que de communiquer entre elles, le service BI avec le serveur de fichiers dédié, la paie avec la base de données employés, etc. L’essentiel du trafic étant limité au périmètre RH, qui n’a que faire de l’ouverture aux autres ressources.

Grâce à la micro-segmentation, on pourra appliquer des règles spécifiques de protection et de contrôle de performances, en se limitant aux flux intra RH et non pas inter services. Sans prétendre tout résoudre, on obtiendra de meilleurs résultats, en phase pour le moins avec les vrais défis sécuritaires des infrastructures modernes.

Trois manières de micro-segmenter un réseau

Généralement, la segmentation d’un réseau a une connotation très physique. On distingue les équipements en fonction de leur raccordement aux switchs et on décide par exemple que telle plage de ports sera réservée aux postes de travail, alors qu’une autre plage sera dédiée aux téléphones. La virtualisation du réseau local a permis de s’affranchir de ce système, très lourd à administrer et trop statique. Toute nouvelle affectation d’une personne se traduisant par une intervention physique sur les switchs et armoires de brassage du local télécommunications.

Elle se fonde, entre autres, sur la distinction des sous-LAN par des protocoles de niveaux 3 et au-dessus, des plages d’adresses IP, l’identité de protocoles de session utilisés, voire par du code applicatif au niveau 7.

Mais la micro-segmentation va beaucoup plus loin, qui permet d’isoler individuellement les charges : une machine physique, une MV, un groupe d’utilisateurs et de leur appliquer des règles de protection adaptées, certaines bien connues, d’autres plus nouvelles.

Tout est là, la micro-segmentation est au fond l’art d’implémenter une architecture protectrice à fine granularité, sans « plomber » les performances de l’ensemble, le risque étant de protéger les ressources au détriment du travail proprement dit des charges.

Ainsi on pourrait imaginer de mettre un pare-feu devant chaque serveur ou MV, de manière à traiter les flux en provenance ou s’adressant à ces charges individuelles.

Sauf qu’il y a un décalage entre les performances des switches, en gros de 2 Tbps pour les plus performants et celles des pares-feux qui ne dépassent guère les 200 Gbps avec des appliances 19 pouces, soit un rapport de un à dix. Et si l’on se met à contrôler tous les flux est-ouest inter VM, on voit bien que l’on risque de tout faire « sauter », pour le moins de saturer les installations.

La mise en œuvre concrète de la micro-segmentation

Il existe trois manières de réaliser une micro-segmentation :

• sur la base de ce que savent faire les équipements du réseau
• via les hyperviseurs
• par le biais des serveurs eux-mêmes

La première solution consiste à utiliser les méthodes traditionnelles des réseaux : pares-feux, ACL (Access Control Lists), etc. On peut l’envisager à condition que le découpage à implémenter ne soit pas trop lourd, la réduction de la surface d’attaque de chacun des serveurs réels ou virtuels, ne pouvant justifier une charge de monitoring trop lourde à supporter.

Les avantages de cette solution tiennent au fait que les administrateurs la connaissent bien et que les règles implémentées dans les pares-feux le sont en dehors des hyperviseurs et des serveurs, ce qui est une bonne chose.

Pour ce qui est inconvénients, il est très difficile d’élaborer des règles applicables à une granularité faible, qui soit en même temps homogène sur l’ensemble du réseau. Plus la granularité de protection d’un réseau important est faible, plus il est difficile de la contrôler, tant ses conséquences sur les autres domaines sont importantes, sur les aspects authentification par exemple, avec les SSO (Single Sign On) et annuaires LDAP. De plus, si l’on veut transporter les services dans un Cloud, il ne faudra pas minimiser la charge financière des pares-feux (pour chaque MV).

Comme toujours, il faudra trouver un compromis entre ce qui est acceptable en termes financiers et charge administrative et les gains sécuritaires que l’on pourra espérer de cette organisation.

La seconde solution est celle que préconise VMWare avec NSX (Network , à savoir faire supporter la micro-segmentation par les hyperviseurs.

Etant donné qu’une couche de supervision, telle que VMWare NSX, est susceptible de traiter tous les aspects virtualisation des réseaux, elle est tout à fait désignée pour prendre en charge la micro-segmentation. Avec cependant quelques restrictions : les charges physiques (« bare metal ») qui ne sont pas supportées (tout est virtuel), la dépendance vis-à-vis d’un fournisseur unique qui peut être gênante, l’incompatibilité de fait avec certaines infrastructures de Cloud (il faut se méfier…), les containers qui ne sont pas supportés, la charge machine induite qui est loin d’être négligeable, le nombre de règles spécifiques à supporter, etc.

Cela dit, c’est sans doute la solution la plus crédible. D’abord parce que NSX comporte toutes les fonctions nécessaires à l’implémentation de la micro-segmentation, mais surtout parce que VMWare n’a plus à faire ses preuves et qu’il a déjà « mangé » 70 % du marché mondial des serveurs. Il n’y a donc pas grand risque à lui faire confiance.

La troisième solution consiste à embarquer la micro-segmentation, non pas dans un hyperviseur, mais dans les serveurs eux-mêmes. Les OS modernes sont tout à fait capables de traiter ces aspects : pares-feux, LAN logiques, etc. Ses avantages sont l’indépendance par rapport à l’infrastructure physique et les hyperviseurs, l’agnostisme vis-à-vis des serveurs, la prise en compte des mouvements réseaux, le déploiement des VM, par exemple, la granularité et la perception fine de ce qui se passe sur chacun des serveurs. Avec toutefois quelques inconvénients : la nécessité d’installer un « agent client » dans chaque hôte, entre autre.