Tenue de journaux et de protocoles
1) Pourquoi les journaux et les protocoles sont-ils nécessaires
Les revues sont la « boîte noire » de l'organisation : elles fournissent des preuves (evidence) pour les audits et les enquêtes, réduisent les risques opérationnels et réglementaires, permettent de reconstituer l'évolution des événements et de confirmer l'exécution des politiques (accès, rétention, cryptage, KYC/AML, PCI, etc.).
Objectifs :- Suivi des actions (qui/quoi/quand/où/pourquoi/quoi).
- Détection et dissuasion des incidents (détectives et contrôles préventifs).
- Base de données probantes pour les régulateurs/vérificateurs (immutabilité).
- Analyse des performances et de la conformité SLA/SLO.
2) Taxonomie des loges (couverture minimale)
Accès et identités (IAM/IGA) : authentification, changement de rôle, SoD, accès JIT.
Infrastructure/cloud/IaC : appels API, dérive de configuration, événements KMS/HSM.
Applications/activités : transactions, opérations PI/Finances, cycle de vie des demandes (DSAR).
Sécurité : IDS/IPS, EDR, DLP/EDRM, WAF, vulnérabilités/patchs, antivirus.
Réseau : firewall, VPN/Zero Trust, proxy, DNS.
CI/CD/DevSecOps : assemblages, déplay, SAST/DAST/SCA, scan secret.
Données/analyses : lineage, accès aux vitrines, masquage/anonymisation.
Opérations : ITSM/tickets, incidents, gestion du changement, tests DR/BCP.
Vendeurs/3rd-party : webhooks, fédération SSO, événements SLA.
3) Exigences réglementaires (repères)
GDPR/ISO 27701 : minimisation/masquage PI, rétention graphique, Legal Hold, trace DSAR.
SOC 2/ISO 27001 : audits-trails, contrôle de l'accès aux logs, preuves de l'exécution des contrôles.
PCI DSS : logigation des accès aux environnements/données des cartes, intégrité des journaux, examen quotidien.
AML/KYC : traçabilité des contrôles, dépistage des sanctions/RER, protocoles STR/SAR.
4) Architecture de logage de référence
1. Producteurs : applications, cloud, réseau, agents hôtes.
2. Bus/collecteurs : réception avec back-pressure, retry, TLS mTLS, déduplication.
3. Normalisation : format unique (JSON/OTel), enrichissement (tenant, user, geo, severity).
- Chaud (recherche/SIEM) : 7-30 jours, accès rapide.
- Froid (objet) : mois/années, stockage bon marché.
- Archive-evidence (WORM/Object Lock) : invariabilité, reçus de hachage.
- 5. Intégrité et signature : chaînes de hachages/mercley-tree/timing.
- 6. Accès et sécurité : RBAC/ABAC, segmentation par pays, accès basé sur des cas.
- 7. Analytique et alertes : SIEM/SOAR, correlation ID, playbooks.
- 8. Répertoires et schémas : registre des types d'événements, versioning, tests de schémas.
5) Politiques-comme-code (exemples YAML)
Retentia et Legal Hold
yaml id: LOG-RET-001 title: "Access logs retention"
scope: ["iam. ","app. access"]
retention:
hot_days: 30 cold_days: 365 worm_years: 3 legal_hold: true # when Legal Hold is active, block privacy removal:
pii_mask: ["email","phone","ip"]
review: "annual"Intégrité et signature
yaml id: LOG-INT-001 title: "Signature and commercial fixation"
hashing: "SHA-256"
anchor:
cadence: "hourly"
store: "s3://evidence/anchors"
verification:
schedule: "daily"
alert_on_failure: true6) Exigences de qualité des magazines
Structuration : seulement JSON/OTel, sans texte « brut ».
Synchronisation temporelle : NTP/PTP, contrôle drift ; l'entrée 'timestamp', 'received _ at'.
Correlation IDs : 'trace _ id', 'span _ id', 'request _ id', 'user _ id' (alias).
Sémantique des champs : dictionnaire de données (data dictionary) et contrat de schéma avec les tests.
Localisation/langue : les champs sont des clés anglaises, les valeurs sont unifiées (enum).
Volume et politique du drop : interdiction du drop incontrôlé ; files d'attente/quotas/échantillonnage par risque.
Données sensibles : masquage/tokenisation ; interdiction de garder les secrets/cartes dans leur intégralité.
7) Confidentialité et minimisation
Hygiène PII : Logons les hashs/tokens au lieu des valeurs ; masque strict pour email/téléphone/IP.
Contexte : Ne pas pisPayer avec des données personnelles sans fondement.
Juridictions : stockage et accès par pays (data residency), traçabilité des copies.
DSAR : étiquettes de recherche et d'exportation par case ; possibilité d'imprimer des rapports avec dépersonnalisation.
8) Invariabilité et preuves (immutabilité)
WORM/Object Lock : Interdiction de supprimer/écraser dans la période.
Crypto : signature des trampolines ; racines Merkli avec ankering quotidien.
Chaîne de stockage (chain of custody) : journal d'accès, reçus de hachage, quites dans les rapports.
Vérification : contrôles d'intégrité périodiques et alertes de dissynchronisation.
9) Contrôle de l'accès aux logs
RBAC/ABAC : rôles « lecture/recherche uniquement » vs « export/sharing ».
Case-based access : accès aux logs sensibles - uniquement dans le cadre d'une enquête/ticket.
Secrets/clés : KMS/HSM ; rotation, split-knowledge, dual-control.
Audit d'accès : journal séparé « qui a lu quels logs » + alertes sur les anomalies.
10) Métriques et SLO loging
Ingestion Lag : le 95-ème centile du retard de l'accueil (le but ≤ 60 fouettait).
Taux de chute : proportion d'événements perdus (objectif 0 ; alert> 0. 001%).
Schema Conformité :% des événements ayant fait l'objet d'une validation de schéma (≥ 99. 5%).
Coverage :% des systèmes sous logigation centralisée (≥ 98 % des systèmes critiques).
Integrity Pass : vérification réussie des chaînes de hachage (100 %).
Examen d'accès : promotion mensuelle des droits, retard - 0.
Taux de Leak PII : PI « purs » détectés dans les logs (cible 0 critique).
11) Dashboards (recrutement minimum)
Ingestion & Lag : volume/vitesse, lag, drop, sources « chaudes ».
Integrity & WORM : état de l'ancrage, de la vérification, de l'objet Lock.
Événements de sécurité : corrélations critiques, carte MITRE.
Access to Logs : qui et ce qu'il a lu/exporté ; anomalies.
Compliance View : Retence/Legal Hold Status, rapports d'audit, exportations DSAR.
Schema Health : erreurs de parsing/version des schémas, proportion d'agents obsolètes.
12) SOP (procédures standard)
SOP-1 : Connexion de la source de logs
1. Enregistrement de la source et de la criticité → 2) sélection du circuit/OTel → 3) TLS/mTLS, tokens →
2. dry-run en stajing (validation des schémas, masques PII) → 5) connexion en prod →
3. ajout aux catalogues/dashboards → 7) vérification de la rétraction/WORM.
SOP-2 : Réponse à l'incident (logs comme evidence)
Detect → Triage → Collecte de logs (case-scope) → Gel (Legal Hold) →
Hesh Fixing and Ankering → Analytics/Timline → Rapport et CAPA → Sortie des leçons.
SOP-3 : Requête/audit reg
1. Ouvrir la case et les filtres par ID de requête → 2) exporter au format requis →
2. vérification Legal/Compliance → 4) hachage Résumé → 5) Envoi et journalisation.
SOP-4 : Révision de l'accès aux logs
Attestation mensuelle des propriétaires ; Les droits des orphelins ; rapport sur la SoD.
13) Formats et exemples
Exemple d'événement d'accès (JSON)
json
{
"ts": "2025-10-31T13:45:12. 345Z",
"env": "prod",
"system": "iam",
"event": "role_grant",
"actor": {"type": "user", "id": "u_9f1...", "tenant": "eu-1"},
"subject": {"type": "user", "id": "u_1ab..."},
"role": "finance_approver",
"reason": "ticket-OPS-1422",
"ip": "0. 0. 0. 0",
"trace_id": "2a4d...",
"pii": {"email": "hash:sha256:..."},
"sign": {"batch_id":"b_20251031_13","merkle_leaf":"..."}
}Règle de détection (pseudo-Rego)
rego deny_access_if_sod_conflict {
input. event == "role_grant"
input. role == "finance_approver"
has_role(input. subject. id, "vendor_onboarder")
}14) Rôles et RACI
15) Gestion des fournisseurs et de la chaîne d'approvisionnement
Dans les contrats : droit d'audit des logs, formats, SLA de stockage et d'accès, WORM/immutabilité.
Sous-processeurs : registre des sources et rétention « de bout en bout ».
Export/Offboard : confirmation de destruction et rapport de hachage résumé.
16) Anti-modèles
Logs en « texte libre », sans schémas et corrélation.
Le stockage sans WORM et la fixation de hachage sont controversés lors de l'audit.
Données sensibles dans les logs « tels quels ».
Pas de synchronisation temporelle et de trace_id normale.
Drop d'événements en pics de charge ; absence de back-pression.
Accès universel aux logs sans contrôle de cas.
Les droits « éternels » de lecture des loges, sans ré-attestation.
17) Chèques-feuilles
Démarrer la fonction Logging
- La taxonomie des sources et la criticité sont déterminées.
- Les schémas et politiques de rétractation/Legal Hold sont déclarés (as-code).
- TLS/mTLS, tokens, agents avec mise à jour automatique.
- Masques PII/tokens testés.
- WORM/Object Lock et l'ancrage sont inclus.
- Dashboards/alertes/métriques sont en cours.
- La révision d'accès et le SoD sont configurés.
Avant l'audit/requête reg
- Assemblé « pack d'audit » : schémas, politiques, rapports d'intégrité, échantillons.
- Vérification de l'intégrité et des journaux d'accès pour la période.
- Statuts DSAR/Legal Hold confirmés.
- Un résumé hash des téléchargements et des confirmations d'envoi a été généré.
18) Modèle de maturité (M0-M4)
M0 Manuel : logs disparates, pas de schémas et de retouche.
M1 Collecte centralisée : recherche de base, taxonomie partielle.
M2 Contrôlable : schémas et politiques-comme-code, dashboards, retentition/WORM.
M3 Intégré : OTel-trace, SOAR, ankering/merkli, case-based access.
M4 Assured : « audit-ready par bouton », détections prédictives, contrôle automatique de l'intégrité et reçus juridiquement significatifs.
19) Articles wiki liés
Surveillance continue de la conformité (CCM)
KPI et métriques de conformité
Legal Hold et le gel des données
Cycle de vie des politiques et procédures
Communication des solutions de conformité
Gestion des changements dans la politique de conformité
Diligence raisonnable et risques d'externalisation
Résultat
Une fonction de logging forte n'est pas un « entrepôt de messages », mais un système géré : événements structurés, schémas et retences rigoureux, immuabilité et signature, confidentialité par défaut, contrôle d'accès rigoureux et réplication en preuve. Un tel système rend les enquêtes rapides, les audits prévisibles et les risques gérables.