PD-47 — Sauvegarde PostgreSQL chiffrée avec PITR et traçabilité probatoire¶

1. Objectif¶

La User Story PD-47 contractualise un mécanisme de sauvegarde PostgreSQL automatisé, chiffré et traçable, garantissant :

• la restauration des métadonnées transactionnelles ProbatioVault ;
• un RPO de 24h via sauvegarde logique quotidienne ;
• un RPO < 5 min entre deux sauvegardes via archivage WAL continu ;
• une rétention glissante de 30 jours ;
• une restauration vérifiable en environnement staging ;
• un journal append-only de chaque opération de sauvegarde.

Ce document définit les obligations fonctionnelles, temporelles, de sécurité, de format de données et de testabilité. Toute règle non vérifiable est marquée hors périmètre.

2. Périmètre / Hors périmètre¶

Inclus¶

• Sauvegarde logique PostgreSQL quotidienne compressée.
• Archivage WAL continu pour PITR entre deux sauvegardes logiques.
• Sauvegarde physique hebdomadaire (base PITR).
• Chiffrement double couche : applicatif + SSE-KMS stockage.
• Stockage S3 dédié avec versioning, IAM isolé, lifecycle 30 jours.
• Orchestration par flow dédié et watchdog indépendant.
• Journal append-only interne pour chaque événement de backup.
• Procédure de restauration testable en staging.
• Vérification d’intégrité par hash post-restauration.

Exclu¶

• Sauvegarde des objets documentaires métier déjà redondés multi-cloud.
• Snapshots d’infrastructure (Terraform/Ansible).
• Sauvegarde Redis.
• Ancrage Merkle/blockchain des événements de backup.

3. Définitions¶

• RPO : perte maximale de données admissible.
• RTO : temps maximal de remise en service.
• PITR : restauration à un instant donné via WAL.
• WAL : journaux de transactions PostgreSQL.
• Backup logique : export logique compressé de la base.
• Basebackup : copie physique complète de la base.
• SSE-KMS : chiffrement côté stockage avec clé KMS fournisseur.
• Chiffrement applicatif : chiffrement avant upload.
• Journal append-only : journal immuable en ajout seul.
• Watchdog : contrôle indépendant de présence du backup attendu.

4. Invariants (non négociables)¶

5. Flux nominaux¶

5.1 Modèle de données contractuel (source unique des formats)¶

FAILED_FORMAT est un code de rejet (format invalide) et n’est pas un état de status ni de la machine d’états. [CORR E-02]

Aucune autre section ne redéfinit ces formats ; elles y font référence.

5.2 Flux nominal F1 — Sauvegarde logique quotidienne¶

1. Déclenchement planifié quotidien à 03:00 Europe/Paris.
2. Production d’un dump logique compressé.
3. Chiffrement applicatif immédiat (AES-256-GCM).
4. Suppression de l’artefact en clair avant 300 s après fin d’export.
5. Upload vers bucket dédié avec SSE-KMS actif.
6. Écriture d’un événement append-only backup_type=pg_dump.
7. Vérification de présence de l’objet attendu par watchdog avant 04:00 Europe/Paris.

5.3 Flux nominal F2 — Archivage WAL continu¶

1. Capture continue des segments WAL.
2. Calcul du hash SHA3-256 par segment WAL avant upload, et journalisation associée. [CORR E-12]
3. Chiffrement applicatif de chaque segment avant persistance distante.
4. Upload vers préfixe wal/.
5. Journalisation append-only par segment ou lot contractuel.
6. Exigence de dérive maximale (lag) de livraison : P95 < 5 min.

5.4 Flux nominal F3 — Sauvegarde physique hebdomadaire¶

1. Déclenchement hebdomadaire le dimanche à 02:00 Europe/Paris.
2. Chiffrement applicatif puis upload SSE-KMS.
3. Journalisation append-only backup_type=basebackup.
4. Conservation selon même politique lifecycle (30 jours).

5.5 Flux nominal F4 — Restauration de validation (staging)¶

1. Sélection d’un point de restauration cible.
2. Restauration base + rejouage WAL jusqu’au point cible.
3. Vérification d’intégrité hash SHA3-256 des artefacts restaurés.
4. Validation de cohérence schéma + données métier attendues.
5. Enregistrement de preuve de test de restauration.

5.6 Atomicité multi-composant (DB + async)¶

5.7 Machine d’états et transitions inverses¶

États : SCHEDULED, RUNNING, SUCCESS, FAILED, EXPIRED, DELETED.

• SCHEDULED -> RUNNING : autorisée.
• RUNNING -> SUCCESS : autorisée.
• RUNNING -> FAILED : autorisée.
• SUCCESS -> EXPIRED : autorisée à expiration de rétention.
• EXPIRED -> DELETED : autorisée (suppression lifecycle).
• FAILED -> SCHEDULED : autorisée (nouvelle tentative planifiée).
• SUCCESS -> RUNNING : interdite (nouvelle exécution doit créer un nouveau backup_id).
• DELETED -> * : interdite (état terminal, résolution manuelle uniquement).
• EXPIRED -> SUCCESS : interdite.
• FAILED -> SUCCESS : interdite sans nouvelle exécution.

Clarification retry vs replanification : les retries (upload/chiffrement/export) sont effectués dans la même tentative (sans transition FAILED -> SCHEDULED) ; la transition FAILED -> SCHEDULED ne s’applique qu’après épuisement des retries et replanification d’une nouvelle tentative. [CORR E-11]

Comportement de retour/downgrade :

• Retour opérationnel FAILED -> SCHEDULED conserve les traces, ne supprime aucun journal.
• Aucune “réouverture” d’un backup SUCCESS ; un nouveau cycle est requis.
• Les états terminaux n’autorisent aucune transition sortante.

5.8 SLA temporels et bornes numériques¶

5bis. Diagrammes Mermaid¶

5bis.1 Machine d’états — Cycle de vie d’un backup (§5.7)¶

stateDiagram-v2
    [*] --> SCHEDULED

    SCHEDULED --> RUNNING : Déclenchement planifié
    RUNNING --> SUCCESS : Export + chiffrement + upload OK\n[INV-47-01, INV-47-02, INV-47-05]
    RUNNING --> FAILED : Erreur export/chiffrement/upload\n[INV-47-05]
    FAILED --> SCHEDULED : Replanification après épuisement retries\n[INV-47-07]
    SUCCESS --> EXPIRED : Expiration rétention 30j\n(§5.8)
    EXPIRED --> DELETED : Suppression lifecycle S3\n[INV-47-04]

    DELETED --> [*]

    note right of RUNNING
        Retries internes (max 3) restent
        dans RUNNING sans transition
        vers FAILED (§5.7 clarification)
    end note

    note right of DELETED
        État terminal — aucune
        transition sortante autorisée
        [INV-47-07]
    end note

    note left of SUCCESS
        Aucune réouverture possible —
        nouveau cycle = nouveau backup_id
        [INV-47-07]
    end note

5bis.2 Séquence — Flux nominal F1 : sauvegarde logique quotidienne (§5.2)¶

sequenceDiagram
    participant Scheduler as Orchestrateur<br/>(Planificateur)
    participant DB as PostgreSQL
    participant Crypto as Module Chiffrement
    participant S3 as Bucket S3<br/>(SSE-KMS)
    participant Journal as Journal<br/>Append-Only
    participant Watchdog as Watchdog<br/>(indépendant)

    Note over Scheduler: 03:00 Europe/Paris — déclenchement

    Scheduler->>Journal: Événement SCHEDULED [INV-47-05]
    Scheduler->>DB: pg_dump compressé
    DB-->>Scheduler: Dump logique (clair)
    Scheduler->>Scheduler: Transition SCHEDULED → RUNNING [INV-47-07]

    Scheduler->>Crypto: Générer DEK éphémère (§10.4)
    Crypto-->>Scheduler: DEK en mémoire [INV-47-09]
    Scheduler->>Crypto: Chiffrer dump (AES-256-GCM)
    Crypto-->>Scheduler: Artefact .enc + hash SHA3-256

    Scheduler->>Scheduler: Purger artefact clair < 300s [INV-47-01]
    Scheduler->>Crypto: Détruire DEK mémoire (§10.4)

    Scheduler->>S3: Upload .enc (SSE-KMS actif) [INV-47-02, INV-47-04]
    S3-->>Scheduler: Confirmation upload

    Scheduler->>Journal: Événement SUCCESS [INV-47-05]
    Scheduler->>Scheduler: Transition RUNNING → SUCCESS [INV-47-07]

    Note over Watchdog: Vérification avant 04:00 [INV-47-06]
    Watchdog->>S3: Vérifier présence backup_YYYYMMDD.enc
    S3-->>Watchdog: Objet présent / absent

    alt Objet absent
        Watchdog->>Journal: Alerte + relance contrôlée (ERR-47-05)
    end

5bis.3 Séquence — Flux nominal F4 : restauration de validation staging (§5.5)¶

sequenceDiagram
    participant Op as Opérateur
    participant S3 as Bucket S3
    participant Crypto as Module Chiffrement
    participant Staging as PostgreSQL<br/>Staging
    participant Journal as Journal<br/>Append-Only

    Op->>S3: Sélection point de restauration cible
    S3-->>Op: Backup .enc + segments WAL .enc

    Op->>Crypto: Déchiffrer backup (K_backup version historique) [§10.3]
    Crypto-->>Op: Dump logique clair

    Op->>Staging: Restauration base
    Staging-->>Op: Base restaurée

    Op->>S3: Récupérer WAL intermédiaires
    Op->>Crypto: Déchiffrer WAL
    Crypto-->>Op: Segments WAL clairs

    Op->>Staging: Rejouage WAL jusqu’au point cible (PITR)
    Staging-->>Op: Base à l’instant T

    Op->>Op: Vérification hash SHA3-256 [INV-47-08]
    Op->>Op: Validation cohérence schéma + données métier

    Op->>Journal: Enregistrement preuve test restauration [INV-47-05]
    Op->>Op: Purger artefacts clairs < 300s [INV-47-01]

6. Cas d’erreur¶

7. Critères d’acceptation (testables)¶

8. Scénarios de test (Given / When / Then)¶

• ST-47-01 (backup quotidien réussi)
  Given une base source disponible
  When l’horloge atteint 03:00 Europe/Paris
  Then un objet backup_YYYYMMDD.enc est stocké, journalisé SUCCESS, sans fichier clair > 300 s.

• ST-47-02 (échec chiffrement)
  Given un export logique généré
  When l’étape de chiffrement échoue
  Then aucun upload n’est effectué et l’exécution est FAILED avec alerte critique.

• ST-47-03 (WAL lag conforme)
  Given une activité transactionnelle continue
  When les segments WAL sont archivés
  Then le lag P95 observé sur 24h est strictement inférieur à 5 minutes.

• ST-47-04 (watchdog déclenchement)
  Given absence d’objet backup du jour à 04:00
  When le watchdog s’exécute
  Then une alerte est émise et une relance contrôlée unique est initiée ; si la relance échoue, une escalade critique est émise. [CORR E-17]

• ST-47-05 (rétention)
  Given un backup daté de plus de 30 jours
  When la politique lifecycle s’applique
  Then l’objet devient EXPIRED puis DELETED selon transitions autorisées.

• ST-47-06 (restauration PITR)
  Given un backup logique J0 et WAL intermédiaires
  When une restauration est demandée à T intermédiaire
  Then la base restaurée correspond à l’état attendu à T avec hash valide.

• ST-47-07 (format invalide hash)
  Given un événement avec hash_sha3_256 hors regex
  When l’événement est soumis
  Then l’événement est rejeté avec code de rejet FAILED_FORMAT et alerte. [CORR E-02]

• ST-47-08 (transition interdite)
  Given un backup en état DELETED
  When une transition sortante est demandée
  Then la transition est refusée explicitement et journalisée.

9. Hypothèses explicites¶

10. Points à clarifier et contraintes techniques¶

10.1 Points à clarifier¶

10.2 Contraintes techniques (stack réelle)¶

• Projet cible principal : ProbatioVault-backend — NestJS + TypeORM + PostgreSQL.
• Composant orchestration/exploitation : ProbatioVault-infra — Terraform + Ansible + Shell.
• Stockage objet compatible S3 avec SSE-KMS requis.
• Aucune exigence mobile/front (React Native/Next.js) dans ce périmètre.
• Aucune transition temporelle non identifiée : faux, des transitions temporelles existent (rétention, RPO/RTO, watchdog) et sont contractualisées en §5.8.
• Aucune borne numérique applicable : faux, bornes numériques définies en §5.8.
• Aucune contrainte inter-module applicable : vrai au sens applicatif métier (pas de guard cross-module API).
• Stratégie de migration DDL : non applicable (aucune modification de colonne existante demandée dans cette story).

10.3 Rotation de clé K_backup¶

La rotation de K_backup est supportée : la rotation ne doit pas rendre les backups historiques indéchiffrables (compatibilité de déchiffrement avec versions précédentes), et les nouveaux backups doivent utiliser la version courante de la clé. [CORR E-13]

10.4 Cycle de vie DEK¶

• Une DEK est générée pour chaque artefact chiffré (backup logique, basebackup, segment WAL), utilisée uniquement en mémoire pour l’opération, puis détruite. [CORR E-18]
• La DEK n’est jamais stockée en clair ; si elle est persistée (ex. enveloppe), elle l’est uniquement sous forme chiffrée conformément à INV-47-09. [CORR E-18]

Références¶

• Epic : Référence épique à compléter.
• JIRA : PD-47.
• Repos concernés : ProbatioVault-backend, ProbatioVault-infra.
• Documents associés : expression de besoin PD-47, exigences NF Z42-013, politiques sécurité clés/chiffrement internes.