> ## Documentation Index > Fetch the complete documentation index at: https://docs.snakysec.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](./02-asset-inventory.md)) et la stratégie de sauvegarde ([03-backup-strategy.md](./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](./runbooks/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](./runbooks/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](./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](./runbooks/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](./runbooks/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](./runbooks/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](./runbooks/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 |