PRA, PCA et sauvegardes
Sommaire
Bloc B3.4 — protéger et archiver les données, organiser le plan de secours, assurer la traçabilité et la résilience face au ransomware.
1. PCA, PRA, RTO, RPO
| Terme | Définition |
|---|---|
| PCA — Plan de continuité d'activité | Dispositif visant à maintenir l'activité pendant l'incident, sans interruption perceptible (redondance, site secondaire actif). |
| PRA — Plan de reprise d'activité | Procédure pour redémarrer le service après une interruption acceptée : restauration, remontée des VM, bascule. |
| RTO — Recovery Time Objective | Durée maximale d'indisponibilité tolérée. « Combien de temps peut-on rester à l'arrêt ? » |
| RPO — Recovery Point Objective | Volume de données maximal que l'on accepte de perdre, exprimé en temps. « Jusqu'à quand peut-on remonter ? » |
Ces valeurs se fixent par service, en fonction de l'enjeu métier. Exemple de dimensionnement pour un studio de jeu vidéo :
| Service | RTO | RPO | Justification |
|---|---|---|---|
| Site web public (marketing) | 24 h | 24 h | Contenu statique, faible impact financier immédiat |
| Base de comptes joueurs | 1 à 4 h | 15 min | Service en production, données personnelles, impact direct sur les utilisateurs |
| Sources du jeu | 8 h | 1 h | Perte = travail des développeurs à refaire ; sauvegarde couplée au dépôt Git |
Un RPO de 15 minutes impose des sauvegardes ou une réplication toutes les 15 minutes : ce n'est pas un souhait, c'est une contrainte de conception qui a un coût.
2. La règle 3-2-1
- 3 copies des données (la production + 2 sauvegardes) ;
- sur 2 supports différents (disque local et NAS, bande, cloud) ;
- dont 1 hors site.
Une sauvegarde locale sur le serveur lui-même ne protège de rien face à un ransomware : le malware chiffre aussi le dossier de sauvegarde, puisqu'il est monté et accessible depuis la machine compromise. Idem pour un partage réseau monté en permanence avec des droits d'écriture.
Variante moderne : la règle 3-2-1-1-0 — dont 1 copie immuable ou hors-ligne, et 0 erreur lors du test de restauration.
3. La sauvegarde immuable
Sauvegarde qui, une fois écrite, ne peut plus être modifiée ni supprimée avant l'expiration d'une durée de rétention définie — y compris par un administrateur. Elle s'appuie sur des mécanismes de type WORM (Write Once Read Many) ou object lock.
C'est la parade aux ransomwares modernes, qui cherchent d'abord à détruire ou chiffrer les sauvegardes avant de s'attaquer à la production, précisément pour interdire la restauration et forcer le paiement.
Bonnes pratiques complémentaires :
- Chiffrer les sauvegardes (une copie volée reste inexploitable) ;
- Compte dédié au moindre privilège pour l'agent de sauvegarde ;
- Tester la restauration régulièrement et chronométrer : une sauvegarde jamais restaurée n'est pas une sauvegarde. C'est ce test qui valide, ou invalide, le RTO annoncé.
- Archivage légal : distinguer sauvegarde (reprise après incident) et archivage (conservation à valeur probante, sur une durée imposée par la réglementation).
4. Preuves numériques et forensic
Après un incident, l'objectif est de reconstituer la chronologie de l'attaque et de conserver des éléments recevables en justice.
- Ne pas travailler sur l'original : on fige le système et on travaille sur une copie.
- Hachage des journaux : calculer régulièrement une empreinte du fichier de log et la stocker sur un autre serveur. Si l'empreinte restait sur la machine compromise, l'attaquant modifierait le log puis recalculerait le hash : la falsification serait indétectable.
- Horodatage qualifié (eIDAS) : délivré par un prestataire de confiance, il lie une donnée à un instant avec une présomption de fiabilité, contrairement à une date système modifiable.
- Journalisation centralisée : envoyer les logs vers un serveur dédié en écriture seule.
- Chaîne de possession : tracer qui a manipulé quelle preuve, quand et comment.
Sources typiques d'une reconstitution : access.log d'Apache (URL suspectes, codes de retour),
auth.log (tentatives SSH, connexions réussies), journaux MySQL (requêtes anormales, volumétrie
d'export). Le rendu attendu est un tableau : date, heure, action, IP source, cible, impact DIC.