Journaux d'audit des opérations

(Section : Opérations et gestion)

1) Désignation et principes

Le journal d'audit est la première source de vérité sur qui, quoi, où, quand et pourquoi, avec la possibilité de prouver l'immuabilité et l'authenticité des enregistrements.

• Exhaustivité : les actions des personnes, des services et des partenaires externes sont couvertes.
• Immuabilité : Les entrées ne peuvent pas être réécrites/supprimées sans trace visible.
• Attribution : l'action est liée au sujet, au rôle, au contexte, aux artefacts.
• Reproductibilité : l'événement peut être reproduit dans le rapport/débat.
• Minimisation du PII : seulement nécessaire, avec masque et tokens.

2) Zones de couverture

Actions personnalisées : connexion/SSO/MFA, modification des rôles/limites, opérations PII.
Opérations privilégiées : JIT/PAM sessions, break-glass, admin-console.
Finances : listes de prix/taxes/publications FX, paiements/décaissements, escroqueries, prélèvements/retours.
Configurations/releases : ficheflags, migration de schémas, dépliage/retour, clés/certificats.
Intégrations : webhooks, signatures, reçus, clés d'identité.
Données : lecture/exportation PII, création/suppression d'artefacts, modifications de stratégies.

3) Architecture et immuabilité

Une passerelle Ingest avec authentification, quotas et validation de schéma.
Stockage WORM (buckets immuables/append-only) : version, Lock de rétention, Legal Hold.
Cryptoquitances : pour les événements critiques, une signature « receipt _ hash » et un DSE sont formés.
Chaînes Merkle : des tranches sont construites périodiquement (checkpoint), le hachage racine est publié.
Chain of custody : trace du mouvement des artefacts (qui a eu accès, quand, sur quelle base).
Time Sync : NTP/PTP, étiquettes 'event _ time' et 'ingest _ time', réglage 'skew'.

4) Schéma de l'événement (référence)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

En option : pour la finance - 'fx _ version/tax _ rule _ version/pricelist _ version' ; pour les webhooks : 'webhook _ id', 'idempotency _ key'.

5) Modèle de données et zones

Hot (opération) : 7-30 jours, demandes rapides/dashboards.
Warm (OLAP) : 6-24 mois, analyse/recherche.
Cold (archive/WORM) : jusqu'à 7-10 ans (par réglementation).
Classes de retraite : 'operational', 'financial', 'security', 'legal _ hold'.
Versioning de la stratégie : tous les événements sont marqués 'policy _ version' ; le changement de stratégie est un événement d'audit distinct.

6) Accès et vie privée

RBAC/ABAC/ReBAC : visibilité par rôle/tenant/région/cas (cas).
Masquage PII : Tokenization des identifiants, sortie primaire - uniquement via des jobs approuvés.
Interdiction de suppression directe : seulement 'tombstone' + Legal Hold ; « prétraitement » explicable avec un magazine séparé.
Audit de l'audit lui-même : qui a regardé/déchargé les logs - est également logé.

7) Qualité, consistance, prises

Contrats de données : schéma strict et validation lambda à l'entrée.
Idempotency & dedup : '(event_id, producteur)' ; «seen-cache» + KV.
Correction du temps : filigranes (watermarks) pour les événements tardifs.
Contrôle de l'exhaustivité : comparaison des compteurs sources et des métriques ingest.

8) Dashboards et demandes

Opérationnel : actions privilégiées, violations de SoD, levées de droits JIT, accès à PII.
Financier : publications FX/Tax/PriceList, différences de quote↔checkout, signatures clés.
Intégrations : reçus de webhooks, lag, retrai, prise.
Communiqués/configi : qui/quand/ce qui a allumé/rendu, lien avec les incidents.
Scripts de recherche : 'trace _ id', 'subject. id`, `target. id ', heure/région/tenant,' policy _ version '.
Exportation : déchargement par lots sur demande avec reçu (manifeste signé).

9) API et webhooks

« POST/audit/ingest » - réception des événements (authentification, limites, schéma).
« GET/audit/search » - filtres, pagination, limite de résultat.
« GET/audit/trace/{ trace _ id} » est un ensemble d'événements sur une chaîne.
'POST/audit/receipt/verify '- vérification du reçu/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10) SLO/métriques de qualité d'audit

Ingest Availability: ≥ 99. 95%.
Freshness (opération) : lag ≤ 30 s p95.
Completeness: ≥ 99. 5 % des sources ont envoyé des données par la fenêtre.
Correctness : divergence des montants de contrôle ≤ 0. 1%.
Tamper-evidence : 100 % des périodes sont certifiées par Merkle racines/signatures.
PYI Hygiene : 100 % des événements avec classe sensible - avec masque/jeton.

11) Pleybooks et incidents

Suspicion de remplacement des enregistrements : vérification immédiate des racines Merkle, rapprochement des reçus DSSE, isolement d'accès, Legal Hold.
Fuite d'IPI : recherche des événements/exportations touchés, vérification de l'accès, avis au DPO/régulateur selon le calendrier.
Violation SoD : bloc d'opération, retrait temporaire du rôle, enquête et ajustement de la politique.
Échec ingest : mise en tampon, mode de dégradation, repli après récupération, contrôle des doublons.

12) Extrait juridique et conformité

Retraite par juridiction : finances/impôts - 5-10 ans ; sécurité - par politique ; les données à caractère personnel sont la durée minimale requise.
Legal Hold : gel de l'enlèvement à la demande du régulateur.
Artefacts de rapport : index des périodes, hachages racines, liste des signataires, inventaire des sources.
Inapplicabilité : crypto-écriture, timestamping indépendant (TSA interne).

13) Spécificité iGaming/fintech

Paiements/paiements : suivi complet des autorisations, compensation, refus, chargeback ; comparaison avec les reçus bancaires.
RTP/limites : publications de profils, modifications observées par RTP et solutions de limites - avec signatures et version.
Affiliations : réception de webhooks, dedup de conversions, objections/escroqueries - uniquement sur les artefacts signés.
Listes de prix/taxes/FX : version de l'artefact dans chaque commande ; remboursements - avec reçus.

14) RACI

15) Risques et anti-modèles

Les logs modifiables sans trace → non-support juridique.
L'absence de synchronisation temporelle → des temporisations incohérentes.
Shadow-export sans reçus → fuites/litiges.
Les secrets dans les loges → des compromis.
Aucun lien avec les SLO/incidents → « cimetière de données » sans intérêt.

16) Chèque de mise en œuvre

• Identifier les zones de couverture et de policy_version.
• Développer ingest avec authentification, schémas et quotas.
• Inclure WORM, Merkle-tranches, DSSE signatures, TSA.
• Personnaliser les retraits par classe et Legal Hold.
• Introduire le RBAC/ABAC/ReBAC et la vérification de l'accès aux journaux.
• Construire des dashboards : privilèges, PII, finances, communiqués/configurations.
• Inclure les playbooks : tamper, fuites PII, défaillance ingest, violation SoD.
• Essayer le relais et le dedup sur le kit de test.
• Établir des exportations avec des reçus et un registre des demandes.
• Vérifier tous les trimestres les métriques de qualité (freshness/completeness/tamper).

17) FAQ

Puis-je tout stocker dans une base de données normale ?
Pour l'opération, oui, mais les journaux critiques doivent être dupliqués dans WORM/append-only avec des signatures et des sections Merkle.

Dois-je loger chaque lecture de données ?
Lecture des IPI/finances - obligatoire ; le reste, par politique et par coût.

Comment prouver l'immuabilité ?
Hachages racines, signatures DSE, TSA indépendante et procédures de vérification reproductibles.

Que faire du « droit de suppression » (RGPD) ?
Supprimer le primaire dans les systèmes de traitement ; dans les revues d'audit - stockez les jetons/hachages sans PII récupérable et conservez Legal Hold si nécessaire.

Résumé : Les journaux d'audit ne sont pas des « logs dans le S3 », mais un historique d'activités cryptographiquement prouvable avec une politique claire, un stockage immuable, un accès contrôlé et une préparation à la controverse/inspection réglementaire. Construisez ingest par contrat, signez les événements critiques, soutenez les tranches Merkle et les dashboards - et vous aurez une base solide pour la confiance, la sécurité et la conformité.