Définis RPO, RTO et dépendances de reprise

01Distingue les deux objectifs

RPO — Recovery Point Objective
→ perte de données maximale acceptable exprimée en temps

RTO — Recovery Time Objective
→ durée maximale visée avant rétablissement d'une capacité acceptable

Exemple :

RPO = 4 h
→ les données restaurées ne doivent pas être plus anciennes que quatre heures

RTO = 8 h
→ le service doit être restauré et validé dans les huit heures

02Pars des conséquences métier

Combien de commandes peuvent être ressaisies ?
Combien de temps une procédure manuelle reste viable ?
À partir de quand les obligations contractuelles sont-elles menacées ?
Quels dommages humains, financiers ou réputationnels apparaissent ?
Quel niveau de service minimal est acceptable ?

Un objectif très court augmente généralement le coût et la complexité de la solution.

03Ne confonds pas objectif et capacité

Objectif déclaré
→ RTO 2 h

Test observé
→ reprise validée en 6 h

Conclusion
→ la capacité actuelle ne respecte pas l'objectif

Réduire artificiellement la mesure ou augmenter l’objectif sans décision métier masque l’écart.

04Cartographie les dépendances

Un service ne peut pas être rétabli avant les éléments dont il dépend.

05Construis une séquence minimale

1. Coeur réseau
2. DNS interne
3. Service identité
4. Base ERP
5. ERP commandes
6. Portail client

L’ordre peut varier selon l’architecture. Il doit être documenté et testé.

06Observe l’erreur intentionnelle

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/recovery-sequence.csv"

Le lab place volontairement :

SRV-106 Portail client → séquence 3
Dépendances → SRV-103 + SRV-105

Mais SRV-105 est en séquence 5. Le résultat attendu est :

BLOCK_DEPENDENCY_ORDER

07Relie fréquence de sauvegarde et RPO

RPO 1 h
→ une sauvegarde quotidienne ne suffit pas

RPO 24 h
→ une copie quotidienne peut convenir si elle réussit et reste restaurable

RPO quasi nul
→ réplication, journalisation ou architecture spécialisée, avec coûts et risques supplémentaires

La fréquence seule ne suffit pas : il faut intégrer la durée du job, les échecs et le moment du dernier point sain.

08Relie architecture et RTO

Le RTO dépend de :

- temps de détection et de décision
- disponibilité des personnes
- accès aux procédures et secrets de reprise
- capacité de calcul et de stockage
- durée de restauration
- ordre des dépendances
- validation technique et métier
- risques de réinfection

La vitesse de copie n’est qu’une partie du délai.

09Prépare plusieurs modes de continuité

Mode dégradé
→ fonctions minimales ou procédure manuelle

Reprise technique
→ reconstruction des services prioritaires

Reprise métier
→ validation des données et processus

Retour à la normale
→ réconciliation, surveillance et fermeture des mesures temporaires

Le PCA maintient ou adapte l’activité ; le PRA organise la reprise des systèmes. Les deux doivent rester cohérents.

10Produis une décision testable

Service : ERP commandes
RTO : 8 h
RPO : 4 h
Dépendances : réseau, DNS, identité, base
Mode dégradé : saisie limitée hors ligne
Responsable métier : ventes
Responsable technique : IT
Test : restauration semestrielle et exercice annuel
Preuve : transaction validée et mesures horodatées