Configurer un environnement de TP cybersécurité sécurisé : segmentation, comptes et supervision

Pourquoi sécuriser l'environnement de TP avant de penser aux exercices

La tentation est grande de préparer d'abord les scénarios d'attaque, les machines cibles et les outils, puis de s'occuper de la sécurité de l'environnement « plus tard ». C'est pourtant l'ordre inverse qu'il faut adopter. Un lab de cybersécurité mal configuré ne constitue pas seulement un risque pour l'établissement — il prive les apprenants d'un apprentissage fondamental : voir comment un environnement professionnel doit être construit avant d'être mis à l'épreuve.

La sécurité réseau commence par la maîtrise du périmètre. Un TP de pentest génère du trafic que les sondes d'un réseau scolaire peuvent interpréter comme une attaque réelle. Un exercice d'analyse de malware produit des artefacts susceptibles de s'échapper d'une VM mal isolée. Sans parler des erreurs de manipulation : une règle de routage oubliée, un pont réseau laissé ouvert par inadvertance, et un étudiant peut accéder à un segment auquel il n'a pas accès, voire générer du trafic vers l'extérieur.

L'ANSSI, dans ses guides de bonnes pratiques pour la sécurisation des systèmes d'information, insiste sur le principe de défense en profondeur : ne pas compter sur une seule mesure de protection, mais superposer des contrôles indépendants. Ce principe s'applique intégralement à un lab pédagogique. Isoler le réseau, cloisonner les comptes, activer la journalisation et prévoir un plan de réponse : chacune de ces couches est indépendante, et chacune réduit l'impact d'une défaillance des autres.

Configurer l'environnement avant les exercices, c'est aussi un geste pédagogique. Les apprenants voient concrètement qu'une architecture sécurisée ne s'improvise pas ; elle se conçoit, se documente et se valide. Cette démarche est précisément ce qu'un architecte sécurité réalise en entreprise, et y exposer les étudiants dès le lab est une plus-value indéniable.

Modèle de zones : étudiants, cibles, admin et DMZ pédagogique

La segmentation réseau est la mesure la plus structurante d'un lab sécurisé. L'objectif est de créer des zones d'isolation stricte, communicant entre elles uniquement selon des règles explicitement définies. Sur un hyperviseur comme Proxmox VE ou VMware ESXi, cela se traduit par des commutateurs virtuels (vSwitch) distincts pour chaque zone. Sous OpenVSwitch, vous disposerez d'un contrôle encore plus fin grâce aux VLAN 802.1Q et aux règles de flux.

Un modèle adapté à un lab de 15 à 25 étudiants comprend quatre zones :

Le pare-feu pfSense ou son successeur OPNsense s'impose ici comme pivot central. Il matérialise les règles entre zones, journalise chaque connexion inter-segments et offre une interface graphique que les étudiants eux-mêmes peuvent étudier dans le cadre d'un TP dédié à la blue team. La configuration du pare-feu devient ainsi un artefact pédagogique à part entière.

Un point souvent négligé : le chemin de gestion. L'accès à la console de l'hyperviseur (interface Proxmox, vSphere Client) doit transiter par un réseau d'administration entièrement séparé — idéalement un VLAN dédié, accessible uniquement depuis la machine physique de l'instructeur ou un poste bastion. Mélanger le trafic de gestion avec le trafic étudiant est une erreur de conception que les professionnels évitent systématiquement ; le lab est le bon endroit pour le montrer en acte.

Enfin, n'exposez jamais les machines cibles directement sur le réseau de l'établissement. Même dans un scénario de TP « sans danger », une machine Metasploitable accessible sur le LAN scolaire est une vulnérabilité que n'importe quelle personne connectée au Wi-Fi de l'école pourrait exploiter.

Gestion des comptes, des mots de passe et des rotations

La gestion des identités est souvent le parent pauvre de la préparation d'un lab pédagogique. On crée un compte admin commun, on communique le mot de passe à toute la promo, et on se retrouve sans aucune traçabilité en cas d'incident. Ce schéma, outre le risque de sécurité évident, supprime toute possibilité d'analyse forensique post-incident — ce qui est précisément ce que l'on souhaite enseigner.

La règle de base est simple : un compte par personne, un rôle par compte. Pour un lab de 20 étudiants, cela implique de provisionner :

• 20 comptes étudiants — droits limités à leur propre VM et à la zone cibles. Aucun droit d'administration sur l'hyperviseur. Aucun accès à la zone admin.
• 1 à 2 comptes instructeur — droits étendus sur l'hyperviseur (création de VM, gestion des snapshots), accès à la supervision. Pas de droits root sur les machines cibles en conditions normales.
• 1 compte service — utilisé par les scripts d'automatisation (snapshots nocturnes, sauvegardes). Droits minimaux, mot de passe long généré aléatoirement, jamais utilisé en interactif.
• 1 compte admin d'urgence — accès uniquement depuis la console physique ou le bastion dédié. Mot de passe stocké dans une enveloppe physique scellée ou un gestionnaire de mots de passe hors ligne (KeePassXC, par exemple). Ce compte ne doit jamais être utilisé en routine.

Pour les mots de passe, les recommandations ANSSI sont claires : longueur minimale de 12 caractères, complexité suffisante, absence de réutilisation entre les environnements. Dans un cadre pédagogique, une excellente habitude consiste à générer les mots de passe initiaux via un outil comme pwgen ou apg, à les transmettre de manière sécurisée (pas par email en clair), et à forcer leur changement à la première connexion.

La rotation des comptes doit être planifiée à minima en fin de semestre. Révoquer les accès des étudiants diplômés, changer les mots de passe des comptes de service, et auditer les comptes dormants sont des gestes d'hygiène que le lab enseigne autant qu'il les pratique. Sur Proxmox, l'intégration avec un annuaire LDAP ou Active Directory simplifie la gestion centralisée des identités et la revue périodique des droits.

Un dernier point : évitez l'escalade de privilèges silencieuse. Configurez sudo sur les VMs Linux de manière à journaliser chaque commande exécutée avec des droits élevés. Les logs sudo constituent un excellent support pédagogique pour discuter de la traçabilité des actions d'administration.

Journaux, alertes minimales et supervision légère à valeur pédagogique

La supervision d'un lab pédagogique sert deux objectifs distincts : détecter les anomalies en temps réel pour maintenir la sécurité de l'environnement, et constituer un corpus de logs que les étudiants pourront analyser lors des TP de blue team. Ces deux objectifs sont complémentaires, et une architecture de supervision bien pensée les sert simultanément.

Wazuh s'impose comme le SIEM open source de référence pour ce type d'usage. Déployé sur un nœud dédié dans la zone admin, il collecte les événements de sécurité des VMs (tentatives de connexion, modifications de fichiers sensibles, commandes sudo, alertes de l'agent hôte), les normalise et les corrèle. Kibana, couplé à la stack Elastic, offre les tableaux de bord nécessaires pour visualiser le trafic et les alertes — et constitue lui-même un excellent support de TP pour les exercices d'analyse de logs.

La collecte de logs doit couvrir a minima :

• Les connexions et déconnexions sur toutes les VMs (logs d'authentification)
• Le trafic inter-zones journalisé par pfSense (règles avec logging activé)
• Les commandes exécutées avec sudo ou en tant que root
• Les modifications de configuration de l'hyperviseur (audit log Proxmox ou vSphere)
• Les alertes de l'antivirus/EDR si des VMs Windows sont présentes dans le lab

Pour les alertes, restez pragmatique. Un lab pédagogique ne dispose pas d'un SOC pour traiter des centaines d'alertes par heure. Configurez Wazuh pour n'émettre des notifications actives que sur les événements à fort impact : connexion en dehors des heures de TP, accès à la zone admin depuis un compte étudiant, flux réseau sortant depuis la zone cibles. Le reste peut être consulté à la demande dans Kibana.

La valeur pédagogique de cette supervision est directe : après chaque session de TP, projeter les logs agrégés et discuter des événements observés transforme le débrief en exercice d'analyse forensique. Les étudiants voient leurs propres actions reflétées dans les journaux — et comprennent immédiatement pourquoi la journalisation exhaustive est une exigence non négociable dans un environnement de production.

Check-list avant chaque session de TP

Une check-list n'est pas un signe de méfiance envers les apprenants : c'est un instrument de rigueur professionnelle. Dans l'aviation, dans le nucléaire, dans la gestion des incidents de sécurité, les check-lists existent précisément parce que l'expertise ne protège pas contre l'oubli. Enseigner cette discipline aux futurs professionnels de la cybersécurité est en soi un objectif pédagogique.

Cette check-list est un point de départ à adapter à votre infrastructure. Sur Proxmox, la restauration des snapshots peut être automatisée via l'API REST et un script déclenché avant chaque session. Sur VMware, les linked clones permettent de recréer l'état initial en quelques secondes. Quoi qu'il en soit, la restauration systématique des cibles est non négociable : un lab dont les machines cibles conservent les traces des TP précédents fausse les exercices et peut introduire des vecteurs d'attaque non prévus.

Plan de réponse si un TP sort du périmètre

Même avec une configuration rigoureuse, des incidents surviennent. Un étudiant découvre une règle de routage résiduelle et accède à un segment interdit. Une VM mal configurée établit une connexion vers un service externe. Un payload d'exploitation dépasse la machine cible et atteint le réseau de l'hyperviseur. Ces événements ne sont pas des catastrophes — à condition d'avoir préparé la réponse à l'avance.

Le plan de réponse d'un lab pédagogique doit couvrir quatre étapes :

1. Détection et confirmation. Wazuh génère une alerte. L'instructeur consulte les logs pfSense pour confirmer la nature du flux anormal. Ne pas agir sur une fausse alerte, mais ne pas ignorer non plus une alerte réelle par excès de confiance dans le confinement.

2. Confinement immédiat. Sur Proxmox ou via OpenVSwitch, déconnecter instantanément la VM concernée de son réseau virtuel. Cette opération prend moins de dix secondes et isole le problème sans éteindre la VM, préservant ainsi son état pour l'analyse forensique. Sur VMware, la même opération s'effectue depuis vSphere Client en retirant la carte réseau virtuelle de son port group.

3. Notification et documentation. Informer le RSSI de l'établissement de l'incident, même si l'impact semble limité. Documenter l'heure, la VM impliquée, la nature du trafic détecté, les actions prises. Un registre d'incidents, aussi simple soit-il, est une exigence de bonne pratique que les apprenants doivent voir appliquée.

4. Débrief pédagogique. Transformer l'incident en cas d'étude. Pourquoi la sortie de périmètre s'est-elle produite ? Quelle règle manquait ? Comment le même scénario serait-il géré dans un SOC d'entreprise ? Ce débrief est souvent la séquence pédagogique la plus dense de toute la session — un « bug » bien géré vaut parfois mieux qu'un TP parfaitement déroulé.

Préparez ce plan par écrit avant le premier TP, partagez-le avec les co-formateurs ou les responsables pédagogiques, et gardez-en une copie accessible hors du réseau du lab (un fichier PDF sur un poste non connecté, ou imprimé). En situation de stress, un plan écrit évite les oublis qui transforment un incident mineur en problème majeur.

Ce qu'il faut retenir

Configurer un environnement de TP cybersécurité sécurisé n'est pas une formalité administrative : c'est un acte pédagogique en soi, qui modélise les pratiques professionnelles que vous souhaitez transmettre. Voici les points essentiels à garder en tête :

• La segmentation réseau précède tout exercice. Quatre zones distinctes — étudiants, cibles, admin, DMZ pédagogique — reliées par un pare-feu pfSense ou OPNsense constituent la colonne vertébrale d'un lab sûr. Sans cette séparation, chaque TP est un risque pour le réseau de l'établissement.

• Un compte par personne, un rôle par compte. Les comptes partagés suppriment la traçabilité et empêchent toute analyse forensique post-incident. Provisionner des identités individuelles avec des droits minimaux est une mesure d'hygiène fondamentale, recommandée par l'ANSSI et applicable quel que soit le budget.

• La supervision a une double valeur. Wazuh et Kibana ne servent pas uniquement à détecter les anomalies en temps réel : les logs collectés pendant le TP deviennent le matériau des débriefs d'analyse. Activez la journalisation dès le premier jour, pas après le premier incident.

• La check-list protège autant qu'elle enseigne. Vérifier l'isolation réseau, restaurer les snapshots et contrôler les comptes avant chaque session prend moins de quinze minutes. Cette rigueur, pratiquée en public devant les apprenants, transmet une norme professionnelle que les cours magistraux n'atteignent pas.

• Tout incident est une ressource pédagogique. Un étudiant qui sort accidentellement du périmètre fournit un cas réel de réponse à incident. Ne cherchez pas à dissimuler l'événement — documentez-le, analysez-le et faites-en le coeur du débrief suivant.

• La sécurité de l'environnement doit être revue à chaque fin de semestre. Rotation des mots de passe, révocation des comptes des anciens apprenants, audit des règles de filtrage : un lab non maintenu se dégrade rapidement et finit par devenir lui-même une vulnérabilité pour l'établissement.

Vous souhaitez aller plus loin et faire intervenir un formateur expérimenté pour concevoir ou auditer votre environnement de lab ? Rendez-vous sur cyberteachers.org pour trouver des experts en labs cybersécurité capables de vous accompagner de la conception de l'architecture jusqu'à l'animation des premières sessions de TP. Que vous débutiez avec VirtualBox sur les postes étudiants ou que vous administriez un cluster Proxmox mutualisé, un formateur spécialisé vous aidera à sécuriser votre environnement et à en faire un véritable outil d'apprentissage.