Sur Free-Work, les annonces d'ingénieur microsegmentation citent presque toujours le même trio : Illumio, Akamai Guardicore Segmentation et le distributed firewall de VMware NSX, avec Cilium dès qu'il y a du Kubernetes. Beaucoup associent le poste au firewalling classique (Fortinet, Palo Alto, Check Point) ou à la gestion des règles avec Tufin et AlgoSec. Les questions d'entretien d'un ingénieur microsegmentation partent du flux est-ouest : ce qui circule entre serveurs sans jamais traverser un pare-feu.
Le projet échoue rarement sur l'outil. Il échoue sur une carte des flux incomplète, une CMDB fausse qui produit de mauvaises étiquettes, ou un passage en blocage pendant une clôture comptable. Le nombre d'applications réellement passées en blocage, et ce qui a cassé la première fois, en disent long. Une personne qui n'a fait que de la visibilité parle de cartes. Celle qui a bloqué parle de retour arrière, de traitements de nuit et de flux oubliés.
Le socle réseau et système compte aussi. Il faut lire un flux SMB ou RPC vers un contrôleur de domaine, savoir ce que fait l'agent dans iptables ou dans Windows Filtering Platform, et expliquer pourquoi un pod Kubernetes sort avec l'adresse de son nœud. Le PDF reprend ces thèmes en 30 questions, avec un cas de 20 minutes.
Les outils de microsegmentation qu'un candidat doit connaître
Illumio Segmentation
La plateforme d'Illumio, dont la documentation technique porte encore le nom Core. Une console centrale, le PCE, calcule la politique à partir d'étiquettes (rôle, application, environnement, localisation) et des agents VEN l'appliquent sur chaque serveur. Les états visibilité, selective et full permettent un passage progressif au blocage. C'est l'outil le plus cité dans les annonces relevées sur Free-Work.
Akamai Guardicore Segmentation
Racheté par Akamai en 2021. La carte Reveal montre les flux entre serveurs avec le processus qui les ouvre. Les règles s'écrivent sur des labels avec trois actions, autoriser, alerter et bloquer, plus des règles Override Block pour les exceptions. Les nouvelles règles passent souvent par une période en alerte avant le blocage.
VMware NSX et vDefend Distributed Firewall
Le pare-feu distribué de NSX filtre au niveau de chaque carte réseau virtuelle, dans l'hyperviseur ESXi, sans agent dans les VM. Broadcom le vend aujourd'hui sous le nom vDefend. Il ne couvre que les VM du parc VMware, ce qui pèse dans le choix depuis le rachat de VMware par Broadcom fin 2023.
Cilium
Le CNI Kubernetes fondé sur eBPF. Ses CiliumNetworkPolicy filtrent sur des identités calculées à partir des labels des pods, jusqu'au niveau HTTP, et sur des noms de domaine en sortie. Hubble affiche les flux acceptés et refusés. Un candidat qui couvre aussi les conteneurs doit le connaître.
Pare-feu de l'OS
iptables ou nftables sous Linux, Windows Filtering Platform et le pare-feu Windows sous Windows. Les agents de microsegmentation pilotent ces mécanismes plutôt que d'inspecter le trafic eux-mêmes. Savoir les lire sert au diagnostic quand une règle ne fait pas ce qu'on attend.
CMDB et source des étiquettes
ServiceNow ou une autre CMDB, les tags cloud et les outils de provisionnement comme Terraform ou Ansible. Les étiquettes en viennent, synchronisées par API. Une CMDB fausse donne des étiquettes fausses, donc des règles qui ouvrent trop ou coupent un flux de production.
Security groups et NSG
Le filtrage natif d'AWS et d'Azure, par instance ou par interface. Il complète ou concurrence l'agent de microsegmentation dans le cloud public. La question à poser au candidat porte sur la source de vérité entre les deux.
SIEM
Splunk, Microsoft Sentinel ou un autre SIEM reçoit les flux refusés, les événements des agents et le journal d'audit de la console. C'est là qu'un agent arrêté ou un balayage interne devient une alerte pour le SOC.
Le poste se trouve dans l'équipe sécurité réseau, souvent à côté des administrateurs pare-feu, et dépend beaucoup des équipes applicatives qui valident les flux. Les missions sont fréquentes chez les grands comptes qui segmentent un parc existant pour limiter la propagation d'un rançongiciel, et chez les intégrateurs qui déploient Illumio ou Guardicore pour leurs clients. Un profil venu du firewalling apporte la rigueur des changements. Un profil venu des systèmes apporte la lecture des flux Windows et Linux. Les éditeurs proposent des formations sur leurs produits. L'expérience d'un passage réel en blocage se vérifie en entretien.
Six savoir-faire à valider chez un ingénieur microsegmentation
- Cartographie des dépendances applicatives
- Modèle d'étiquettes et lien avec la CMDB
- Règles en liste d'autorisation et refus globaux
- Passage progressif en blocage et retour arrière
- Plateformes Illumio, Guardicore, NSX et Cilium
- Exploitation, automatisation et réponse à incident
Flux, étiquettes et blocage : cinq questions d'entretien
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une application de quarante serveurs doit passer en microsegmentation et personne ne connaît ses flux. Comment construisez-vous la carte ?
Une bonne réponseIl déploie les agents en mode visibilité et laisse tourner assez longtemps pour couvrir les cycles de l'application : traitements de nuit, clôture mensuelle, sauvegardes, purges. Il lit les flux par processus et par port, puis les confronte à la CMDB et à l'équipe applicative. Il sort d'abord les flux d'infrastructure communs (DNS, NTP, Active Directory, supervision, sauvegarde, EDR) pour les traiter une fois pour tout le parc, et ne garde dans la règle applicative que ce qui est propre à l'application.
Signal d'alerteUne semaine de capture puis une règle par flux observé, ou une matrice demandée à l'équipe applicative et recopiée telle quelle sans la comparer aux flux réels.
Question 2 · confirmé
Quel modèle d'étiquettes proposez-vous pour un parc de deux mille serveurs, et d'où viennent les valeurs ?
Une bonne réponseQuelques dimensions stables, souvent rôle, application, environnement et localisation comme dans le modèle d'Illumio, avec des valeurs normalisées. Les valeurs viennent d'une source maintenue : la CMDB (ServiceNow par exemple), les tags cloud ou le provisionnement Terraform, synchronisés par API. Il désigne qui corrige une étiquette fausse et prévoit une étiquette d'attente pour les serveurs non qualifiés, parce qu'une étiquette erronée ouvre ou coupe des flux.
Signal d'alerteDes étiquettes saisies à la main serveur par serveur, ou une dizaine de dimensions dont personne ne tient les valeurs à jour.
Question 3 · senior
Vous passez une application du mode visibilité au blocage. Que vérifiez-vous avant, et comment revenez-vous en arrière ?
Une bonne réponseAvant : plus aucun flux non couvert sur une période représentative (les lignes rouges d'Illumination, les alertes des règles Guardicore), une simulation de la politique (Draft View chez Illumio), l'équipe applicative prévenue et disponible, une fenêtre hors clôture et la recette traitée avant la production. Pendant et après : tests fonctionnels et suivi des flux refusés. Le retour arrière consiste à repasser les étiquettes concernées en visibilité, ce qui prend quelques minutes, et il l'a préparé avant.
Signal d'alerteBascule un vendredi soir sur toute l'application, sans retour arrière prévu, ou « on attend que les utilisateurs appellent ».
Question 4 · confirmé
Comment Illumio ou Guardicore appliquent-ils concrètement une règle sur un serveur Linux ou Windows ?
Une bonne réponseLa politique est calculée par la console centrale (le PCE chez Illumio) à partir des étiquettes, puis l'agent la traduit dans le pare-feu de l'OS : iptables ou nftables sous Linux, Windows Filtering Platform sous Windows. L'agent remonte aussi les flux et le processus associé. Il en tire les conséquences : la règle tient sans console joignable, il faut surveiller qu'aucun autre outil ne réécrit le pare-feu local, et l'agent doit être protégé contre l'arrêt.
Signal d'alerte« L'agent inspecte tous les paquets comme un IPS », ou aucune idée de l'endroit où la règle est appliquée.
Question 5 · confirmé
Dans Kubernetes avec Cilium, que change la première CiliumNetworkPolicy qui sélectionne un pod ?
Une bonne réponseEn mode par défaut, un pod non sélectionné reste libre. Dès qu'une règle le sélectionne avec une section ingress, tout le trafic entrant non autorisé est refusé, et de même pour egress. Le piège classique : une règle egress qui oublie la résolution DNS vers kube-dns et casse l'application. Il connaît le mode always qui applique le refus à tous les pods, et utilise Hubble pour voir les flux refusés.
Signal d'alerte« Seul le flux décrit est bloqué », ou une règle egress posée sans penser au DNS.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur microsegmentation : les questions fréquentes
Quelle différence entre un ingénieur microsegmentation et un ingénieur firewall ?
L'ingénieur firewall filtre aux frontières : entre Internet et le datacenter, entre zones ou entre sites, sur des équipements comme Palo Alto ou Fortinet. L'ingénieur microsegmentation filtre au plus près des serveurs, à l'intérieur d'une même zone, avec des agents ou le pare-feu distribué de l'hyperviseur. Les bases sont communes (TCP/IP, logique de règles, gestion des changements). La microsegmentation demande en plus de lire les flux applicatifs et système, et de travailler avec chaque équipe applicative.
Quel profil convient si le candidat idéal n'existe pas ?
Deux origines fonctionnent bien. Un administrateur pare-feu habitué aux matrices de flux et aux changements encadrés, ou un ingénieur systèmes qui connaît les flux Active Directory, Windows et Linux. Le premier apprend vite l'outil, le second comprend vite ce que la carte montre. Un profil qui n'a jamais diagnostiqué un flux refusé en production ne convient pas, car le poste consiste surtout à bloquer sans casser.
Une expérience sur Illumio est-elle transférable à Guardicore ou NSX ?
Largement. Les trois outils reposent sur la même démarche : cartographier, étiqueter, écrire une liste d'autorisation, passer en blocage par étapes. Le vocabulaire, l'interface et l'endroit où la règle s'applique changent (agent sur l'OS ou hyperviseur). Le candidat décrit un passage en blocage qu'il a mené : s'il explique la méthode et le retour arrière, il prendra l'autre outil en main en quelques semaines.
Y a-t-il un test technique ?
Une lecture commentée pendant l'entretien suffit. Le support est une extraction de carte des flux d'une application de dix serveurs, avec des flux d'infrastructure, un flux suspect et un serveur sans agent ; la personne propose la politique et l'ordre de passage en blocage. En vingt minutes, on voit si la personne trie les flux, repère l'anomalie et prévoit un retour arrière.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
