AC23.01 | Concevoir et développer des applications communicantes
AC23.02 | Utiliser des serveurs et des services réseaux virtualisés
AC23.03 | Sécuriser les services et données d'un système
💡 Quelles ont été vos démarches, prises de décisions, degré d'implication et d'autonomie ?
Le projet réseau a été l'une des expériences les plus concrètes de l'année sur ce que signifie vraiment "sécuriser" un système. Avant ce projet, la sécurité restait pour moi quelque chose d'assez abstrait. J'avais entendu parler de pare-feux, de VLANs, d'IDS, mais sans jamais vraiment les configurer ni les tester.
Ce qui a changé ma vision, c'est la phase d'audit. Quand on a utilisé Nmap depuis l'extérieur du réseau qu'on venait de construire, et qu'on a vu notre propre infrastructure depuis l'œil d'un attaquant, ça donne une perspective très différente. On a découvert une vulnérabilité qu'on avait nous-mêmes créée : le port SSH de la machine IDS était accessible depuis Internet. Ce n'était pas une erreur théorique dans un devoir — c'était un vrai problème dans un vrai réseau. Et avec Metasploit, on a poussé l'analyse encore plus loin, en identifiant un algorithme cryptographique faible supporté par notre propre serveur SSH.
Ce projet m'a appris que la sécurité n'est pas un état qu'on atteint une fois pour toutes — c'est un processus d'amélioration continue. Construire l'infrastructure, l'auditer, trouver ses failles, les documenter et proposer des corrections : c'est ce cycle qui m'a vraiment formé.
Sur le stage, j'ai retrouvé cette logique dans la gestion de la sécurité de la base de données. Le mécanisme de Row Level Security de Supabase garantit que chaque utilisateur ne voit que les données correspondant à son rôle. Diagnostiquer des bugs "silencieux" — où un utilisateur ne pouvait rien lire sans qu'aucun message d'erreur n'apparaisse — m'a demandé de raisonner exactement comme lors de l'audit réseau : tester chaque couche méthodiquement pour trouver où ça bloque.
💡 Quelles ressources avez-vous choisies et combinées ?
Pour le projet réseau : documentation OpenWRT, Bind9, Suricata, et surtout les pages de man Linux. J'ai appris à lire une documentation technique dense et à en extraire l'essentiel, ce qui n'était pas forcément naturel pour moi au départ.
Pour le stage : la documentation Supabase sur les politiques RLS, et une méthode de diagnostic par simulation de rôle (me connecter à la base avec les identifiants de chaque profil d'utilisateur pour reproduire les bugs).
💡 En vous appuyant sur vos traces, justifiez la maîtrise des apprentissages visés
Le rapport technique du projet réseau documente l'ensemble de l'infrastructure déployée et des vulnérabilités identifiées, avec des recommandations correctives. Ce n'est pas un rapport "tout va bien" — on y assume ce qui ne fonctionnait pas parfaitement, ce qui me semble plus honnête et plus formateur.