PD-4 — Créer buckets AWS S3 avec Object Lock¶

Métadonnées¶

• ID : PD-4
• Epic : PD-198 — STORAGE
• Type : Infrastructure / Probatoire
• Priorité : Critique (WORM obligatoire)

1. Objectif¶

Provisionner l'infrastructure de stockage primaire AWS S3 avec Object Lock (COMPLIANCE) afin d'assurer un mode WORM (Write Once Read Many) juridiquement opposable, garantissant l'immutabilité des archives ProbatioVault.

Cette couche constitue le Niveau 1 de la chaîne de conservation probatoire :

1. AWS S3 Paris (Object Lock COMPLIANCE)
2. AWS Glacier Deep Archive Paris (PD-5)
3. Cross-Region Replication Francfort (PD-6)
4. OVH Cold Archive (optionnel)

2. Description¶

Créer trois buckets AWS S3 distincts, chacun avec des politiques d'immutabilité et de rétention adaptées aux usages, dans la région eu-west-3 (Paris), avec Object Lock COMPLIANCE (documents, audit) ou GOVERNANCE (backups), et SSE-KMS dédié à la région.

2.1 Bucket Documents¶

Nom : probatiovault-{env}-documents-cold

• Object Lock : COMPLIANCE
• Rétention : dynamique (3 à 100 ans) selon le type de document
• Versioning : Activé
• Lifecycle :
• Transition vers Glacier Deep Archive après 90 jours
• Purge automatique à échéance légale
• Usage : fichiers utilisateurs chiffrés côté client (AES-256-GCM)
• Chiffrement serveur : SSE-KMS (clé dédiée Paris)

2.2 Bucket Audit¶

Nom : probatiovault-{env}-audit-logs

• Object Lock : COMPLIANCE
• Rétention : fixe 50 ans
• Versioning : Activé
• Mode : Append-only strict (aucune suppression, aucune modification)
• Usage :
• Journaux probatoires
• Audit logs signés HSM
• Événements NF Z42-013 / ISO 14641
• Chiffrement serveur : SSE-KMS (clé dédiée Paris)

2.3 Bucket Backups¶

Nom : probatiovault-{env}-backups

• Object Lock : GOVERNANCE
• Rétention : 30 jours
• Versioning : Activé
• Lifecycle :
• Suppression automatique après 30 jours
• Usage : sauvegardes PostgreSQL et artefacts techniques
• Chiffrement serveur : SSE-KMS (clé dédiée Paris)

3. Implémentation Terraform¶

Ressources à créer¶

• aws_s3_bucket (×3) avec object_lock_enabled = true
• aws_s3_bucket_object_lock_configuration (documents, audit, backups)
• aws_s3_bucket_versioning (×3)
• aws_s3_bucket_server_side_encryption_configuration (SSE-KMS, 1 clé KMS Paris)
• aws_s3_bucket_policy (×3) : deny delete/overwrite, TLS only, principle of least privilege
• aws_s3_bucket_lifecycle_configuration (documents → GDA 90j ; backups delete 30j)
• aws_s3_bucket_logging (logs vers bucket dédié)
• IAM : rôles/keys distincts (backend, auditor) stockés dans Vault

Configuration clé¶

• Object Lock COMPLIANCE (documents, audit) et GOVERNANCE (backups)
• Bucket policies avec Deny explicite sur DeleteObject/DeleteObjectVersion hors expiration
• Rétention dynamique gérée par le backend (headers Object Lock) + default retention côté bucket si besoin
• Chiffrement SSE-KMS avec clé dédiée région Paris (eu-west-3)
• Accès forcé en HTTPS uniquement

4. Durées de rétention légales¶

Tableau à valider par un juriste avant mise en production.

5. Critères d'acceptation¶

Fonctionnels¶

• 3 buckets AWS S3 créés avec Object Lock activé (COMPLIANCE pour documents/audit, GOVERNANCE pour backups)
• Versioning activé sur tous les buckets
• Lifecycle policies configurées (documents → GDA 90j, backups purge 30j)
• Bucket policies bloquant toute suppression avant échéance (deny delete/overwrite)

Techniques¶

• Terraform validé et appliqué sans erreur
• State Terraform stocké dans backend sécurisé
• Upload avec Object Lock fonctionnel
• Suppression impossible (AccessDenied)
• SSE-KMS actif avec clé dédiée Paris

Sécurité¶

• Object Lock COMPLIANCE effectif (documents, audit)
• IAM roles distincts (backend, auditor) avec principe du moindre privilège
• Audit logs S3 activés (bucket de logs dédié)
• Credentials stockés dans Vault

Conformité¶

• Rétention conforme aux obligations légales
• Journaux audit immuables
• Alignement NF Z42-013 / ISO 14641 documenté

6. Tests essentiels¶

Test 1 — Upload avec Object Lock¶

aws s3api put-object \
  --bucket probatiovault-dev-documents \
  --key test.enc \
  --body /tmp/file.enc \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2034-01-01T00:00:00Z"

Attendu : succès, objet immuable jusqu'en 2034.

Diagrammes¶

Cycle de vie d'un objet S3 (state diagram)¶

Modélise les transitions d'état d'un objet depuis l'upload jusqu'à la purge à échéance légale. Référence : critères d'acceptation §5 — Object Lock COMPLIANCE effectif, lifecycle policies, suppressions impossibles avant échéance.

stateDiagram-v2
    [*] --> Upload : PUT avec Object Lock headers

    Upload --> Active_COMPLIANCE : Bucket documents / audit\n(COMPLIANCE mode)
    Upload --> Active_GOVERNANCE : Bucket backups\n(GOVERNANCE mode)

    Active_COMPLIANCE --> Locked : Rétention COMPLIANCE\n(3-100 ans selon type)
    Locked --> Locked : DELETE → AccessDenied\n(immutabilité WORM)
    Locked --> GlacierDeepArchive : Lifecycle 90j\n(bucket documents)
    GlacierDeepArchive --> GlacierDeepArchive : DELETE → AccessDenied\n(rétention maintenue)
    GlacierDeepArchive --> Purged : Échéance légale atteinte\n(purge automatique)
    Locked --> Purged : Échéance légale atteinte\n(bucket audit — 50 ans)

    Active_GOVERNANCE --> RetentionGov : Rétention GOVERNANCE\n(30 jours)
    RetentionGov --> Purged : Lifecycle 30j\n(suppression automatique)

    Purged --> [*]

Provisionnement et upload (sequence diagram)¶

Flux multi-service couvrant le provisionnement Terraform et l'upload chiffré SSE-KMS. Référence : critères d'acceptation §5 — SSE-KMS actif, IAM roles distincts, credentials dans Vault.

sequenceDiagram
    participant TF as Terraform
    participant S3 as AWS S3 (eu-west-3)
    participant KMS as AWS KMS (Paris)
    participant V as HashiCorp Vault
    participant BE as Backend

    rect rgb(230, 240, 255)
    note over TF, V: Phase 1 — Provisionnement infrastructure
    TF->>S3: create bucket (object_lock_enabled=true)
    TF->>S3: set object_lock_configuration (COMPLIANCE/GOVERNANCE)
    TF->>S3: enable versioning
    TF->>KMS: create CMK (region eu-west-3)
    TF->>S3: set SSE-KMS (clé dédiée Paris)
    TF->>S3: set bucket_policy (deny delete/overwrite, TLS only)
    TF->>S3: set lifecycle (GDA 90j / purge 30j)
    TF->>V: store IAM credentials (backend, auditor)
    end

    rect rgb(240, 255, 240)
    note over BE, KMS: Phase 2 — Upload avec Object Lock
    BE->>V: retrieve IAM credentials
    V-->>BE: access_key + secret_key
    BE->>S3: PutObject (Object Lock COMPLIANCE,<br/>retain-until-date, SSE-KMS)
    S3->>KMS: encrypt (CMK Paris)
    KMS-->>S3: ciphertext
    S3-->>BE: 200 OK (VersionId, ETag)
    end

    rect rgb(255, 240, 240)
    note over BE, S3: Phase 3 — Tentative de suppression (WORM)
    BE->>S3: DeleteObject
    S3-->>BE: 403 AccessDenied (Object Lock COMPLIANCE)
    end

Test 2 — Tentative de suppression¶

aws s3api delete-object \
  --bucket probatiovault-dev-documents \
  --key test.enc

Attendu : AccessDenied.

Test 3 — Versioning¶

• Uploader plusieurs versions du même fichier
• Vérifier que chaque version possède son Object Lock

7. Dépendances¶

Avant¶

• PD-0 — Setup Terraform OVH
• PD-1 — Provisionner VPC

Après¶

• PD-5 — AWS Glacier Deep Archive Paris
• PD-6 — Cross-Region Replication Francfort
• PD-7 — OVH Cold Archive

8. Points d'attention¶

• Object Lock COMPLIANCE irréversible
• Tester exhaustivement en environnement dev
• Impossible de réduire une durée de rétention
• Coûts long terme importants (50–100 ans)
• Validation juridique obligatoire

9. Definition of Done¶

• Buckets OVH WORM opérationnels
• Object Lock et versioning actifs
• Suppressions impossibles avant échéance
• Terraform reproductible et audité
• Documentation conformité validée

Cette US est critique et conditionne toute la chaîne probatoire ProbatioVault.

User Story¶

• Implementation Plan
• Critères d'acceptabilité
• Retour d'expérience