PD-6 — Activer Cross-Region Replication Paris → Francfort¶

📚 Navigation User Story

| Document | | | ---------- | -- | | 📋 **Spécification** | *(ce document)* | | 🛠️ [Plan d'implémentation](PD-6-plan.md) | | | ✅ [Critères d'acceptation](PD-6-acceptability.md) | | | 📝 [Retour d'expérience](PD-6-rex.md) | | [← Retour à storage](../PD-198-epic.md) · [↑ Index User Story](index.md)

Métadonnées¶

ID : PD-6
Epic : PD-198 — STORAGE
Type : Product Delivery / Infrastructure
Priorité : Critique (résilience probatoire)
Story Points : 5

Contexte¶

ProbatioVault repose sur une architecture probatoire multi-niveaux garantissant la résilience, la souveraineté et l'immutabilité des archives, conformément aux normes NF Z42-013 et ISO 14641.

La couche Cross-Region Replication (CRR) constitue le niveau 3 de redondance probatoire, assurant la survie des archives en cas de perte complète d'une région AWS.

Architecture globale (référence : Architecture Tech Lead v4.1) :

Niveau 1 : OVH Object Storage (actif)
Niveau 2 : AWS Glacier Deep Archive – Paris (WORM)
Niveau 3 : CRR vers AWS Glacier Deep Archive – Francfort
Niveau 4 : OVH Cold Archive (optionnel)

La présente user story vise à activer officiellement et auditer cette couche CRR critique.

Objectif¶

Configurer la Cross-Region Replication automatique entre :

AWS Glacier Deep Archive – Paris (eu-west-3) → bucket source
AWS Glacier Deep Archive – Francfort (eu-central-1) → bucket de réplication

afin de garantir :

la résilience géographique totale des archives probatoires,
la conservation WORM stricte sur les deux régions,
l'intégrité cryptographique (hash, TSA, Merkle, blockchain),
la conformité long terme réglementaire.

Portée¶

Inclus :

Création et configuration des buckets S3 Paris et Francfort.
Activation de la Cross-Region Replication (CRR).
Configuration IAM minimale dédiée à la réplication.
Tests de réplication, intégrité et restauration.
Mise en place du monitoring et des alertes.
Infrastructure as Code (Terraform).

Hors-périmètre :

Export OVH → AWS Paris (PD-5).
Archivage OVH Cold Archive (PD-7).
PRE, HSM, chiffrement (autres PD).

Architecture cible¶

[ OVH Object Storage (France, actif) ]
                  │  (export asynchrone BullMQ)
                  ▼
[ AWS Glacier Deep Archive – Paris ]
                  │  (Cross-Region Replication)
                  ▼
[ AWS Glacier Deep Archive – Francfort ]

Propriétés attendues :

Réplication asynchrone (latence typique 1–30 min).
Object Lock Compliance conservé sur les deux régions.
Clés KMS distinctes Paris / Francfort.
Données déjà chiffrées côté client (Zero-Knowledge).

Tâches techniques¶

1. Préparation des buckets¶

Bucket source – Paris

Nom : pv-archives-paris
Région : eu-west-3
Versioning : activé (obligatoire)
Object Lock : COMPLIANCE, durée ≥ 10 ans
Storage class : GLACIER_DEEP_ARCHIVE

Bucket destination – Francfort

Nom : pv-archives-frankfurt
Région : eu-central-1
Versioning : activé
Object Lock : activé
Suppression : interdite (s3:DeleteObject bloqué)

2. Configuration IAM¶

Créer un rôle dédié : pv-crr-replication-role

Principes :

Permissions minimales (least privilege).
Accès lecture sur Paris, écriture réplication sur Francfort.

3. Activation Cross-Region Replication¶

Configuration CRR :

Réplication de tous les objets.
Réplication des tags probatoires (hash, TSA, MerkleRoot).
Réplication du mode Object Lock.
Pas de réplication des suppressions.
Storage class cible : DEEP_ARCHIVE.

Activation via Terraform (infrastructure idempotente).

4. Tests de réplication¶

Upload d'un fichier *.enc via le pipeline ProbatioVault.
Vérification apparition dans le bucket Francfort.
Vérification :
hash identique,
version ID identique,
Object Lock conservé,
audit log présent.

Latence cible : ≤ 30 minutes.

5. Monitoring & alerting¶

Metrics CloudWatch à activer :

BytesPendingReplication
OperationsFailedReplication
ReplicationLatency

Alertes :

Latence > 60 minutes.
Erreurs de réplication.
Backlog > 100 objets.

Notifications : email + webhook (Slack / Discord).

6. Documentation & automatisation¶

Documentation : /docs/infra/aws/crr/
Terraform production :
buckets Paris / Francfort,
rôle IAM CRR,
règles de réplication.
Plan de reprise (restore Francfort → Paris / OVH).

Diagrammes Mermaid¶

Diagramme d'etats — Cycle de vie d'un objet replique¶

Les objets probatoires traversent plusieurs etats entre le depot initial et la confirmation de replication. Ce diagramme couvre les invariants d'immutabilite (AC4) et de replication fonctionnelle (AC3).

stateDiagram-v2
    [*] --> UploadedParis : Upload .enc via pipeline ProbatioVault

    UploadedParis : Objet dans pv-archives-paris
    UploadedParis : Object Lock COMPLIANCE active
    UploadedParis : Storage class GLACIER_DEEP_ARCHIVE

    UploadedParis --> PendingReplication : CRR declenche (asynchrone)

    PendingReplication : BytesPendingReplication > 0
    PendingReplication : ReplicationLatency en cours

    PendingReplication --> Replicated : Hash identique + Object Lock conserve (AC3)
    PendingReplication --> ReplicationFailed : OperationsFailedReplication > 0

    ReplicationFailed --> PendingReplication : Retry automatique AWS

    Replicated : Objet dans pv-archives-frankfurt
    Replicated : Hash SHA-256 identique (AC3)
    Replicated : Object Lock COMPLIANCE herite
    Replicated : Suppression interdite (AC4)

    Replicated --> [*]

    note right of Replicated
        Latence cible <= 30 min
        Alerte si > 60 min (AC5)
    end note

    note right of ReplicationFailed
        Alerte CloudWatch declenchee (AC5)
        Backlog surveille (seuil 100 objets)
    end note

Diagramme de sequence — Flux de replication CRR Paris-Francfort¶

Ce diagramme illustre les interactions entre les services lors du flux nominal de replication, incluant le chiffrement KMS distinct par region (AC1) et le monitoring CloudWatch (AC5).

sequenceDiagram
    participant Pipeline as Pipeline ProbatioVault
    participant Paris as S3 Paris (pv-archives-paris)
    participant IAM as IAM Role (pv-crr-replication-role)
    participant KMSp as KMS Paris
    participant KMSf as KMS Francfort
    participant Frankfurt as S3 Francfort (pv-archives-frankfurt)
    participant CW as CloudWatch

    Pipeline->>Paris: PUT .enc (deja chiffre Zero-Knowledge)
    activate Paris
    Paris->>Paris: Object Lock COMPLIANCE applique (AC1)
    Paris->>Paris: Storage class GLACIER_DEEP_ARCHIVE (AC1)
    Paris-->>CW: Metric BytesPendingReplication++
    deactivate Paris

    Note over Paris,Frankfurt: Cross-Region Replication (asynchrone, 1-30 min)

    Paris->>IAM: Demande credentials replication
    IAM-->>Paris: Credentials least privilege (lecture Paris)

    Paris->>KMSp: Dechiffrement cle enveloppe (SSE-KMS)
    KMSp-->>Paris: Cle dechiffree

    Paris->>Frankfurt: Replicate objet + tags probatoires + Object Lock
    activate Frankfurt
    Frankfurt->>KMSf: Chiffrement cle enveloppe (KMS Francfort distinct)
    KMSf-->>Frankfurt: Cle chiffree

    Frankfurt->>Frankfurt: Versioning + Object Lock COMPLIANCE herite (AC3, AC4)
    Frankfurt->>Frankfurt: s3:DeleteObject bloque (AC4)
    Frankfurt-->>CW: Metric ReplicationLatency emise
    deactivate Frankfurt

    CW->>CW: Evaluation seuils (latence > 60min, backlog > 100)

    alt Latence > 60 min OU erreur replication
        CW-->>Pipeline: Alerte email + webhook (AC5)
    end

    Note over Paris,Frankfurt: Hash SHA-256 identique des deux cotes (AC3)

Critères d'acceptation (AC)¶

AC1 — Buckets configurés

Versioning actif.
Object Lock compliance.
Glacier Deep Archive.

AC2 — CRR activée

Statut "Replication: Enabled" sur Paris.

AC3 — Réplication fonctionnelle

Objet répliqué en Francfort.
Hash identique.
Métadonnées probatoires identiques.

AC4 — Résilience probatoire

Suppression interdite en Francfort.
Aucun overwrite possible.

AC5 — Monitoring opérationnel

Metrics visibles.
Alertes déclenchées correctement.

AC6 — Terraform

terraform apply sans erreur.
terraform plan idempotent.

Tests¶

Test 1 — Upload & réplication¶

Upload test.enc.
Vérifier versionID Paris = versionID Francfort.

Test 2 — Intégrité cryptographique¶

Comparer hash SHA-256 local et métadonnées Francfort.

Test 3 — WORM¶

Tentative suppression en Francfort → refusée.

Test 4 — Monitoring¶

Désactiver temporairement rôle CRR.
Vérifier erreurs + alerte.

Test 5 — Plan de reprise¶

Restaurer depuis Francfort.
Déchiffrement OK (K_doc intact).

Dépendances¶

Avant :

PD-5 — Export OVH → AWS Paris.

Après :

PD-7 — OVH Cold Archive (optionnel).
PD-60+ — Preuves Merkle / Blockchain.

Definition of Done¶

CRR Paris → Francfort active et auditée.
Buckets WORM immuables sur les deux régions.
Tests de réplication et de restauration validés.
Monitoring + alertes opérationnels.
Terraform versionné et documenté.
Documentation complète disponible.