Spécification fonctionnelle complète pour l'Audit Log des Authentifications (PD-31)

# Spécification fonctionnelle complète pour l'Audit Log des Authentifications (PD-31)

Résumé exécutif¶

Cette spécification décrit la mise en place d'un système de journalisation exhaustive et probatoire pour toutes les opérations d'authentification sur ProbatioVault, une infrastructure de preuve numérique souveraine. Le but est de garantir que chaque événement soit horodaté avec précision UTC, associé à des métadonnées contextuelles et intégré dans le journal append-only (PostgreSQL + triggers). Les logs seront inclus dans un batch Merkle périodique, ancrés via TSA + blockchain et exploitables pour audit, investigation ou production judiciaire.

Glossaire¶

• PD-31 : Story de l'expression de besoin
• AUTH_LOGIN_SUCCESS : Événement d'authentification réussie
• AUTH_LOGIN_FAILURE : Événement d'échec d'authentification
• AUTH_LOGOUT : Événement de déconnexion volontaire
• AUTH_MFA_ATTEMPT : Événement d'initiation d'une vérification MFA
• AUTH_MFA_SUCCESS : Événement de validation du code MFA
• AUTH_MFA_FAILURE : Événement de rejet du code MFA
• AUTH_DEVICE_REVOKED : Accès refusé en raison d'un device blacklisté
• AUTH_TOKEN_INVALID : Accès refusé en raison d'un JWT expiré/invalide
• ios, pwa, api : Canaux couverts pour l'authentification
• event_id : Identifiant unique monotonique de chaque événement
• event_type : Code de l'événement (voir 4.1)
• timestamp : Horodatage UTC de chaque événement
• user_id : Identifiant utilisateur interne
• identity_level : Niveau d'identité (email, oidc, enterprise)
• device_id : Identifiant du dispositif utilisé pour l'authentification
• channel : Canal utilisé pour l'authentification (ios, pwa ou api)
• ip_address : Adresse IPv4 ou IPv6 de la connexion
• user_agent : User-Agent complet de la requête d'authentification
• geo_country : Code pays ISO 3166-1 de l'emplacement géographique de la connexion
• geo_region : Région/État de l'emplacement géographique de la connexion
• success : Indicateur du succès ou de l'échec de l'opération d'authentification
• failure_reason : Code erreur en cas d'échec de l'authentification
• session_id : Identifiant de session JWT associée à la connexion
• correlation_id : Traçabilité inter-services pour suivre les événements liés à une même requête
• risk_score : Score de risque calculé pour chaque événement d'authentification

Fonctionnalités détaillées¶

F-01-01: Journalisation des opérations d'authentification réussies (AUTH_LOGIN_SUCCESS)¶

• Description : Enregistrement exhaustif et probatoire de chaque tentative d'authentification réussie, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés avec succès sur ProbatioVault
• Prérequis : L'utilisateur doit avoir initié une demande d'authentification valide et fourni des informations d'identification correctes.
• Flux nominal : Un événement AUTH_LOGIN_SUCCESS est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_LOGIN_SUCCESS est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-001: 100% des opérations d'authentification réussies sont enregistrées avec succès; CA-01-002: Les événements AUTH_LOGIN_SUCCESS contiennent toutes les métadonnées contextuelles requises.

F-01-02: Journalisation des opérations d'authentification échouées (AUTH_LOGIN_FAILURE)¶

• Description : Enregistrement exhaustif et probatoire de chaque tentative d'authentification échouée, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs ayant initié une demande d'authentification avec des informations d'identification incorrectes ou invalides sur ProbatioVault
• Prérequis : L'utilisateur doit avoir initié une demande d'authentification valide et fourni des informations d'identification incorrectes ou invalides.
• Flux nominal : Un événement AUTH_LOGIN_FAILURE est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_LOGIN_FAILURE est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-003: 100% des opérations d'authentification échouées sont enregistrées avec succès; CA-01-004: Les événements AUTH_LOGIN_FAILURE contiennent toutes les métadonnées contextuelles requises.

F-01-03: Journalisation des déconnexions volontaires (AUTH_LOGOUT)¶

• Description : Enregistrement exhaustif et probatoire de chaque demande de déconnexion initiée par l'utilisateur, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés sur ProbatioVault qui souhaitent se déconnecter volontairement.
• Prérequis : L'utilisateur doit être connecté à la plateforme et initier une demande de déconnexion valide.
• Flux nominal : Un événement AUTH_LOGOUT est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_LOGOUT est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-005: 100% des opérations de déconnexion volontaires sont enregistrées avec succès; CA-01-006: Les événements AUTH_LOGOUT contiennent toutes les métadonnées contextuelles requises.

F-01-04: Journalisation des tentatives de vérification MFA (AUTH_MFA_ATTEMPT)¶

• Description : Enregistrement exhaustif et probatoire de chaque demande d'initiation d'une vérification MFA, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés sur ProbatioVault qui souhaitent initier une vérification MFA pour renforcer leur sécurité.
• Prérequis : L'utilisateur doit être connecté à la plateforme et fournir des informations d'identification valides pour initier une demande de vérification MFA.
• Flux nominal : Un événement AUTH_MFA_ATTEMPT est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_MFA_ATTEMPT est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-007: 100% des tentatives de vérification MFA sont enregistrées avec succès; CA-01-008: Les événements AUTH_MFA_ATTEMPT contiennent toutes les métadonnées contextuelles requises.

F-01-05: Journalisation des validations de code MFA (AUTH_MFA_SUCCESS)¶

• Description : Enregistrement exhaustif et probatoire de chaque validation réussie d'un code MFA, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés sur ProbatioVault qui ont fourni un code MFA valide pour renforcer leur sécurité.
• Prérequis : L'utilisateur doit être connecté à la plateforme, avoir initié une demande de vérification MFA et fournir un code MFA valide.
• Flux nominal : Un événement AUTH_MFA_SUCCESS est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_MFA_SUCCESS est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-009: 100% des validations réussies de code MFA sont enregistrées avec succès; CA-01-010: Les événements AUTH_MFA_SUCCESS contiennent toutes les métadonnées contextuelles requises.

F-01-06: Journalisation des rejets de code MFA (AUTH_MFA_FAILURE)¶

• Description : Enregistrement exhaustif et probatoire de chaque validation échouée d'un code MFA, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés sur ProbatioVault qui ont fourni un code MFA invalide ou expiré pour renforcer leur sécurité.
• Prérequis : L'utilisateur doit être connecté à la plateforme, avoir initié une demande de vérification MFA et fournir un code MFA invalide ou expiré.
• Flux nominal : Un événement AUTH_MFA_FAILURE est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_MFA_FAILURE est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-011: 100% des rejets de code MFA sont enregistrés avec succès; CA-01-012: Les événements AUTH_MFA_FAILURE contiennent toutes les métadonnées contextuelles requises.

F-01-07: Journalisation du refus d'accès pour device révoqué (AUTH_DEVICE_REVOKED)¶

• Description : Enregistrement exhaustif et probatoire de chaque tentative d'authentification rejetée en raison d'un device blacklisté, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés sur ProbatioVault qui essaient de se connecter avec un device révoqué ou blacklisté.
• Prérequis : L'utilisateur doit être connecté à la plateforme et fournir des informations d'identification valides, mais le device utilisé est blacklisté.
• Flux nominal : Un événement AUTH_DEVICE_REVOKED est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_DEVICE_REVOKED est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-013: 100% des refus d'accès pour device révoqué sont enregistrés avec succès; CA-01-014: Les événements AUTH_DEVICE_REVOKED contiennent toutes les métadonnées contextuelles requises.

F-01-08: Journalisation du refus d'accès pour token invalide (AUTH_TOKEN_INVALID)¶

• Description : Enregistrement exhaustif et probatoire de chaque tentative d'authentification rejetée en raison d'un JWT expiré ou invalide, incluant les métadonnées contextuelles.
• Acteurs : Utilisateurs authentifiés sur ProbatioVault qui essaient de se connecter avec un token expiré ou invalide.
• Prérequis : L'utilisateur doit être connecté à la plateforme et fournir des informations d'identification valides, mais le JWT utilisé est expiré ou invalide.
• Flux nominal : Un événement AUTH_TOKEN_INVALID est créé, horodaté avec précision UTC, associé aux métadonnées contextuelles et intégré dans le journal append-only.
• Flux alternatifs : Aucun flux alternatif n'est prévu pour cette fonctionnalité.
• Postconditions : L'événement AUTH_TOKEN_INVALID est stocké de manière immuable, horodaté et associé aux métadonnées contextuelles dans le journal append-only.
• Critères d'acceptation (CA) : CA-01-015: 100% des refus d'accès pour token invalide sont enregistrés avec succès; CA-01-016: Les événements AUTH_TOKEN_INVALID contiennent toutes les métadonnées contextuelles requises.

Invariants de sécurité (INV)¶

• INV-01-01 : Le journal append-only doit être immuable et ne peut pas être modifié ou supprimé une fois qu'un événement est enregistré.
• INV-01-02 : Les horodatages UTC doivent inclure des millisecondes pour garantir la précision temporelle de chaque événement.
• INV-01-03 : Chaque événement doit être associé à un hash SHA-3-256, qui est utilisé pour assurer l'intégrité et le chaînage des événements dans le journal append-only.
• INV-01-04 : Les données sensibles (mots de passe, secrets MFA, clés cryptographiques) ne doivent jamais être stockées dans les logs d'authentification.
• INV-01-05 : Le chiffrement at-rest et in-transit doit être utilisé pour protéger la confidentialité des données stockées dans le journal append-only.

Modèle de données (MD)¶

Le modèle de données comprend une table PostgreSQL appelée authentication_events avec les colonnes suivantes :

• event_id (UUID v7, clé primaire)
• event_type (Enum)
• timestamp (ISO-8601)
• user_id (UUID, indexé)
• identity_level (Enum)
• device_id (UUID)
• channel (Enum)
• ip_address (String)
• user_agent (String)
• geo_country (ISO 3166-1)
• geo_region (String)
• success (Boolean)
• failure_reason (Enum, conditionnel)
• session_id (UUID)
• correlation_id (UUID)
• risk_score (Float 0-1)

Interfaces API¶

Endpoints¶

• POST /auth/events : Créer un nouvel événement d'authentification et l'intégrer dans le journal append-only.
• GET /auth/events/{event_id} : Récupérer les détails d'un événement d'authentification spécifique à partir du journal append-only.
• GET /auth/events?filter={filtres} : Récupérer une liste filtrée d'événements d'authentification à partir du journal append-only.

Authentication et Authorization¶

Les endpoints de l'API sont protégés par un mécanisme d'authentification basé sur des clés API, qui garantit que seuls les utilisateurs autorisés peuvent accéder aux données du journal append-only. Les rôles ADMIN et AUDITOR ont accès à l'ensemble des fonctionnalités de l'API d'authentification, tandis que les autres rôles sont limités dans leurs actions en fonction de leur niveau d'autorisation.

Request/Response JSON¶

Les requêtes et réponses pour les endpoints de l'API utilisent le format JSON. Les exemples suivants illustrent la structure des données échangées entre le client et le serveur :

Requête POST /auth/events (créer un nouvel événement)¶

{
  "event_type": "AUTH_LOGIN_SUCCESS",
  "timestamp": "2026-03-15T14:37:18.987Z",
  "user_id": "e9befdbf-cdaa-4fba-9f2f-094cb76492af",
  "identity_level": "email",
  "device_id": null,
  "channel": "pwa",
  "ip_address": "192.168.1.100",
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36",
  "geo_country": "FR",
  "geo_region": null,
  "success": true,
  "failure_reason": null,
  "session_id": "a89befdbf-cdaa-4fba-9f2f-094cb76492af",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000",
  "risk_score": 0.1
}

Réponse GET /auth/events/{event_id} (récupérer un événement spécifique)¶

{
  "event_id": "3ba8567b-2f4a-4e09-ad1d-c1beacdbceff",
  "event_type": "AUTH_LOGIN_SUCCESS",
  "timestamp": "2026-03-15T14:37:18.987Z",
  "user_id": "e9befdbf-cdaa-4fba-9f2f-094cb76492af",
  "identity_level": "email",
  "device_id": null,
  "channel": "pwa",
  "ip_address": "192.168.1.100",
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36",
  "geo_country": "FR",
  "geo_region": null,
  "success": true,
  "failure_reason": null,
  "session_id": "a89befdbf-cdaa-4fba-9f2f-094cb76492af",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000",
  "risk_score": 0.1
}

Réponse GET /auth/events?filter={filtres} (récupérer une liste filtrée d'événements)¶

[
  {
    "event_id": "3ba8567b-2f4a-4e09-ad1d-c1beacdbceff",
    "event_type": "AUTH_LOGIN_SUCCESS",
    "timestamp": "2026-03-15T14:37:18.987Z",
    "user_id": "e9befdbf-cdaa-4fba-9f2f-094cb76492af",
    "identity_level": "email",
    "device_id": null,
    "channel": "pwa",
    "ip_address": "192.168.1.100",
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36",
    "geo_country": "FR",
    "geo_region": null,
    "success": true,
    "failure_reason": null,
    "session_id": "a89befdbf-cdaa-4fba-9f2f-094cb76492af",
    "correlation_id": "123e4567-e89b-12d3-a456-426614174000",
    "risk_score": 0.1
  },
  {...}
]

Codes erreur¶

Les codes d'erreur suivants peuvent être renvoyés par les endpoints de l'API en cas d'échec :

• 400 Bad Request : Les données fournies dans la requête sont invalides ou manquantes.
• 401 Unauthorized : L'utilisateur n'est pas authentifié ou ne dispose pas des autorisations nécessaires pour accéder aux ressources demandées.
• 403 Forbidden : L'utilisateur est authentifié mais ne dispose pas des autorisations nécessaires pour effectuer l'action demandée.
• 404 Not Found : La ressource demandée n'existe pas ou n'est plus disponible.
• 500 Internal Server Error : Une erreur inattendue s'est produite sur le serveur.

Événements (consommés/publiés)¶

Les événements d'authentification sont consommés par l'API pour être enregistrés dans le journal append-only et publiés vers les systèmes de notification, d'alerting et d'ancrage. Les événements suivants peuvent être consommés ou publiés :

• AUTH_LOGIN_SUCCESS
• AUTH_LOGIN_FAILURE
• AUTH_LOGOUT
• AUTH_MFA_ATTEMPT
• AUTH_MFA_SUCCESS
• AUTH_MFA_FAILURE
• AUTH_DEVICE_REVOKED
• AUTH_TOKEN_INVALID

Contraintes techniques (performance, sécurité, conformité)¶

Performance¶

Les contraintes de performance pour le système d'authentification sont les suivantes :

• Latence insertion < 5 ms (P99) : Le temps nécessaire pour enregistrer un événement dans le journal append-only doit être inférieur à 5 millisecondes dans 99% des cas.
• Throughput > 1000 evt/s : Le système doit pouvoir traiter plus de 1000 événements par seconde pour garantir une scalabilité suffisante.
• Impact sur auth < 1 ms overhead : L'impact du journalisation des événements d'authentification sur la latence globale de l'authentification doit être inférieur à 1 milliseconde.

Sécurité¶

Les contraintes de sécurité pour le système d'authentification sont les suivantes :

• Chiffrement at-rest (AES-256) et in-transit (TLS 1.3) : Les données stockées dans le journal append-only doivent être chiffrées à l'aide d'un algorithme AES-256, tandis que les communications entre le client et le serveur doivent utiliser TLS 1.3 pour garantir la confidentialité des données en transit.
• Séparation Zero-Knowledge : Les informations sensibles (mots de passe, secrets MFA, clés cryptographiques) ne doivent jamais être stockées dans les logs d'authentification pour préserver le principe de séparation des responsabilités et garantir la confidentialité des données.
• Accès aux logs limité : Seuls les utilisateurs disposant des rôles ADMIN ou AUDITOR peuvent accéder aux événements d'authentification enregistrés dans le journal append-only, afin de limiter l'exposition des données sensibles.
• Audit RGPD : Les logs doivent être audités régulièrement pour vérifier la conformité avec les exigences du Règlement Général sur la Protection des Données (RGPD).

Conformité¶

Les contraintes de conformité pour le système d'authentification sont les suivantes :

• Normes de conformité : Le système doit respecter les normes de conformité RGPD, NF Z42-013 et ISO 14641.
• Archivage légal : Les logs doivent être conservés pendant une durée minimale de 10 ans pour répondre aux exigences d'archivage légal.
• Rétention des données : La politique de rétention des données doit garantir que les événements d'authentification sont stockés dans le journal append-only pendant une durée suffisante, tout en optimisant l'utilisation du stockage et la performance.
• Migration automatique vers cold storage : Après 3 ans de conservation dans le stockage chaud (PostgreSQL), les événements d'authentification doivent être migrés automatiquement vers un stockage froid (S3 Glacier) pour optimiser l'utilisation des ressources et garantir la conformité aux exigences de rétention.

Dépendances¶

Les dépendances suivantes sont nécessaires pour mettre en œuvre le système d'authentification probatoire :

• Journal append-only (PD-37) : La mise en place du journal append-only est une condition préalable à l'enregistrement des événements d'authentification de manière immuable et sécurisée.
• Batch Merkle (PD-39) : L'intégration des événements d'authentification dans un batch Merkle périodique est nécessaire pour garantir l'ancrage cryptographiquement sécurisé de ces données.
• Ancrage TSA (PD-39) et ancrage blockchain (PD-40) : L'utilisation d'un service d'horodatage certifié (TSA) et d'une blockchain publique pour l'ancrage des batches Merkle est nécessaire pour garantir la vérification indépendante de l'intégrité des données.
• Auth SRP-6a (PD-24/25) : La mise en place d'un mécanisme d'authentification sécurisé basé sur le protocole SRP-6a est une condition préalable à l'enregistrement des événements d'authentification.
• Session management (PD-28) : La gestion des sessions utilisateur est nécessaire pour assurer la cohérence et la traçabilité des actions effectuées par les utilisateurs sur la plateforme.

Hors périmètre¶

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

• Dashboard de visualisation des logs (story dédiée) : La création d'un tableau de bord pour visualiser les événements d'authentification enregistrés dans le journal append-only est hors du périmètre de cette story.
• Analytics temps réel (Grafana, Prometheus) : L'analyse des données en temps réel à l'aide de solutions telles que Grafana ou Prometheus n'est pas couverte par cette story.
• Intégration SIEM externe (Splunk, ELK) : L'intégration avec des outils de gestion d'événements et d'informations de sécurité (SIEM) tels que Splunk ou Elastic Stack n'est pas couverte par cette story.
• Notifications push utilisateur : La mise en place de notifications push pour informer les utilisateurs des événements liés à leur authentification est hors du périmètre de cette story.
• Rapport PDF certifié automatique : La génération automatique d'un rapport PDF certifiant l'intégrité et la véracité des données enregistrées dans le journal append-only n'est pas couverte par cette story.

Questions ouvertes¶

Les questions suivantes restent à résoudre pour finaliser la mise en œuvre du système d'authentification probatoire :

1. Quelle solution de stockage chaud (PostgreSQL) et froid (S3 Glacier) utiliser pour optimiser les performances, le coût et la sécurité ?
2. Comment gérer l'indexation des événements d'authentification dans le journal append-only pour garantir une recherche rapide et efficace ?
3. Quels mécanismes de chiffrement at-rest (AES-256) et in-transit (TLS 1.3) utiliser pour protéger les données sensibles dans le journal append-only ?
4. Comment mettre en place un système d'alerting temps réel pour détecter et signaler les patterns anormaux, tels que bruteforce ou geo-hopping ?
5. Quelle solution de gestion des sessions utilisateur (PD-28) utiliser pour assurer la cohérence et la traçabilité des actions effectuées par les utilisateurs sur la plateforme ?