PD-30 — Expression de besoin¶

Metadata¶

1. Contexte¶

ProbatioVault repose sur un modèle de sécurité zero-knowledge, multi-device, et à forte exigence probatoire (journal append-only, traçabilité des accès, conformité RGPD et eIDAS).

L'authentification (cf. architecture SRP-6a + JWT décrite dans les spécifications techniques 42) permet l'accès initial au système.

Cependant, une fois authentifié, l'utilisateur peut : - Accéder depuis plusieurs appareils - Conserver des sessions actives simultanément - Révoquer un appareil compromis - Être soumis à des exigences d'invalidation immédiate en cas d'incident de sécurité

La gestion actuelle des sessions doit être renforcée pour répondre aux exigences suivantes : - Contrôle en temps réel des sessions actives - Invalidation immédiate - Gestion fine par device - Expiration maîtrisée - Traçabilité auditée

2. Objectifs¶

Mettre en place un mécanisme permettant :

1. Stockage centralisé des sessions actives
2. Gestion automatique de leur durée de validité (TTL)
3. Invalidation immédiate d'une session ou d'un ensemble de sessions
4. Visualisation des appareils actuellement connectés
5. Cohérence avec le modèle zero-knowledge et probatoire

3. Besoins fonctionnels¶

3.1 Gestion des sessions actives¶

Le système doit permettre : - L'enregistrement d'une session lors d'une authentification réussie - L'association d'une session à : - Un identifiant utilisateur - Un identifiant device - Des métadonnées contextuelles (IP, user-agent, timestamp) - Le maintien d'une liste actualisée des sessions actives par utilisateur

3.2 Durée de vie (TTL)¶

Chaque session doit : - Posséder une durée de validité définie - Expirer automatiquement sans intervention humaine - Être renouvelable sous conditions (ex : activité continue)

Le système doit permettre : - Une configuration de durée différente selon le contexte (mobile, web, API) - Une politique stricte pour les contextes sensibles

3.3 Invalidation immédiate¶

Le système doit permettre : - L'invalidation d'une session spécifique - L'invalidation de toutes les sessions d'un utilisateur - L'invalidation liée à un événement : - Changement de mot de passe - Révocation d'un device - Suspicion d'intrusion - Demande judiciaire

L'invalidation doit être : - Immédiate - Effective sur l'ensemble des instances backend - Vérifiable et journalisée

3.4 Liste des appareils actifs¶

Un utilisateur doit pouvoir : - Consulter la liste de ses appareils actuellement connectés - Voir pour chaque appareil : - Type - Date de connexion - Dernière activité - Localisation approximative - Révoquer un appareil individuellement

Ce besoin est cohérent avec la section "Gestion des sessions et révocation" du cahier d'architecture 41.

3.5 Cohérence avec les exigences de sécurité¶

Le système de gestion des sessions doit respecter : - Le modèle stateless distribué de l'API - L'architecture multi-instance (scalabilité horizontale) - L'isolation stricte des données par utilisateur - L'absence de stockage de secrets en clair - La traçabilité probatoire (journal append-only)

Il ne doit pas : - Introduire de point unique de défaillance non maîtrisé - Permettre le contournement d'une révocation - Créer de dépendance forte à un état local d'instance

4. Contraintes¶

4.1 Contraintes techniques¶

• Compatible avec une architecture distribuée
• Montée en charge linéaire
• API stateless
• Synchronisation rapide inter-instances

4.2 Contraintes réglementaires¶

• Respect RGPD (données minimisées, purge automatique)
• Capacité de production d'un journal d'accès sur demande judiciaire
• Cohérence avec le mécanisme d'ancrage probatoire

4.3 Contraintes de sécurité¶

• Protection contre le replay
• Protection contre l'usurpation de token
• Résistance aux attaques par session fixation
• Isolation stricte entre utilisateurs

5. Résultats attendus¶

Le système est considéré conforme si : - Un utilisateur peut voir en temps réel ses sessions actives - Une session révoquée devient immédiatement inutilisable - Les sessions expirent automatiquement à échéance - La révocation d'un device supprime toute possibilité d'accès - Les journaux permettent de prouver : - Qu'une session existait - Qu'elle a été invalidée - À quel moment - Par quelle action

6. Risques identifiés¶

7. Tensions à préserver¶

Ces tensions ne doivent pas être arbitrées dans ce document. Elles devront être traitées en phase de spécification :

• Stateless API vs contrôle centralisé des sessions
• Performance vs vérification systématique
• Auditabilité forte vs minimisation des données
• Simplicité opérationnelle vs granularité fine par device

8. Hors périmètre¶

• Implémentation du mécanisme d'authentification (déjà fait : PD-23, PD-25, PD-26)
• Gestion des enveloppes de clés (PD-37, PD-40)
• Interface utilisateur mobile/web (stories app dédiées)
• Alerting et monitoring (story infra dédiée)

9. Dépendances¶

10. Synthèse¶

PD-30 vise à introduire une gestion robuste, distribuée et auditable des sessions utilisateurs permettant :

• La maîtrise du cycle de vie des connexions
• La révocation immédiate multi-device
• La visibilité utilisateur sur ses accès actifs
• La conformité probatoire et réglementaire

Ce document définit ce qui est attendu.

La manière de l'implémenter (ex : moteur de stockage Redis, mécanisme TTL, architecture précise) relève de la Spécification Canonique Contractuelle (étape 1).

Validation PO¶

• Besoin validé par le PO
• Date de validation : 2026-02-18
• Commentaires : Validé sans modification