Catégorie : Non classé

• Stage de 2ème année – Polaris : Nantes Métropole

  

  Introduction

  Lors de mon stage de deuxième année, j’ai eu la chance de rejoindre à nouveau l’unité du DRN de Nantes Métropole. Le projet qui m’a été confié portait sur l’automatisation massive de la mise à jour du firmware des switchs.

  L’infrastructure gérée par l’équipe couvre plus de 400 sites répartis dans toute la ville. Dans ce contexte, les mises à jour logicielles représentent une opération sensible et chronophage lorsqu’elles sont réalisées manuellement. L’objectif du projet était donc de concevoir une solution fiable permettant d’industrialiser ce processus tout en limitant les risques liés à l’administration de masse.

  Automatisation avec Ansible et NetBox

  La solution développée repose sur l’utilisation d’Ansible pour l’automatisation et de NetBox comme source centrale d’inventaire. NetBox est un outil « source de vérité » permettant de faire l’inventaire exhaustif de son parc informatique. Ayant travaillé sur Netbox lors de mon stage de 1ère année ce projet s’inscrit dans la continuité de ce que j’ai pu accomplir avec l’équipe du DRN.

  Création du playbook : Un inventaire dynamique

  Grâce au plugin d’inventaire dynamique netbox.netbox.nb_inventory, les informations des équipements concernés sont récupérées via une API (REST) selon plusieurs critères définis dans NetBox. L’inventaire utilisé par le playbook est ainsi généré directement à partir des données présente dans NetBox, ce qui permet de travailler sur un parc d’équipements cohérent et toujours à jour.

  Avant toute intervention sur l’environnement de production, j’ai mis en place un laboratoire de test afin de reproduire une architecture proche de celle utilisée par l’équipe réseau. Cet environnement comprenait une machine Linux exécutant Ansible, une instance NetBox et un switch Cisco utilisé pour les expérimentations. Cette phase m’a permis de valider l’intégration entre les différents composants et de tester les modules réseau fournis par Ansible.

  Fonctionnement du playbook

  

  Le cœur du projet repose sur un playbook chargé d’orchestrer le processus de mise à jour. Lors de son exécution, Ansible se connecte aux équipements via SSH en utilisant le mode network_cli. Le playbook commence par récupérer les informations matérielles du switch grâce au module ios_facts.

  Ces informations permettent de vérifier que le modèle détecté correspond bien à celui référencé dans NetBox. En cas d’incohérence, l’exécution du playbook est interrompu afin d’éviter toute mise à jour sur un équipement incorrect. Une seconde vérification concerne l’espace disponible dans la mémoire flash du switch. Le playbook extrait les informations du système de fichiers et compare l’espace libre avec la taille de l’image firmware à installer.

  Lorsque toutes les conditions sont réunies, un handler est déclenché afin de lancer les étapes de transfert et d’installation du firmware. Cette organisation permet de séparer clairement les phases de vérification et les actions critiques.

  

  Détail du fichier d’inventaire : ios15.2_7_E12_inventory.yml

  Détail des taches du playbook : iosE12_firmware_update.yml

  Détail des taches du handler : handler.yml

  Choix du protocole de transfert du firmware

  Une partie importante du projet a consisté à déterminer la méthode la plus fiable pour transférer les images firmware vers les switchs. Plusieurs scénarios ont été étudiés autour du protocole SCP, en mode push et pull, avec le switch configuré comme serveur dans certains cas. Ces tests ont cependant révélé plusieurs limites. Selon les modèles, les switchs Cisco gèrent difficilement le rôle de serveur SCP, notamment en raison de contraintes matérielles et logicielles. De plus, cette architecture nécessitait l’ouverture de flux spécifiques sur le pare-feu afin de permettre les échanges avec la machine Ansible, ce qui augmentait indirectement la surface d’attaque de l’infrastructure.

  Afin de simplifier l’architecture et de limiter les risques de sécurité, la solution retenue a finalement été le téléchargement du firmware via HTTPS en mode client. Dans ce modèle, le switch récupère directement l’image depuis un serveur web, en utilisant un flux déjà autorisé sur l’infrastructure. Cette approche s’est révélée plus simple à maintenir et plus cohérente avec les exigences de sécurité du réseau.

  Gestion des contraintes liées au protocole SSH

  Lors du développement du playbook, certaines difficultés sont apparues lors de la connexion aux équipements réseau. Plusieurs modèles de switchs utilisent encore des clés d’algorithmes de chiffrement SSH anciennes qui ne sont plus activées par défaut sur les systèmes récents. Cette incompatibilité empêchait Ansible d’établir correctement les connexions avec certains équipements.

  Pour résoudre ce problème, le mode de connexion network_cli a été utilisé. Celui-ci s’appuie directement sur la configuration OpenSSH de la machine exécutant Ansible. Il a donc été nécessaire d’adapter cette configuration afin de permettre la prise en charge des algorithmes requis par certains équipements plus anciens.

  Résultat du projet

  Une attention particulière a été portée à la sécurisation du processus. Les différentes vérifications intégrées au playbook garantissent que les mises à jour ne sont exécutées que lorsque l’état de l’équipement correspond exactement aux conditions attendues.

  À l’issue du stage, le playbook était fonctionnel. Il constitue désormais une base solide pour automatiser la gestion des mises à jour du parc de switchs de Nantes Métropole et démontre l’intérêt de l’automatisation pour l’administration d’infrastructures réseau à grande échelle. Il servira également de template afin de de mettre à jour d’autres versions de firmware Cisco.

  Conclusion

  Ce stage m’a permis de travailler sur un projet concret d’automatisation réseau dans un environnement professionnel réel. Le développement du playbook Ansible et son intégration avec NetBox m’ont confronté aux enjeux de fiabilité, de sécurité et de gestion d’infrastructures à grande échelle.

  Cette expérience a renforcé mes compétences en automatisation et en administration réseau, tout en me donnant une meilleure compréhension des contraintes opérationnelles liées à la gestion d’un parc important d’équipements.

  7 mars 2026

  ---

• Projet GSB

  

  Contexte

  Dans le cadre de ce projet, nous travaillerons sur la création d’une infrastructure réseau pour une entreprise fictive : le laboratoire GSB. Le but : permettre aux visiteurs médicaux de saisir leurs comptes-rendus et leurs frais via une application interne hébergée sur des serveurs. Nous virtualiserons cet environnement à l’aide VMware :

  

  Analyse du cahier des charges

  Le cahier des charges imposait :

  • Accès à l’application via visite.gsb.coop

  Architecture avec :

  • un serveur web en DMZ,
  • un serveur BDD, un DNS et un serveur de sauvegarde
  • Services obligatoires : HTTPS, SSL/TLS, FTP sécurisé, authentification

  Phase 1 : Proposition d’équipements

  Nous allons dans le cadre du projet réaliser un devis fictif :

  devis_gsbTélécharger

  Matériel prévu :

  • 4 serveurs physiques
  • 1 switch 24 ports
  • 1 routeur Cisco
  • 1 poste client

  Nous réalisons également une maquette à l’aide de Packet Tracer avant de réellement mettre en place notre infrastructure réseau :

  

  Phase 2 : Mise en place des serveurs

  – Serveur Web (Linux + Apache + PHP 8.3)

  • Installation d’Apache, PHP et phpMyAdmin
  • Accès sécurisé en HTTPS
  • Page d’accueil liée à l’application
  • Pare-feu + permissions réduites

  – Serveur BDD (MariaDB)

  • Installation de MariaDB
  • Importation de 3 bases
  • Création d’utilisateurs avec droits limités

  – Serveur FTP sécurisé (SFTP)

  • Mise en place du service
  • Utilisateurs dédiés
  • Tests d’envoi/récupération de fichiers
  • Restrictions d’accès

  – Serveur de sauvegarde (Windows Server 2022)

  • Sauvegardes incrémentielles quotidiennes
  • Sauvegardes complètes hebdomadaires
  • Tests de restauration

  Phase 3 – DHCP & DNS

  Serveur DHCP

  • Installation du package dhcp-server sur Rocky Linux
  • Réservations d’adresses pour certains équipements
  • Service actif au démarrage + vérification des baux

  Serveur DNS

  • Zone DNS pour gsb.coop
  • Enregistrements A : visite.gsb.coop, ftp.gsb.coop, ns.gsb.coop…
  • Configuration complète (SOA, NS, PTR…)
  • Tests de résolution depuis toutes les machines

  Compétences mobilisées

  • Création d’un réseau segmenté (DMZ / PROD)
  • Routing, VLAN, adressage IP
  • Installation et sécurisation de serveurs Linux & Windows
  • Virtualisation VMware
  • Mise en place des services : Apache, MariaDB, DNS, DHCP, FTP et automatisation des sauvegardes

  Conclusion

  Ce projet m’a permis de concevoir une infrastructure réseau fonctionnelle en intégrant différents services tels que le web, les bases de données, DNS, DHCP, le FTP ou la sauvegarde. J’ai appris à faire coexister ces services de manière cohérente et à organiser mon travail efficacement. Cette expérience a renforcé mon intérêt pour les métiers de l’administration réseau et système.

  1 décembre 2025

  ---

• Stage de 1ère année – Polaris : Nantes Métropole

  

  Introduction

  J’ai récemment eu l’opportunité d’effectuer un stage enrichissant au sein de l’unité Réseau et Télécoms du Département des Ressources Numériques (DRN) de Nantes Métropole. Situé dans le bâtiment Polaris à l’Île de Nantes, ce stage m’a permis de plonger au cœur des infrastructures réseau d’une grande collectivité, avec une mission principale axée sur l’automatisation et une immersion concrète dans les opérations sur le terrain.

  Ma Mission Principale : L’Automatisation des Sauvegardes avec NetBox

  Ma tâche principale consistait à automatiser les sauvegardes de configurations des commutateurs (switchs) de Nantes Métropole en utilisant l’outil open-source NetBox. Ce projet s’est articulé autour du plugin ‘netbox-config-backup’ et de la bibliothèque Python ‘NAPALM’. Pour commencer, j’ai mis en place un environnement de test avec Lubuntu sur VirtualBox afin de comprendre l’architecture de NetBox. L’application repose sur des services PostgreSQL, Redis, Nginx/Apache et Gunicorn. Cette phase m’a permis de tester la compatibilité du plugin ‘netbox-config-backup’ avec différents équipements, notamment des switchs Cisco 2960, C1000 et Alcatel OS6360, validant ainsi sa fiabilité pour la récupération des configurations via SSH. J’ai également pû résoudre des problèmes de dépendances et de drivers, étape importante pour le déploiement du plugin.

  

  Avec mon tuteur, Adrien Grellier, nous avons mis à jour NetBox en production en utilisant Ansible, garantissant un déploiement sécurisé avec un fichier de configuration lisible. J’ai ensuite enrichi la base de données avec des informations sur plus de 900 switchs, puis automatisé les sauvegardes en utilisant un script Python pour convertir des fichiers CSV en JSON, facilitant ainsi la planification des sauvegardes. L’évaluation de la charge réseau en production a été essentielle pour déployer cette automatisation.

  Découverte du Métier : Interventions sur Site

  Au-delà de ma mission principale, j’ai eu l’opportunité de participer à diverses interventions sur le terrain, ce qui m’a offert une vision complète du quotidien d’un technicien réseau. J’ai par exemple assisté au diagnostic d’une rupture réseau sur le site Loire-Chezine, liée à une erreur de câblage de fibre, et découvert des outils spécifiques comme le Visual Fault Locator (VFL). J’ai également participé à l’installation, au remplacement et à la configuration d’équipements réseau tels que des switchs, des bornes Wi-Fi et des bornes DECT sur de nombreux sites.

  J’ai eu la chance de visiter deux data centers partenaires, observant des opérations sensibles comme le remplacement d’un switch LEAF, ce qui a élargi ma compréhension des environnements à haute disponibilité. A la fin de mon stage, j’ai eut la responsabilité de stacker 3 switchs C-1000 48port pour la médiatèque Jacques Demy (HStack). Enfin, j’ai pu découvrir des outils essentiels aux opérateurs du DRN tels que Centreon pour le monitoring, Efficient IP pour la gestion des adresses IP, et Palo-Alto pour le pare-feu, ainsi que NetBox pour la documentation exhaustive des équipements.

  Bilan

  Ce stage a été une expérience déterminante, renforçant mon intérêt pour les métiers des systèmes informatiques, de l’infrastructure et du réseau. Sur le plan technique, j’ai développé des compétences en gestion de bases de données avec le déploiement et l’administration de services comme Redis et PostgreSQL. J’ai également acquis une expérience en développement avec l’utilisation de Python. Ma compréhension de la configuration réseau s’est approfondie avec l’installation physique et la configuration de switchs, ainsi que la réalisation de câblage réseau. Au-delà des compétences techniques, j’ai renforcé mes soft skills, notamment le travail d’équipe, la présentation orale, la prise d’initiative, le savoir-être en milieu professionnel et le développement de l’esprit critique face aux décisions techniques.

  Conclusion

  Ce stage à Nantes Métropole a été une immersion complète et formatrice. J’ai acquis des compétences techniques solides en automatisation réseau et en gestion d’infrastructures, tout en découvrant la réalité du terrain et l’importance d’une gestion rigoureuse pour assurer la disponibilité des réseaux. Je remercie chaleureusement toute l’équipe du DRN, et en particulier mon tuteur Adrien GRELLIER, ainsi que mes collègues Élise CAPPON, Nicolas LAVERGNE, Kévin GREMERET et Michel MARTINEAU, pour leur accompagnement et leurs précieux conseils. Cette expérience a consolidé mon ambition de poursuivre ma carrière dans ce domaine passionnant.
  
  Pour plus d’information il est possible pour vous de retrouver mon Rapport de stage 1ère année ici

  25 juin 2025

  ---

• Projet Docker

  Contexte

  Dans le cadre du projet Docker-2025, nous sommes stagiaire au sein de l’entreprise STESIO. Notre mission est le développement d’une application de gestion des ressources humaines pour la société ‘X’ . Ce projet permet de mettre en place une infrastructure haute disponibilité, comprenant un serveur d’application et une base de données MariaDB.

  

  Qu’est ce que Docker ?

  Docker est une plateforme de virtualisation légère qui permet de créer, déployer et gérer des applications dans des conteneurs. Ces conteneurs encapsulent tout ce dont une application a besoin pour fonctionner, y compris le code, les bibliothèques et les dépendances, ce qui garantit une cohérence entre les environnements de développement, de test et de production. Nous allons également utiliser son interface graphique : Portainer

  Pourquoi Docker ?

  Docker offre de nombreux avantages pour le développement et le déploiement d’applications. Ses conteneurs sont portables, fonctionnant sur n’importe quel système compatible, ce qui simplifie le déploiement. Chaque conteneur est isolé, évitant les conflits entre applications et renforçant la sécurité. Docker permet aussi une scalabilité facile, avec la possibilité d’ajouter ou de retirer des conteneurs rapidement. De plus, les conteneurs sont légers et démarrent plus vite que les machines virtuelles, grâce à leur partage du même noyau. Enfin, des outils comme Docker Compose et Docker Swarm rendent la gestion des conteneurs simple et efficace.

  Mission

  Nous allons déployer un conteneur utilisant l’image MariaDB et un autre avec l’image phpMyAdmin pour gérer la base de données. Ensuite, nous mettrons en place deux conteneurs Apache servant de serveurs web, tout en configurant HAProxy pour assurer la haute disponibilité. Ces serveurs web hébergeront une page affichant dynamiquement les rangs de notre base de données.

  Étape 1 : MariaDB & phpMyAdmin

  Tout d’abord, nous allons déployer un conteneur MariaDB à l’aide la commande :

  docker run --name mariadb -e MYSQL_ROOT_PASSWORD=password -d mariadb:latest

  ‘-e’ : Permet de définir une variable d’environnement, en l’occurence notre mot de passe en tant que root : MYSQL_ROOT_PASSWORD=password, ‘-d ‘ lance le container en arrière plan.

  Nous vérifions le bon fonctionnement de l’image en utilisant la console :

  

  Maintenant, déployons le container phpMyAdmin :

  docker run --name phpmyadmin -d -e PMA_HOST=mariadb -p 8080:80 phpmyadmin/phpmyadmin

  Ici, PMA_HOST=mariadb spécifie que phpMyAdmin se connecte au conteneur MariaDB. On pourra accéder à phpMyadmin via le port 8080

  

  Étape 2 : HAproxy & serveurs Apache

  Afin de déployer notre service HAproxy et nos serveurs Apache, nous utilisons le fichier docker compose suivant :

  version: '3.8'
  services:
    haproxy:
      image: haproxy:latest
      ports:
        - "80:80"
      volumes:
        - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg
      networks:
        - haproxy-net
    srvapache1:
      image: php:apache
      networks:
        - haproxy-net
    srvapache2:
      image: php:apache
      networks:
        - haproxy-net
  

  Il nous faudra également créer un fichier de configuration nommé haproxy.cfg :

  global
      log stdout format raw local0
  defaults
      log global
      mode http
      timeout connect 5000ms
      timeout client 50000ms
      timeout server 50000ms
  frontend http_front
      bind *:80
      default_backend http_back
  backend http_back
      server srvapache1 srvapache1:80 check
      server srvapache2 srvapache2:80 check

  Nous déployons ainsi notre service haproxy ainsi que nos 2 serveurs Apache à l’aide de la commande : docker compose up -d

  Etape 3 : Connexion PDO

  Nous allons maintenant lier nos serveurs Apache à notre base de donnée grâce à une connexion PDO. Nous créons alors un fichier « connexion.php » :

  <?php
  // Paramètres de connexion à la base de données
  $db       = "dbcontact";         // Nom de la base de données
  $dbhost   = "172.22.0.3";        
  $dbport   = 3306;                // Port par défaut pour MySQL/MariaDB
  $dbuser   = "user";              
  $dbpasswd = "secret";            
  try {
      // Création de la chaîne de connexion DSN (Data Source Name)
      $dsn = "mysql:host=$dbhost;port=$dbport;dbname=$db;charset=utf8mb4";
      
      // Création d'une instance PDO pour se connecter à la base de données
      $connexion = new PDO($dsn, $dbuser, $dbpasswd);
      
      // Configuration de PDO pour lancer des exceptions en cas d'erreur
      $connexion->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
  } catch (PDOException $e) {
      die("Erreur de connexion : " . $e->getMessage());
  }
  ?>

  Ensuite nous allons éditer notre fichier index.php :

  <html>
    <body>
      <h1>Hello!</h1>
      <?php
        // Inclure le fichier de connexion
        include 'connexion.php';
        // Exécuter la requête pour récupérer les données
        $query = "SELECT * FROM personne";
        $stmt = $connexion->prepare($query);
        $stmt->execute();
        // Récupérer les résultats
        $resultats = $stmt->fetchAll(PDO::FETCH_ASSOC);
        // Afficher les résultats
        if ($resultats) {
            echo "<h2>Liste des personnes :</h2>";
            echo "<ul>";
            foreach ($resultats as $personne) {
                echo "<li>" . htmlspecialchars($personne['nom']) . " - " . htmlspecialchars($personne['age']) . " ans</li>";
            }
            echo "</ul>";
        } else {
            echo "Aucune personne trouvée.";
        }
       // Afficher le nom d'hôte
        $hostname = gethostname();
        echo " hostname : " . htmlspecialchars($hostname);
      ?>
    </body>
  </html>

  Afin de vérifier le bon fonctionnement de notre service haute disponibilité, nous modifions la page index de nos 2 serveurs apache afin qu’elles retournent le nom d’hôte de leur « machine », pour cela nous utiliserons la fonction .php gethostname()

  Pour un aspect un peu plus plaisant, je me suis permis de rajouter un du CSS à notre page :

  

  En multipliant les requêtes HTTP, on constate que le nom d’hôte change, ce qui confirme le bon fonctionnement de la répartition des charges entre les deux hôtes.

  

  Résultat :

  Notre connexion PDO est fonctionnelle, notre page web accède à la base de donnée et affiche les informations de manière dynamique ! Lorsque nous actualisons notre page, les 2 serveurs Apache se relayent de sorte à gérer les nombreuses requêtes. On constate que les nom d’hôtes changent à chaque requête signifiant qu’il s’agit d’un serveur différent.

  9 avril 2025

  ---

• Projet Python

  Automatisation complète de la gestion des utilisateurs

  Contexte du projet

  Dans le cadre de ma formation en BTS SIO, option SISR, j’ai eu l’opportunité de participer à un projet centré sur la gestion et la manipulation de bases de données. L’objectif était de mettre en pratique les compétences acquises en SQL et en Python afin de concevoir une chaîne d’automatisation complète, permettant de manipuler, administrer et stocker efficacement des données.

  Python, en tant que langage informatique portable est, et sera de plus en plus utilisé pour assurer des tâches d’administration système de part sa multi-compatibilité.

  L’objectif était de construire une solution cohérente permettant :

  • La normalisation d’identités utilisateurs
  • La génération de logins conformes aux standards d’entreprise
  • La création automatisée de comptes et bases MariaDB
  • L’application stricte du principe du moindre privilège
  • L’intégration à un environnement Active Directory
  • La génération de mots de passe robustes

  Les différentes étapes du projet :

  I – Lecture et écriture de fichiers CSV – Base du projet

  Le point de départ repose sur la lecture d’un fichier CSV contenant :

  Prenom;NOM
  Alain;Lambert
  Jean-Baptiste;Le Floc’h
  Sophie;O’Connor
  François Xavier;DE LA VILLETANAY
  Émilie;DUPONT-THIBERT
  Anaïs;MARTÍNEZ-GÓMEZ
  Pierre-Paul;D’ALEMBERT
  Marie-Josée;ST-PIERRE 

  Le script loginNormalizer.py génère automatiquement des logins au format normalisé :

  login
  alambert
  jblefloch
  soconnor
  fxdelavilletanay
  edupontthibert
  amartinezgomez
  ppdalembert
  mjstpierre

  Le projet a ensuite été complexifié pour gérer des cas réels d’entreprise :

  • Prénoms composés → utilisation des initiales
  • Noms à particules (de, du, le…)
  • Accents
  • Apostrophes
  • Tirets
  • Caractères spéciaux

  II – Création d’une base MariaDB

  Le projet a ensuite intégré une dimension base de données. Il ne s’agissait plus seulement de générer des logins, mais de créer un environnement sécurisé pour chaque utilisateur.

  Une base dédiée est créée, un utilisateur associé est configuré, et les privilèges sont strictement limités à sa propre base. Le principe du moindre privilège est appliqué : aucun accès aux autres bases, aucune opération administrative possible.

  Accès distant

  Maintenant nous allons permettre un accès distant à partir de l’adresse ipv4 d’une machine de sorte à simuler un cas d’utilisation depuis un réseau externe: pour cela nous devrons éditer les fichier de configuration de mariadb et du serveur Apache :

  

  

  III – Intégration au domaine et extraction Active Directory

  Pour rapprocher le projet d’un environnement professionnel, une station Windows 10 a été intégrée au domaine stesio.jol. Les scripts PowerShell extractUsersPerpignan.ps1 puis extractUsersToulouse.ps1 ont permis d’extraire des utilisateurs depuis différentes unités d’organisation vers des fichiers CSV structurés. À partir de ce moment, les données utilisées provenaient d’un véritable annuaire Active Directory, ce qui ancre le projet dans une logique d’infrastructure réelle.

  

  IV – Génération et validation de mots de passe robustes

  La sécurisation des accès constitue une étape essentielle. Le script createPassword.py génère automatiquement des mots de passe respectant une politique stricte de complexité et d’unicité.

  extrait du fichier de sortie :

  password
  gVeu9.&*Y6w/
  z.fBPC2-4Bnw
  :P2yQ:*@5vqf
  fJV7xxeX=2+R
  Kdj9@9Us-9=t
  .H4?/=vHnu4+
  Lpz45aR6-I<x
  9m>.MCC7jz$W
  3#41ITw%!kqG
  x+5@&7PlR4T4

  V – Consolidation des données utilisateurs

  Une fois les utilisateurs extraits et les mots de passe générés, le script genererLoginToulouse.py centralise les informations, applique la normalisation et produit un fichier consolidé prêt pour la création des comptes MariaDB. On passe alors d’une succession de traitements isolés à une véritable chaîne de transformation cohérente.

  VI – Génération automatisée des scripts SQL de création

  Afin d’industrialiser le déploiement, genererScriptSqlCreate.py produit automatiquement un script SQL permettant de créer les utilisateurs MariaDB, leurs bases dédiées et leurs privilèges associés.

  Chaque utilisateur dispose de sa propre base, préfixée pour identifier l’environnement, et ne peut manipuler que ses propres données. Cette automatisation permet un déploiement rapide, homogène et sécurisé.

  

  VII – Génération automatisée des scripts SQL de suppression

  La gestion du cycle de vie ne s’arrête pas à la création. Le script genererScriptSqlDrop.py génère les instructions nécessaires pour supprimer proprement les utilisateurs et leurs bases associées. Cette étape garantit qu’aucun accès résiduel ne subsiste et complète l’approche d’automatisation industrielle.

  

  Conclusion :

  Ce projet démontre l’évolution d’un simple script Python vers une automatisation complète de la gestion des utilisateurs dans un environnement structuré. En reliant Active Directory, la normalisation des identités et l’administration MariaDB, j’ai construit un workflow cohérent, sécurisé et reproductible.

  Au-delà de l’aspect technique, il reflète ma capacité à penser un projet dans sa globalité, à automatiser intelligemment et à appliquer des principes professionnels de gestion des accès.

  Livrables – projet pythonTélécharger

  12 janvier 2025

  ---

• Veille technologique

  Comment protéger une entreprise contre des attaques de type ransomware ?

  Comme nous l’indique sa construction étymologique, « ransom » signifie rançon, le suffixe « ware » dans ce contexte est dérivé du mot « malware ». Un malware étant un logiciel créé à des fins malveillantes, il fait partie de la famille des « virus»

  Le ransomware est donc un malware ayant comme but de faire payer à sa victime une rançon, par le chantage, après avoir chiffré les données personnelles de l’utilisateur. Celui-ci aura alors besoin d’une clé pour regagner l’accès à ses données, en échange d’une somme plus ou moins conséquente, souvent réclamée en cryptomonnaie.

  Au sein d’une entreprise traitant des données sensibles, ce type d’attaque pourrait faire de graves dégâts, empêchant possiblement aux opérateurs d’accéder à leurs outils, ou encore entachant la réputation de l’entreprise quant à la sécurisation des données. Afin de lutter contre ce phénomène, nous allons mettre en place une veille technologique dans laquelle nous déterminerons 3 principaux objectifs :

  • Définir un plan d’action efficace pour lutter/se protéger contre ce type d’attaque.
  • S’informer sur les pratiques actuelles mises en place par les attaquants externes.
  • Réduire les risques qu’un utilisateur puisse devenir la victime d’un ransomware.

  Pour se faire, nous avons utilisé des outils de curation comme ‘scoop.it’ et ‘netvibes.com’. De nombreuses sources ont été parcourues et beaucoup d’informations pertinentes en sont parvenues.

  Retrouvez les Sources ici.

  Ici, un condensé synthétique des information obtenues par cette veille technologique sous la forme d’un diaporama :

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  • 

  10 décembre 2024

  ---