Chapitre 15.1 — Logger la sécurité (sans fuite)

⏱️ TL;DR — La détection commence par de bons logs. On journalise les événements de sécurité utiles : connexions (réussies et échouées), accès refusés (403), changements sensibles (mot de passe, email, rôle, MFA), actions d’admin, dépassements de rate limit, entrées rejetées. Chaque entrée doit dire qui, quoi, quand, d’où (userId, action, horodatage, IP) — mais jamais de secrets ni de PII sensibles (rappel Partie 13 : pas de mot de passe, token, objet complet). On loggue des identifiants, pas des contenus. Les logs doivent être structurés (pour être requêtables), horodatés de façon fiable, protégés (accès restreint, intègres) et conservés assez longtemps pour enquêter. Un log qui fuite est une faille ; un log absent est un angle mort.

🎯 Objectifs

• Identifier les événements de sécurité à journaliser.
• Structurer une entrée de log utile (qui/quoi/quand/d’où) sans secrets ni PII.
• Protéger les logs (accès, intégrité, conservation).
• Éviter les deux extrêmes : trop peu (angle mort) et trop / fuite (Partie 13).

Pourquoi logger : voir pour détecter

Sans journalisation, une attaque est invisible : le bruteforce sur ton login, l’énumération d’ids (IDOR tenté), l’accès à une ressource interdite, l’exfiltration — rien ne laisse de trace exploitable. Le Top 10 OWASP classe les défaillances de journalisation et de supervision parmi les risques majeurs, précisément parce qu’elles retardent la détection (souvent des mois) et privent d’éléments pour enquêter après coup. Les logs sont la matière première de la détection (chapitre 15.2) et de l’investigation (chapitre 15.3).

Quels événements journaliser

On journalise les événements qui ont une valeur de sécurité — ceux qui, relus, permettent de repérer une attaque ou de reconstituer ce qui s’est passé :

L’idée : pouvoir répondre plus tard à « qui a fait quoi, quand, d’où ? » sur les actions qui comptent. Les échecs sont aussi importants que les succès : une salve d’échecs de login ou de 403 est un signal d’attaque.

Structurer une entrée utile

Une bonne entrée de log est structurée (JSON de préférence — requêtable par un outil) et contient les champs qui permettent l’analyse :

{
  "timestamp": "2026-07-16T10:42:03Z",
  "event": "login_failed",
  "userId": "u_123",            // ou l'email MASQUE si pas d'userId
  "ip": "203.0.113.42",
  "userAgent": "...",
  "reason": "bad_password",
  "requestId": "req_abc"        // pour correler les logs d'une meme requete
}

• Horodatage fiable (UTC), type d’événement normalisé, acteur (userId), source (IP), contexte (requestId pour corréler).
• Structuré : un format cohérent permet de requêter (« tous les login_failed de cette IP sur 10 min »), condition de la détection.
• Corrélable : un requestId/traceId relie les logs d’une même requête à travers les services.

Ne pas fuiter : logs sûrs (rappel Partie 13)

Point critique : un log de sécurité qui fuite des secrets ou de la PII est lui-même une faille (Partie 13). Les logs sont exportés, conservés longtemps, consultés largement, rarement chiffrés — moins protégés que la base.

⚠️ Piège — L’ironie du logging de sécurité : en voulant « tout tracer », on fuite ce qu’on doit protéger. Ne loggue jamais : un mot de passe (même sur un échec !), un token/clé, un objet utilisateur complet, un numéro sensible, le corps brut d’une requête d’auth, l’en-tête Authorization, une URL contenant un secret en query. On loggue des identifiants (userId), un email masqué si nécessaire, un type de raison (bad_password, pas le mot de passe tenté). Configure la rédaction automatique (Partie 13) des champs sensibles. Un log qui « aide à débuguer » en imprimant tout est une fuite en attente.

Protéger et conserver les logs

• Accès restreint : les logs contiennent des données sensibles (IP, userId, actions) — accès limité, comme la production.
• Intégrité : un attaquant qui obtient l’accès tente souvent d’effacer ses traces. Envoyer les logs vers un stockage centralisé (à part, append-only si possible) protège la trace même si le serveur d’origine est compromis.
• Horodatage synchronisé (NTP) pour corréler entre systèmes.
• Conservation suffisante pour enquêter (les intrusions sont souvent découvertes tard), mais bornée (les logs contiennent de la PII → durées de conservation, RGPD — Partie 13).

💡 Réflexe — Deux questions à te poser sur ta journalisation : (1) « Si une attaque avait lieu maintenant, en verrais-je la trace ? » — si non (login sans log d’échec, accès sans log de 403), c’est un angle mort à combler. (2) « Mes logs contiennent-ils un secret ou une PII qui ne devrait pas y être ? » — si oui, c’est une fuite à corriger (rédaction). Logger les bons événements, sans les mauvaises données : c’est l’équilibre du chapitre.

🎯 Côté attaquant — L’attaquant a deux intérêts liés aux logs. D’abord, il agit discrètement en comptant sur ton absence de journalisation/supervision : si tu ne logges pas les échecs de login, les 403, les accès anormaux, il opère sans être vu pendant des semaines. Ensuite, s’il obtient un accès, il cherche à effacer ses traces (supprimer/altérer les logs locaux) — d’où l’importance d’une centralisation hors de sa portée. Et si tes logs sont mal protégés, ils deviennent pour lui une source (IP, userId, structure interne, parfois secrets mal caviardés). Bons logs, bien protégés = il perd son invisibilité.

🧭 Sur FormaCampus — FormaCampus journalise les événements de sécurité (connexions réussies/échouées, resets, changements de rôle/email/MFA, 403 et tentatives d’accès à des ressources d’autrui, dépassements de rate limit, entrées rejetées) en JSON structuré avec timestamp UTC, event, userId, ip, requestId. La rédaction automatique masque les champs sensibles (Partie 13) : aucun mot de passe, token ni objet complet ne transite. Les logs partent vers un stockage centralisé à accès restreint (l’attaquant ne peut pas les effacer sur place), horodaté (NTP), avec une durée de conservation définie (assez pour enquêter, bornée pour le RGPD). Cette base propre alimente la détection (chapitre 15.2) et l’investigation d’incident (chapitre 15.3).

✏️ Exercices

Exercice 1 — Corrige le log d’échec de login. Un dev logge les échecs ainsi : logger.warn('login KO', { email, password, body: req.body }). Qu’est-ce qui cloche et comment corriger ?

Exercice 2 — Comble l’angle mort. Une appli ne logge que les erreurs 500. Un attaquant tente un IDOR (change des ids et reçoit des 403) puis un bruteforce (nombreux 401). Rien n’est tracé. Quels événements ajouter et pourquoi ?

🧠 Quiz de révision

Chapitre suivant : Détection, monitoring & alerting — transformer ces logs en signaux et être prévenu à temps.