Conçois un socle de sauvegarde isolé, versionné et surveillé

L’idée reçue

« Les données sont copiées sur un autre disque, donc elles sont sauvegardées. »

Une copie accessible par les mêmes comptes, dans le même domaine de confiance et sans historique peut être chiffrée ou supprimée avec la source.

01Définis ce qui doit être restauré

Données métier
Bases de données
Configurations
Identités et annuaires
Secrets récupérables selon procédure
Code et infrastructure as code
Clés de licence et installateurs
Documentation de reprise
Catalogue des sauvegardes

Sauvegarder uniquement les fichiers utilisateurs ne suffit pas à reconstruire un service.

02Distingue les mécanismes

Mécanisme

But

Limite

Synchronisation

répliquer rapidement l’état courant

réplique aussi suppression ou chiffrement

Réplication

disponibilité et bascule

ne fournit pas forcément un historique sain

Snapshot

revenir à un état local

peut partager le même stockage et les mêmes privilèges

Sauvegarde

conserver des versions restaurables séparées

doit être testée et protégée

Ces mécanismes peuvent se compléter, mais ne sont pas interchangeables.

03Utilise une baseline explicite

Le lab applique une baseline pédagogique proche du principe 3-2-1 :

au moins 3 copies
sur au moins 2 types de support ou systèmes distincts
au moins 1 copie hors site
au moins 1 copie offline ou immuable

Cette baseline doit être adaptée à la mission, au volume, au risque et aux obligations de l’organisation.

04Sépare les domaines de confiance

Production compromise
→ les comptes de production ne doivent pas pouvoir détruire toutes les sauvegardes

Administrateur de sauvegarde compromis
→ une couche d'immuabilité ou une séparation supplémentaire doit limiter l'effacement

Cloud principal compromis
→ la copie de reprise ne doit pas dépendre uniquement du même tenant et des mêmes identités

La séparation organisationnelle et des accès compte autant que la distance physique.

05Protège confidentialité et intégrité

Chiffrement
→ protège les données sauvegardées contre la lecture non autorisée

Checksum ou contrôle d'intégrité
→ détecte une altération

Immutabilité
→ empêche modification ou suppression pendant une période définie

Versioning
→ conserve plusieurs états dans le temps

Les clés de chiffrement et leur récupération doivent être documentées séparément.

06Surveille la capacité réelle

- dernier succès
- durée du job
- volume attendu et volume copié
- espace restant
- erreurs et exclusions
- âge de la dernière copie saine
- date du dernier test de restauration
- couverture du périmètre

Un job vert peut avoir sauvegardé zéro donnée utile si le périmètre a changé.

07Observe la revue du lab

lab=/tmp/soria-cyber-vulnerability-resilience-$USER
bash module3-cyber-vulnerability-resilience.sh setup "$lab"
bash module3-cyber-vulnerability-resilience.sh run "$lab"
column -s, -t "$lab/output/backup-review.csv"

Résultats attendus :

BKP-101 → PASS_BASELINE
BKP-102 → BLOCK_RESILIENCE_GAP
BKP-103 → IMPROVE_MONITORING
BKP-104 → BLOCK_RESILIENCE_GAP
BKP-105 → PASS_BASELINE

08Traite les écarts

Copies insuffisantes
→ ajouter une copie indépendante

Même domaine de confiance
→ séparer identité, rôle et stockage

Pas d'offline ou immuable
→ créer une copie protégée contre l'effacement

Pas de monitoring
→ alerte sur échec, vieillissement et capacité

Test trop ancien
→ planifier une restauration contrôlée

Mission

Revois cinq plans de sauvegarde

Explique pourquoi BKP-102 et BKP-104 sont bloqués, pourquoi BKP-103 reste insuffisant malgré ses copies, puis propose une preuve vérifiable pour chaque correction.

✓À retenir

Une sauvegarde utile est complète, séparée, protégée, surveillée et restaurable. Le nombre de copies n’a de sens qu’avec des domaines de défaillance réellement distincts.