PD-31 — Expression de besoin¶

Audit Log des Authentifications¶

Story : PD-31 Epic : PD-182 (AUTH) Projet : ProbatioVault-backend Version : 1.0 Date : 2026-02-15

1. Contexte¶

ProbatioVault est une infrastructure de preuve numérique souveraine fondée sur : - Un modèle Zero-Knowledge (SRP-6a, dérivations locales) - Une séparation forte des responsabilités (Backend / HSM / Stockage) - Un journal append-only probatoire - Un ancrage périodique (Merkle + TSA + blockchain)

L'authentification constitue le point d'entrée critique de la plateforme. Toute opération d'accès doit être traçable, horodatée et auditée, conformément : - Aux exigences d'auditabilité (architecture technique) - Aux exigences probatoires (journal immuable + ancrage périodique — Preuve Composite) - Aux normes de conformité (RGPD, NF Z42-013, ISO 14641)

2. Problème à résoudre¶

Aujourd'hui : Les événements d'authentification ne sont pas systématiquement journalisés de manière probatoire. En cas de litige, d'audit sécurité ou d'expertise judiciaire, il est impossible de : - Prouver qu'un utilisateur s'est connecté à une date précise - Démontrer qu'une tentative d'accès non autorisée a eu lieu - Fournir des preuves d'existence antérieure des logs

Demain : Chaque événement d'authentification sera intégré dans le cycle probatoire complet, permettant une opposabilité juridique.

3. Objectifs¶

3.1 Objectif principal¶

Garantir que toutes les opérations d'authentification soient : 1. Enregistrées de manière exhaustive 2. Horodatées avec précision UTC 3. Associées à des métadonnées contextuelles (IP, device, geoloc) 4. Intégrées dans le journal append-only 5. Incluses dans le batch Merkle périodique 6. Ancrées via TSA + blockchain 7. Exploitables pour audit, investigation ou production judiciaire

3.2 Objectifs secondaires¶

• Alerting temps réel : Détecter et signaler les patterns anormaux (bruteforce, geo-hopping)
• Scoring de risque : Attribuer un score de risque à chaque événement
• Preuve d'alerte : Les alertes elles-mêmes doivent être intégrées au cycle probatoire

4. Périmètre fonctionnel¶

4.1 Événements à journaliser¶

4.2 Canaux couverts¶

4.3 Métadonnées à collecter¶

*Peut être absent pour tentatives sur identifiant inconnu

4.4 Données exclues (Zero-Knowledge)¶

Les logs ne doivent JAMAIS contenir : - Mot de passe (hashé ou non) - Secret MFA (TOTP seed, recovery codes) - Clés cryptographiques - Données personnelles non nécessaires (principe de minimisation RGPD)

5. Contraintes¶

5.1 Immutabilité (NON NÉGOCIABLE)¶

5.2 Architecture probatoire¶

Événement Auth
    ↓
Journal append-only (PostgreSQL + triggers)
    ↓
Batch Merkle (toutes les 10 min ou 1000 événements)
    ↓
TSA (horodatage certifié)
    ↓
Blockchain (ancrage public)
    ↓
Preuve Composite vérifiable

5.3 Rétention¶

Migration automatique après 3 ans vers cold storage.

5.4 Performance¶

L'insertion dans le journal ne doit JAMAIS bloquer le flow d'authentification (async + queue).

5.5 Confidentialité¶

• Logs accessibles uniquement aux rôles ADMIN et AUDITOR
• Chiffrement at-rest (AES-256)
• Chiffrement in-transit (TLS 1.3)
• Respect séparation Zero-Knowledge

6. Alerting temps réel¶

6.1 Patterns à détecter¶

6.2 Caractéristiques¶

• Configurables : Seuils modifiables sans redéploiement
• Scoring : Chaque alerte contribue au risk_score de l'événement
• Journalisées : Les alertes sont elles-mêmes des événements probatoires
• Intégrées : Incluses dans le cycle d'ancrage Merkle

6.3 Actions¶

7. Export judiciaire¶

7.1 Format Preuve ProbatioVault¶

L'export pour expertise judiciaire doit inclure :

1. Sous-ensemble des logs demandés (filtré par date, user, etc.)
2. Merkle path correspondant (preuve d'inclusion)
3. Merkle root ancré
4. Jeton TSA (horodatage certifié)
5. Transaction blockchain (preuve d'ancrage public)
6. Métadonnées du batch d'ancrage

7.2 Garanties¶

L'export prouve : - Les logs existaient à la date T (antériorité) - Ils n'ont pas été modifiés depuis (intégrité) - Ils faisaient partie d'un ensemble cohérent (batch) - Cet ensemble a été figé cryptographiquement (Merkle) - Ce figement est ancré via tiers de confiance (TSA + blockchain)

8. Hors périmètre¶

Les éléments suivants sont explicitement exclus de cette story :

• Dashboard de visualisation des logs (story dédiée)
• Analytics temps réel (Grafana, Prometheus)
• Intégration SIEM externe (Splunk, ELK)
• Notifications push utilisateur
• Rapport PDF certifié automatique

9. Critères de succès¶

10. Dépendances¶

11. Risques identifiés¶

Validation PO¶

Date : 2026-02-15 Statut : En attente validation

Document généré dans le cadre du workflow de gouvernance ProbatioVault.