PD-17 — Journalisation des accès et refus (Extension probatoire)¶

1. Objectif¶

Définir une extension fonctionnelle et probatoire du mécanisme de journalisation existant (PD-37) afin de tracer toutes les tentatives d’accès, réussies ou refusées, sans jamais altérer ni affaiblir les garanties cryptographiques, juridiques et probatoires établies par PD-37.

La présente spécification établit que PD-17 ne crée pas de journal autonome et n’introduit aucun schéma concurrent, mais s’appuie exclusivement sur le journal probatoire signé HSM existant, en l’enrichissant par des informations de contexte d’accès et de refus.

La preuve HSM issue de PD-37 fait foi. PD-17 est une extension descriptive, non substitutive.

2. Périmètre / Hors périmètre¶

Périmètre¶

Enrichissement sémantique du journal probatoire existant vault_secure.audit_log.
Traçabilité des accès autorisés.
Traçabilité des accès refusés.
Journalisation des décisions de contrôle d’accès (ALLOW / DENY).
Maintien strict du caractère append-only, WORM logique et signé HSM.

Hors périmètre¶

Toute modification ou suppression des champs probatoires HSM existants (PD-37).
Toute journalisation non signée ou non horodatée.
Toute analyse temps réel, dashboard ou moteur d’alerting.
Toute décision d’autorisation (déjà couverte par d’autres PD).

3. Définitions¶

Journal probatoire : registre append-only, signé matériellement (HSM), horodaté et vérifiable indépendamment.
Accès : tentative d’interaction avec une ressource protégée (document, enveloppe, métadonnée, API).
Refus (DENY) : tentative d’accès rejetée par une règle de sécurité ou de conformité.
Événement d’audit : entrée atomique et immuable du journal.
PD-37 : mécanisme fondateur de journalisation probatoire signée HSM.
Payload canonique PD-17 : sous-objet JSON normé, inclus dans entry_canonical, décrivant le résultat d’accès et son contexte.
Journal probatoire : registre append-only, signé matériellement (HSM), horodaté et vérifiable indépendamment.
Accès : tentative d’interaction avec une ressource protégée (document, enveloppe, métadonnée, API).
Refus (DENY) : tentative d’accès rejetée par une règle de sécurité ou de conformité.
Événement d’audit : entrée atomique et immuable du journal.
PD-37 : mécanisme fondateur de journalisation probatoire signée HSM.

4. Invariants (non négociables)¶

Unicité du journal :
Il existe un seul journal probatoire de référence : vault_secure.audit_log.
Primauté de PD-37 :
Les colonnes probatoires PD-37 (entry_canonical, entry_hash, hsm_signature, etc.) sont intangibles.
Encodage unique des données PD-17 :
Toute information PD-17 (ALLOW/DENY, codes de refus, contexte étendu) est exclusivement encodée dans entry_canonical.
Aucune colonne supplémentaire n’est créée.
Append-only strict :
Aucune mise à jour ni suppression d’événement n’est autorisée.
Signature obligatoire :
Chaque événement (ALLOW ou DENY) DOIT être signé par le HSM.
Horodatage certifié :
Chaque événement DOIT être horodaté selon la politique PD-37.
Neutralité décisionnelle testable :
PD-17 n’émet aucune décision.
Critère testable : aucune règle d’autorisation ou de refus n’est implémentée dans le module PD-17.
Unicité du journal :
Il existe un seul journal probatoire de référence.
Aucun journal parallèle ne peut être créé pour PD-17.
Primauté de PD-37 :
Tous les champs probatoires définis par PD-37 sont obligatoires et intangibles.
Append-only strict :
Aucune mise à jour ni suppression d’événement n’est autorisée.
Signature obligatoire :
Chaque événement (ALLOW ou DENY) DOIT être signé par le HSM.
Horodatage certifié :
Chaque événement DOIT être horodaté selon la politique PD-37.
Neutralité fonctionnelle :
PD-17 n’introduit aucune décision de sécurité.
Il constate uniquement des décisions déjà prises.

5. Flux nominaux¶

5.0 Structure canonique PD-17 (normative)¶

Le champ entry_canonical DOIT contenir un objet JSON canonique incluant le sous-objet suivant :

{
  "pd": "PD-17",
  "access_result": "ALLOW" | "DENY",
  "deny_code": "<CODE>" | null,
  "context": {
    "actor_type": "USER" | "SERVICE" | "SYSTEM",
    "actor_id": "<uuid>",
    "entity_type": "DOCUMENT" | "ENVELOPE" | "API",
    "entity_id": "<uuid>",
    "ip_address": "<ip>",
    "user_agent": "<string>"
  }
}

5.1 Accès autorisé¶

Une tentative d’accès est évaluée par le moteur de sécurité.
La décision ALLOW est rendue.
Un événement d’audit est créé.
entry_canonical.access_result = "ALLOW".
deny_code = null.
L’événement est signé HSM et persisté.

5.2 Accès refusé¶

Une tentative d’accès est évaluée.
La décision DENY est rendue.
Un événement d’audit est créé.
entry_canonical.access_result = "DENY".
deny_code DOIT appartenir à la taxonomie définie en §10.1.
L’événement est signé HSM et persisté.

5.1 Accès autorisé¶

Une tentative d’accès est évaluée par le moteur de sécurité.
La décision ALLOW est rendue.
Un événement d’audit est créé dans audit_log.
L’événement inclut :
les champs probatoires PD-37,
les métadonnées contextuelles PD-17,
un indicateur de résultat = ALLOW.
L’événement est signé HSM et persisté.

5.2 Accès refusé¶

Une tentative d’accès est évaluée.
La décision DENY est rendue.
Un événement d’audit est créé dans audit_log.
L’événement inclut :
les champs probatoires PD-37,
les métadonnées contextuelles PD-17,
un indicateur de résultat = DENY,
un code de refus.
L’événement est signé HSM et persisté.

5bis. Diagrammes¶

5bis.1 Diagramme d’états — Cycle de vie d’un événement d’audit PD-17¶

Un événement d’audit traverse au minimum 4 états avant persistance. Tout échec de validation ou de signature entraîne un rejet irréversible (INV-4 : append-only strict, INV-5 : signature obligatoire).

stateDiagram-v2
    [*] --> CREATED : Tentative d’accès détectée
    CREATED --> VALIDATED : Schéma JSON §5.0 conforme\n(INV-3 : encodage unique entry_canonical)
    CREATED --> REJECTED : Schéma JSON §5.0 non conforme
    VALIDATED --> SIGNED : Signature HSM réussie\n(INV-5 : signature obligatoire)
    VALIDATED --> REJECTED : Échec signature HSM
    SIGNED --> PERSISTED : Écriture append-only\n(INV-4 : append-only strict,\nINV-6 : horodatage certifié)
    PERSISTED --> [*]
    REJECTED --> [*]

    note right of CREATED
        access_result = ALLOW | DENY
        deny_code renseigné si DENY (§10.1)
    end note

    note right of REJECTED
        Aucun accès accordé (fail-closed)
        INV-7 : neutralité décisionnelle
    end note

5bis.2 Diagramme de séquence — Flux nominal ALLOW / DENY¶

Interactions entre le moteur de sécurité, le module PD-17 (extension descriptive), le journal PD-37 et le HSM. PD-17 ne prend aucune décision (INV-7 : neutralité décisionnelle) ; il enrichit le payload canonique avant délégation à PD-37.

sequenceDiagram
    participant Client
    participant SecurityEngine as Moteur de sécurité<br/>(externe à PD-17)
    participant PD17 as Module PD-17<br/>(extension descriptive)
    participant PD37 as Journal PD-37<br/>(vault_secure.audit_log)
    participant HSM as HSM<br/>(signature matérielle)

    Client->>SecurityEngine: Tentative d’accès (ressource protégée)
    SecurityEngine->>SecurityEngine: Évaluation ALLOW / DENY

    alt Accès autorisé (§5.1)
        SecurityEngine->>PD17: Décision ALLOW + contexte
        PD17->>PD17: Assemblage payload canonique §5.0<br/>access_result=ALLOW, deny_code=null<br/>(INV-3 : encodage dans entry_canonical)
        PD17->>PD37: Événement d’audit (entry_canonical enrichi)
        PD37->>HSM: Demande signature (INV-5)
        HSM-->>PD37: Signature ECDSA
        PD37->>PD37: Horodatage certifié (INV-6)<br/>Persistance append-only (INV-4)
        PD37-->>PD17: OK (entrée signée persistée)
        PD17-->>SecurityEngine: Audit enregistré
        SecurityEngine-->>Client: Accès accordé
    else Accès refusé (§5.2)
        SecurityEngine->>PD17: Décision DENY + deny_code (§10.1) + contexte
        PD17->>PD17: Assemblage payload canonique §5.0<br/>access_result=DENY, deny_code=CODE<br/>(INV-3 : encodage dans entry_canonical)
        PD17->>PD37: Événement d’audit (entry_canonical enrichi)
        PD37->>HSM: Demande signature (INV-5)
        HSM-->>PD37: Signature ECDSA
        PD37->>PD37: Horodatage certifié (INV-6)<br/>Persistance append-only (INV-4)
        PD37-->>PD17: OK (entrée signée persistée)
        PD17-->>SecurityEngine: Audit enregistré
        SecurityEngine-->>Client: Accès refusé
    end

    note over PD17: INV-7 : PD-17 ne prend<br/>aucune décision d’accès
    note over PD37: INV-1 : journal unique<br/>INV-2 : champs PD-37 intangibles

6. Cas d’erreur¶

Métadonnée invalide :
Critère : non-conformité au schéma JSON §5.0.
Comportement : l’événement est rejeté avant signature.
Échec de signature HSM :
L’événement n’est pas persisté.
L’accès est refusé.
Journal indisponible :
Mode strict par défaut : accès refusé.
Aucun mode dégradé n’est défini dans PD-17 (hors périmètre).
Échec de signature HSM : l’accès DOIT être bloqué et aucun accès effectif ne peut être accordé.
Journal indisponible : l’opération concernée DOIT être refusée par défaut.
Métadonnée invalide : l’événement est rejeté avant signature.

7. Critères d’acceptation (testables)¶

Tout accès (ALLOW ou DENY) génère exactement une entrée signée.
Aucune entrée PD-17 n’existe sans signature HSM valide.
Les champs PD-37 sont présents et inchangés.
Les accès refusés sont traçables au même niveau probatoire que les accès autorisés.
Le journal reste vérifiable indépendamment du système applicatif.

8. Scénarios de test (Given / When / Then)¶

Scénario 1 — Accès autorisé¶

Given un utilisateur authentifié valide
When il accède à un document autorisé
Then une entrée signée HSM avec résultat ALLOW existe dans le journal

Scénario 2 — Accès refusé¶

Given un utilisateur non autorisé
When il tente un accès interdit
Then une entrée signée HSM avec résultat DENY et code de refus existe

Scénario 3 — Tentative sans journal¶

Given une indisponibilité du journal
When une tentative d’accès est faite
Then l’accès est refusé

9. Hypothèses explicites¶

PD-37 fournit un mécanisme de vérification indépendante des signatures.
Le moteur d’autorisation est externe à PD-17.
Tous les événements PD-17 respectent strictement le schéma §5.0.
Les événements DENY sont signés au même niveau probatoire que les ALLOW.
Le journal PD-37 est déjà en production et validé juridiquement.
Les décisions d’accès sont déterminées par un composant externe à PD-17.
Les métadonnées ajoutées n’ont pas vocation à être exhaustives ni décisionnelles.

10. Points à clarifier¶

10.1 Taxonomie des codes de refus (OBLIGATOIRE)¶

Une taxonomie fermée DOIT être définie avant implémentation, par exemple : - AUTH_INVALID - AUTH_EXPIRED - ACL_DENY - OWNER_MISMATCH - QUOTA_EXCEEDED - SYSTEM_LOCKED

10.2 Politique de volumétrie¶

Acceptabilité du volume de signatures HSM générées par les DENY.

10.3 Exposition utilisateur¶

Filtrage strict requis (RLS + anonymisation IP si exposé).

10.4 Traçabilité des tentatives UPDATE/DELETE¶

À définir : journalisation explicite des violations de trigger PD-37.
Liste normative des codes de refus.
Durée de conservation spécifique des événements DENY (si distincte).
Exposition éventuelle de ces journaux à l’utilisateur final (lecture seule).

Décision structurante actée par cette spécification :

PD-17 est une extension normative de PD-37. Toute implémentation divergente est non conforme.