Pistes d'audit et traces d'accès

1) But et domaine d'application

Objectif : garantir la probabilité des actions des utilisateurs/services, la transparence des enquêtes, le respect des exigences des régulateurs et des normes internes (GDPR/AML, contrats avec les fournisseurs PSP/KYC, ISO/PCI si applicable).
Couverture : tous les systèmes prod, services de plateforme (compte, paiements, antifrod, CUS/sanctions, RG), panneaux admin, passerelles API, DWH/BI, infrastructure (K8s/cloud), intégration avec les fournisseurs.

2) Que loger (classes d'événements)

1. Identification et accès : login/logout, MFA, changement de mot de passe/clé, SSO, accès « break-glass ».
2. Actions administratives : modifications des rôles/droits, configurations, règles antifrod/sanctions, drapeaux ficha.
3. Opérations PII/finddays : lecture/exportation/suppression, déchargement, accès KYC, affichage des profils VIP.
4. Transactions et argent : cash out/dépôts, annulations, retours, solutions de chargback.
5. Conformité/AML/KYC : résultats du dépistage (sanctions/PEP/Adverse Media), décisions (TP/FP), EDD/STR/SAR.
6. Incidents et sécurité : escalade, modifications des règles WAF/IDS, isolation des services, rotation des secrets.
7. Intégrations/fournisseurs : appels API, erreurs, temporisations, exportations, confirmations de suppression/retour de données.

3) Champs d'événement obligatoires (minimum)

`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`

'Actor _ type '(user/service/vendor),' actor _ id ',' actor _ org '(si B2B)

`subject_type` (account/tx/document/dataset), `subject_id`

`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)

`result` (success/deny/error) и `reason`/`error_code`

'ip', 'device _ fingerprint', 'geo' (pays/région), 'auth _ context' (MFA/SSO)

'fields _ accessed '/' scope '(lorsque vous travaillez avec PII/findans) - avec masquage

"purpose "/" ticket _ id' (base : DSAR, incident, requête du régulateur, tâche opérationnelle)

4) Invariabilité et probabilité

Stockage WORM pour la copie « dorée » (buckets immuables/politiques de rétention).
Cryptopsy/chaîne de hachage : signature périodique de paquets d'événements et/ou construction d'une chaîne de hachage (hash chaining) pour identifier les modifications.
Journal des changements de schémas/règles : versionnons les schémas et les politiques de logage ; toute modification est effectuée par l'ACR.
Stockage à deux circuits : index en ligne (recherche) + archive/immutabilité.

5) Synchronisation temporelle et trace

Un seul NTP/Chrony dans tous les environnements ; dans les loges - « ts _ utc » comme source de vérité.
Chaque journal est 'trace _ id '/' span _ id' pour la trace de bout en bout des requêtes (corrélation entre les services, les fournisseurs et le front).

6) Intimité et secrets

Interdit : mots de passe, jetons complets PAN/CSC, numéros de documents complets, biométrie « brute ».
Masquage par défaut : e-mail/téléphone/IBAN/PAN → tokens/affichage partiel.
Pseudonyme : 'user _ id' → un jeton stable dans l'analyse ; la liaison à l'ID réel est uniquement dans le contour protégé.
Compatibilité DSAR : possibilité d'extraire sélectivement les loges par sujet sans révéler les IPI étrangers.

7) Durées et niveaux de conservation (rétentions)

8) Accès et contrôle (RBAC/ABAC)

Les rôles de lecture des logs d'audit sont séparés des rôles d'administration.
Accès MFA et Just-in-Time (break-glass) avec auto-enregistrement/logging des causes.
Politique du « minimum » : accès aux champs PII/findddans uniquement par nécessité et avec fixation de « purpose ».
Exportation/déchargement : listes blanches de destinataires et de formats ; signature/hash obligatoire, journal de déchargement.

9) Intégration avec SIEM/SOAR/ETL

Le flux d'événements d'audit entre dans le SIEM pour les corrélations (e. g., masse 'READ _ PII' + entrée à partir d'un nouvel appareil).
SOAR-playbooks : auto-tickets en cas de violation des politiques (non « purpose », volume anormal, accès hors fenêtre).
ETL/DWH : vitrines 'audit _ access', 'pii _ exports', 'admin _ changes' avec contrôle qualité et versibilité des schémas.

10) Qualité des données et validateurs

Schémas en tant que code (JSON/Protobuf/Avro) : champs obligatoires, types, dictionnaires ; Validateurs CI.
Le rejet et la queue de quarantine pour les événements avec des erreurs de schéma ; les métriques du mariage.
Déduplication/idempotence par '(event_id, trace_id, ts)' ; contrôle de la réémission.

11) RACI

12) SOP : Enquête sur l'accès aux données

1. Déclencheur : alert SIEM (anormal « READ _ PII »/export), plainte, signal du vendeur.
2. Collecte d'artefacts : déchargement d'événements par 'actor _ id '/' subject _ id'/' trace _ id', journal 'purpose', logs associés (WAF/IdP).
3. Vérification de la légalité : présence d'une base (DSAR/incident/tâche de service), d'une négociation, de fenêtres d'accès.
4. Analyse d'impact : portée/catégories d'IPI, compétences, risques pour les entités.
5. Solution : incident-bridge (avec High/Critical), containment (retrait des accès, rotation des clés).
6. Rapport et APA : causes, politiques violées, mesures (déguisement, formation, changements au CCCR), échéances.

13) SOP : Exportation de données (régulateur/partenaire/DSAR)

1. Demande → vérification de la base et de l'identité (pour DSAR) → création d'une demande dans DWH.
2. Impersonnalisation/minimisation par défaut ; l'inclusion des IPI uniquement sur une base juridique.
3. Génération de déchargement (CSV/JSON/Parquet) → signature/hash → entrée dans le journal de déchargement (qui/quand/quoi/à/base).
4. Transmission via un canal approuvé (sFTP/lien sécurisé) ; la durée de conservation de la copie est définie par la politique.
5. Post-contrôle : Accusé de réception, suppression des fichiers temporaires.

14) Métriques et KRIs/KPIs

Coverage : proportion de systèmes critiques qui envoient des événements d'audit ≥ 95 %.
Erreurs DQ : événements rejetés par le validateur, ≤ 0. 5 % du débit.
Perte de flux MTTD : ≤ 15 min (alert en silence).
Accès anormaux sans 'purpose' : = 0 (KRI).

Temps de réponse à l'enquête : médiane ≤ 4 h, P95 ≤ 24 h

Exportations signées/hachages : 100 %.
Respect des règles : Effacement/archives dans les délais ≥ 99 %.

15) Exigences pour les fournisseurs et les sous-traitants

DPA/SLA : description des logs d'audit (schémas, échéances, géographie, format d'exportation), WORM/immutabilité, notification d'incident SLA.
Accès du fournisseur : comptes de service nommés, journaux de leurs actions, possibilité d'audit sélectif.
Offbording : révocation de clés, exportation/suppression de journaux, acte de fermeture, confirmation de la destruction des backups.

16) Sécurité et protection contre la manipulation

Répartition des rôles : admin source ≠ admin stockage ≠ auditeur.
Signature des agents/collecteurs, mTLS entre les composants.
Contrôles anti-tampon : comparaison des hachages, contrôles d'intégrité réguliers, alertes sur les écarts.
Géo-réplication des copies WORM et tests de restauration réguliers.

17) Erreurs types et anti-modèles

Loger les valeurs sensibles (PAN/secrets) → activer immédiatement redaction-middleware.
L'absence de 'purpos'/' ticket _ id' lors de l'accès à PII.
Téléchargements locaux sur le bureau et envoi par e-mail.
L'absence de schéma unique et de validation → les champs « muets », l'impossibilité de corrélation.
Un seul super compte sans lien avec une personne ou un service.

18) Chèques-feuilles

18. 1 Lancer/revoter la politique

• Schémas et dictionnaires approuvés ; champs obligatoires inclus
• Masquage et interdictions de secrets inclus
• Configuré NTP, 'trace _ id'partout
• Couches Hot/Warm/Cold/WORM créées
• RBAC/ABAC et break-glass décoré
• SIEM/SOAR intégrés, alertes testées

18. 2 Audit mensuel

• Échantillon d'exportations : signatures/journaux corrects
• Vérification des retraits/suppressions/Legal Hold
• Les métriques DQ sont normales, quarantine analyse
• Les loges vendoriennes sont disponibles/complètes

19) Feuille de route pour la mise en œuvre

Semaines 1-2 : inventaire des systèmes, alignement des schémas et des champs obligatoires, réglage de l'heure et de la trace.
Semaines 3-4 : activation du masquage, couche WORM, intégration avec SIEM/SOAR, lancement des journaux d'exportation.
Mois 2 : automatisation des validateurs/alerts, pleybooks d'investigation, formation des équipes.
Mois 3 + : audits réguliers, stress tests d'intégrité, optimisation des coûts (tiering), révision des fournisseurs/contrats.

TL; DR

Pistes d'audit fortes = événements complets et structurés + immutabilité (WORM) et signatures + masquage PII + accès dur et journal de déchargement + intégration avec SIEM/SOAR. Cela accélère les enquêtes, réduit les risques et rend la conformité prouvable.