⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Sécuriser le réseau d’une entreprise industrielle en partant de zéro

Premier vrai exercice de conception d’architecture réseau de ma formation OpenClassrooms. Pas un lab Proxmox où je casse des trucs dans mon coin, mais un scénario complet : un client fictif, des contraintes budgétaires, une baie de brassage qui n’a que 4U de libre, et 12 utilisateurs qui doivent continuer à bosser pendant qu’on sécurise tout.

Le scénario : Forges de l’Ouest, une PME de métallurgie à Angers, vient de se prendre une cyberattaque. Leur bureau d’études tourne sur un réseau plat, des Windows Server 2012 R2 en fin de support, du LDAP en clair, des comptes partagés. J’interviens en tant qu’ingénieur cybersécurité externe pour concevoir la nouvelle architecture et planifier le déploiement. Trois livrables à produire, puis une soutenance orale de 30 minutes.

Les configs détaillées et la documentation technique sont sur le repo GitHub du projet.

Ce que j’ai trouvé en arrivant

J’ai commencé par disséquer l’infrastructure existante en la croisant avec les recommandations ANSSI. Résultat : 10 failles, dont 4 critiques.

La plus évidente, c’est le réseau plat. Tout le monde sur le même 192.168.100.0/24, sans aucune segmentation. Un poste de l’atelier compromis et l’attaquant peut se balader librement vers les serveurs, la direction, la téléphonie. La plus dangereuse, c’est l’authentification LDAP en clair sur le port 389. Une simple capture réseau suffisait pour récupérer l’ensemble des mots de passe.

En fouillant l’inventaire des applications métier et les comptes AD, j’ai aussi trouvé deux collaborateurs absents de l’organigramme qui avaient encore des comptes actifs. Ce genre de détail, un attaquant le repère tout de suite.

Trouver les bonnes références ANSSI pour chaque mesure m’a pris plus de temps que prévu. Le guide fait 65 pages de recommandations et toutes ne s’appliquent pas au contexte d’un bureau d’études de 12 personnes. Il faut savoir faire le tri entre ce qui est pertinent et ce qui relève d’un SI à 500 utilisateurs.

Pourquoi FortiGate et pas pfSense

Le choix du pare-feu a été le premier arbitrage. J’utilise pfSense dans mon homelab, je le connais bien, et j’aurais pu bâtir toute l’architecture dessus. Mais dans le contexte d’une entreprise industrielle qui manipule des plans techniques et des données de production sensibles, le FortiGate 60F s’imposait pour d’autres raisons : le support constructeur, les signatures IPS/IDS mises à jour automatiquement, et surtout la certification ANSSI (CSPN). Ça apporte de la cohérence au projet puisque toute l’architecture suit les recommandations de la même autorité.

Un point que j’ai appris en cours de route : sans la licence FortiGuard UTP, le FortiGate n’est qu’un pare-feu stateful basique. C’est la licence qui active l’IPS/IDS temps réel, l’antivirus réseau, le filtrage web et le contrôle applicatif. La licence coûte 1 500 euros sur trois ans, soit presque autant que le boîtier lui-même. En contexte industriel, c’est justifié. Mais c’est le genre de chose qu’on oublie facilement quand on chiffre un projet.

Le reste de la stack est en open source : Apache Guacamole pour le bastion d’administration (rupture protocolaire exigée par l’ANSSI), Nginx en reverse proxy dans la DMZ, Rsyslog pour la journalisation centralisée. C’est ce qui m’a permis de rester dans le budget.

Segmenter en 7 VLANs avec 10 000 euros

L’idée centrale du projet, c’est la segmentation. On passe d’un réseau plat à 7 VLANs isolés plus une DMZ, avec le FortiGate qui contrôle chaque flux entre les zones.

Chaque pôle métier (Direction, Production, Études, Technique) a son propre VLAN. Les serveurs sont isolés dans un VLAN dédié, la téléphonie IP est séparée, et l’administration passe obligatoirement par un bastion dans un VLAN sans accès Internet. L’idée, c’est que si un poste de l’atelier est compromis, l’attaquant ne peut pas pivoter directement vers les serveurs via SSH ou RDP. Il doit passer par le bastion, qui enregistre tout.

Dans une PME, on ferait pareil. Séparer la comptabilité de la production, isoler les serveurs des postes utilisateurs, forcer l’administration à passer par un point de contrôle unique. Le nombre de VLANs change, pas la logique.

Le budget de 10 000 euros HT obligeait à faire des choix. J’ai opté pour un serveur reconditionné (Xeon, 64 Go de RAM) qui héberge les 4 VMs nécessaires, ce qui économise environ 1 500 euros par rapport au neuf. L’extension de garantie 3 ans compense le risque. Pour le stockage, un NAS 2 baies en RAID 1 plutôt qu’une VM de backup sur le même hyperviseur. Mon mentor m’a fait réaliser que c’était un point de défaillance unique : si l’hyperviseur tombe ou est compromis par un ransomware, la sauvegarde tombe avec. Leçon retenue.

Budget final : 8 610 euros HT, soit 86% de l’enveloppe. 14% de marge pour les imprévus, ce qui est conforme aux bonnes pratiques de gestion de projet IT.

Le placement du serveur de logs

Le choix le plus discuté a été le placement du serveur Rsyslog. La recommandation ANSSI R67 parle de journalisation centralisée, mais ne prescrit pas où placer le serveur. Deux options : en DMZ, plus proche des flux à surveiller, ou en VLAN serveurs, moins exposé.

J’ai choisi le VLAN 50 (serveurs). Le serveur de logs contient des informations sensibles sur l’ensemble du SI. Le placer en DMZ, c’est l’exposer à la zone la plus vulnérable du réseau. Les logs remontent au serveur via le FortiGate qui filtre les flux. C’est un choix que j’ai dû défendre à la soutenance, et l’évaluateur a validé le raisonnement.

La cartographie comme source de vérité

La cartographie réseau sous draw.io a été le livrable le plus chronophage. Pas à cause de la complexité technique, mais parce que chaque modification devait se propager dans les deux autres documents (plan projet et documentation).

J’ai appris ça à mes dépens. J’ai changé le placement du serveur de logs dans la cartographie sans mettre à jour le plan projet, et l’incohérence m’a sauté aux yeux pendant la relecture croisée. Plus tard, j’ai aussi refait le devis parce que j’avais commencé à chercher du matériel avant d’avoir finalisé l’architecture. Quand j’ai changé la topologie, le devis ne correspondait plus.

Désormais, mon principe est simple : la cartographie est la source de vérité. On modifie là-bas, et on propage partout ensuite. C’est un réflexe qui vient du monde de la data. Quand on gère des flux ETL, on ne modifie pas le rapport sans mettre à jour la source. C’est pareil ici.

La documentation L3 a été scindée en deux parties : un guide utilisateur (ce qui change au quotidien pour les 12 collaborateurs) et un guide administrateur (procédures de maintenance, accès bastion, politique de sauvegarde). Le point clé du guide utilisateur : expliquer aux techniciens pourquoi ils ne peuvent plus accéder directement aux serveurs depuis leur poste. Le bastion ajoute une étape, mais c’est cette étape qui empêche un attaquant ayant compromis un poste de pivoter vers les serveurs.

La suite

J’ai l’intention de reproduire cette architecture dans mon homelab Proxmox. Concrètement :

• Déployer la segmentation VLAN via Proxmox SDN avec pfSense comme firewall (dans le homelab, pas besoin de certification ANSSI)
• Monter un bastion Apache Guacamole pour sécuriser l’accès à mes VMs
• Intégrer Rsyslog et Wazuh pour aller plus loin que la simple centralisation de logs
• Tester la politique de sauvegarde 3-2-1 avec mon NAS Synology

L’idée, c’est que chaque projet de formation devienne un projet homelab concret. La théorie c’est bien, mais c’est en cassant des trucs en lab qu’on apprend.

Ce que j’en retiens

Ce projet m’a appris que la conception coûte plus cher en temps que l’implémentation. Pas en heures de travail brutes, mais en aller-retours. Chaque décision technique tire un fil qui touche le budget, le planning, la documentation. Et quand on modifie un choix en cours de route, tout le reste bouge.

L’autre leçon, c’est que la sécurité physique est la première couche de défense en profondeur. C’est un angle mort fréquent dans les projets étudiants. Mon mentor me l’a rappelé, et les échanges sur Discord avec d’autres étudiants ayant déjà passé la soutenance m’ont confirmé que les évaluateurs posent systématiquement la question. J’ai intégré un kit complet (badge RFID, caméra IP, sonde environnementale) dans le budget pour cette raison.

Je ne suis pas encore sûr d’avoir fait le meilleur choix sur tous les points. Le placement de Rsyslog en VLAN serveurs plutôt qu’en DMZ se défend, mais l’argument inverse n’est pas absurde non plus. Ce qui compte, c’est d’avoir un raisonnement documenté derrière chaque décision. C’est ça que l’évaluateur cherche, et c’est ça qu’un employeur attend aussi.

Code source et documentation technique : Repo GitHub du projet P10

Ressources : ANSSI - Recommandations administration sécurisée des SI | Documentation Fortinet | Apache Guacamole