04 rto rpo matrix

Matrice RPO / RTO formalisée

1. Objet

Document de référence formalisant les engagements RPO/RTO par actif, opposable contractuellement aux clients (annexes DPA) et à un auditeur externe (ANSSI, pentest, RFP).

Cette matrice complète l’inventaire (02-asset-inventory.md) et la stratégie de sauvegarde (03-backup-strategy.md).

2. Définitions normatives

Terme	Définition	Source
RPO (Recovery Point Objective)	Quantité maximale de données acceptable à perdre, mesurée en temps. RPO 5min = perte max 5 min de données	ISO 22301:2019 §3.34
RTO (Recovery Time Objective)	Durée maximale acceptable entre la survenance d’un incident et la reprise du service	ISO 22301:2019 §3.35
MTPD (Maximum Tolerable Period of Disruption)	Durée au-delà de laquelle l’impact métier devient inacceptable (faillite, rupture contrat, sanction)	ISO 22301:2019 §3.20
WRT (Work Recovery Time)	Temps post-RTO nécessaire pour valider que les données restaurées sont cohérentes et utilisables	Pratique BCMS

Relation : RTO + WRT ≤ MTPD doit toujours être vérifié.

3. Engagements globaux plateforme

Métrique	Engagement V1	Justification
RPO global	5 minutes	pgbackrest WAL streaming continu
RTO global	4 heures	pgbackrest restore (~2h) + smoke (~30min) + buffer ops (~1h30)
WRT	1 heure	Vérification chaîne Ed25519 + count critical tables + spot-check audits
MTPD	12 heures	Au-delà : risque rupture contrat client + obligation notif CSIRT-FR

Cohérence : RTO 4h + WRT 1h = 5h ≤ MTPD 12h.

4. Matrice détaillée par actif

4.1 Actifs critiques (RPO ≤ 24h, RTO ≤ 2h)

Actif	Criticité	RPO	RTO	WRT	Source recovery	Runbook
PostgreSQL data	Critique	5 min	2h	30 min	pgbackrest PITR	01-restore-postgres-pitr.md
Audit log Ed25519 chain	Critique	5 min	2h	30 min (verify chain)	Inclus PostgreSQL	Idem
LogAnchor (Ed25519 sigs)	Critique	5 min	2h	15 min (verify sigs)	Inclus PostgreSQL	Idem
Vault secrets	Critique	24h	1h	30 min	Snapshot raft + unseal	02-restore-vault-from-snapshot.md
Shares Shamir Vault	Critique	N/A (offline)	1h max (récup notaire = 30min)	N/A	Trustee notaire	01-keyholders.md
Cert X.509 plateforme + clients	Critique	24h	1h	15 min	Vault	Idem 02
ClientSecret AES-256-GCM	Critique	5 min	2h	15 min	Inclus PostgreSQL + clé Vault	Idem 01
Comptes Entra (break-glass)	Critique	N/A (Microsoft SLA)	30 min	N/A	Compte break-glass + KeePass	N/A (responsabilité Microsoft)
DNS zone snakysec.com	Critique	30j	1h	15 min	Backup mensuel YAML	09-restore-dns.md

4.2 Actifs importants (RPO ≤ 24h, RTO ≤ 4h)

Actif	Criticité	RPO	RTO	WRT	Source recovery	Runbook
Artifacts (audits JSON, GRC docs)	Importante	24h	4h	30 min	restic OVH/Scaleway	04-restore-artifacts.md
Container images Docker	Importante	N/A (registry)	30 min	N/A	Docker registry GitLab	N/A
Code source applicatif	Importante	N/A (git)	30 min	N/A	Git remote + miroir	N/A
Worker BullMQ jobs en cours	Importante	N/A (idempotents)	30 min	N/A	Re-trigger après restart	07-restore-redis-bullmq.md
TLS certs Let’s Encrypt	Modérée	N/A	15 min	N/A	Re-issue ACME automatique	08-restore-tls-certs.md

4.3 Actifs faibles (récupération non critique)

Actif	Criticité	RPO	RTO	Stratégie
Logs Traefik	Faible	N/A	N/A	Régénérables, pas de backup nécessaire
AOF Redis	Faible	N/A	N/A	Jobs idempotents, restart à vide
Cache Next.js	Faible	N/A	N/A	Régénéré au démarrage
Sessions NextAuth	Faible	N/A	0 (déconnexion users acceptée)	Re-login après restore

5. Scénarios composites

5.1 Scénario “VPS détruit” (datacenter HS, ransomware total)

Étape	Durée cible	Action
Détection	0-15 min	Sentry alerte + monitoring uptime
Décision activation DR	15-30 min	DR Owner triage P1
Provisioning nouveau VPS OVH	30 min - 1h	OVH UI + bootstrap script
Bootstrap Docker stack	1h - 1h30	docker compose up -d, traefik ACME
Restore Vault (snapshot + unseal Shamir)	1h30 - 2h	Procédure runbook 02
Restore PostgreSQL (PITR)	2h - 3h30	Procédure runbook 01
Restore artifacts	3h30 - 4h	Procédure runbook 04 (parallèle si possible)
Smoke check + verify chain Ed25519	4h - 4h30	Script smoke-after-restore.sh
Communication clients (notif partielle)	4h30 - 5h	Email transactionnel
Reprise complète	≤ 5h	Inférieur à MTPD 12h ✓

5.2 Scénario “Corruption table audit log” (suppression accidentelle, bug import)

Étape	Durée cible	Action
Détection	0-10 min	Verify chain quotidien échoue → lockdown
Triage	10-20 min	DR Owner identifie le seq cassé via UI integrity tab
Décision PITR	20-30 min	Choix target-time pré-corruption
Backup base actuelle	30-45 min	Snapshot avant restore (sécurité)
Restore PostgreSQL PITR	45 min - 2h	pgbackrest restore —target-time
Verify chain Ed25519	2h - 2h30	verifyFullChain() doit passer
Reprise normale + audit log re-scellé	2h30 - 3h	Lift lockdown
Reprise complète	≤ 3h	Inférieur à MTPD 12h ✓

5.3 Scénario “Perte Vault uniquement” (corruption raft storage)

Étape	Durée cible	Action
Détection	0-5 min	Vault sealed automatiquement, app down
Récupération snapshot	5-15 min	restic restore latest
Vault operator raft snapshot restore	15-30 min	Procédure runbook 02
Unseal Shamir (3 shares Nicolas)	30-45 min	3 prompts interactifs
Restart app + re-init AppRole	45 min - 1h	Compose restart
Verify : login plateforme + 1 audit test	1h - 1h15	Smoke check fonctionnel
Reprise complète	≤ 1h15	Inférieur à MTPD 12h ✓

6. Engagements contractuels client

6.1 SLA contractualisable V1

Les CGU et DPA SnakySec V1 incluent les engagements suivants :

Engagement	Valeur	Mesure
Disponibilité plateforme (uptime)	99.5% mensuel	Monitoring uptime externe
RPO maximum garanti	24h	Sauvegarde quotidienne minimum
RTO maximum garanti	8h (vs 4h cible interne)	Marge de sécurité contractuelle
Notification incident significatif client	<4h	Email transactionnel + portail status
Notification breach data perso	<24h (vs 72h CNIL)	DPA RGPD art. 33

Marge de sécurité : engagements contractuels (RTO 8h) > cibles internes (RTO 4h) pour absorber imprévus (récupération enveloppe trustee, problème unseal, etc.) sans rupture contractuelle.

6.2 Pénalités

V1 : pas de pénalités contractuelles (négociation au cas par cas client par client). Phase 2 : grille de pénalités standard à formaliser (avoir prorata, exit assistance gratuite, etc.).

7. Limites et hors-périmètre

Cas	Engagement V1	Justification
Catastrophe régionale (multi-DC OVH HS)	Best effort, RTO 12-24h	Pas de multi-région V1, reconstruction manuelle
Acte malveillant interne (DR Owner compromis)	Procédure trustee + mandataire SASU, RTO ouvert	Scénario gravissime, plan continuité humaine activé
Incompatibilité réglementaire post-mise en demeure	Suspension service possible	Conformité prime sur disponibilité
Force majeure (guerre, pandémie majeure, cyberattaque étatique généralisée)	Best effort	Cas force majeure légale, exonération SLA

8. Mesure et amélioration continue

8.1 Métriques suivies

Métrique	Source	Fréquence
Uptime plateforme	Monitoring externe (UptimeRobot ou équivalent)	Mensuel
Durée last backup PostgreSQL	pgbackrest CLI	Quotidien (smoke check)
Durée last backup Vault	restic CLI	Quotidien
Résultat dernier test restore	docs/dr/test-results/	Trimestriel
Nombre incidents activant le plan DR	PlatformAuditLog action dr.activate	Mensuel
Durée moyenne incident (MTTR)	PlatformAuditLog start/end	Trimestriel

8.2 Revue annuelle

Le DR Owner revoit cette matrice annuellement, ou immédiatement si :

• Un test de restore dépasse le RTO cible
• Un incident réel dépasse le RTO contractuel
• Un changement architectural modifie significativement les volumétries
• Une évolution réglementaire impose un RPO/RTO inférieur

9. Validation

Version	Date	Auteur	Approbateur
1.0	2026-04-26	Nicolas Schiffgens	Nicolas Schiffgens