Situation Pro : Protection et Résilience du Patrimoine (Sauvegarde)

1. Contexte et Objectifs

Suite à la fusion entre Solutech et Horizon, l'instance GLPI est devenue le centre névralgique de l'organisation. Elle contient l'intégralité de l'inventaire matériel, les contrats de maintenance et l'historique du support.

L'objectif de cette mission était de garantir la continuité d'activité (PCA) en mettant en place une stratégie de sauvegarde industrielle. Il s'agissait de passer d'une manipulation manuelle à un automate capable de sécuriser les données contre les pannes matérielles ou les cyberattaques (Ransomwares).

2. Besoins identifiés

  • Intégrité des données : Extraire la base de données MariaDB et les fichiers physiques (pièces jointes) sans corruption.
  • Sécurité et Confidentialité : Appliquer le principe du moindre privilège pour les opérations de maintenance.
  • Automatisation : Supprimer le risque d'oubli humain par une planification rigoureuse.
  • Gestion de la rétention : Maîtriser l'espace disque en gérant un historique de versions (Archives).
  • Traçabilité : Centraliser les journaux d'activité (logs) pour surveiller le bon fonctionnement du robot.

3. Solution technique retenue et justifications

Pour cette mission, j'ai implémenté une solution basée sur les standards Linux, privilégiant la robustesse et la sécurité :

  • Utilisateur de maintenance dédié :
    • Justification : Création d'un compte MariaDB prenom-sauvegarde possédant uniquement les droits de lecture (SELECT, LOCK TABLES). Cela respecte la ségrégation des tâches : même si le compte est compromis, l'attaquant ne peut pas supprimer la base de production.
  • Fichier de secrets client (.my.cnf) :
    • Justification : Permet une authentification automatique sans inscrire le mot de passe en clair dans le script Bash. Le fichier est sécurisé par un chmod 600.
  • Script Bash industriel :
    • Justification : Utilisation de variables pour la maintenabilité et vérification des codes de retour ($?). Le script stoppe son exécution et logue une erreur si le dump SQL échoue.
  • Logrotate (Gestion de la rétention) :
    • Justification : Utilisation de l'outil système pour gérer le roulement des archives. J'ai configuré une rétention de 5 archives historiques, garantissant ainsi 6 points de restauration disponibles en permanence.
  • Cron (Planification) :
    • Justification : Déclenchement automatique pour garantir un RPO (Recovery Point Objective) de 24 heures.
  • Standard FHS (Journaux) :
    • Justification : Centralisation du log dans /var/log/backup_solutech.log avec gestion des droits (chown), permettant une surveillance conforme aux normes professionnelles.

4. Réalisation (Ce que j'ai fait)

  1. Exploration technique : Identification de la structure de la base de données via des requêtes SQL (SHOW TABLES).
  2. Archivage du Filesystem : Utilisation de la commande tar pour compresser les répertoires critiques (/files, /config, /apache).
  3. Sécurisation : Création de l'utilisateur de maintenance et du fichier de configuration masqué.
  4. Développement de l'automate : Rédaction du script backup_solutech.sh incluant la gestion des logs et le transfert de propriété des fichiers.
  5. Configuration système : Mise en place de la règle de rotation dans /etc/logrotate.d/ et de la tâche planifiée via crontab.
  6. Test de résilience (Crash Test) : Simulation d'un sinistre total (suppression BDD et fichiers) suivie d'une procédure de restauration complète via les lignes de commande mysql et tar.

5. Preuves de réalisation finale

📸 Preuve 1 : Identification du patrimoine (SQL)

Affichage de la structure de la CMDB avant extraction. Exploration SQL

📸 Preuve 2 : Contrôle d'intégrité de l'archive

Vérification du contenu de la sauvegarde de configuration (tar -tvf). Vérification Archive

📸 Preuve 3 : Imputabilité du compte de maintenance

Preuve de l'existence du compte restreint dans le système MariaDB. Utilisateur Sauvegarde

📸 Preuve 4 : Industrialisation et Traçabilité

Contenu du répertoire de destination et journal de bord (/var/log) montrant un succès. Logs et Backups

📸 Preuve 5 : Rétention Système (Logrotate)

Résultat du mécanisme de rotation montrant le fichier actif et les archives historiques. Rotation Logrotate

📸 Preuve 6 : Planification du robot (Cron)

Programmation de la sauvegarde automatique dans la table Cron. Crontab

📸 Preuve 7 : Succès de la Restauration (Résilience)

Interface GLPI après le test de restauration : l'historique et les données sont de retour. Restauration GLPI