Maîtriser les Logs pour une Sécurité Impénétrable en DevOps

Les Logs Comme Arme de Sécurité

Si la lecture des logs est une compétence DevOps fondamentale, son application à la sécurité est un art en soi. Les logs de sécurité sont votre système d'alerte précoce : ils racontent ce que les attaquants tentent, ce qu'ils réussissent, et ce qui a été compromis. Encore faut-il savoir les écouter.

Les Logs Qui Comptent en Sécurité

Sur chaque infrastructure que je gère, je collecte et analyse systématiquement :

• Les logs d'authentification : tentatives de connexion échouées, connexions depuis des IPs inhabituelles, escalade de privilèges
• Les logs du API server Kubernetes : qui a fait quoi sur le cluster (kubectl exec, kubectl port-forward, suppression de ressources)
• Les logs des Ingress Controllers : scans de vulnérabilités, tentatives d'injection SQL, requêtes suspectes
• Les logs CloudTrail (AWS) : appels API sur le compte AWS, modifications de security groups, création de nouveaux IAM users

Un Cas Réel : L'Attaque Détectée par les Logs

Chez un client dans la fintech, notre monitoring Grafana a déclenché une alerte à 2h du matin : un pic anormal de tentatives d'authentification échouées sur l'API. En examinant les logs dans Loki, j'ai identifié un pattern de credential stuffing : des milliers de combinaisons email/mot de passe testées depuis une centaine d'IPs différentes (un botnet).

L'attaque n'avait compromis aucun compte grâce au rate limiting et à l'authentification MFA, mais sans les logs et les alertes, nous n'aurions pas su que notre plateforme était ciblée. Nous avons immédiatement renforcé la protection : blocage des IPs source, renforcement du rate limiting, et notification aux utilisateurs pour qu'ils vérifient leurs identifiants.

Le SIEM Léger avec Grafana

Pour la plupart de mes clients (des startups et PME, pas des grandes entreprises), un SIEM commercial (Splunk, QRadar) est surdimensionné et hors budget. À la place, je construis un "SIEM léger" avec la stack que nous avons déjà :

• Loki pour centraliser tous les logs de sécurité
• Grafana pour les dashboards de sécurité et les alertes
• Des règles d'alerte LogQL pour détecter les patterns suspects

Un dashboard type que je déploie comprend : le nombre de connexions échouées par minute, les nouvelles IPs source, les appels API sensibles (suppression de ressources, modification de security groups), et les scans de ports détectés par les logs réseau.

L'Intégrité des Logs

Un point souvent négligé : les logs eux-mêmes doivent être protégés. Un attaquant sophistiqué essaiera d'effacer ses traces en modifiant les logs. Pour s'en prémunir :

• Envoi immédiat vers un stockage centralisé : les logs quittent le serveur source en temps réel, avant qu'un attaquant puisse les modifier
• Stockage immuable : sur AWS, j'utilise des buckets S3 avec Object Lock pour garantir que les logs ne peuvent pas être supprimés ou modifiés
• Séparation des droits : le compte qui stocke les logs est différent de celui qui héberge les applications

L'Audit Trail en Conformité

Pour les clients soumis à des normes (ISO 27001, HDS, SOC 2), les logs d'audit sont une exigence formelle. Lors d'un audit chez un client en conformité ISO 27001, l'auditeur a demandé à voir les logs des 3 derniers mois pour un accès spécifique à la base de données. Grâce à notre centralisation dans Loki avec une rétention de 6 mois, nous avons pu fournir la trace complète en moins de 5 minutes.

Le Conseil Pratique

Commencez simple. Mettez en place une alerte sur les connexions échouées et les modifications de security groups. Ajoutez progressivement des règles pour les patterns suspects spécifiques à votre contexte. Et surtout, testez vos alertes : simulez une attaque et vérifiez que vous la détectez. Un système d'alerte qui n'a jamais été testé est un système d'alerte qui ne marchera pas le jour J.