Aller au contenu

PD-46 — Expression de Besoin

Contexte

ProbatioVault permet aux utilisateurs de stocker des documents sensibles avec garantie d'intégrité probatoire. Le téléchargement de ces documents doit être sécurisé, audité et compatible avec le modèle de preuve composite de la plateforme.

Problème

Actuellement, il n'existe pas de mécanisme standardisé pour permettre le téléchargement sécurisé des documents stockés sur S3. Les besoins sont :

  1. Sécurité : Empêcher tout accès non autorisé aux documents
  2. Performance : Permettre des téléchargements directs depuis S3 (sans passer par le backend)
  3. Traçabilité : Journaliser chaque téléchargement effectif dans le registre probatoire
  4. Multi-canal : Supporter iOS, PWA et API B2B

Solution proposée

Implémenter un système de pre-signed URLs S3 avec : - TTL court (5 minutes) - Vérification des droits au moment du téléchargement effectif - Journalisation append-only des événements

Canaux supportés

Canal Authentification Cas d'usage
Application iOS JWT ProbatioVault Utilisateur final mobile
PWA (web) JWT ProbatioVault Utilisateur final navigateur
API B2B OAuth 2.0 / OIDC ERP, DMS partenaires

Modèle d'autorisation

Coffre personnel

Un utilisateur peut télécharger un document si : - Il est owner du document - OU il bénéficie d'un partage actif : - Lecture autorisée - Non expiré - Non révoqué

Coffre entreprise

Un utilisateur peut télécharger un document si : - Authentification OIDC valide - Appartenance au tenant propriétaire du document - Rôle autorisé pour l'action de téléchargement - Action rattachée à la personne morale responsable

Caractéristiques de la pre-signed URL

Propriété Valeur Justification
TTL 5 minutes Fenêtre minimale acceptable pour un téléchargement
Confidentialité Non-secret Peut circuler pendant son TTL
Single-use Non La sécurité repose sur la vérification des droits
Scope GET uniquement Lecture seule, pas d'upload

Principe de sécurité : La pre-signed URL n'est pas un secret. La sécurité repose sur : 1. Le TTL court 2. La vérification des droits au moment effectif du téléchargement

Comportement de révocation

Scénario Comportement
Droit révoqué + nouvelle requête Refusée (HTTP 403)
Droit révoqué + téléchargement en cours Non interrompu
URL expirée (TTL) Refusée (HTTP 403)

Fenêtre résiduelle acceptée : Un téléchargement déjà initié avant révocation peut se terminer. Cette fenêtre technique est acceptable et documentée.

Journalisation probatoire

Événements journalisés

Événement Journalisé Justification
Téléchargement effectif (succès) Oui Preuve d'accès
Tentative refusée après révocation Oui Trace de tentative non autorisée
Génération du lien pre-signed Non Pas d'accès effectif, bruit inutile

Structure de l'événement audit

Chaque événement est rattaché à : - Acteur : Personne physique identifiée (user_id) - Personne morale : Le cas échéant, organisation responsable (tenant_id) - Document : Référence au document téléchargé (document_id) - Timestamp : Horodatage certifié - Résultat : SUCCESS | DENIED

Stockage dans le registre append-only existant (cohérent avec l'architecture de preuve composite).

Invariants fonctionnels

INV-46-01 : La validité d'un téléchargement dépend du TTL ET du maintien du droit d'accès au moment de la requête.

INV-46-02 : La révocation d'un droit empêche toute nouvelle requête de téléchargement.

INV-46-03 : Un téléchargement déjà initié n'est pas interrompu par une révocation ultérieure.

INV-46-04 : Chaque succès ou refus de téléchargement est journalisé dans le registre probatoire append-only.

INV-46-05 : L'événement audit est rattaché à un acteur (personne physique) et, le cas échéant, à une personne morale responsable.

INV-46-06 : Aucun téléchargement ne doit permettre de contourner le modèle Zero-Knowledge. Le contenu déchiffré n'est jamais exposé côté serveur.

Contraintes non fonctionnelles

Contrainte Justification
Compatibilité WORM immuable Cohérence avec l'architecture de stockage existante
Cohérence preuve composite / Merkle Événements audit intégrés dans l'agrégation périodique
Respect RGPD Minimisation des données journalisées (faits effectifs uniquement)
Zero-Knowledge serveur Le serveur ne voit jamais le contenu en clair
Performance mobile Latence acceptable sur connexion 4G

Tensions assumées

Tension Décision Justification
Lien circulant vs sécurité TTL court (5min) + contrôle dynamique Compromis UX/sécurité acceptable
Révocation immédiate vs simplicité Blocage nouvelles requêtes uniquement Fenêtre résiduelle technique acceptée
Sécurité stricte vs UX Pas d'interruption download en cours Évite frustration utilisateur
Traçabilité vs RGPD Journalisation faits effectifs uniquement Pas de génération de lien loggée
Single-use vs performance Liens réutilisables pendant TTL Évite re-génération pour retry/resume

Critères de succès

  1. Un utilisateur autorisé peut télécharger un document via iOS, PWA ou API B2B
  2. Un utilisateur non autorisé reçoit HTTP 403
  3. Les droits sont vérifiés au moment du téléchargement effectif (pas seulement à la génération)
  4. Chaque téléchargement effectif est journalisé avec acteur + document + timestamp
  5. Chaque refus post-révocation est journalisé
  6. Le TTL de 5 minutes est respecté
  7. Les téléchargements en cours ne sont pas interrompus par une révocation

Hors périmètre

  • Resume partiel (Range requests) — à traiter dans une story dédiée
  • Download progress tracking côté client
  • Quota de téléchargement par utilisateur
  • Notification de téléchargement au owner
  • Téléchargement en batch (ZIP)
  • Génération de lien à usage unique (single-use)
  • Restriction par IP
  • Modification des flux de partage existants

Références

Auteur : Claude Opus 4.5 (orchestrateur) Date : 2026-02-11 Statut : En attente de validation PO