Chiffrement des fichiers en Db — opt-in par l'utilisateur propriétaire

[ronan-develop]

Description

Permettre à un utilisateur propriétaire d'activer le chiffrement au repos de ses fichiers (choix laissé au user, pas un comportement forcé). Vision exprimée par l'utilisateur (Ronan), à approfondir avant implémentation — ce ticket sert de point de départ, pas de spec figée.

Principes évoqués :

• Opt-in : le propriétaire choisit d'activer ou non le chiffrement pour son espace
• Quand le propriétaire est connecté, ses fichiers sont accessibles en clair (déchiffrement à la volée) ; l'idée est que la donnée reste chiffrée au repos sur disque/en base indépendamment de la session
• Les invités (accès via Share) doivent continuer à accéder normalement aux ressources qui leur sont partagées, y compris quand le propriétaire n'est pas connecté — implique que la clé de déchiffrement ne peut pas dépendre uniquement de la session du propriétaire
• Les liens publics (ShareLink) restent en clair, non chiffrés — cohérent avec le fait qu'un lien public n'a pas de notion d'identité/session
• Objectif de fond : un accès direct à la base de données (ex. un admin cPanel/hébergeur, ou un accès DB compromis) sans la clé de chiffrement ne doit exposer que du contenu chiffré, illisible

Points à clarifier avant tout développement (chantier de conception, pas d'implémentation immédiate)

• Où vit la clé de chiffrement si elle ne peut pas dépendre uniquement de la session du propriétaire (sinon les invités ne peuvent jamais accéder à un partage quand le propriétaire est déconnecté) ? Ex. clé dérivée du mot de passe propriétaire mais mise en cache serveur, enveloppe de clé partagée avec les invités au moment du Share, etc.
• APP_ENCRYPTION_KEY existe déjà dans config/services.yaml mais n'est injectée nulle part (ThumbnailService a un docblock qui prétend à tort que la source est déjà chiffrée, cf. avancement du 2026-07-19) — point de départ technique existant mais non branché
• Granularité : chiffrement par utilisateur, par fichier, ou par ressource partagée ?
• Impact sur les vignettes/EXIF/traitement média (le pipeline actuel lit les fichiers en clair sur disque)
• Impact performance (chiffrement/déchiffrement à la volée sur des fichiers potentiellement volumineux — RAW, vidéos)
• Rotation de clé et récupération en cas de perte du mot de passe propriétaire (le contenu chiffré devient-il définitivement perdu ?)

Critères d'acceptation

• Décision de conception documentée (où vit la clé, comment les invités et les liens publics restent fonctionnels) avant tout code
• Le propriétaire peut activer/désactiver le chiffrement pour son espace
• Fichiers chiffrés au repos : un accès direct à la base/au disque sans la clé ne restitue que du contenu chiffré
• Les partages actifs (Share) restent accessibles aux invités indépendamment de la session du propriétaire
• Les liens publics (ShareLink) restent servis en clair, sans régression
• Tests : accès non autorisé, rotation/désactivation du chiffrement, cas limite (partage actif pendant que le propriétaire est déconnecté)

Zone concernée

Stockage (fichiers, MediaService) + Auth (JWT, sécurité)

Effort estimé

L — plusieurs jours (nécessite une phase de conception dédiée avant l'estimation d'implémentation)