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.
Calendrier des tests DR
Principe
Tier 2 BCMS-grade exige au moins 1 test annuel par procédure critique.
Notre stratégie répartit les tests sur 4 trimestres pour éviter la
saturation et garantir une couverture continue.
Chaque test produit un procès-verbal dans docs/dr/test-results/ (template
templates/post-incident-report.md).
Calendrier annuel
Q1 — janvier-mars
Test : Restauration PostgreSQL PITR
- Runbook : 01-restore-postgres-pitr.md
- Environnement : pré-prod (jamais sur prod)
- Cible : restore vers
target-time = NOW() - 1 hour puis pg_promote()
- Validation : smoke-after-restore.sh OK + chain Ed25519 valid
- Durée prévue : 2 heures
- Procès-verbal :
docs/dr/test-results/YYYY-Q1-postgres-pitr.md
Q2 — avril-juin
Test : Restauration Vault depuis snapshot raft
- Runbook : 02-restore-vault-from-snapshot.md
- Environnement : pré-prod
- Cible : démarrer Vault from-scratch + restore snapshot J-1 + unseal Shamir
- Validation :
vault status sealed=false + AppRole login OK + secrets accessibles
- Durée prévue : 1 heure
- Procès-verbal :
docs/dr/test-results/YYYY-Q2-vault-restore.md
Q3 — juillet-septembre
Test : Rotation Shamir + récupération enveloppe trustee
- Runbook : 06-rotate-shamir-keys.md
- Environnement : pré-prod (rotation simulée), prod (récupération enveloppe trustee + re-scellage)
- Cible :
vault operator rekey + nouvelles 5 shares + dépôt enveloppe notaire
- Validation : Vault unseal avec nouvelles shares fonctionne + procès-verbal notaire signé
- Durée prévue : 4 heures (incl. RDV notaire)
- Coût : ~50-100€ (acte simple)
- Procès-verbal :
docs/dr/test-results/YYYY-Q3-shamir-rotation.md
Q4 — octobre-décembre
Test : Exercice incident complet en mode “blanc”
- Runbook : 05-recover-from-ransomware.md + tous les IR
- Environnement : env de test isolé (pas pré-prod, pas prod)
- Cible : simulation ransomware end-to-end, incl. rédaction notif CSIRT-FR + CNIL fictives
- Validation : 7 phases parcourues, MTTR < 12h, notifs rédigées en <24h fictives
- Durée prévue : 1 journée (8h consolidées)
- Procès-verbal :
docs/dr/test-results/YYYY-Q4-incident-blanc.md
Tests mensuels (smoke checks)
En complément du cycle trimestriel, le 1er samedi de chaque mois :
- Restore partial artifacts : 1 client random, restore depuis backup vers env de test
- Verify chain audit log : trigger via UI, vérifier
valid: true
- Verify Sentry monitor heartbeats : vérifier que tous les jobs DR ont check-in OK les 7 derniers jours
Durée : 30 minutes / mois. Procès-verbal abrégé dans
docs/dr/test-results/YYYY-MM-monthly-smoke.md.
Tests automatiques quotidiens
Sans intervention humaine, les vérifications suivantes tournent en continu :
| Test | Fréquence | Source |
|---|
| dr-verify smoke check | Daily 06:30 UTC | ofelia → dr-runner |
| GitLab CI dr:verify | Daily 07:00 UTC | OIDC WIF + restic check |
| Sentry monitor check-ins | Real-time | Backup scripts via sentry_check_in() |
| Audit chain integrity | Daily (worker) | audit-chain-worker.ts |
| Anchor signing | Daily 23:00 UTC | audit-chain-worker.ts |
Échec de l’un déclenche alerte Sentry + email DR Owner immédiat.
Tests à l’occasion (ad-hoc)
| Déclencheur | Test à effectuer |
|---|
| Mise à jour Vault majeure (X.Y → X.Y+1) | Test runbook 02 sur env de test avant déploiement prod |
| Mise à jour pgbackrest | Test runbook 01 sur env de test |
| Nouveau fournisseur S3 | Test pull/push depuis dr-runner |
| Recrutement 1er salarié | Test transmission keyholders (si élargissement Shamir) |
Engagement annuel
Volume total : 5 tests (1 mensuel × 12 mois + 4 trimestriels) = ~30 procès-verbaux/an.
Effort total : ~12-15 jours-homme/an. Tenable solo.
Reporting annuel
Synthèse annuelle dans docs/dr/test-results/YYYY-annual-summary.md :
- Liste de tous les tests exécutés
- Taux de succès / échec
- MTTR moyen mesuré
- Tests qui ont dépassé leur RTO cible (et pourquoi)
- Actions correctives mises en œuvre
- Sujets pour la roadmap N+1
À montrer en RFP client : preuve concrète de la maturité Tier 2.
| Version | Date | Auteur |
|---|
| 1.0 | 2026-04-26 | Nicolas Schiffgens |