3S Sécurité - Chenôve (21)

# Rapport de stage — Groupe-3 (3S Sécurité) **Esteban MOUSSU** *BTS Services Informatiques aux Organisations, option SISR (Solutions d'Infrastructure, Systèmes et Réseaux) — 1ère année* *Lycée Le Castel, Dijon (21)* Professeur responsable : M. DUPUY Professeur de SISR : M. SÈVRE Période de stage : du 1er juin au 3 juillet 2026 Entreprise d'accueil : 3R Groupe — service 3S Sécurité Tuteur en entreprise : M. CLERGET --- ## Sommaire 1. [Remerciements](#remerciements) 2. [Introduction](#introduction) 3. [Présentation de l'entreprise d'accueil](#présentation-de-lentreprise-daccueil) 4. [Le poste et les missions qui m'ont été confiées](#le-poste-et-les-missions-qui-mont-été-confiées) 5. [Découverte des outils de supervision et de sécurité](#1-découverte-des-outils-de-supervision-et-de-sécurité) 6. [Exploitation et maintenance de l'infrastructure](#2-exploitation-et-maintenance-de-linfrastructure) 7. [Virtualisation et administration système](#3-virtualisation-et-administration-système) 8. [Sécurisation et durcissement des systèmes](#4-sécurisation-et-durcissement-des-systèmes-hardening) 9. [Automatisation avec Ansible](#5-automatisation-avec-ansible) 10. [Détection et prévention d'intrusion](#6-détection-et-prévention-dintrusion) 11. [Conteneurisation avec Podman](#7-conteneurisation-avec-podman) 12. [Mission principale : trouver un outil de sauvegarde de bases de données](#8-mission-principale--trouver-un-outil-de-sauvegarde-de-bases-de-données) 13. [Difficultés rencontrées et comment je les ai réglées](#difficultés-rencontrées-et-comment-je-les-ai-réglées) 14. [Ce que le stage m'a apporté](#ce-que-le-stage-ma-apporté) 15. [Conclusion](#conclusion) 16. [Annexe : glossaire des outils et technologies rencontrés](#annexe--glossaire-des-outils-et-technologies-rencontrés) --- ## Remerciements Je remercie toute l'équipe de Groupe-3 de m'avoir accueilli, et en premier lieu Sébastien, mon tuteur, qui a pris le temps de m'expliquer les choses et qui m'a confié de vraies missions plutôt que de me laisser regarder par-dessus l'épaule. Merci aussi à Vincent, avec qui j'ai passé pas mal de journées, et à Lucas, l'alternant développeur, toujours dispo pour répondre à mes questions. Enfin, merci à mes professeurs, M. DUPUY et M. SÈVRE, pour leur suivi pendant cette période. --- ## Introduction J'ai effectué mon stage de première année de BTS SISR chez Groupe-3, dans l'entité 3S Sécurité, du 1er juin au 3 juillet 2026. Cinq semaines, donc, dans un service qui s'occupe d'infrastructure et de sécurité informatique. Il y a un point que je trouve important de préciser : l'entreprise a l'habitude de prendre des stagiaires, mais jamais encore de première année de BTS. En général ce sont des deuxième année, voire des étudiants d'un niveau plus élevé. J'étais donc le premier de ce niveau, et forcément ça m'a poussé à en faire un peu plus pour être à la hauteur de la confiance qu'on me faisait. Pendant ces cinq semaines, j'ai appris beaucoup de choses : la supervision d'un parc, la gestion de pare-feux, la virtualisation, le durcissement de systèmes, l'automatisation, et pour finir la gestion de bases de données. Les missions ont pris de plus en plus d'ampleur au fil du stage. J'ai commencé en observant et en assistant le stagiaire de mon tuteur, et j'ai terminé en menant un projet complet tout seul, du cahier des charges jusqu'à la présentation devant mon tuteur. J'ai choisi de ne pas raconter ce rapport jour par jour, comme je l'avais fait dans mon compte rendu quotidien, mais plutôt de le regrouper par thèmes. Je trouve que c'est plus clair pour montrer ce que j'ai appris que de suivre l'ordre du calendrier. --- ## Présentation de l'entreprise d'accueil Groupe-3 réunit trois entreprises qui se complètent. 3R Réseau s'occupe de tout ce qui touche à l'infrastructure réseau, au câblage et à la fibre optique. 3S Sécurité, l'entité qui m'a accueilli, est spécialisée dans la sécurité informatique, la vidéosurveillance et les réseaux Wifi. Enfin, il y a Trois Nuages, la troisième structure du groupe. Concrètement, le groupe couvre toute la chaîne chez ses clients, du câble physique jusqu'à la sécurité informatique, en passant par le réseau et la vidéosurveillance. Moi, j'étais côté 3S Sécurité, dans l'équipe technique qui supervise, exploite et sécurise le parc informatique de plusieurs clients. --- ## Le poste et les missions qui m'ont été confiées Sébastien était mon tuteur, et j'ai surtout travaillé avec lui, avec Vincent (stagiaire) et avec Lucas (alternant développeur). Si je devais résumer mon stage, je dirais qu'il s'est joué sur trois plans. D'abord, il a fallu que je me familiarise avec les outils et l'infrastructure de la boîte : les solutions de supervision, de sécurité, de virtualisation, celles qui tournent vraiment en production. Ensuite, j'ai participé à l'exploitation de tous les jours (suivi de la supervision, mises à jour de pare-feux, diagnostic matériel, installation de VM). Et enfin, à partir de la mi-juin, on m'a confié un projet à mener seul : chercher, tester et comparer des outils de sauvegarde de bases de données, avec à la clé une preuve de concept et une présentation à l'équipe. --- ## 1. Découverte des outils de supervision et de sécurité La première semaine a surtout servi à me faire découvrir tout l'arsenal que 3S Sécurité utilise pour surveiller et protéger les infrastructures de ses clients. Il y en avait pas mal, et je n'en connaissais quasiment aucun avant d'arriver. **Cisco Umbrella**, c'est un service DNS qui bloque l'accès aux sites malveillants et qui permet aussi de filtrer les mails dangereux. **Cisco Meraki** sert à piloter tout un réseau depuis une seule interface web. **StormShield**, c'est un pare-feu français qui filtre le trafic et sécurise l'infrastructure des clients ; l'entreprise s'en sert d'ailleurs à la place de VMware, devenu payant, pour la virtualisation (j'y reviens en partie 3). Il y a aussi **TrendMicro**, qui analyse les logs des postes et des serveurs et qui peut carrément isoler une machine compromise : c'est ce qu'on appelle une solution XDR. **Ogo** est un pare-feu applicatif (un WAF) qui protège les sites web et les API contre les attaques. Enfin, **DNS Scanner** est un outil développé en interne par 3S Supervision : il cherche des noms de domaine qui ressemblent à un domaine cible (par exemple une variante avec une faute de frappe) pour repérer les tentatives d'usurpation d'identité. À côté de ça, j'ai découvert toute la chaîne d'observabilité de l'entreprise, organisée autour de **Grafana**, qui affiche les tableaux de bord. Les métriques remontent via **Prometheus** et via **Telegraf**, un agent installé chez les clients. Les logs, eux, partent en **Syslog**, sont regroupés par **Loki**, puis affichés dans Grafana. Et **InfluxDB** stocke les séries temporelles. Pour que ce soit plus parlant : les clients envoient leurs logs en Syslog, Loki les centralise, Grafana les affiche. En parallèle, Telegraf et Prometheus fournissent les métriques à Grafana, et InfluxDB s'occupe du stockage. Une fois qu'on a le schéma en tête, ça se tient bien. --- ## 2. Exploitation et maintenance de l'infrastructure Les premiers jours, j'ai beaucoup suivi Sébastien et Vincent dans leur travail quotidien. C'est ce qui m'a le mieux fait comprendre à quoi ressemble vraiment la routine d'un service d'infra, loin de la théorie vue en cours. Il y a d'abord la routine de supervision, que Vincent fait trois fois par jour (matin, midi et soir) : on vérifie les syslogs des clients et les métriques dans Grafana, on s'assure que les sauvegardes se sont bien passées (sur les NAS Synology et via Acronis), et on regarde les boîtes mails, la perso comme celle du support, pour répondre aux tickets. On a aussi eu à mettre à jour des pare-feux StormShield en cluster chez un gros client qui a plusieurs sites en France. Le principe : on sauvegarde la config du pare-feu actif, puis on inverse les rôles entre les deux pare-feux pour faire la mise à jour sur l'autre. Sauf que ça ne s'est pas passé comme prévu. Un des deux pare-feux n'a pas voulu redémarrer après la bascule, sans qu'on comprenne bien pourquoi, et il a fallu une intervention physique. On a dû reporter la fin de l'opération au lendemain. Ça m'a montré qu'en exploitation, même une manip censée être carrée peut coincer. J'ai aussi ajouté un widget de température dans le tableau de bord Grafana, pour surveiller les serveurs Proxmox de l'entreprise, et j'ai vérifié le lendemain que la donnée avait bien été collectée pendant la nuit. C'était le cas. Un autre jour, on a diagnostiqué un serveur HP ProLiant DL360 Gen10 qui perdait de la RAM : 32 Go n'étaient plus détectés. Le System Fast Test dans le BIOS, puis un coup d'œil à l'iLO, ont pointé un souci de carte mère au niveau d'un slot. Pour être sûr, on a inversé les barrettes afin de voir si le problème venait du slot ou de la barrette. Le slot restait défectueux. Du coup, pour limiter les risques, on a enlevé 16 Go de chaque côté pour décaler la barrette de 32 Go et éviter le slot en question. Enfin, Sébastien en a profité pour me rappeler la différence entre un reverse proxy et un proxy direct. Le reverse proxy se place devant les serveurs : dans le cas d'un serveur web, le client ne parle pas directement au serveur mais au reverse proxy, ce qui permet de répartir la charge, d'ajouter de la sécurité et de cacher les serveurs réels. Le proxy direct (le *forward proxy*), lui, se met devant les clients, par exemple pour bloquer l'accès à certains sites sur un réseau. --- ## 3. Virtualisation et administration système Une bonne partie du stage a tourné autour de la virtualisation avec **Proxmox** et de l'administration Linux. C'est sans doute la partie où j'ai le plus mis les mains dedans. ### Installer et comparer deux distributions J'ai installé Proxmox sur un poste dédié, avec une clé USB Ventoy contenant l'ISO, puis j'y ai monté deux machines virtuelles : une **Debian 13** et une **AlmaLinux**. La Debian s'est installée sans souci. Pour AlmaLinux 10.2, en revanche, j'ai galéré : à chaque lancement, la VM redémarrait et revenait sur l'écran d'installation. Les forums parlaient d'un problème de driver ou de GRUB, mais la vraie cause était ailleurs — une incompatibilité avec l'architecture du processeur virtuel de Proxmox. En prenant une ISO x86_64_v2 au lieu d'une x86_64 standard, c'est passé. Plus tard, comme l'option de sécurisation n'était pas encore dispo sur la 10.2, je suis repassé sur AlmaLinux 9.8 avec l'option `cpu host`. Ça m'a donné l'occasion de comparer les deux systèmes : | Critère | Debian 13 (Trixie) | AlmaLinux 10.2 | |---|---|---| | Date de sortie | Août 2025 | Mai 2026 | | Support | Support complet jusqu'au 9 août 2028, puis support LTS jusqu'au 30 juin 2030 | Support actif jusqu'au 31 mai 2030, support de sécurité jusqu'au 31 mai 2035 | | Sécurité | Pas aux normes par défaut, il faut une config assez complexe pour durcir le système | Programme de certification de nommage aligné sur les normes ANSSI | | Performances | Système léger en installation minimale | OS orienté stabilité et charges serveurs longues | Au final, les deux sont gratuits et open source, mais AlmaLinux offre un support plus long et une sécurisation des données un peu meilleure de base. ### Le partitionnement avec LVM Ensuite, j'ai mis en pratique **LVM** sur une machine Debian, pour séparer les répertoires sensibles (`/home`, `/opt`, `/var`, `/var/tmp`) du reste du système. C'est une bonne pratique demandée par le durcissement, dont je parle juste après. Avant de me lancer, il a fallu que je comprenne le vocabulaire : - le **PV** (Physical Volume), c'est le disque ou la partition utilisé par LVM ; - le **VG** (Volume Group), c'est le groupe qui rassemble les PV ; - le **LV** (Logical Volume), c'est le volume logique, l'équivalent d'une partition. Dans les faits, j'ai ajouté un deuxième disque à ma VM, étendu le groupe de volumes existant avec ce disque, agrandi `/home` de 10 Go, créé deux nouveaux volumes (`/opt` et `/var/tmp`), formaté le tout en ext4, récupéré les UUID et ajouté les lignes correspondantes dans `/etc/fstab`. Après un `findmnt --verify` pour vérifier que je n'avais pas fait de bêtise, j'ai monté les partitions, et après un redémarrage, un `df -h` m'a confirmé que chaque répertoire avait bien son propre volume. --- ## 4. Sécurisation et durcissement des systèmes (hardening) C'est probablement la mission technique qui m'a le plus appris. Le **hardening**, ou durcissement, c'est le fait de renforcer la sécurité d'un système en réduisant sa surface d'attaque et en limitant ses vulnérabilités. Pour ça, j'ai utilisé **OpenSCAP**, un outil d'audit de conformité, avec le profil **ANSSI-BP-028** en version minimale. L'ANSSI, c'est l'agence française de sécurité des systèmes d'information, donc autant dire que le référentiel est sérieux. J'ai appliqué tout ça sur mes deux VM, AlmaLinux et Debian. La démarche est toujours la même. On installe OpenSCAP et ses paquets (sur AlmaLinux : `openscap`, `openscap-utils`, `scap-security-guide` ; sur Debian : `openscap-scanner`, `bzip2`, `ssg-debian`). On repère le profil ANSSI-BP-028 minimal dans le catalogue. On lance un premier scan avec `oscap xccdf eval`, qui sort un rapport HTML où chaque règle est marquée conforme ou non. Puis on corrige — d'abord à la main pour certaines choses (par exemple mettre un mot de passe sur GRUB2 avec `grub-mkpasswd-pbkdf2`), et ensuite automatiquement grâce à l'option `--remediate`. Sur AlmaLinux, j'ai fini par atteindre 100 % de conformité après remédiation. Sur Debian, ça a été une autre histoire. Les paquets `ssg-debian` et `ssg-base` des dépôts officiels n'étaient pas adaptés à Debian 13, encore en développement à ce moment-là. J'ai d'abord essayé de changer de miroir et de forcer des mises à jour, sans succès. La solution a été d'ajouter le dépôt de test **Debian Forky** (la future version) avec un système d'épinglage de paquets, pour ne récupérer que les paquets SCAP de ce dépôt sans risquer de déstabiliser le reste du système. Grâce à ça, je suis passé de 95 % à 98,33 % après remédiation. Le reste dépendait justement du partitionnement LVM dont j'ai parlé plus haut. Ce qui m'a le plus marqué, c'est la logique de la démarche : on mesure un état de départ, on applique un référentiel reconnu, on corrige les écarts, et on remesure. C'est une méthode que je pourrai réutiliser ailleurs. --- ## 5. Automatisation avec Ansible À partir de la deuxième semaine, Sébastien m'a présenté **Ansible**. En gros, c'est un outil qui permet de configurer des machines sans intervention humaine, à partir de fichiers de configuration. Deux notions à retenir : l'**inventaire**, qui liste les machines à gérer (rangées en groupes, du type `proxmox` ou `vms`), et le **playbook**, qui décrit les tâches à exécuter dessus. ### Mes premiers playbooks Mon tout premier playbook servait juste à récupérer les infos des machines de l'inventaire, via le module `gather_facts` : la distribution, la version, l'IP principale, la mémoire, le nombre de processeurs, les disques… Ça a bien fonctionné sur mes deux machines, et ça m'a permis de comprendre comment Ansible « voit » les hôtes. Ensuite, en télétravail, j'ai écrit plusieurs scripts capables de s'adapter tout seuls à la distribution ciblée : un pour installer un paquet selon la distribution, un pour en désinstaller, un pour changer l'IP. J'ai même testé sur openSUSE Leap, une distribution que je ne connaissais pas, après avoir remplacé une Ubuntu qui me posait problème (mes scripts avaient besoin d'un compte root, ce qui ne collait pas avec la logique de groupe `sudo` d'Ubuntu). ### Relier Ansible au cloud-init de Proxmox La mission d'après a été de brancher Ansible sur le **cloud-init** de Proxmox. Le cloud-init, c'est ce qui configure automatiquement une VM à son premier démarrage (utilisateur, mot de passe, clé SSH, réseau). J'ai créé un compte dédié à Ansible avec les droits d'admin sur les VM Proxmox, puis j'ai généré une clé API avec un token lié à ce compte. Mon playbook vérifie d'abord que les paquets nécessaires (`python3-proxmox`, `python3-requests`) sont bien là sur la machine ciblée, puis il configure l'utilisateur, le mot de passe et la carte réseau du cloud-init pour mes deux VM. J'ai réutilisé cette base pour un script de clonage automatique de VM : à partir d'un template existant, le script me demande le nom, l'IP et l'ID de la nouvelle VM, puis il clone et applique la config réseau et les comptes tout seul. C'est un vrai gain de temps quand on doit sortir plusieurs machines d'affilée. J'ai aussi écrit un playbook pour installer et configurer **ZSH** (un shell plus complet que Bash, avec l'auto-complétion et d'autres options) automatiquement sur les machines de l'inventaire. --- ## 6. Détection et prévention d'intrusion Sébastien et Vincent m'ont expliqué la différence entre deux dispositifs qui reviennent souvent en sécurité réseau, et que je confondais un peu au départ. L'**IDS**, le système de détection d'intrusion, examine le trafic et alerte les administrateurs quand il repère une activité suspecte. Mais il n'intervient pas dans le trafic, il se contente de signaler. L'**IPS**, le système de prévention d'intrusion, va plus loin : il intercepte le trafic, analyse les flux malveillants et bloque les menaces avant qu'elles n'atteignent le réseau. C'est plus actif, et ça décharge un peu les équipes de sécurité. Dans la continuité de TrendMicro (vu en partie 1), j'ai aussi regardé deux composants qui complètent la solution XDR. Le **Deep Discovery Inspector (DDI)** est une appliance réseau qui offre une vue complète sur le réseau et détecte les menaces, les rançongiciels ou les attaques ciblées. Le **Deep Discovery Analyzer (DDAN)** est une plateforme d'analyse par sandbox : elle fait tourner des fichiers ou des URL suspects dans un environnement isolé pour les analyser en profondeur. Enfin, Vincent m'a montré **NetBox**, un outil open source et gratuit qui automatise la gestion de l'inventaire réseau (baies, serveurs, switchs, interfaces, câblage, jusqu'à la couleur des câbles). Il est compatible avec Ansible, et l'entreprise envisage de l'adopter plus tard. --- ## 7. Conteneurisation avec Podman Un matin où Sébastien n'était pas là, j'ai voulu profiter du temps pour tester **Podman** de mon côté. C'est un outil de conteneurisation dans le même esprit que Docker, mais plus sécurisé : Docker donne les droits root aux conteneurs par défaut, alors que Podman peut se configurer avec des ACL précises. Podman permet aussi de regrouper des conteneurs qui partagent un même réseau dans ce qu'on appelle un *pod*. J'ai déployé, en conteneurs Podman, une partie de la chaîne d'observabilité que j'avais découverte au début du stage : Grafana, Loki (avec sa config officielle récupérée sur leur GitHub) et Prometheus, le tout relié, avec la remontée des logs via Syslog qui fonctionnait bien. Voir les logs arriver dans Grafana après les avoir fait transiter par tous ces conteneurs, c'était plutôt satisfaisant. Ça m'a bien servi pour la suite, parce que ma mission principale reposait justement sur des conteneurs Podman : plusieurs serveurs de bases de données (**MariaDB**, **MongoDB**, **PostgreSQL**) et leurs outils, isolés dans un réseau dédié. --- ## 8. Mission principale : trouver un outil de sauvegarde de bases de données À partir de la mi-juin, Sébastien m'a confié une mission complète, à faire en autonomie : chercher, tester et comparer des outils de sauvegarde de bases de données, en vue de les mettre plus tard en production dans l'entreprise. C'est le projet dont je suis le plus fier, parce que j'ai tout géré du début à la fin. ### Le cahier des charges Sébastien ne m'a pas juste dit « trouve un truc ». Il m'a donné une liste de contraintes assez précises. L'outil devait être gratuit et open source, compatible avec MariaDB, MySQL, MongoDB et PostgreSQL, maintenu et mis à jour dans la durée. Les données devaient rester intègres et se restaurer rapidement. Il fallait aussi que ce soit assez simple pour être utilisé par n'importe qui dans la boîte, avec une communauté active derrière le projet, auto-hébergé, et évidemment sécurisé. ### Monter l'environnement de test Pour tester tout ça, j'ai monté un environnement complet. D'abord sur une VM AlmaLinux, puis sur une Debian 12 sous UTM quand j'étais en télétravail. Trois conteneurs de bases de données (MariaDB sur le port 3306, PostgreSQL sur le 5432 et MongoDB sur le 27017), isolés dans un réseau Podman dédié, plus un client web (dbGate) pour gérer tout ça facilement. Ensuite, j'ai injecté des jeux de données dans chaque base pour me rapprocher de conditions réelles — pour MongoDB j'ai dû prendre un jeu allégé, parce que la lenteur de la VM faisait planter l'import avec des fichiers trop lourds. ### Les outils que j'ai comparés J'ai retenu et testé trois outils. **Portabase**, d'abord, un outil surtout développé par des Français, compatible avec beaucoup de moteurs (PostgreSQL, MySQL, MariaDB, MongoDB, Redis/Valkey, SQLite, FireBird, MSSQL). Il gère plusieurs organisations, les notifications sur beaucoup de canaux (Slack, Ntfy, Gotify, Discord, Webhook, Telegram, Email), la double authentification et plusieurs types de stockage (S3, local, drive). Il fonctionne avec des agents légers installés sur les serveurs à sauvegarder. **Databasement**, ensuite, conçu par un développeur espagnol, compatible MySQL, MariaDB, PostgreSQL, MongoDB, SQLite et d'autres. Lui n'a pas besoin d'agent : il passe par un tunnel SSH. Il gère le stockage en S3, FTP ou en local. Et **Databasus**, d'origine géorgienne, gratuit, auto-hébergé et open source, compatible PostgreSQL, MySQL, MariaDB et MongoDB. Les sauvegardes sont programmables, le stockage peut se faire sur S3, Google Drive ou FTP, et le projet a une communauté active (29 contributeurs sur GitHub et un Telegram dédié). Il gère lui aussi plusieurs canaux de notification. Après avoir configuré chaque outil en détail (les connexions, les sauvegardes automatiques, les politiques de rétention, les alertes selon leur niveau de gravité), je suis passé aux tests de restauration. Le principe : je génère une sauvegarde manuelle de chaque base, je supprime volontairement les données pour simuler une perte, puis je restaure avec chaque outil. Pour rendre la preuve de concept plus visuelle, j'ai codé un petit site de démonstration hébergé sous Apache2, qui affiche le contenu des bases en direct. Comme ça, on voit les données disparaître après la suppression, puis réapparaître après la restauration. ### Les résultats | Serveur de base de données | Databasus | Databasement | Portabase | |---|---|---|---| | MariaDB | Non fonctionnel | Fonctionnel | Non fonctionnel | | MongoDB | Fonctionnel | Fonctionnel | Non fonctionnel | | PostgreSQL | Fonctionnel | Fonctionnel | Non fonctionnel | Portabase, je n'ai jamais réussi à le faire tourner correctement : l'interface web restait blanche, sans la moindre erreur dans les logs. En allant demander directement aux développeurs sur leur Discord, on m'a expliqué que l'outil ne supportait pas Podman, seulement Docker, et leurs solutions de contournement n'ont rien donné. Ça m'a un peu déçu, parce que c'était justement celui que je voulais le plus utiliser. J'ai aussi noté une limite chez Databasement : sa base PostgreSQL est dans la même image que le serveur web, ce qui n'est pas très propre, puisqu'il faut mettre à jour toute l'image dès qu'un seul des deux doit l'être. Au bout du compte, j'ai conclu que Databasement était l'outil le plus complet et le plus fiable par rapport au cahier des charges. Ses restaurations sont un peu plus lentes que celles de Databasus, mais il fait le travail sur tous les moteurs. Databasus reste une bonne alternative, notamment pour MongoDB et PostgreSQL. ### La restitution J'ai terminé la mission en préparant une présentation avec support, une démo en direct et la preuve de concept. Sébastien m'a aidé à préparer, puis j'ai présenté à l'équipe. Le fond a été validé — j'avais bien répondu à la demande. En revanche, on m'a fait remarquer que je devais soigner mon vocabulaire technique à l'oral, ce qui est une remarque juste et sur laquelle je vais travailler. On a aussi eu quelques soucis de performance pendant la présentation à distance, parce que l'outil de visio consommait tellement de RAM qu'il en restait peu pour faire tourner la VM de démo. --- ## Difficultés rencontrées et comment je les ai réglées Le stage m'a mis face à pas mal de problèmes concrets. Je préfère les assumer plutôt que de faire comme si tout avait été fluide, parce que c'est justement en les réglant que j'ai le plus appris. Il y a eu la panne de RAM sur le serveur HP, que j'ai déjà racontée : diagnostic via le BIOS et l'iLO, isolement de la cause en inversant les barrettes, puis contournement en attendant une vraie réparation. Il y a eu l'incident sur les pare-feux StormShield en cluster, où l'un des deux n'a pas voulu redémarrer après la bascule et a nécessité une intervention physique qu'on n'avait pas prévue. Côté virtualisation, l'installation d'AlmaLinux sur Proxmox m'a fait chercher un moment avant que je comprenne que le problème venait de l'architecture du processeur virtuel, et pas d'un driver ou de GRUB comme le disaient les forums. Toujours sur AlmaLinux et Debian, les dépôts de paquets SCAP n'étaient pas adaptés à Debian 13, et j'ai dû ajouter un dépôt de test avec un épinglage bien précis pour ne prendre que ce dont j'avais besoin. Une journée de télétravail a aussi été compliquée : je devais continuer mon apprentissage sur Ansible avec Proxmox, mais je n'arrivais pas à faire tourner Proxmox chez moi. J'ai essayé UTM, puis VirtualBox, mais impossible de virtualiser une architecture x86_64 depuis un Mac ARM, et impossible aussi de virtualiser Proxmox dans une autre VM. J'ai fini par contourner en installant directement les systèmes cibles sous UTM, sans passer par Proxmox, ce qui m'a permis de continuer quand même. Pour la mission principale, le principal blocage a été Portabase, incompatible avec Podman. Plutôt que de m'entêter, je suis allé poser la question directement aux développeurs, ce qui m'a fait gagner du temps et éviter de creuser une fausse piste. Et pour finir, la présentation à distance a souffert du manque de ressources, la visio prenant trop de mémoire pour laisser tourner la démo correctement. --- ## Ce que le stage m'a apporté Sur le plan technique, j'ai appris énormément de choses que je n'aurais pas pu voir aussi concrètement en cours. J'ai administré des systèmes Linux (Debian et AlmaLinux), avec de l'installation, du partitionnement LVM et de la gestion de services. J'ai fait de la virtualisation avec Proxmox et géré le cycle de vie de VM. J'ai durci des systèmes avec OpenSCAP en suivant un référentiel ANSSI, ce qui m'a vraiment donné une méthode. J'ai automatisé pas mal de tâches avec Ansible, jusqu'à me connecter à l'API de Proxmox et son cloud-init. J'ai pris en main Podman, y compris en réseau isolé et avec des volumes persistants. Et j'ai manipulé plusieurs moteurs de bases de données ainsi que leurs outils de sauvegarde et de restauration. À tout ça s'ajoutent les solutions de sécurité réseau (pare-feu, WAF, XDR, IDS/IPS, DNS filtrant) et la stack de supervision (Grafana, Loki, Prometheus). Mais je ne retiens pas que la technique. J'ai appris à mener un projet de bout en bout, depuis un besoin exprimé par mon tuteur jusqu'à une présentation devant l'équipe. J'ai gagné en méthode dans le diagnostic : isoler les causes, chercher de façon documentée, et toujours revérifier après une correction. J'ai aussi compris que la communication compte autant que le reste, et la remarque sur mon vocabulaire à l'oral m'a bien fait prendre conscience de ce qu'il me reste à travailler. Un épisode m'a particulièrement marqué. En montrant mon portfolio personnel à l'équipe, les développeurs de 3S Sécurité ont repéré une faille : une clé de webhook Discord traînait en clair dans mon dépôt Git, et ils ont réussi à envoyer des messages sur mon canal de contact. Je l'ai corrigée aussitôt. Sur le coup c'était gênant, mais c'est sans doute la leçon la plus concrète que j'ai eue sur la gestion des secrets, bien plus parlante que les cas théoriques vus en formation. --- ## Conclusion Ce stage chez 3R Groupe, et plus précisément à 3S Sécurité, m'a fait découvrir de l'intérieur comment fonctionne un service d'infrastructure et de sécurité, avec un niveau de réalité que je n'avais pas en formation. J'ai monté en compétence sur des outils professionnels de supervision, de virtualisation, d'automatisation et de sécurisation, et surtout j'ai été responsabilisé petit à petit, jusqu'à porter seul un projet complet. Au-delà des outils, ce stage m'a confirmé que c'est bien ce genre de métiers, autour de l'infrastructure et de la sécurité, qui m'intéresse. Il m'a aussi appris l'importance de la rigueur, de la méthode et de la communication dans un cadre professionnel. Et le fait d'avoir été le premier stagiaire de première année de BTS accueilli par l'entreprise ne s'est pas ressenti au quotidien comme un frein : au contraire, ça m'a permis de progresser vite au contact d'une équipe expérimentée. --- ## Annexe : glossaire des outils et technologies rencontrés | Terme | Définition courte | |---|---| | Ansible | Outil d'automatisation de la configuration de machines, sans agent, basé sur des playbooks. | | Cisco Meraki | Solution de pilotage centralisé d'un réseau depuis une interface web. | | Cisco Umbrella | Service DNS filtrant, bloque les sites malveillants et les mails dangereux. | | Cloud-init | Service de configuration automatique d'une VM à son premier démarrage. | | DDAN (Deep Discovery Analyzer) | Plateforme d'analyse sandbox de fichiers/URL suspects (TrendMicro). | | DDI (Deep Discovery Inspector) | Appliance réseau de détection de menaces et d'attaques ciblées (TrendMicro). | | DNS Scanner | Outil interne 3S détectant le typosquatting de noms de domaine + Comparaison du code des sites malveillants et images. | | Grafana | Outil de visualisation de tableaux de bord à partir de métriques et de logs. | | Hardening | Durcissement d'un système pour réduire sa surface d'attaque. | | IDS | Système de détection d'intrusion (alerte sans bloquer). | | InfluxDB | Base de données orientée séries temporelles. | | IPS | Système de prévention d'intrusion (bloque activement les menaces). | | LVM | Gestionnaire de volumes logiques pour un partitionnement flexible. | | Loki | Outil de centralisation et d'agrégation de logs, utilisé avec Grafana. | | NetBox | Outil open source de gestion d'inventaire et de documentation réseau. | | Ogo | Pare-feu applicatif (WAF) protégeant sites web et API. | | OpenSCAP | Outil d'audit de conformité de sécurité selon un référentiel normé. | | Podman | Outil de conteneurisation proche de Docker, sans démon root par défaut. | | Prometheus | Outil de collecte de métriques système et applicatives. | | Proxmox | Solution de virtualisation open source. | | StormShield | Pare-feu français filtrant le trafic réseau. | | Syslog | Protocole standard de journalisation (logs) réseau. | | Telegraf | Agent de collecte de métriques installé sur les machines supervisées. | | TrendMicro (XDR) | Solution de détection et réponse étendues sur postes et serveurs. | | ZSH | Interpréteur de commandes (shell) avancé, alternative à Bash. |