Logs de sécurité et détection

Prérequis : cours 4.x + DevOps 7.1 (logs).

Pourquoi

Sans logs sécu, une intrusion se découvre par hasard (ou par la victime qui appelle). Avec : brute-force vu en minutes, exfiltration en heures, et des preuves pour comprendre.

Concepts

• Quoi logger : auth (succès/échecs + IP + user-agent), changements de privilèges, accès admin, erreurs 4xx/5xx en rafale, uploads, exports massifs. Jamais : mots de passe, tokens, PII inutile (cf. DevOps 7.1).
• Alertes : 5 échecs login/5 min/IP, nouveau pays pour un compte, pic de 4xx, admin hors horaires, export > N lignes. Peu, actionnables (cf. DevOps 7.3 : 3 alertes !).
• Rétention : 90 j en ligne + 1 an archivé (légalement variable ; l'incident se découvre souvent 3 mois après). Intègres (append-only, hash chaîné ou WORM) : des logs modifiables ne prouvent rien.
• Corrélation : requestId/userId partout (DevOps 7.1) + horloges sync : suivre l'attaquant à travers proxy/app/base.

Exemple : les 5 alertes de départ

1. ≥5 échecs login / 5 min / IP → fail2ban + alerte
2. Login depuis nouveau pays → mail à l'user
3. Pic 4xx (>50/min) → scan probable
4. Accès admin hors horaires → vérifier
5. Export > 10k lignes → valider (exfiltration ?)

Cas réel

Exfiltration lente (2000 lignes/nuit pendant 2 mois) : invisible aux seuils instantanés, visible aux cumuls (export/user/semaine) + alerte « nouveau pattern ». Sans cumul : découverte par hasard, 120k lignes parties.

Pièges

• Logger les mots de passe « pour débugger l'auth » : le log devient la fuite (cf. 3.1 hash).
• 90 jours de logs que personne ne lit : sans alertes + revues, c'est du stockage, pas de la détection.
• Alertes non testées : la règle existe, le mail part en spam. Tester chaque alerte (feu vert mensuel).

À retenir

Auth+privilèges+rafales+exports loggés, 5 alertes actionnables, 90 j + archive intègre, corrélation par IDs.