32-7 · Chapitre 32 · 5 min de lecture

Qui a vu ce secret ? Pourquoi les journaux d'audit sont plus importants que vous ne le pensez

Recevez une notification à 3h du matin : un accès à une base de production a été utilisé pour une requête destructive. Sans journaux d'audit, impossible de savoir qui a vu ce mot de passe. Découvrez pourquoi ces logs sont essentiels pour la sécurité de vos secrets.

Qui a vu ce secret ? Pourquoi les journaux d'audit sont plus importants que vous ne le pensez

Vous recevez une notification à 3 heures du matin. Quelqu'un a utilisé un identifiant de base de données de production pour exécuter une requête destructive. Les dégâts sont faits. Votre première question n'est pas "comment ont-ils pénétré ?" mais "qui avait accès à ce mot de passe ?"

Si votre équipe ne peut pas répondre à cette question en quelques minutes, vous avez un problème qu'aucun chiffrement ni rotation ne pourra résoudre. Sans journaux d'audit, vous naviguez à l'aveugle. Un secret pourrait fuir pendant des semaines sans que vous puissiez déterminer s'il s'agit d'une brèche externe ou d'un acte interne.

La caméra de surveillance de vos secrets

Considérez les journaux d'audit des secrets comme une caméra de sécurité à l'entrée d'un bâtiment. Chaque fois qu'une personne ou un système récupère un secret, le coffre enregistre qui a fait la demande, quel secret a été demandé, l'heure exacte et l'origine de la requête. Cet enregistrement s'appelle une piste d'audit.

La règle cruciale : les utilisateurs normaux ne peuvent pas désactiver ni supprimer ces journaux. Seuls les administrateurs disposant de privilèges spéciaux le peuvent. Si les utilisateurs pouvaient effacer leur propre historique d'accès, tout le système d'audit deviendrait inutile. Vous auriez des logs qui ne montrent que ce que les gens veulent que vous voyiez.

Ce que chaque piste d'audit doit capturer

Une piste d'audit utile doit contenir au moins quatre informations :

Qui a accédé. Il peut s'agir d'un nom d'utilisateur, d'un compte de service ou d'un nom d'application. Vous devez connaître exactement l'identité qui a fait la demande, pas simplement "quelqu'un de l'équipe backend".

Quel secret a été consulté. Enregistrez le nom ou le chemin du secret, pas sa valeur. Vous n'avez pas besoin de stocker le mot de passe réel dans le log. Vous devez juste savoir que "le mot de passe de la base de production" a été récupéré.

Quand cela s'est produit. Les horodatages doivent avoir une précision à la seconde près. Lors d'une enquête sur un incident, une différence de quelques minutes peut changer toute l'histoire. L'accès a-t-il eu lieu cinq minutes avant l'incident ou cinq minutes après ?

Le résultat. La demande a-t-elle réussi ou échoué ? Si elle a été refusée, pourquoi ? Une tentative d'accès échouée peut être tout aussi importante qu'une réussie. Elle peut indiquer que quelqu'un teste des identifiants volés.

Les coffres modernes comme HashiCorp Vault, AWS Secrets Manager et Azure Key Vault fournissent ces logs prêts à l'emploi. Les logs peuvent être envoyés à un système SIEM ou à un stockage centralisé comme Elasticsearch. L'important n'est pas où vivent les logs, mais qui peut les lire. Les équipes de sécurité et les intervenants en cas d'incident doivent avoir un accès en lecture. Les développeurs normaux n'ont généralement pas besoin de parcourir la piste d'audit.

Voici à quoi ressemble une entrée de journal d'audit réelle provenant de HashiCorp Vault :

{
  "time": "2025-03-15T02:34:12.847Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "display_name": "deploy-bot",
    "policies": ["deploy", "default"]
  },
  "request": {
    "path": "secret/data/production/db-password",
    "operation": "read",
    "remote_address": "10.0.1.42"
  },
  "response": {
    "data": {
      "data": null
    },
    "warnings": null
  }
}

Lire les logs demande de la pratique

Les journaux d'audit ne servent pas uniquement à l'investigation post-incident. Ils vous aident à comprendre les schémas normaux afin de repérer les anomalies.

Considérez ce scénario : votre journal d'audit montre que le compte "deploy-bot" a accédé au secret "db-production-password" à 2h34 du matin. Est-ce normal ? Cela dépend. Si votre pipeline exécute des déploiements nocturnes, cet accès est attendu. Mais s'il n'y avait aucun déploiement planifié cette nuit-là, vous devez poser des questions. Peut-être que quelqu'un a déclenché manuellement une exécution du pipeline. Ou peut-être que les identifiants du deploy-bot ont été compromis.

Voici des schémas suspects courants qui apparaissent dans les journaux d'audit :

Accès répété au même secret dans un court intervalle de temps
Accès depuis une adresse IP qui ne correspond pas à la plage habituelle de votre équipe
Un développeur qui n'accède normalement qu'aux secrets de staging qui récupère soudainement des identifiants de production
Accès à des secrets dans des environnements qui ne correspondent pas au rôle de l'utilisateur

Ce dernier point est délicat. Parfois, un développeur a légitimement besoin d'un accès à la production pour un correctif urgent. Mais si cela se produit à plusieurs reprises sans explication, cela peut indiquer un usage abusif. Le journal d'audit vous donne les données pour avoir cette conversation.

Les journaux d'audit aident aussi à la récupération

Lorsque vous soupçonnez qu'un secret a été compromis, les journaux d'audit vous indiquent l'étendue des dégâts. Vous pouvez voir exactement quelles identités ont récupéré ce secret dans une fenêtre de temps spécifique. Cela vous aide à prioriser la rotation. Si un seul compte de service a accédé au secret compromis, vous n'avez besoin de faire tourner les identifiants que pour ce compte. Si vingt utilisateurs et applications différents l'ont récupéré, vous avez un travail de nettoyage bien plus important.

Sans journaux d'audit, vous devez supposer le pire et tout faire tourner. Cela crée du travail inutile et des temps d'arrêt. Avec les journaux d'audit, vous ne faites tourner que ce qui doit l'être.

Une liste de contrôle pratique pour les journaux d'audit des secrets

Si vous mettez en place une gestion des secrets aujourd'hui, voici une liste de contrôle rapide pour vérifier votre couverture d'audit :

Chaque accès à un secret est enregistré avec l'identité, le nom du secret, l'horodatage et le résultat
Les logs ne peuvent pas être supprimés ou modifiés par les utilisateurs normaux
Les journaux d'audit sont envoyés à un emplacement central que les équipes de sécurité peuvent interroger
Vous avez un processus pour examiner les logs périodiquement, pas seulement lors des incidents
Vous connaissez les schémas d'accès normaux pour chaque environnement

L'essentiel

Les journaux d'audit n'empêchent pas les fuites de secrets. Mais ils vous donnent la capacité de répondre à la question la plus importante après une brèche : qui a vu quoi, et quand. Sans cette réponse, vous devinez. Et deviner en matière de sécurité, c'est ainsi que les petits incidents deviennent de grandes catastrophes.