Chapitre 4 -- Stockage et immutabilite¶

4.1 Architecture WORM¶

Principe fondamental¶

ProbatioVault garantit l'immutabilite des documents archives au moyen du mecanisme WORM (Write Once Read Many). Ce mecanisme repose sur la fonctionnalite S3 Object Lock en mode COMPLIANCE, proposee par AWS et adossee a un controle materiel (hardware-backed). En mode COMPLIANCE, aucun acteur -- y compris le compte racine AWS -- ne peut supprimer ni modifier un objet avant l'expiration de sa periode de retention.

Ce choix repond directement aux exigences de la norme NF Z42-013:2020 (immutabilite des archives) et de la norme ISO 14641:2018 (fiabilite et integrite de la conservation).

Difference entre les modes GOVERNANCE et COMPLIANCE¶

ProbatioVault utilise exclusivement le mode COMPLIANCE. Ce mode constitue la garantie la plus forte disponible dans l'ecosysteme S3 pour satisfaire les obligations legales de conservation (Code du travail L3243-4, Code de commerce L123-22).

Prerequis techniques de l'Object Lock¶

Deux prerequis sont necessaires pour activer S3 Object Lock sur un bucket :

1. Versioning S3 obligatoire : le versioning doit etre active avant la mise en place de l'Object Lock. Chaque modification d'un objet cree une nouvelle version ; les versions anterieures restent protegees par leur propre retention.
2. Activation a la creation du bucket : l'Object Lock doit etre active au moment de la creation du bucket. Il n'est pas possible de l'ajouter a un bucket existant.

Protection par politique de bucket (DenyAllDeletes)¶

En complement de l'Object Lock, chaque bucket d'archivage est protege par une politique de bucket explicite qui interdit toute operation de suppression (DeleteObject, DeleteObjectVersion) pour tous les principaux (*). Cette politique constitue une couche de defense supplementaire : meme si une faille de configuration IAM survenait, les suppressions resteraient bloquees au niveau du bucket.

De plus, le bloc d'acces public est active sur chaque bucket (BlockPublicAcls, BlockPublicPolicy, IgnorePublicAcls, RestrictPublicBuckets), interdisant tout acces non authentifie.

Diagramme : Protection WORM multi-couches¶

graph TB
    DOC["Document chiffre"]
    OL["Object Lock COMPLIANCE"]
    BP["Bucket Policy DenyAllDeletes"]
    IAM["IAM Explicit Deny Delete"]
    VER["Versioning S3"]
    PAB["Public Access Block"]

    DOC --> OL
    DOC --> BP
    DOC --> IAM
    DOC --> VER
    DOC --> PAB

    OL -->|"Retention hardware-backed"| PROT["Immutabilite garantie"]
    BP -->|"Deny DeleteObject *"| PROT
    IAM -->|"Aucun role ne peut supprimer"| PROT
    VER -->|"Historique complet conserve"| PROT
    PAB -->|"Zero acces public"| PROT

    style OL fill:#2d6a4f,color:#fff
    style BP fill:#2d6a4f,color:#fff
    style IAM fill:#2d6a4f,color:#fff
    style VER fill:#40916c,color:#fff
    style PAB fill:#40916c,color:#fff
    style PROT fill:#1b4332,color:#fff

Legende : Cinq couches de protection convergent pour garantir l'immutabilite de chaque document archive. L'Object Lock COMPLIANCE constitue la couche primaire (non contournable), les autres couches fonctionnent comme defense en profondeur.

4.2 Stockage actif OVH¶

Justification du choix hybride¶

L'architecture de stockage de ProbatioVault repose sur un modele hybride multi-cloud combinant OVH Cloud et AWS. Ce choix resulte d'une contrainte technique determinante : OVH Cloud ne prend pas en charge la fonctionnalite S3 Object Lock native. Il est donc impossible d'implementer une immutabilite WORM hardware-backed sur OVH seul. A l'inverse, utiliser AWS exclusivement pour le stockage actif engendrerait une latence elevee (restauration Glacier de 12 a 48 heures) et un cout prohibitif en stockage S3 Standard (~23 USD/TB/mois).

La solution hybride offre le meilleur compromis :

• OVH pour l'acces rapide aux documents actifs (latence inferieure a 100 ms) ;
• AWS pour l'archivage a valeur probante avec immutabilite COMPLIANCE.

Configuration des buckets OVH¶

Le stockage actif OVH est deploye dans la region GRA (Gravelines, France), ce qui assure la souverainete des donnees sur le territoire europeen.

Endpoint S3 : https://s3.gra.cloud.ovh.net

Caracteristiques du stockage actif¶

Chiffrement au repos¶

Chaque objet stocke sur OVH beneficie d'un double chiffrement :

1. Chiffrement applicatif (couche 1) : le backend ProbatioVault chiffre chaque document avec une cle unique K_doc derivee de la cle maitre utilisateur (K_master_user) via AES-256-GCM, avant tout envoi reseau. Seul le detenteur de la cle privee peut dechiffrer.
2. Chiffrement au repos (couche 2) : OVH applique automatiquement un chiffrement AES-256 supplementaire au niveau du stockage objet.

Le document transite entre le backend et OVH via TLS 1.2+ (couche intermediaire), portant le total a trois couches de protection cryptographique.

4.3 Archivage froid AWS Glacier¶

Architecture de l'archivage¶

Chaque document depose sur le stockage actif OVH est replique de maniere asynchrone vers AWS S3, region eu-west-3 (Paris, France), dans le bucket documents-cold. Un worker de replication asynchrone (base sur BullMQ/Redis) surveille les nouveaux objets OVH toutes les 5 minutes, les telecharge, puis les envoie vers AWS avec les parametres d'Object Lock COMPLIANCE.

Apres un delai configurable (J+1 dans la configuration actuelle), les objets transitent automatiquement vers la classe de stockage Glacier Deep Archive grace a une politique de lifecycle S3. Cette classe offre le cout de stockage le plus bas du marche pour l'archivage longue duree.

Buckets AWS (region Paris)¶

Endpoint S3 : https://s3.eu-west-3.amazonaws.com

Caracteristiques de Glacier Deep Archive¶

Processus de restauration¶

La restauration d'un document archive en Glacier Deep Archive suit le processus suivant :

1. Le backend emet une requete de restauration (RestoreObject) aupres d'AWS.
2. AWS rend le document disponible temporairement en S3 Standard (delai de 12 a 48 heures selon le mode choisi).
3. Le backend telecharge le document restaure et le dechiffre avec la cle K_doc correspondante.
4. Le document est delivre a l'utilisateur ; la copie temporaire expire selon la duree configuree.

Ce processus est transparent pour l'utilisateur final : le systeme bascule automatiquement entre OVH (acces rapide) et AWS (restauration differee) selon la disponibilite du document sur le stockage actif.

Chiffrement sur AWS¶

Le chiffrement au repos sur AWS suit le meme principe de defense en profondeur :

• Couche applicative : le document arrive deja chiffre cote client (AES-256-GCM avec K_doc).
• Couche serveur (SSE-S3) : AWS applique un chiffrement AES-256 supplementaire avec cles gerees par S3.
• Bucket Key active pour optimiser les couts de chiffrement sans compromettre la securite.

4.4 Replication cross-region¶

Objectif de la replication¶

La replication cross-region (CRR) de Paris vers Frankfurt assure la resilience geographique du SAE. En cas de sinistre majeur affectant la region Paris (catastrophe naturelle, panne datacenter prolongee), les archives restent disponibles depuis la region Frankfurt. Cette disposition repond a l'exigence RGPD de resilience des donnees et aux bonnes pratiques de continuite d'activite (PCA/PRA).

Configuration technique¶

Comportement de la replication¶

Lorsqu'un nouvel objet est depose dans le bucket source (Paris), le mecanisme CRR d'AWS copie automatiquement l'objet vers le bucket de destination (Frankfurt). Le Replication Time Control (RTC) garantit que 99,99 % des objets sont repliques en moins de 15 minutes.

La replication porte sur l'integrite complete de l'objet :

• Les donnees (contenu chiffre) sont copiees a l'identique.
• Les metadonnees de retention (Object Lock COMPLIANCE, date d'expiration) sont repliquees fidelement.
• Les tags (type de document, duree de retention) sont conserves.
• Les delete markers ne sont pas repliques : une tentative de suppression dans Paris ne se propage pas vers Frankfurt, ce qui renforce la protection.

Les objets arrivent directement en classe DEEP_ARCHIVE a Frankfurt, sans passer par S3 Standard, ce qui elimine toute phase de stockage intermediaire couteux.

Protection du bucket Frankfurt¶

Le bucket de destination beneficie des memes protections que le bucket source :

• Object Lock COMPLIANCE avec retention de 50 ans.
• Politique de bucket DenyAllDeletes.
• Chiffrement AES-256 (SSE-S3).
• Bloc d'acces public active.
• Versioning active.
• Aucun acces direct en ecriture (seul le role IAM de replication CRR peut ecrire).

Diagramme : Flux de stockage de bout en bout¶

graph LR
    ING["Ingestion document"]
    ENC["Chiffrement AES-256-GCM"]
    OVH["OVH S3 Gravelines<br/>(stockage actif)"]
    WORKER["Worker replication<br/>(BullMQ)"]
    PARIS["AWS S3 Paris<br/>Object Lock COMPLIANCE"]
    GLACIER["Glacier Deep Archive<br/>(J+1)"]
    CRR["CRR 15 min SLA"]
    FRA["AWS Frankfurt<br/>DEEP_ARCHIVE"]

    ING --> ENC
    ENC --> OVH
    OVH --> WORKER
    WORKER --> PARIS
    PARIS --> GLACIER
    PARIS --> CRR
    CRR --> FRA

    style OVH fill:#264653,color:#fff
    style PARIS fill:#2a9d8f,color:#fff
    style GLACIER fill:#e76f51,color:#fff
    style FRA fill:#e76f51,color:#fff
    style ENC fill:#457b9d,color:#fff

Legende : Le document est chiffre cote client, depose sur OVH pour acces rapide, replique vers AWS Paris avec Object Lock COMPLIANCE, puis transite en Glacier Deep Archive (J+1). La replication CRR vers Frankfurt assure la resilience geographique avec un SLA de 15 minutes.

4.5 Retention et legal holds¶

Politique de retention par type de document¶

La duree de retention est definie au niveau de chaque objet lors de son depot dans le bucket AWS. Elle depend du type de document, conformement aux obligations legales francaises :

La retention par defaut est fixee a 50 ans au niveau du bucket (configuration Object Lock). Cette duree maximale s'applique en l'absence de specification particuliere, conformement au principe de precaution. Chaque objet peut recevoir une date de retention individuelle plus courte que la retention par defaut du bucket, mais jamais plus longue que celle-ci.

Mecanisme de legal hold¶

Le legal hold est un verrou supplementaire, independant de la retention, qui peut etre applique a tout moment sur un objet. Lorsqu'un legal hold est actif, l'objet ne peut pas etre supprime meme si sa periode de retention a expire.

Cas d'usage du legal hold dans ProbatioVault :

• Litige en cours : un document fait l'objet d'une procedure judiciaire ; le legal hold empeche toute destruction jusqu'a resolution du litige.
• Audit externe : pendant la duree d'un audit de certification, les documents concernes sont proteges par legal hold pour garantir leur disponibilite.
• Enquete interne : en cas de suspicion de fraude ou d'incident de securite, le legal hold preserve l'integralite des preuves.

Le legal hold est gere par le biais de l'API S3 (PutObjectLegalHold) et ne peut etre leve que par un principal IAM disposant de la permission s3:PutObjectLegalHold. Dans ProbatioVault, cette permission est reservee aux administrateurs de conformite.

Interaction retention et legal hold¶

La suppression n'est possible que lorsque la retention a expire ET aucun legal hold n'est actif. Les deux mecanismes fonctionnent de maniere independante et cumulative.

Conformite RGPD et droit a l'effacement¶

L'article 17 du RGPD (droit a l'effacement) semble entrer en tension avec l'impossibilite de supprimer des objets en mode COMPLIANCE. Toutefois, l'article 17.3.b du RGPD prevoit une derogation explicite :

Le droit a l'effacement ne s'applique pas lorsque le traitement est necessaire au respect d'une obligation legale.

Les documents conserves dans ProbatioVault relevent systematiquement d'obligations legales (Code du travail, Code de commerce, obligations de tracabilite). De plus, le chiffrement client-side zero-knowledge assure la pseudonymisation effective des donnees : les cles S3 ne contiennent aucune information nominative, et seul le detenteur de la cle privee peut acceder au contenu en clair.

4.6 Durabilite et SLA¶

Engagements de durabilite¶

La durabilite de 11 nines d'AWS S3 signifie que, sur un million d'objets stockes pendant 10 000 ans, la probabilite de perte d'un seul objet est statistiquement negligeable. Ce niveau de durabilite est obtenu par la replications automatique des donnees sur un minimum de trois zones de disponibilite au sein d'une meme region.

Resilience multi-niveaux¶

L'architecture de stockage de ProbatioVault offre quatre niveaux de resilience :

Scenarios de panne et mitigation¶

Panne du stockage OVH :

• Les uploads sont mis en file d'attente (BullMQ) et retraites automatiquement au retablissement du service.
• Les lectures basculent sur une restauration depuis AWS Glacier (delai de 12 a 48 heures).
• Les archives restent intactes sur AWS Paris et Frankfurt.

Panne d'AWS region Paris :

• Les journaux d'audit sont temporairement bufferises en base PostgreSQL, puis synchronises vers AWS au retablissement.
• Les archives sont disponibles depuis le bucket replica Frankfurt.
• Les operations utilisateur ne sont pas impactees (les lectures se font depuis OVH en conditions normales).

Panne AWS multi-region :

• Le stockage actif OVH reste disponible pour les operations courantes.
• Les archives sont protegees par la durabilite inherente a la replication multi-region (la probabilite d'une panne simultanee Paris + Frankfurt est extremement faible).

Diagramme : Architecture multi-cloud¶

graph TB
    subgraph OVH["OVH Cloud -- Gravelines, France"]
        HOT["documents-hot<br/>Stockage actif<br/>Latence < 100 ms"]
        BAK["backups<br/>Sauvegardes 30 j"]
        TMP["temp-uploads<br/>Transit 7 j"]
    end

    subgraph AWS_PARIS["AWS -- Paris (eu-west-3)"]
        COLD["documents-cold<br/>Object Lock COMPLIANCE<br/>50 ans"]
        AUDIT["audit-logs<br/>Append-only<br/>Object Lock 50 ans"]
        LOGS["s3-access-logs<br/>Metadata 90 j"]
    end

    subgraph AWS_FRA["AWS -- Frankfurt (eu-central-1)"]
        REPLICA["archives-frankfurt<br/>DEEP_ARCHIVE<br/>Object Lock COMPLIANCE"]
    end

    HOT -->|"Worker async"| COLD
    COLD -->|"CRR 15 min"| REPLICA
    COLD -->|"Lifecycle J+1"| DA["Glacier Deep Archive"]

    style OVH fill:#264653,color:#fff
    style AWS_PARIS fill:#2a9d8f,color:#fff
    style AWS_FRA fill:#e76f51,color:#fff
    style HOT fill:#457b9d,color:#fff
    style COLD fill:#457b9d,color:#fff
    style REPLICA fill:#457b9d,color:#fff

Legende : Architecture tri-site avec stockage actif OVH Gravelines (acces rapide), archivage WORM AWS Paris (Object Lock COMPLIANCE + Glacier Deep Archive) et replica de resilience AWS Frankfurt (DEEP_ARCHIVE avec CRR). Les trois sites assurent conjointement la disponibilite, la durabilite et la conformite normative.

Synthese du chapitre¶

Invariants couverts : INV-249-01 (chapitre du manuel), INV-249-02 (composants documentes), INV-249-03 (diagrammes Mermaid), INV-249-06 (consolidation sans duplication), INV-249-07 (exploitable sans code).

Normes satisfaites :

• NF Z42-013:2020 : immutabilite des archives, tracabilite des operations, perennite de conservation.
• ISO 14641:2018 : fiabilite (Object Lock hardware-backed), integrite (versioning + checksum), exploitabilite (restauration < 12 h).
• RGPD : resilience des donnees (CRR multi-region), pseudonymisation (chiffrement client-side zero-knowledge), derogation article 17.3.b pour obligations legales.