Stratégie de stockage des logs et des événements

1) Objectif et domaine d'action

Objectif : assurer le stockage légitime, sûr et économique des logs/événements, soutenir les enquêtes, les audits, les rapports AML/KYC et la résilience de la plateforme.
Couverture : tous les environnements (prod/stage/dev), applications et microservices, antifrod et paiements, CUS/sanctions, RG, infrastructure (K8s/cloud/SDN/WAF), partenaires/vendeurs (PSP, KYC, antifrod, analytique).

2) Classes de logs et composition minimale des champs

1. Sécurité (SecOps/Identity) : authentification, signaux ATO/antifrod, changements de rôles et de politiques, accès à PII.

Поля: `actor`, `subject`, `action`, `result`, `ip`, `device`, `geo`, `risk_score`, `trace_id`.

2. Transactions/paiements : dépôts/retraits, chargebacks, règles antifrod.

Поля: `tx_id`, `amount`, `currency`, `psp`, `status`, `rule_hits[]`, `evidence_ref`.
3. CUS/sanctions/RER : initiations, résultats, fournisseur/version des listes, décisions (vrai/faux positif).
4. Opérations/SRE : métriques SLO, sorties, auto, incidents, alertes.
5. Marketing/CRM (facultatif) : événements de consentement/résiliation, campagne (sans PII superflu).
6. Audit de l'accès aux données : lecture/exportation/suppression de jeux avec PII ; références aux cas DSAR/AML.

3) Durées et niveaux de stockage (Hot/Warm/Cold/WORM)

4) Synchronisation temporelle et tracabilité

Base de temps unique : NTP/Chrony, stocker 'ts _ utc' (UTC) + 'ts _ local' (pour les rapports).
Corrélation : dans chaque journal, inclure 'trace _ id '/' span _ id' et 'source _ service'.
Fuseaux horaires : rapports/exportations - avec une indication explicite de TZ.

5) Accès, cryptage et partage des responsabilités

Cryptage : at rest (KMS ; rotation des clés pendant au moins 90 jours pour les espaces secrets) et in transit (TLS 1. 2+).
RBAC/ABAC : accès au minimum ; rôles distincts pour la lecture des logs d'audit.
Break-glass : accès temporaire avec autorisation multifactorielle et auto-fermeture.
Segmentation : logs avec PII/finances - index/réservoirs séparés, clés séparées.
Logs d'accès : toutes les lectures/exportations sont enregistrées et revues.

6) Intimité et masquage

Il est strictement interdit de loger : mots de passe, jetons, PAN (complet), CVV/CVC, numéros de documents complets, données biométriques « brutes ».
Masquage par défaut : email → 'p @ domain. com`; Téléphone → '+ XXX123' ; IBAN/PAN → tokens/4 derniers chiffres.
Pseudonyme : remplacer 'user _ id' par un jeton persistant dans les logs analytiques/marketing.
Cookies/SDK : Loger uniquement les identifiants techniques avec le consentement (CMP) et sans sclérose avec PII, à moins qu'il n'y ait une base légale.
Compatibilité DSAR : Stocker une référence à la source du jeu et la possibilité d'extraire/supprimer sélectivement.

7) Qualité des données et formatage

Diagramme-comme-code : diagrammes JSON centralisés/protocoles d'événements, versioning.
Validations : not null/fourchettes/regex ; les événements rejetés sont dans une queue de quarantine avec une étiquette de cause.
Déduplication : par '(trace_id, ts, source)' ; niveaux d'idempotentialité pour les rétrogrades.
Enrichissement : strictement déterministe ; géo/device-attributs - indiquant la version des dictionnaires.

8) Architecture et niveaux de stockage

Hot : référentiels indexables/clusters de recherche (enquêtes opérationnelles, SIEM).
Warm : stockage d'objets avec accès/index de cold accéléré.
Cold : stockage objet/archivé (classe glacier/analogique), requêtes via batch.
WORM/Legal Hold : bacs/politiques immuables de rétention et de « rétention légale » avec l'impossibilité de supprimer/modifier avant l'expiration du délai.

9) Suppression, archivage et Legal Hold (SOP)

1. Le planificateur quotidien calcule les candidats à la date limite.
2. Vérification des incidents actifs/enquêtes/Legal Hold.
3. Archivage : migration vers Cold/WORM si nécessaire.
4. Suppression : nettoyage sécurisé + journal ('dataset', 'range', 'actor', 'hash _ before/after').
5. Rapport dans Compliance/Data à la fin du batch.

10) Intégration avec la conformité (GDPR/AML/PCI/ISO)

RGPD : minimisation, objectifs/fondations en RoPA ; Disponibilité DSAR ; Les avis de 72 heures reposent sur des logs d'audit.
AML : stockage des logs de contrôle des sanctions, liens STR/SAR ; Durée de 5 à 10 ans (par pays).
DSS PCI (le cas échéant) : interdiction des données d'authentification sensibles ; ségrégation des loges du périmètre de paiement.
ISO 27001/ISMS : la politique de logigation en tant que document obligatoire ; audits et tests annuels.

11) Vendeurs et sous-traitants

DPA/SLA : prescrire les durées de conservation, géographie, TOMs, format d'exportation, WORM/Legal Hold, temps de réaction à l'incident.
Vérification : questionnaires, logiques d'accès à l'IPI, test d'incident/notification.
Offbording : suppression/retour des logs, acte de fermeture, confirmation de la destruction des copies/backups.

12) Surveillance et alertes

KRIs : augmentation des échecs de validation> X %, laga ingestion> Y, échec ETL <99 %, tentatives d'accès hors fenêtre.
KPI : couverture par loging ≥ 95 % des services ; MTTD de panne de pipline ≤ 15 min ; proportion de demandes Hot terminées ≤ 2 secondes - ≥ 95 %.
SOAR : auto-tickets en cas de violation de la rétention/accès/masquage.

13) RACI

14) Exportations et rapports

Liste blanche des destinataires et des formats (CSV/Parquet/JSON) avec impersonnalisation par défaut.
Signature/hachage de chaque sauvegarde, journal de déchargement.
Modèles de rapports réglementaires : résumés des sanctions/REER, KYC, AML-alertam, accès PII, incidents.

15) Exigences de développement et d'exploitation

Loger de manière significative : actions/solutions clés, pas tout le trafic.
Normes de niveau : 'DEBUG' interdit dans prod ; 'INFO' pour les événements d'entreprise ; 'WARN/ERROR' pour les anomalies.
Redaction-middleware : une seule couche de masquage dans les gateways/SDK.
Environnements de test : données synthétiques ou pseudonymisation ; interdiction des copies des logs prod dans dev.
Communiqués : checklist loging/masquage dans l'ACR ; les drapeaux de fonction pour le logging étendu.

16) Chèques-feuilles

16. 1 Contrôle hebdomadaire

• Synchronisation du temps sans dérive
• Erreurs d'ingestion
• Pas de PII/secrets directs dans les samples
• Accès/rôles pertinents
• Succès de l'ETL ≥ 99 %

16. 2 Audit mensuel

• Vérification des retraits/suppressions
• Échantillon aléatoire d'exportations (signature/hash ok)
• Revues des vendeurs (logs d'accès, incidents)
• Mise à jour des schémas/manuels

16. 3 Avant de supprimer/archiver

• Pas de Legal Hold/incident
• Exportation d'artefacts liés (si nécessaire)
• Protocole de destruction établi

17) Incidents logiques (playbook rapide)

PII/secrets détectés dans les logs → activer immédiatement les règles de redaction, restreindre l'accès, lancer le nettoyage/rotation des clés, évaluer l'échelle (DPO/Legal), si nécessaire - notifications.
La panne de pipline des logs → le passage à la tampon, alert SRE, restart ingestion, post-mortem.

18) Feuille de route pour la mise en œuvre

Semaines 1-2 : inventaire des sources, harmonisation des délais, matrice de base, schéma-code.
Semaines 3 à 4 : introduction du masquage/révision, séparation des index avec PII, NTP/trace-ID, WORM pour les ensembles critiques.
Mois 2 : automatisation de la suppression/archivage, KRIs/KPIs et alertes, playbooks SOAR.
Mois 3 + : audit des fournisseurs, optimisation des coûts (tiering), revalorisation trimestrielle des délais et des exigences des juridictions.

TL; DR

Politique unique des logs = Matrice de temps claire + masquage et cryptage + RBAC et audit d'accès + WORM/Legal Hold + qualité et synchronisation temporelle. Cela réduit les risques (GDPR/AML/PCI), réduit le coût du stockage et accélère les enquêtes.