Chapitre 7 — Tracabilite et audit¶

Statut : DRAFT | Derniere mise a jour : 2026-02-26 | Story : PD-249

7.1 Piste d'audit append-only¶

Principe fondamental¶

ProbatioVault maintient un journal d'audit immutable conforme aux exigences de tracabilite de la norme NF Z42-013:2020 SS9.2 et de la norme ISO 14641:2018 SS11.4. Chaque action significative -- ingestion, consultation, destruction, administration -- genere un evenement enregistre de maniere irreversible dans le schema vault_secure.audit_log.

Le caractere immutable repose sur un mecanisme de protection au niveau de la base de donnees : un trigger PostgreSQL BEFORE UPDATE OR DELETE intercepte toute tentative de modification ou de suppression et leve une exception. Aucun chemin applicatif ne permet de contourner cette protection, car le trigger est execute par le moteur de base de donnees lui-meme, independamment de la couche applicative.

Propriete WORM du journal : le journal d'audit fonctionne selon le principe Write Once Read Many. Une fois une entree inseree, elle ne peut etre ni modifiee, ni supprimee, ni reordonnee. Cette garantie est assurée par :

• le trigger PostgreSQL bloquant les operations UPDATE et DELETE ;
• l'absence de toute route API permettant la modification d'une entree existante ;
• la signature cryptographique HSM rendant toute alteration detectable (cf. section 7.3).

Schema de la table audit_log¶

La table vault_secure.audit_log constitue le registre central de tracabilite. Chaque entree contient les champs suivants :

Les champs actor_id, action_type et entity_id sont indexes pour permettre des recherches performantes lors des audits.

Stockage et retention¶

Le journal d'audit est stocke dans le schema securise vault_secure de la base PostgreSQL, protege par les mecanismes RLS (Row-Level Security) du systeme. La retention des entrees d'audit est indefinie : aucune politique de purge automatique ne s'applique au journal. Cette conservation permanente repond a l'exigence normative de tracabilite complete sur toute la duree de vie du SAE.

7.2 Journalisation des evenements¶

Taxonomie des evenements¶

Le systeme d'audit couvre l'ensemble des actions significatives du SAE, organisees en six domaines fonctionnels. Chaque type d'evenement suit la convention de nommage domaine.action pour garantir une classification non ambigue.

Domaine Document -- Cycle de vie des archives :

Domaine Partage -- Operations de re-chiffrement delegue (PV-PRE) :

Domaine Cles -- Gestion du materiel cryptographique :

Domaine Authentification -- Sessions et identite :

Domaine Administration -- Operations privilegiees :

Domaine Systeme et Securite -- Evenements internes et alertes :

Controle d'acces : journal des autorisations et refus¶

Au-dela des evenements metier, le SAE journalise chaque decision de controle d'acces. Chaque tentative d'acces a une ressource protegee genere un evenement access.allow ou access.deny contenant :

• l'identite de l'acteur (ou null pour les requetes non authentifiees) ;
• la ressource ciblee (type et identifiant) ;
• l'action tentee (lecture, ecriture, suppression) ;
• le code de refus le cas echeant (UNAUTHORIZED, FORBIDDEN, RATE_LIMITED, RESOURCE_SEALED, etc.) ;
• le contexte de la requete (methode HTTP, chemin, identifiant de requete, claims JWT).

Ce mecanisme est implemente par un intercepteur NestJS (AccessAuditInterceptor) associe a un decorateur @AuditedResource qui permet d'annoter chaque endpoint avec le type de ressource et l'action concernee. L'interception est systematique : aucun acces a une ressource protegee ne peut echapper a la journalisation.

Format canonique des evenements¶

Chaque evenement d'audit est serialise selon la norme RFC 8785 (JSON Canonicalization Scheme -- JCS) avant signature. Cette canonicalisation produit une representation JSON deterministe garantissant que deux evenements identiques produisent exactement la meme chaine d'octets. Les regles appliquees sont :

• Tri lexicographique des cles d'objet par points de code Unicode ;
• Absence d'espaces blancs superflus (pas d'indentation, pas de separateurs) ;
• Nombres : representation minimale sans notation scientifique pour les entiers ;
• Chaines : echappement minimal conforme a la specification JSON.

Seuls les champs fonctionnels sont inclus dans le perimetre signe : actorId, actionType, entityId, entityType, metadata, timestamp. Les champs contextuels ipAddress et userAgent sont stockes a des fins d'investigation mais exclus de la signature pour des raisons de confidentialite (ces donnees peuvent varier sans que l'evenement metier soit altere).

Retention¶

La politique de retention des evenements d'audit est alignee sur la conservation indefinie du journal (cf. section 7.1). Aucun mecanisme de purge automatique n'est implemente. Cette approche garantit la disponibilite de la piste d'audit complete pour toute verification future, conformement aux exigences ISO 14641 SS11.4 et NF Z42-013 SS9.2.

7.3 Signature HSM des journaux¶

Architecture de signature¶

Chaque entree du journal d'audit est signee cryptographiquement par un HSM (Hardware Security Module) via le protocole PKCS#11. Cette signature garantit deux proprietes essentielles pour la valeur probante :

• Integrite : toute modification d'une entree invalide sa signature ;
• Non-repudiation : la cle privee de signature ne quitte jamais le HSM, rendant impossible la production de fausses signatures en dehors du materiel securise.

L'algorithme de signature utilise est ECDSA sur courbe P-384 avec SHA-384 (ECDSA_SHA384), offrant un niveau de securite de 192 bits adapte a la conservation probatoire de longue duree. La cle dediee porte le label probatiovault-audit-ecdsa-p384 et presente les attributs suivants :

Pipeline de signature¶

Le processus de signature d'une entree d'audit suit quatre etapes sequentielles, illustrees par le diagramme ci-dessous :

sequenceDiagram
    participant App as Application
    participant Canon as JsonCanonicalizeService
    participant Hash as HashService
    participant HSM as HSM PKCS#11
    participant DB as PostgreSQL

    App->>Canon: Extraction champs signes
    Canon->>Canon: Canonicalisation RFC 8785
    Canon->>Hash: JSON canonique
    Hash->>Hash: SHA3-256 (32 octets)
    Hash->>HSM: Hash buffer
    HSM->>HSM: ECDSA P-384 Sign
    HSM-->>App: Signature DER
    App->>DB: INSERT append-only
    Note over DB: Trigger immutabilite actif

Etape 1 -- Extraction : les champs fonctionnels de l'evenement (actorId, actionType, entityId, entityType, metadata, timestamp) sont extraits. Les champs contextuels (ipAddress, userAgent) sont exclus du perimetre signe.

Etape 2 -- Canonicalisation : le JsonCanonicalizeService produit une representation JSON conforme a la RFC 8785. Le service offre egalement une methode de verification isCanonical() permettant de confirmer qu'une chaine JSON est deja sous forme canonique.

Etape 3 -- Hachage : le HashService calcule l'empreinte SHA3-256 du JSON canonique, produisant un hash de 32 octets. Ce hash constitue le message soumis au HSM pour signature.

Etape 4 -- Signature HSM : le HSM signe le hash avec la cle dediee via l'interface PKCS#11. La cle privee reste dans le perimetre materiel du HSM durant toute l'operation. La signature produite est au format DER (Distinguished Encoding Rules).

L'ensemble (JSON canonique, hash, signature, identifiant de cle) est persiste dans la table vault_secure.audit_log en une seule operation INSERT, protegee par le trigger d'immutabilite.

Resilience : queue de signature asynchrone¶

En cas d'indisponibilite temporaire du HSM, le systeme ne bloque pas le flux operationnel. L'architecture prevoit une file de traitement asynchrone BullMQ pour gerer les retentatives de signature :

graph TB
    subgraph Flux nominal
        A[Evenement audit] --> B[AuditLogService]
        B --> C{HSM disponible ?}
        C -->|Oui| D[Signature synchrone]
        D --> E[INSERT audit_log]
    end

    subgraph Flux de resilience
        C -->|Non| F[Queue BullMQ<br/>audit-signature]
        F --> G[AuditSignatureProcessor]
        G --> H{Signature OK ?}
        H -->|Oui| E
        H -->|Non, retries epuises| I[Dead Letter Queue]
        I --> J[DLQ Retry Processor]
        J --> K[Alerte si age > 24h]
    end

La file audit-signature est configuree avec les parametres suivants :

Apres epuisement des retentatives, l'entree est transferee dans une Dead Letter Queue (DLQ) persistee en base de donnees (audit_signature_dlq). Un processeur dedie (AuditDlqRetryProcessor) retente periodiquement la signature des entrees DLQ. Les entrees non resolues declenchent une alerte operationnelle apres 24 heures, et une alerte critique lorsque le nombre d'entrees en attente depasse 10.

Un administrateur peut egalement declencher une retentative manuelle ou marquer une entree comme irrecuperable (ABANDONED) avec justification tracee. Les etats possibles d'une entree DLQ sont : PENDING, RETRYING, RESOLVED, ABANDONED.

Verification d'integrite¶

Le systeme expose une capacite de verification permettant de valider l'integrite de toute entree d'audit. La verification procede en trois etapes :

1. Verification du hash : recalcul du SHA3-256 a partir du entry_canonical stocke et comparaison avec le entry_hash enregistre ;
2. Verification de la signature : validation de la signature ECDSA via la cle publique du HSM ;
3. Verification de la coherence : controle que le JSON canonique stocke est bien sous forme canonique (via isCanonical()).

Le resultat de verification contient un indicateur global (valid/invalid) et le detail de chaque controle (hashMatch, signatureValid, entryIntact). Cette capacite peut etre invoquee unitairement ou par lot, et constitue le mecanisme de base pour les audits externes et la verification d'integrite periodique (cf. section 7.5).

7.4 Bordereau de destruction¶

Contexte et cadre normatif¶

La destruction definitive d'un document archive est une operation irreversible qui necessite une preuve probatoire autonome. Le bordereau de destruction (PD-250, statut : DONE) constitue cette preuve : il atteste de maniere incontestable quels documents ont ete detruits, quand, et dans quelles conditions.

Ce mecanisme repond aux exigences suivantes :

• ISO 14641:2018 SS11.4 : tracabilite et preuve de destruction, auditabilite ;
• NF Z42-013:2020 SS9.2 : journalisation, integrite et conservation des preuves ;
• Reglement eIDAS art. 26 (signature qualifiee) et art. 42 (horodatage qualifie) ;
• RGPD : minimisation des donnees (aucune donnee personnelle dans le bordereau).

Principe fail-closed¶

La destruction physique d'un document (suppression de l'objet S3 et de la reference en base) n'est autorisee qu'apres la production et la validation complete du bordereau. Si la signature ou l'horodatage du bordereau echoue, aucune destruction n'est executee. Ce principe fail-closed garantit qu'il ne peut exister de destruction sans preuve associee.

Contenu du bordereau¶

Chaque batch de destruction produit exactement un bordereau consolide au format PDF/A. Le contenu est strictement limite aux champs techniques autorises, a l'exclusion de toute donnee personnelle directe :

Exclusions : nom, prenom, email, adresse, numero de telephone, numero de securite sociale et toute donnee permettant l'identification directe d'une personne physique.

Scellement du bordereau¶

Le bordereau suit un processus de scellement en trois etapes :

1. Generation PDF/A : le contenu est mis en forme dans un document PDF/A conforme ;
2. Signature electronique : le bordereau est signe par un service de signature qualifie (eIDAS art. 26) ;
3. Horodatage RFC 3161 : un jeton d'horodatage qualifie (eIDAS art. 42) est appose sur le bordereau signe.

Si l'horodatage echoue apres les tentatives de retentative configurees (3 par defaut), le batch passe en etat FAILED et aucune destruction n'est executee.

Conservation¶

Les bordereaux de destruction beneficient d'une conservation indefinie. Ils sont stockes en tant que documents probatoires avec les protections suivantes :

• statut SEALED sans date d'expiration (jamais eligibles a la destruction automatique) ;
• protection WORM PostgreSQL via triggers SECURITY DEFINER ;
• Object Lock COMPLIANCE sur S3 avec retention maximale.

Un endpoint d'administration, restreint au role ADMIN, permet la consultation des bordereaux avec filtrage par date et par batch.

Tracabilite unitaire¶

Chaque document detruit dans un batch genere une entree d'audit individuelle contenant la reference au documentId, au batchId et au bordereauId. Ces entrees respectent les proprietes de non-perte (persistance transactionnelle ACID), d'ordre causal (sequence PostgreSQL audit_seq monotone croissante) et de completude (exactement une entree par document traite).

7.5 Rapports d'integrite¶

Statut : En cours de developpement (PD-251, Q1 2026). Cette section decrit l'architecture cible et les mecanismes deja specifies. Les implementations partielles sont signalees.

Objectif¶

Le mecanisme de verification d'integrite periodique vise a detecter de maniere proactive toute corruption de la chaine probatoire (documents WORM, preuves Merkle, jetons TSA, ancres blockchain). Il repond a l'exigence NF Z42-013 SS11.1 et ISO 14641 SS6.2 concernant la verification periodique de l'integrite avec tracabilite.

Chaine de preuve verifiee¶

Chaque cycle de verification (run) examine quatre maillons pour chaque archive selectionnee :

Aucune archive ne peut etre marquee "verifiee" si l'un des quatre maillons n'a pas un resultat explicite.

Double verification avant gel¶

En cas de mismatch de hash detecte, une procedure de confirmation en deux etapes evite les faux positifs :

1. Relecture via une nouvelle connexion S3 et recalcul independant du SHA3-256 ;
2. Lecture alternative (endpoint HEAD + GET) avec recalcul.

Si le mismatch est confirme apres ces verifications (3 tentatives maximum, timeout de 5 secondes par tentative), le document transite vers l'etat SUSPECT et la procedure de reaction graduee est declenchee.

Reaction graduee¶

La reponse a une anomalie confirmee suit quatre phases :

Format du rapport de run¶

Chaque run de verification produit un rapport, y compris en l'absence d'anomalie. Le rapport contient :

• le perimetre traite (nombre d'archives, criteres de selection) ;
• les metriques de verification (duree, nombre de verifications par maillon) ;
• les anomalies detectees avec detail de chaque phase de reaction ;
• le statut final du run ;
• l'horodatage du rapport.

La retention des rapports est configurable (defaut : 3 650 jours, soit 10 ans), avec des bornes contractuelles de 1 a 36 500 jours.

Priorisation et frequence¶

Les archives sont priorisees selon un score multi-criteres (0.00 a 1.00) tenant compte du statut juridique, de l'age et de la criticite contractuelle. Les archives dont le score depasse le seuil de haute priorite (defaut : 0.80) sont traitees en premier. La frequence de verification est configurable par cron, avec des politiques de scope (complet, partitionne, rotatif).

Conformite normative du module de tracabilite¶

Le tableau suivant recapitule la couverture des exigences normatives par les mecanismes decrits dans ce chapitre :

References¶

• RFC 8785 -- JSON Canonicalization Scheme (JCS) : https://www.rfc-editor.org/rfc/rfc8785
• RFC 3161 -- Time-Stamp Protocol : https://www.rfc-editor.org/rfc/rfc3161
• PKCS#11 -- Cryptographic Token Interface Standard : https://docs.oasis-open.org/pkcs11/
• ISO 14641:2018 -- Archivage electronique : conception et exploitation d'un SAE
• NF Z42-013:2020 -- Archivage electronique : specifications relatives a la conception et a l'exploitation de systemes informatiques
• eIDAS (UE) n 910/2014 -- Reglement sur l'identification electronique et les services de confiance