Documentation Index
Fetch the complete documentation index at: https://snakysec.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
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 |
| 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 |
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 |
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 |
