Journaliser sans exposer les secrets : guide pratique pour un projet IA

Les logs sont indispensables pour comprendre une erreur, un refus de permission ou une lenteur. Ils deviennent dangereux lorsqu’ils copient des tokens, mots de passe, cookies, contenus de fichiers ou prompts sensibles. Le bon compromis n’est pas de désactiver toute journalisation : c’est de choisir des événements utiles, de masquer les champs dangereux avant stockage et de limiter qui peut lire les traces et combien de temps elles restent disponibles.

Dans un projet IA, la prudence est accrue : prompts, réponses, appels d’outils et documents peuvent contenir des données personnelles, des secrets ou des instructions non fiables. Journalisez le comportement du système, pas par défaut l’intégralité du contenu qu’il a vu.

Ce que vous allez apprendre

Vous allez définir un schéma d’événements, identifier les champs interdits, appliquer une redaction avant émission, protéger l’accès aux logs, fixer une rétention et vérifier par tests qu’un secret ne passe pas dans les traces. La méthode convient à une API, un worker ou un agent avec outils.

Prérequis

• Une liste des parcours et incidents que les logs doivent aider à diagnostiquer.
• Un inventaire des données sensibles : tokens, identifiants, cookies, emails, documents et prompts.
• Un environnement de test avec des valeurs factices reconnaissables.
• Un propriétaire des journaux et une politique de rétention.
• Un canal sécurisé pour les incidents nécessitant davantage de détails.

Ne collez pas de secret réel dans un test. Utilisez une valeur factice au format identifiable afin de vérifier le masquage sans créer une nouvelle exposition.

1. Définir les événements avant les messages

Commencez par les questions auxquelles vous voulez répondre : quelle version a traité la tâche, quel outil a échoué, quel statut HTTP a été renvoyé, quelle règle a refusé une action, combien de temps a pris une étape. Ces éléments peuvent être représentés par des champs structurés et une corrélation de requête, sans enregistrer le texte complet d’un utilisateur.

Préférez un identifiant de tâche, un type d’événement, un résultat, une durée et un composant à une phrase libre construite par concaténation. Les messages libres capturent facilement une URL signée, une variable d’environnement ou un objet entier. Un schéma rend aussi les recherches et alertes plus fiables.

Vérification : prenez un incident récent non sensible et vérifiez que le schéma proposé permettrait de le diagnostiquer sans connaître le contenu exact d’un prompt ou d’un token.

2. Classer les champs avant de les émettre

Classez les champs en trois groupes : autorisés par défaut, autorisés sous forme réduite et interdits. Les identifiants de requête, version d’application et codes d’erreur sont souvent autorisés. Une adresse email peut devoir être pseudonymisée ou remplacée par un identifiant interne. Les mots de passe, tokens, cookies, clés privées, en-têtes d’autorisation et charge utile complète sont interdits.

Les informations apparemment innocentes peuvent devenir sensibles une fois combinées. Une URL peut contenir un jeton ; un message d’erreur peut répéter une variable d’environnement ; un objet d’outil peut contenir un document entier. Adoptez une règle de minimisation : si le champ ne sert pas à une question de diagnostic définie, ne le journalisez pas.

Vérification : relisez les structures de logs existantes et cherchez les objets sérialisés, erreurs brutes et en-têtes complets. Marquez chaque champ avec son niveau et sa justification.

3. Masquer avant le stockage

La redaction doit intervenir avant que l’événement atteigne la console, le collecteur ou un outil tiers. Créez des fonctions centralisées qui remplacent les champs interdits par une valeur fixe et réduisent les identifiants autorisés sous forme partielle. Ne comptez pas sur une règle de recherche après ingestion : le secret a déjà pu être transmis, indexé ou copié.

Évitez d’essayer de deviner tous les secrets uniquement avec une expression régulière. Les détecteurs peuvent constituer une défense complémentaire, mais la sécurité principale reste le schéma explicite et l’absence de sérialisation d’objets non maîtrisés. Pour les erreurs, sélectionnez le code, le composant et le type plutôt que d’imprimer la requête entière.

Vérification : injectez les valeurs factices de test dans chaque chemin d’erreur, de succès et d’exception. Recherchez-les dans les sorties locales et le collecteur ; elles ne doivent pas apparaître.

4. Protéger accès et rétention

Les logs doivent être accessibles aux personnes qui diagnostiquent, pas à tous les comptes de l’organisation. Séparez lecture, administration du collecteur et suppression. Utilisez l’authentification forte, des rôles limités et des audits d’accès lorsque la sensibilité le demande. Les exportations de logs sont elles-mêmes des copies de données : traitez-les avec les mêmes règles que le système source.

Définissez une durée de rétention proportionnée. Conserver indéfiniment des événements augmente le risque et le coût sans toujours augmenter la capacité de diagnostic. Préparez une suppression ou expiration vérifiable, ainsi qu’une procédure d’exception justifiée lors d’un incident.

Vérification : contrôlez qu’un compte applicatif ne peut pas consulter le collecteur et qu’un compte de lecture ne peut pas changer la rétention. Vérifiez qu’un événement de test expire ou devient inaccessible selon la politique.

5. Observer les agents sans enregistrer leur contexte complet

Pour un agent IA, journalisez la version du workflow, l’outil demandé, la décision d’autorisation, la durée, le statut et les identifiants internes de tâche. Ne conservez le prompt, la réponse ou le contenu d’un document que si une politique explicite l’autorise, avec une finalité, une durée et un accès définis. Une transcription intégrale est rarement nécessaire pour détecter qu’un outil a été refusé ou qu’un appel a expiré.

Quand un contenu doit être référencé, conservez un identifiant, une empreinte ou un emplacement contrôlé plutôt que le texte dans tous les logs. Cette approche garde une capacité de corrélation tout en réduisant les copies. Les sorties d’outils doivent être traitées comme des données non fiables et ne doivent pas pouvoir injecter une valeur secrète dans un champ libre.

Vérification : lancez une tâche d’agent de test et confirmez que vous pouvez expliquer le parcours et le refus d’une action sans retrouver le corpus ni une clé dans les traces.

6. Tester régulièrement et réagir à une fuite

Ajoutez des tests automatiques pour les fonctions de redaction et des tests d’intégration pour les chemins d’erreur importants. Contrôlez aussi les outils de diagnostic temporaires : un console.log ajouté dans l’urgence est une source fréquente d’exposition. La revue de code devrait repérer les objets complets et les en-têtes avant livraison.

Si un secret atteint les logs, considérez-le comme potentiellement exposé. Arrêtez sa diffusion, limitez l’accès aux traces, révoquez ou remplacez le secret selon votre procédure, puis corrigez le chemin de journalisation. Effacer un écran ne garantit pas la disparition des copies dans un collecteur ou une exportation.

Vérification : réalisez un exercice avec un secret factice : détectez sa présence, suivez l’alerte, vérifiez le masquage et documentez la procédure sans utiliser de valeur réelle.

Problèmes fréquents et solutions

Les erreurs brutes sont imprimées pour accélérer le débogage. Transformez-les en codes et champs sélectionnés, puis conservez les détails sensibles uniquement dans le canal d’incident autorisé.

Les logs deviennent inutiles après masquage. Ajoutez des identifiants de corrélation, catégories d’erreur et métriques, plutôt que de réintroduire le contenu complet.

Un fournisseur de logs reçoit toutes les données. Réduisez l’événement avant l’envoi et examinez les droits, région, rétention et exportations du fournisseur.

On découvre une clé dans un ancien log. Révoquez la clé, identifiez les copies et corrigez le chemin. Ne concluez pas qu’elle est sûre parce qu’elle est ancienne.

FAQ

Peut-on journaliser une adresse email ?

Seulement si une finalité et une politique l’autorisent. Préférez un identifiant interne ou une forme pseudonymisée lorsque le diagnostic ne requiert pas l’adresse complète.

Le masquage par expression régulière suffit-il ?

Non. Il peut compléter des contrôles, mais le schéma et l’interdiction d’objets non maîtrisés sont plus fiables.

Faut-il garder les prompts pour déboguer ?

Évaluez d’abord si un identifiant, une empreinte ou un échantillon contrôlé suffit. La conservation du contenu complet doit être explicitement justifiée et protégée.

Qui peut lire les logs ?

Les rôles qui en ont besoin pour l’exploitation ou la sécurité, selon le principe du moindre privilège. L’accès doit être revu régulièrement.

Que faire si un token apparaît ?

Traitez-le comme exposé : limitez les copies, révoquez ou remplacez-le, corrigez le code et vérifiez que le chemin ne reproduit plus la fuite.

Conclusion

Journaliser sans exposer les secrets demande de décider ce qui est utile avant de collecter. Avec un schéma, une redaction avant stockage, des accès limités, une rétention maîtrisée et des tests factices, les logs restent un outil de diagnostic sans devenir un inventaire involontaire de données sensibles.

Sources et limites

Sources primaires : OWASP Logging Cheat Sheet, OWASP Secrets Management Cheat Sheet et NIST SP 800-92. Les obligations de conservation dépendent des données et de la juridiction. Ce guide ne remplace pas une politique de journalisation ou de réponse à incident.