Mon Portfolio — Blocs de compétences
Cette page présente mes SAE classées par Blocs de compétences.
Pour chaque bloc, je mets en avant une SAE qui m'a permit d'acquérir les compétences de ce bloc,
avec une brève explication de comment je les ai acquises.
Bloc « Administrer » — Niveau 3 : Concevoir un réseau
Apprentissages critiques (AC31.x)
-
Contexte
Dans la SAE 5.01, nous devions concevoir une solution complète de virtualisation basée sur Proxmox, accessible via une interface web, pour permettre aux enseignants et étudiants de disposer de VMs prêtes à l’emploi pour les TP.
Objectifs
Définir une architecture réseau cohérente (VLAN, routage, IP, services exposés), garantir la communication entre les VMs, l’interface web et les utilisateurs tout en gardant un niveau de sécurité suffisant.
Problèmes rencontrés
- Difficulté à choisir un plan d’adressage permettant d’isoler les services tout en restant simple à administrer.
- Gestion du routage entre les réseaux internes Proxmox et le réseau d’accès des utilisateurs.
- Prise en compte des flux nécessaires à l’authentification sécurisée (LDAPS, HTTPS).
Solutions mises en place
- Conception d’un schéma logique et physique du réseau (segments pour Proxmox, VMs, accès web, annuaire).
- Définition d’un plan IP structuré par rôle (infrastructure, services, clients) pour limiter les erreurs de config.
- Identification et documentation des ports et protocoles nécessaires pour les différents services (API, LDAPS, HTTPS).
Résultats et validation de l’AC
Le réseau conçu permet d’héberger les VMs, d’exposer l’interface web de gestion et d’intégrer l’authentification sécurisée. Le tout est documenté dans le compte rendu, ce qui montre la capacité à concevoir un projet de réseau complet adapté au besoin de la SAE.
Documents associés
-
Contexte
Pour la SAE 5.01 et la SAE 5.02, la documentation était un livrable majeur : d’un côté l’infrastructure Proxmox et l’interface web, de l’autre le projet Git piloté en équipe.
Objectifs
Produire une documentation lisible, complète et exploitable par un tiers : description de l’architecture, procédures de déploiement, règles Git, organisation des branches.
Problèmes rencontrés
- Faire le lien entre les choix techniques et leur justification (pourquoi ce schéma, pourquoi cette sécurité).
- Structurer la documentation pour qu’elle soit utilisable sans avoir vu le projet oralement.
- Maintenir la doc à jour malgré les évolutions du projet (ajout de fonctionnalités, modifications réseau).
Solutions mises en place
- Rédaction d’un CR structuré (contexte, architecture, services, sécurité, tests) pour la SAE 5.01.
- Utilisation de Markdown pour la doc du projet Git (SAE 5.02), avec une structure claire (README, sections, changelog).
- Ajout systématique des mises à jour (modif de branches, règles de merge) dans la doc au fur et à mesure.
Résultats et validation de l’AC
La documentation produite permet de rejouer l’installation de l’infrastructure, de comprendre les choix réseau et de suivre la stratégie Git. L’AC est validé par la qualité des documents fournis.
Documents associés
-
Contexte
Dans la SAE 5.01, la maquette est constituée du serveur Proxmox, d’un ensemble de VMs modèles, de l’interface web et de l’intégration au SI (authentification, accès réseau).
Objectifs
Proposer un environnement fonctionnel démontrable : un enseignant doit pouvoir lancer une VM et un étudiant s’y connecter via l’interface web, comme dans le système final.
Problèmes rencontrés
- Configuration initiale des VMs modèles pour qu’elles soient réutilisables sans reconfiguration lourde.
- Alignement entre les paramètres réseau de Proxmox et les besoins de l’interface de gestion.
- Validation de la stabilité de la maquette (tests de connexion, redémarrage, multi-utilisateurs).
Solutions mises en place
- Création de VMs « modèles » préconfigurées (OS, outils, réseau) clonables pour les TP.
- Tests de bout en bout : création d’une VM, affectation réseau, accès via l’interface web.
- Rédaction de scénarios de démonstration (cas d’usage : enseignant / étudiant).
Résultats et validation de l’AC
La maquette démontre clairement le fonctionnement du système final : la démonstration de la chaîne complète (de Proxmox à la VM accessible via web) valide l’AC.
Documents associés
-
Contexte
En SAE 5.01 et SAE 5.02, une soutenance était prévue pour présenter le projet, les choix techniques, la gestion d’équipe et les résultats.
Objectifs
Être capable d’expliquer et justifier l’architecture réseau, la stack technique, la sécurité et l’organisation du projet devant un jury.
Problèmes rencontrés
- Adapter le niveau de détail au public (enseignants parfois plus orientés réseau que dev, et inversement).
- Mettre en avant les difficultés réelles sans donner l’impression d’un projet instable.
Solutions mises en place
- Préparation d’un fil conducteur : besoin → architecture → réseau → sécurité → démonstration.
- Utilisation de schémas (réseau, Proxmox, flux) pour illustrer les explications lors de l’oral.
- Mise en avant des problèmes rencontrés et de la manière dont ils ont été résolus (plutôt que de les cacher).
Résultats et validation de l’AC
Les soutenances ont permis de défendre clairement le projet, de justifier les décisions techniques et de montrer la maîtrise de l’environnement. L’AC est validé par la capacité à argumenter sur l’ensemble de la solution.
Application à la ressource R506
Dans la ressource R506, le projet Tacos’N’Go a également permis de travailler cette compétence. Nous avons défendu notre concept de food truck connecté devant un jury : présentation du site web de commande, de la carte interactive Leaflet pour localiser le camion, et du système de paiement en ligne. Chaque membre du groupe a expliqué sa partie (front-end, API Flask, base de données SQLite, design). La soutenance a mis en avant les choix techniques justifiés et la cohérence commerciale du projet (rapidité, simplicité d’usage, approche moderne du street food).
Cette présentation a validé notre capacité à argumenter et défendre un projet numérique complet, de la conception à la démonstration, dans un contexte concret et professionnel.
Documents associés
-
Contexte
Les SAE 5.01 et 5.02 ont été réalisées en équipe : il a fallu se coordonner sur les tâches réseau, système, développement et documentation.
Objectifs
Mettre en place une communication fluide entre les membres du binôme / groupe pour éviter les doublons, les oublis et les conflits techniques ou Git.
Problèmes rencontrés
- Différences de vision sur la manière d’organiser les branches et les merges.
- Synchronisation des modifications (un membre modifie la doc pendant que l’autre change l’architecture).
Solutions mises en place
- Réunions régulières pour faire le point sur l’avancement et les priorités.
- Utilisation de messages de commit explicites et d’un fichier CHANGELOG pour tracer les modifications (SAE 5.02).
- Répartition claire des rôles (réseau, système, doc, dev) avec points de synchronisation.
Résultats et validation de l’AC
La communication a permis de garder un projet cohérent, avec une architecture claire et une documentation alignée sur la réalité du système. L’AC est validé par la qualité du travail d’équipe et la cohérence du rendu final.
Application à la ressource R506
Dans la ressource R506, la communication au sein de l’équipe a été essentielle pour coordonner le développement du projet Tacos’N’Go. Chaque membre avait un rôle précis (développement du site web, base de données, API Flask, design graphique). Nous avons échangé régulièrement via Discord pour répartir les tâches et suivre la progression. Des retours enseignants ont également permis d’améliorer l’ergonomie et de corriger les erreurs techniques.
Cette collaboration fluide a permis de maintenir une cohérence entre les différentes parties du projet et de répondre efficacement aux attentes du jury. L’AC31.05 est donc validé par la communication continue et structurée mise en œuvre durant la ressource R506.
Documents associés
-
Contexte
Les SAE 5.01 et 5.02 ont été menées sur plusieurs semaines, avec des jalons : conception, installation, test, documentation et soutenance.
Objectifs
Structurer le projet en étapes claires (planification) et suivre l’avancement pour éviter les rushs de dernière minute et les oublis de fonctionnalités.
Problèmes rencontrés
- Tendance à se concentrer sur la technique (installation, scripts) au détriment de la doc au début.
- Gestion du temps entre SAE 5.01, SAE 5.02 et autres matières.
Solutions mises en place
- Découpage du projet en tâches : installation Proxmox, configuration réseau, dev interface, tests, doc.
- Organisation du travail Git par étapes (SAE 5.02) : d’abord les sections prioritaires, puis les détails.
- Réservation de créneaux spécifiques pour la documentation et les tests.
Résultats et validation de l’AC
Le projet a été mené jusqu’au bout avec une architecture fonctionnelle, une doc complète et des soutenances prêtes dans les délais. Cela montre la capacité à gérer les étapes d’un projet du début à la fin.
Application à la ressource R506
Pour le projet Tacos’N’Go, nous avons organisé le travail en plusieurs phases claires : conception, développement, intégration, tests, puis soutenance. Le découpage a été établi dès le départ pour garantir une avancée régulière. Chaque étape était validée avant de passer à la suivante (création de la base de données, configuration de l’API, intégration de la carte Leaflet, ajout du paiement).
Cette gestion rigoureuse du temps et des priorités nous a permis d’obtenir un rendu final complet et fonctionnel. L’AC31.06 est donc validé par la planification efficace et le suivi méthodique du projet Tacos’N’Go.
Documents associés
Bloc « Connecter » — Niveau 3 : Déployer une solution de communication sur IP
Apprentissages critiques (AC32.x)
-
Contexte
Dans la SAE 5.01, le système de communication repose sur un serveur Proxmox hébergeant des VMs accessibles à distance via une interface web sécurisée.
Objectifs
Permettre aux utilisateurs (enseignants / étudiants) de communiquer avec les VMs (prise en main à distance) au travers d’un environnement homogène et sécurisé.
Problèmes rencontrés
- Gestion des flux entre le réseau interne Proxmox et le réseau d’accès de l’IUT.
- Configuration correcte des interfaces réseau sur les VMs et sur Proxmox.
- Prise en compte des contraintes de sécurité tout en gardant un système utilisable.
Solutions mises en place
- Configuration des interfaces réseau Proxmox pour gérer les VLAN / réseaux dédiés aux VMs.
- Définition de règles NAT / routage pour exposer certains services sans ouvrir tout le SI.
- Tests de communication bout en bout (client → interface web → VM).
Résultats et validation de l’AC
Les utilisateurs peuvent accéder aux VMs via l’interface prévue, avec une communication stable et sécurisée. Cet AC est validé par la mise en place d’un système de communication IP complet entre utilisateurs, interface et VMs.
Documents associés
-
Contexte
Même si la SAE 5.01 ne met pas en œuvre un Wi-Fi au sens strict, elle traite de manière équivalente l’accès distant sécurisé au SI (interface web + LDAPS).
Objectifs
Garantir que l’accès au système (interface de gestion, VMs) se fait via des canaux chiffrés et authentifiés, comme on le ferait pour un Wi-Fi sécurisé en production.
Problèmes rencontrés
- Gestion des certificats TLS pour chiffrer l’accès à l’interface.
- Configuration correcte de LDAPS pour éviter les erreurs de confiance / certificats.
Solutions mises en place
- Génération et installation de certificats pour les services exposés en HTTPS.
- Tests de connexion avec différents clients pour vérifier l’authentification sécurisée.
- Analyse et correction des erreurs de certificats (CA non reconnue, CN incorrect, etc.).
Résultats et validation de l’AC
L’accès distant se fait via des canaux chiffrés, avec authentification centralisée, ce qui est l’objectif principal d’un réseau Wi-Fi / accès distant sécurisé. L’AC est donc couvert par la SAE 5.01.
Documents associés
-
Contexte
Dans la SAE 5.01, les VMs, Proxmox et les services d’infrastructure reposent sur un réseau d’accès fixe (plan IP, routage, accès depuis l’IUT).
Objectifs
Assurer un accès fiable, avec des adresses IP cohérentes, aux différents services hébergés (Proxmox, VMs, annuaire, interface web).
Problèmes rencontrés
- Assignation des IP fixes pour éviter les conflits entre VMs et services.
- Nécessité de garder une certaine souplesse pour ajouter des VMs sans saturer le plan d’adressage.
Solutions mises en place
- Réservation de plages IP par rôle (infrastructure, services, VMs pédagogiques).
- Documentation précise du plan IP dans le compte rendu (pour faciliter la maintenance).
- Tests de connectivité pour vérifier que chaque service est atteignable de bout en bout.
Résultats et validation de l’AC
Le réseau d’accès fixe permet de joindre les services sans conflit d’adresses, avec une vision claire des plages utilisées. L’AC est validé par la mise en œuvre concrète dans la SAE 5.01.
Documents associés
-
Contexte
La SAE 5.01 met en place une interface permettant d’accéder aux VMs via le réseau de l’IUT, avec une authentification sécurisée et des flux chiffrés.
Objectifs
Assurer que seules les personnes autorisées accèdent aux ressources, et que les données en transit sont protégées contre l’interception.
Problèmes rencontrés
- Configuration correcte de LDAPS et gestion du certificat côté serveur et client.
- Gestion des droits d’accès (qui peut lancer quelle VM, via quels comptes).
Solutions mises en place
- Intégration de l’authentification AD/LDAP à l’interface (niveau applicatif).
- Utilisation du protocole TLS pour chiffrer les échanges.
- Tests d’accès avec différents comptes pour valider la gestion des droits.
Résultats et validation de l’AC
Le SI n’est accessible que via une connexion sécurisée, avec authentification et contrôle d’accès. Cela valide l’AC32.04 via la SAE 5.01.
Documents associés
-
Contexte
La SAE 5.01 et surtout la SAE 5.02 reposent sur un travail collaboratif structuré : partage du dépôt Git, branches par personne, branche d’intégration, version stable.
Objectifs
Mettre en place une vraie organisation de projet : chacun contribue, les conflits sont gérés, les décisions sont tracées, les livrables sont cohérents.
Problèmes rencontrés
- Conflits Git lors de modifications simultanées sur les mêmes fichiers.
- Risque de casser la branche principale si chacun pousse directement dessus.
Solutions mises en place
- Définition d’un workflow Git : branches dev-NOM → branche dev → branche master.
- Usage de merge requests / revues avant intégration sur la branche d’intégration.
- Communication régulière sur les changements majeurs (nouvelle section, nouvelle fonctionnalité).
Résultats et validation de l’AC
Le projet avance de façon collaborative et maîtrisée, sans perte de travail ni branches cassées. L’AC est clairement validé par l’organisation mise en œuvre dans la SAE 5.02 et appliquée également dans la SAE 5.01 pour la partie code.
Application à la ressource R506
La collaboration dans le cadre du projet Tacos’N’Go s’est appuyée sur un travail en équipe organisé. Nous avons utilisé GitHub pour le partage du code et Trello pour la répartition des tâches et le suivi de l’avancement. Chaque membre disposait de son espace de travail (branche dédiée) afin d’éviter les conflits de code. Les réunions d’équipe et le partage des versions sur Git ont permis une intégration fluide du front-end, du back-end et de la base de données.
Cette méthode de travail reflète une vraie collaboration en mode projet, inspirée des pratiques professionnelles, et valide l’AC32.05 au travers du projet Food Truck.
Documents associés
Bloc « Programmer » — Niveau 3 : Piloter un projet de développement d’une application R&T
Apprentissages critiques (AC33.x)
-
Contexte
Dans la SAE 5.01, il a fallu définir les spécifications techniques de l’interface web, de l’API et de l’intégration avec Proxmox. Dans la SAE 5.02, les spécifications concernaient l’organisation Git et la documentation.
Objectifs
Transformer le besoin global (« gérer des VMs via une interface ») en exigences techniques précises : API, routes, données, flux, sécurité, organisation des branches, types de documents.
Problèmes rencontrés
- Difficulté à formaliser ce qui doit être “obligatoire” vs “optionnel” dans la première version.
- Prendre en compte à la fois les contraintes réseau, système et développement.
Solutions mises en place
- Rédaction d’un cahier de spécifications (endpoints API, fonctionnalités de l’interface, profil d’utilisateurs).
- Définition claire des workflows Git (SAE 5.02) : quels types de changements, quelles branches, quelles règles.
- Validation des specs avec l’équipe avant de coder / configurer.
Résultats et validation de l’AC
Les spécifications ont servi de base pour le développement de l’interface et l’organisation Git, ce qui montre la capacité à élaborer des specs techniques réalistes et applicables.
Documents associés
-
Contexte
La SAE 5.02 est centrée sur la mise en place d’un environnement collaboratif via Git, avec une équipe qui rédige et maintient une documentation technique.
Objectifs
Créer un environnement de travail structuré et partagé où chacun peut contribuer sans tout casser, avec un historique clair des modifications.
Problèmes rencontrés
- Conflits de fusion entre branches dev-NOM et dev.
- Risque de perdre des modifications si deux personnes travaillent sur la même section.
Solutions mises en place
- Organisation stricte des branches (personnelles, d’intégration, stable).
- Règles de nommage des commits et fréquence de push / pull.
- Utilisation d’un fichier CHANGELOG pour tracer les ajouts de sections.
Résultats et validation de l’AC
Le dépôt Git est structuré, l’historique est lisible et l’équipe peut collaborer efficacement. L’AC33.02 est validé par la mise en place d’un environnement Git collaboratif complet.
Application à la ressource R506
Pour le projet Tacos’N’Go, nous avons mis en place un environnement collaboratif complet : GitHub pour la gestion du code, Visual Studio Code pour l’édition commune, et un serveur Flask local pour les tests et l’intégration. Chaque membre pouvait ainsi développer sa partie (site web, API, base SQLite) et la tester en local avant la mise en commun.
Grâce à cet environnement structuré, le travail a pu être effectué de manière simultanée et coordonnée, permettant à chacun de contribuer efficacement sans conflit de version. L’AC33.02 est donc validé par la mise en place d’un écosystème de développement partagé.
Documents associés
-
Contexte
La SAE 5.02 inclut la rédaction d’une documentation claire permettant à des utilisateurs de comprendre le projet sans explication orale directe.
Objectifs
Produire une documentation qui puisse servir de support de formation : présentation du projet, des fonctionnalités et des méthodes pour l’utiliser correctement.
Problèmes rencontrés
- Rendre des concepts techniques accessibles à quelqu’un qui n’a pas suivi le développement.
- Choisir le bon niveau de détail pour ne pas perdre le lecteur.
Solutions mises en place
- Organisation du texte en sections simples : contexte, objectifs, fonctionnement, exemples.
- Utilisation de captures d’écran / schémas (dans la mesure du possible) pour illustrer.
- Relecture avec l’équipe en se mettant à la place d’un utilisateur novice.
Résultats et validation de l’AC
La documentation permet à un lecteur externe de comprendre comment fonctionne le projet et comment contribuer ou l’utiliser, ce qui valide l’AC33.03.
Documents associés
-
Contexte
La SAE 5.01 se termine par le déploiement réel de la solution (Proxmox, VMs, interface web). Il faut aussi être capable de la maintenir (mise à jour, corrections).
Objectifs
Passer d’un prototype à un système déployé, stable, reproductible et documenté.
Problèmes rencontrés
- Différences entre l’environnement de test et l’environnement final.
- Problèmes lors des redémarrages (services qui ne se relancent pas correctement, dépendances).
Solutions mises en place
- Procédure d’installation détaillée (ordre des étapes, prérequis, vérifications).
- Tests après redémarrage pour vérifier que tous les services critiques reviennent en ligne.
- Ajout de correctifs documentés en cas de problème (bugfixes, ajustements config).
Résultats et validation de l’AC
La solution est installable à partir de la documentation et reste fonctionnelle dans le temps, ce qui montre la capacité à déployer et maintenir un système technique complet.
Documents associés
-
Contexte
Pour concevoir la solution SAE 5.01 / 5.02, il a fallu se renseigner sur Proxmox, l’API, les bonnes pratiques réseau / sécurité et les workflows Git modernes.
Objectifs
Ne pas se limiter à un simple “TP” mais proposer une solution actuelle et cohérente avec les pratiques du monde professionnel.
Problèmes rencontrés
- Choix de la bonne manière d’interagir avec Proxmox (API, scripts, outils existants).
- Comprendre les implications de l’authentification LDAPS et du chiffrement HTTPS.
Solutions mises en place
- Consultation de la documentation officielle Proxmox / Node.js / Git.
- Comparaison de plusieurs approches avant de choisir la plus adaptée au contexte IUT.
- Adaptation des pratiques vues en cours avec des exemples trouvés dans la doc / communautés.
Résultats et validation de l’AC
La solution s’appuie sur des outils et des méthodes utilisés en production (hyperviseur Proxmox, API, Git structuré, sécurité), ce qui valide l’AC33.05.
Application à la ressource R506
Le projet Tacos’N’Go nous a amenés à effectuer une veille technologique pour choisir les outils les plus adaptés. Nous avons étudié les frameworks web modernes (Flask, Express, Node.js) avant de retenir Flask pour sa légèreté et sa simplicité. Nous avons également découvert Leaflet pour la carte interactive, et exploré la solution de paiement Stripe pour simuler des transactions en ligne. Le design du site s’est inspiré des tendances actuelles de la restauration connectée.
Cette démarche d’exploration et d’adaptation montre notre capacité à nous informer sur les nouveautés technologiques et à les intégrer dans un projet concret et professionnel.
Documents associés
-
Contexte
Dans la SAE 5.01, l’environnement doit être sécurisé : accès restreint à l’interface, trafic chiffré, isolation des VMs, gestion des droits.
Objectifs
Réduire la surface d’attaque au strict nécessaire tout en gardant un système exploitable par les utilisateurs.
Problèmes rencontrés
- Gestion des certificats TLS (émission, installation, confiance).
- Gestion des comptes et droits d’accès pour éviter les accès non souhaités.
- Équilibre entre sécurité et simplicité d’utilisation pour les étudiants.
Solutions mises en place
- Utilisation d’HTTPS et LDAPS pour sécuriser les échanges.
- Limitation des accès à l’interface (rôles, comptes) et filtrage réseau.
- Tests d’accès avec différents profils pour vérifier les restrictions.
Résultats et validation de l’AC
L’environnement est sécurisé par conception : accès chiffrés, authentification, segmentation. L’AC33.06 est validé par l’ensemble des choix de la SAE 5.01.
Documents associés
Bloc « Sécuriser » — Niveau 2 : Mettre en œuvre un SI sécurisé
Apprentissages critiques (AC34.xCyber)
-
Contexte
Dans la SAE 5.Cyber.03, j’ai mis en place un environnement Elastic pour superviser plusieurs éléments du SI (Ubuntu, Windows, service web, switch Cisco, Docker+BDD). Chaque flux de log permet d’identifier des risques potentiels.
Objectifs
Être capable d’identifier les événements critiques dans les logs, de distinguer le normal de l’anormal, et d’évaluer les risques associés aux comportements observés.
Problèmes rencontrés
- Volume important de logs, rendant difficile la détection manuelle d’événements importants.
- Compréhension fine des champs remontés par les différents Beats (Filebeat, Winlogbeat, etc.).
Solutions mises en place
- Création de dashboards Kibana pour filtrer par type d’événement (authentification, erreur, réseau…).
- Identification des patterns d’événements “normaux” pour mieux repérer les anomalies.
- Utilisation des TPs (logs d’attaques / tests) pour confronter les hypothèses à des cas concrets.
Résultats et validation de l’AC
Grâce à la supervision centralisée et à l’analyse des dashboards, j’ai pu identifier les risques (brute-force, erreurs applicatives, erreurs réseau, etc.) et proposer des pistes de remédiation, ce qui valide l’AC34.01Cyber.
Documents associés
-
Contexte
La SAE 5.Cyber.03 repose sur l’installation et la configuration de la stack Elastic (Elasticsearch, Kibana) et des Beats (Filebeat, Metricbeat, Winlogbeat, Packetbeat, éventuellement Logstash pour Cisco).
Objectifs
Déployer des outils de sécurisation et de supervision permettant de collecter et analyser les logs des systèmes et des équipements réseau.
Problèmes rencontrés
- Configuration parfois complexe des Beats (format des logs, modules, pipelines).
- Problèmes de remontée des logs Cisco nécessitant l’utilisation de Logstash.
- Débogage des erreurs de connexion entre Beats et Elasticsearch.
Solutions mises en place
- Installation détaillée et configuration d’Elasticsearch / Kibana (CR Installation Elastic).
- Activation des modules Filebeat pour Nginx, système, etc. et ajustement des chemins de logs.
- Mise en place de Logstash pour recevoir les logs Cisco et les envoyer dans Elasticsearch.
Résultats et validation de l’AC
Les outils de supervision sont opérationnels, les logs sont collectés et visualisés dans Kibana. L’AC34.02Cyber est validé par la mise en œuvre concrète de ces outils.
Documents associés
-
Contexte
Dans la SAE 5.Cyber.03, j’ai supervisé des machines Ubuntu et Windows, en remontant leurs journaux système et de sécurité vers Elastic.
Objectifs
Identifier les événements liés à la sécurité des OS (authentifications, élévations de privilèges, services sensibles) et adapter le durcissement en conséquence.
Problèmes rencontrés
- Comprendre la structure des journaux système (syslog sous Ubuntu, Event Logs sous Windows).
- Filtrer les événements intéressants parmi un grand volume de logs.
Solutions mises en place
- Configuration de Filebeat sur Ubuntu pour envoyer les logs systèmes / auth vers Elasticsearch.
- Installation et configuration de Winlogbeat sur Windows pour remonter les journaux de sécurité.
- Création de vues Kibana pour suivre les connexions, les erreurs, les événements critiques.
Résultats et validation de l’AC
Les systèmes d’exploitation sont surveillés en continu et les événements de sécurité sont visibles et analysables, ce qui permet d’améliorer leur durcissement. L’AC34.03Cyber est ainsi validé.
Documents associés
-
Contexte
Pour la SAE 5.Cyber.03, j’ai conçu une architecture de supervision intégrant Elastic, les Beats, Logstash et les différentes sources de logs (OS, web, Cisco, BDD/Docker).
Objectifs
Proposer une architecture qui centralise les logs de sécurité tout en respectant la segmentation du SI et les bonnes pratiques de sécurité.
Problèmes rencontrés
- Choix des flux de logs à remonter pour ne pas saturer la plateforme.
- Gestion des accès au tableau de bord (qui peut voir quoi).
Solutions mises en place
- Définition d’un schéma logique : sources → Beats → (Logstash) → Elasticsearch → Kibana.
- Sélection des logs les plus pertinents pour la sécurité (authentification, services critiques, réseau).
- Organisation des dashboards par type d’équipement / service (Ubuntu, Windows, Cisco, Web, BDD/Docker).
Résultats et validation de l’AC
L’architecture proposée est cohérente, évolutive et exploitable pour la sécurité. Elle répond aux besoins de la SAE 5.Cyber.03 et valide l’AC34.04Cyber.
Documents associés
Bloc « Surveiller » — Niveau 2 : Mettre en œuvre un système de surveillance
Apprentissages critiques (AC35.xCyber)
-
Contexte
Dans la SAE 5.Cyber.03, j’ai mis en place des dashboards Kibana pour suivre en temps quasi réel l’activité des machines Ubuntu/Windows, du service web, du switch Cisco, de Docker et de la BDD.
Objectifs
Avoir une vision centralisée de l’activité du SI : charges, erreurs, connexions, événements de sécurité, pour pouvoir détecter les comportements anormaux.
Problèmes rencontrés
- Choix des métriques et des logs à afficher pour ne pas surcharger les tableaux de bord.
- Compréhension de certains champs techniques spécifiques (par ex. codes d’erreurs Nginx, statuts Cisco).
Solutions mises en place
- Création de dashboards thématiques : système, réseau, web, base de données, etc.
- Utilisation de filtres et de recherches sauvegardées pour isoler rapidement un équipement ou un type d’événement.
- Analyse des TPs pour apprendre à reconnaître des patterns d’attaques / incidents.
Résultats et validation de l’AC
L’activité du SI est visible et compréhensible via Kibana, ce qui permet de surveiller les machines et équipements dans leur ensemble. L’AC35.01Cyber est validé par ces mises en place.
Documents associés
-
Contexte
Les TPs associés à la SAE 5.Cyber.03 incluent des scénarios d’attaques, de tests de vulnérabilité ou d’incidents, qui doivent être observés dans Elastic.
Objectifs
Appliquer une méthodologie rigoureuse pour tester la remontée des logs, la détection d’événements et la pertinence des dashboards.
Problèmes rencontrés
- Synchronisation entre l’instant où l’on réalise le test (attaque / action) et l’apparition dans les logs.
- Identification du bon index / dashboard pour retrouver l’événement généré.
Solutions mises en place
- Réalisation de tests étape par étape (un seul changement à la fois) pour lier cause et effet.
- Utilisation de filtres par timestamp, adresse IP, utilisateur pour retrouver rapidement les événements.
- Documentation des scénarios de tests dans le compte rendu TPs.
Résultats et validation de l’AC
Les tests montrent que les événements attendus sont bien visibles dans Elastic, et que la méthodologie permet de valider ou non la configuration. L’AC35.02Cyber est validé par cette approche structurée.
Documents associés
-
Contexte
À partir des TPs et des scénarios de la SAE 5.Cyber.03, j’ai dû analyser certains incidents (erreurs applicatives, tentatives de connexion, anomalies réseau) et en déduire une réaction adaptée.
Objectifs
Être capable de diagnostiquer un incident à partir des logs et de proposer des actions (correction, blocage, durcissement, alerte).
Problèmes rencontrés
- Distinguer un vrai incident (attaque, dysfonctionnement) d’une simple erreur ponctuelle.
- Suivre la chaîne d’événements (cause → conséquences) dans les logs.
Solutions mises en place
- Analyse chronologique des logs autour de l’incident (avant / pendant / après).
- Recoupement entre plusieurs sources (web, système, réseau) pour confirmer l’incident.
- Proposition de mesures : correction config, renforcement des règles, surveillance renforcée.
Résultats et validation de l’AC
Les analyses d’incidents montrent une capacité à comprendre ce qui s’est passé et à suggérer des actions concrètes, ce qui valide l’AC35.03Cyber.
Documents associés
-
Contexte
Dans la SAE 5.Cyber.03, j’ai dû non seulement installer Elastic, mais aussi administrer la plateforme : ajouter de nouvelles sources, ajuster les dashboards, gérer les pipelines de logs.
Objectifs
Assurer que la plateforme de supervision reste opérationnelle, pertinente et exploitable dans le temps.
Problèmes rencontrés
- Problèmes de remontée de certains logs (Cisco, services particuliers).
- Nécessité d’ajuster la configuration quand la structure du SI supervisé évolue.
Solutions mises en place
- Configuration et maintenance de Logstash pour intégrer proprement les logs réseau.
- Modification des fichiers de configuration des Beats lors de l’ajout de nouveaux services.
- Adaptation des dashboards Kibana pour suivre les nouveaux indicateurs ou équipements.
Résultats et validation de l’AC
L’outil de supervision est géré comme un véritable composant du SI : configuration, mises à jour, adaptation. L’AC35.04Cyber est validé par la capacité à administrer Elastic et ses agents.
Documents associés