Outils d'audit et de loging
1) Pourquoi est-ce nécessaire
Objectifs :- Traçabilité des actions (qui/quoi/quand/d'où/pourquoi).
- Enquêtes rapides sur les incidents et les forensés.
- Répondre aux exigences des régulateurs et des clients.
- Gestion des risques et réduction du TMTI en cas d'incident.
- Prise en charge des modèles de risque, antifrod, complication (KYC/AML/RTBF/Legal Hold).
- Exhaustivité de la couverture des sources.
- L'immuabilité et l'intégrité des documents.
- Schémas d'événements normalisés.
- Disponibilité de recherche et corrélation.
- Minimisation des données personnelles et contrôle de la vie privée.
2) Paysage d'outils
2. 1 Gestion des logs et indexation
Сбор/агенты: Fluent Bit/Fluentd, Vector, Logstash, Filebeat/Winlogbeat, OpenTelemetry Collector.
Stockage et recherche : Elasticsearch/OpenSearch, Loki, ClickHouse, Splunk, Datadog Logs.
Streaming/pneus : Kafka/Redpanda, NATS, Pulsar - pour le tampon et fan-out.
Parsing et normalisation : Grok/regex, OTel processeurs, Logstash pipelines.
2. 2 SIEM/Detect & Respond
SIEM: Splunk Enterprise Security, Microsoft Sentinel, Elastic Security, QRadar.
UEBA/analyse comportementale : modules intégrés dans SIEM, détecteurs ML.
SOAR/orchestration : Cortex/XSOAR, Tines, Shuffle - automatisation des playbooks.
2. 3 Audit et invariabilité
Аудит подсистем: Linux auditd/ausearch, Windows Event Logs, DB-аудит (pgAudit, MySQL audit), Kubernetes Audit Logs, CloudTrail/CloudWatch/Azure Monitor/GCP Cloud Logging.
Stockage immuable : WORM-buckets (Object Lock), S3 Glacier Vault Lock, write-once volumes, journal avec crypto-écriture/chaîne de hachage.
TSA/horodatages : ancrage NTP/PTP, ancrage périodique des hachages en temps de confiance externe.
2. 4 Observabilité et traçabilité
Métriques/Tracks : Prometheus + Tempo/Jaeger/OTel, corelation des logs ↔ des tracés par trace_id/span_id.
Dashboards et alertes : Grafana/Kibana/Datadog.
3) Sources d'événements (couverture)
Infrastructure : OS (syslog, auditd), conteneurs (Docker), orchestration (Kubernetes Events + Audit), périphériques réseau, WAF/CDN, VPN, IAM.
Applications et API : passerelle API, mash-service, serveurs Web, backends, files d'attente, planificateurs, webhooks.
Bases de données et référentiels : requêtes, DDL/DML, accès aux secrets/clés, accès au référentiel objet.
Intégration de paiement : PSP/Equairing, chargeback-ivens, 3DS.
Opérations et processus : entrées dans les consoles/CI/CD, panneaux admin, modifications des configurations/fichflages, versions.
Sécurité : IDS/IPS, EDR/AV, scanners de vulnérabilité, DLP.
Événements personnalisés : authentification, tentatives de connexion, changement de statut KYC, dépôts/retraits, paris/jeux (avec anonymisation si nécessaire).
4) Schémas de données et normes
Modèle d'événement unique : 'timestamp', 'event. category`, `event. action`, `user. id`, `subject. id`, `source. ip`, `http. request_id`, `trace. id`, `service. name`, `environment`, `severity`, `outcome`, `labels.`.
Стандарты схем: ECS (Elastic Common Schema), OCSF (Open Cybersecurity Schema Framework), OpenTelemetry Logs.
Clés de corrélation : 'trace _ id', 'session _ id', 'request _ id', 'device _ id', 'k8s. pod_uid`.
Qualité : champs obligatoires, validation, déduplication, échantillonnage pour les sources « bruyantes ».
5) Référence architecturale
1. Collecte sur les nodes/agents →
2. Traitement préalable (parsing, édition PII, normalisation) →
3. Pneu (Kafka) avec retenti ≥ 3-7 jours →
4. Forks de flux :- Stockage en ligne (recherche/corrélation, stockage à chaud 7-30 jours).
- Archives immuables (WORM/Glacier 1-7 ans pour l'audit).
- SIEM (détection et incidents).
- 5. Dashboards/recherche (opérations, sécurité, conformité).
- 6. SOAR pour l'automatisation des réactions.
- Hot : SSD/indexation, recherche rapide (réponse rapide).
- Warm : compression/accès moins fréquent.
- Cold/Archive (WORM) : stockage à long terme bon marché, mais immuable.
6) Immuable, intégrité, confiance
WORM/objet lock : verrouillage de la suppression et de la modification pendant la durée de la stratégie.
Crypto, et une chaîne de hachages, sur les mamelons/cuvettes des loges.
Hash-ankering : publication périodique de hachages dans un registre externe ou une heure de confiance.
Synchronisation temporelle : NTP/PTP, surveillance de la dérive ; l'enregistrement 'clock. source`.
Contrôle des changements : quatre yeux/double contrôle pour les politiques de rétention/Legal Hold.
7) Vie privée et conformité
Minimisation PII : ne stocker que les champs nécessaires, modifier/masquer dans ingest.
Alias : 'user. pseudo_id', le stockage du mapping est séparé et limité.
RGPD/DSAR/RTBF : classification des sources, suppression/dissimulation logique gérée dans les répliques, exceptions aux obligations légales de stockage.
Legal Hold : marques « freeze », suspension de la suppression dans les archives ; journal d'action autour de Hold.
Mapping sur les normes : ISO 27001 A.8/12/15, SOC 2 CC7, PCI DSS Req. 10, régulation locale des marchés.
8) Opérations et processus
8. 1 Playbooks/Runbooks
Perte de source : comment identifier (heartbeats), comment récupérer (replay du pneu), comment compenser les passes.
Augmentation des retards : vérification des files d'attente, sharding, index, backpressure.
Enquête sur l'événement X : modèle KQL/ES-query + lien avec le contexte de la piste.
Legal Hold : Qui pose, comment filmer, comment documenter.
8. 2 RACI (en résumé)
R (Responsable) : Équipe d'observation pour la collecte/livraison ; SecOps pour les règles de détection.
A (Comptable) : CISO/Head of Ops pour les politiques et le budget.
C (Consulté) : DPO/Juridique pour la vie privée ; Architecture pour les circuits.
I (Informed) : Sappport/Produit/Gestion des risques.
9) Métriques de qualité (SLO/KPI)
Coverage :% des sources critiques sont connectées (cible ≥ 99 %).
Ingest lag : p95 délai de livraison (<30 secondes).
Indexing success : proportion d'événements sans erreur de parsing (> 99. 9%).
Recherche latitude : p95 <2 secondes par requête type 24h de la fenêtre.
Drop rate : perte d'événements <0. 01%.
Alert fidelity : Precision/Recall selon les règles, proportion de faux positifs.
Cost per GB : coût de stockage/indice par période.
10) Politiques de conservation (exemple)
Les politiques sont précisées par le Legal/DPO et les réglementations locales.
11) Détection et alertes (squelette)
Règles (rule-as-code) :- Authentification suspecte (déplacement impossible, TOR, erreurs fréquentes).
- Escalade des privilèges/rôles.
- Modifications des configurations/secrets en dehors du calendrier de sortie.
- Modèles de transaction anormaux (signaux AML/antifrod).
- Déchargement massif de données (déclencheurs DLP).
- Tolérance aux pannes : Flot 5xx, dégradation de latency, restarts multiples pod's.
- Enrichissement de la réputation géo/IP, lien vers les versions/fichflags, lien vers les pistes.
12) Sécurité d'accès aux logs
RBAC et ségrégation des responsabilités : rôles distincts pour les lecteurs/analystes/admins.
Accès juste à temps : jetons temporels, audit de toutes les lectures d'index « sensibles ».
Cryptage : in-transit (TLS), at-rest (KMS/CMK), isolation des clés.
Secrets et clés : rotation, limitation de l'exportation d'événements avec PII.
13) Feuille de route pour la mise en œuvre
MVP (4-6 semaines) :1. Catalogue source + schéma minimum (ECS/OCSF).
2. Agent sur les nodes + collecteur OTel ; parsing centralisé.
3. Stockage Hot (OpenSearch/Elasticsearch/Loki) + dashboards.
4. Alerts de base (authentification, 5xx, modifications de configues).
5. Archive dans Object Storage avec objet lock (WORM).
Phase 2 :- Kafka comme un pneu, des crampons, une file d'attente rétractable.
- SIEM + premières règles de corrélation, SOAR-playbooks.
- Cryptopompes, ankering de hachages.
- Politiques de Legal Hold, DSAR/RTBF procédure.
- Détection UEBA/ML.
- Catalogue d'événements, lineage.
- Optimisation des coûts : échantillonnage des loges « bruyantes », tiering.
14) Erreurs fréquentes et comment les éviter
Bruit de journal sans schéma : → entrer les champs obligatoires et l'échantillonnage.
Pas de traces : → d'introduire des trace_id dans les services cor et proxy.
Un seul « monolithe » de logs : → diviser par domaines et niveaux de criticité.
Absence d'immuabilité : → activer WORM/Object Lock et la signature.
Secrets dans les logs : filtres/éditeurs →, scanners de tokens, revues.
15) Chèque de démarrage
- Registre des sources avec priorité de criticité.
- Régime unique et validateurs (CI pour parser).
- Stratégie des agences (daemonset en k8s, Beats/OTel).
- Pneu et rétention.
- Stockage chaud/froid/archivé + WORM.
- RBAC, cryptage, journal d'accès.
- Alerts de base et playbooks SOAR.
- Dashboards pour Ops/Sec/Compliance.
- DSAR/RTBF/Legal Hold.
- KPI/SLO + budget de stockage.
16) Exemples d'événements (simplifiés)
json
{
"timestamp": "2025-10-31T19:20:11.432Z",
"event": {"category":"authentication","action":"login","outcome":"failure"},
"user": {"id":"u_12345","pseudo_id":"p_abcd"},
"source": {"ip":"203.0.113.42"},
"http": {"request_id":"req-7f91"},
"trace": {"id":"2fe1…"},
"service": {"name":"auth-api","environment":"prod"},
"labels": {"geo":"EE","risk_score":72},
"severity":"warning"
}
17) Glossaire (résumé)
La piste d'audit est une séquence d'enregistrements immuables qui enregistre les actions du sujet.
WORM est un mode de stockage « enregistré-une fois, lu-multirase ».
SOAR - Automatisation de la réponse aux incidents de pleybooks.
UEBA - Analyse du comportement des utilisateurs et des entités.
L'OCSF/ECS/OTel est la norme des circuits de logs et de télémétrie.
18) Résultat
Le système d'audit et de logage n'est pas une « pile de logs », mais un programme géré avec un schéma de données clair, une archive immuable, une corrélation et des pleybooks de réaction. Le respect des principes énoncés dans cet article améliore l'observation, accélère les enquêtes et ferme les exigences clés des Opérations et Complaens.