Bilan de stage

Le stage est fini. Les huit billets précédents racontent déjà ce que j'ai fait, alors je voudrais plutôt faire le point sur ce qui a changé dans ma façon de bosser.

Le décalage du départ

J'arrivais avec trois ans de homelab derrière moi. Proxmox, OPNsense, une quinzaine de conteneurs, un VPN mesh. Je me pensais à l'aise sur l'infrastructure, et sur les outils, je l'étais vraiment.

Ce que le stage m'a montré, c'est que je confondais deux compétences : faire fonctionner un système, et défendre un système. Je n'avais que la première.

Trois exemples précis de ce décalage :

• Je montais des conteneurs avec le socket Docker en accès complet parce que la doc officielle le faisait, sans voir que c'était une escalade de privilèges vers l'hôte.
• Mes règles de pare-feu étaient un empilement historique, sans aucun document expliquant pourquoi elles existaient.
• Je ne regardais mes journaux que quand quelque chose cassait. Du point de vue de la sécurité, ça revient à ne jamais les regarder.

Aucune de ces trois lacunes n'était un manque de connaissance technique. C'étaient des manques de méthode, et je ne pouvais pas les voir tout seul.

Ce que j'ai acquis

Documenter avant de construire. C'est l'apprentissage le plus transférable, et le moins technique. La matrice de flux écrite avant la première règle a servi trois fois : à configurer, à déboguer, puis à valider en fin de mission. Sans elle, la phase de tests n'aurait produit qu'une liste de ports sans signification.

Je suis capable de formaliser une politique de flux réseau avant sa mise en œuvre, et de m'en servir comme référence pour vérifier ce qui a été déployé.

Raisonner en modèle de menace. Avant, j'évaluais une config à sa capacité à fonctionner. Maintenant je me demande systématiquement : si un attaquant contrôlait ce composant, il obtiendrait quoi ? C'est cette question qui m'a fait voir le problème du socket Docker, celui du résolveur DNS ouvert, et l'intérêt de chiffrer les flux internes.

Je suis capable d'évaluer l'impact de la compromission d'un composant sur le reste d'une infra, et d'en tirer des mesures de cloisonnement.

Écrire de la détection qui sert à quelque chose. Mes premières règles Wazuh crachaient des centaines d'alertes inutiles. Reformuler la question a divisé le volume par cent et rendu chaque alerte exploitable.

Je suis capable de définir des règles de détection à partir des hypothèses de sécurité d'une infra, et d'évaluer leur pertinence au regard du bruit qu'elles génèrent.

Le lien avec la formation

Le Bachelor m'avait donné les briques : réseau, crypto, systèmes, bases du pentest. Je savais expliquer 802.1Q, dessiner une chaîne de certification, décrire une attaque par force brute.

Ce que le stage a apporté, c'est l'ordre dans lequel ces briques se posent, et ce qui les relie.

L'exemple qui résume tout : le cours de crypto m'avait appris à quoi sert une PKI et comment fonctionne une chaîne de signature. Le stage m'a appris que le plus dur, dans une PKI, n'est pas cryptographique. C'est de distribuer le certificat racine sur des dizaines de systèmes qui gèrent chacun leur magasin de confiance à leur manière.

La théorie décrit le mécanisme. La pratique révèle où se trouve la difficulté, et ce n'est presque jamais au même endroit.

Autre apport, auquel je ne m'attendais pas : le travail à trois. Sur mon homelab je suis seul, je peux tout changer, je n'ai de comptes à rendre à personne. À trois sur une infra partagée, une règle modifiée sans prévenir casse le travail des autres.

Ce que je referais autrement

Automatiser dès le départ. J'ai tout configuré à la main, puis découvert Ansible en fin de mission. Résultat : mes machines ne sont pas exactement identiques, et je ne peux pas prouver qu'elles le sont. Une infra reproductible est aussi une infra auditable.

Tester au fur et à mesure. On a validé la segmentation à la fin. Les deux écarts trouvés existaient depuis des semaines. Un scan de contrôle après chaque déploiement les aurait révélés tout de suite, quand le contexte était encore frais dans la tête.

Relire les fichiers qu'on reprend. L'interface d'administration exposée par défaut est passée parce qu'on avait intégré un docker-compose.yml sans le lire ligne à ligne.

Trois propositions

Si je reprenais la mission demain, voilà ce que je proposerais en priorité.

1. Un scan de conformité automatisé après chaque déploiement. Un script qui rejoue la matrice de flux depuis chaque VLAN et signale tout écart, lancé automatiquement plutôt qu'une fois en fin de projet. Peu coûteux à mettre en place, et ça transforme un contrôle ponctuel en garde-fou permanent.

2. La configuration décrite en code. Reprendre les configs manuelles sous forme de rôles Ansible versionnés. Trois bénéfices : reconstruire une machine à l'identique, tracer chaque changement dans l'historique Git, et rendre possible une revue par un pair avant application.

3. Une revue systématique des briques tierces. Étendre les scans Trivy à un contrôle du fichier de composition lui-même : ports publiés, volumes montés, privilèges demandés. Les deux problèmes les plus sérieux qu'on ait rencontrés ne venaient pas d'une faille logicielle, mais d'une valeur par défaut que personne n'avait remise en question.

Ressenti

J'ai découvert que ce qui me plaît là-dedans, c'est moins de construire que de comprendre comment ça casse. La phase de validation, où on retourne l'infrastructure contre elle-même, est celle que j'ai préférée. C'est aussi celle qui m'a fait le plus douter de ce que j'avais construit, ce qui est probablement bon signe.

Le distanciel a demandé une rigueur particulière. Sans collègue à côté, on ne débloque pas une situation en se tournant vers son voisin. Il faut formuler son problème par écrit, ce qui oblige à le cerner, et règle souvent la question avant même de l'avoir posée.

Point d'amélioration honnête : j'ai encore tendance à vouloir tout faire moi-même avant de demander de l'aide. Ça m'a coûté du temps la première semaine, et je n'ai pas complètement corrigé le réflexe.

Je termine avec une idée nettement plus claire de ce que je veux faire : rester sur l'infrastructure, mais du côté de ceux qui la défendent et qui vérifient qu'elle tient. C'est dans cette direction que je cherche mon alternance de troisième année.