Partir du travail de la personne
Un journal utile explique un événement avec le minimum d'informations praticable. Partez de la question d'exploitation : quelle opération a échoué, à quelle étape, sous quelle version et avec quel résultat externe ? Enregistrer toute la requête transforme facilement le diagnostic en copie incontrôlée des données clients.
Conserver un périmètre utile
Préférez événements structurés, horodatage, identifiant de requête et codes non sensibles. Gardez le contenu client dans le système autorisé. OWASP traite l'exclusion des données sensibles et la protection des journaux. Définissez conservation, accès et nettoyage avant l'urgence.
Un scénario à répéter
Une intégration refuse par exemple une modification client. L'événement contient nom d'intégration, identifiant d'opération, tentative et catégorie d'erreur. L'opérateur consulte séparément le dossier autorisé. Testez aussi un message fournisseur contenant courriel ou jeton : nettoyer vos champs ne nettoie pas son texte. Vérifiez le journal stocké, pas uniquement l'entrée de la fonction.
Ne pas déplacer le problème
Ne placez pas de secrets dans des URL enregistrables par proxy ou analyse. Un identifiant haché n'est pas automatiquement anonyme. Le mode debug ne doit pas accroître silencieusement la collecte. Séparez audit de sécurité et diagnostic si accès ou conservation diffèrent. L'erreur de secours ne doit pas révéler de valeur sensible.
Définir l'événement avant l'incident
Pour l'échec d'intégration, définissez nom, heure, opération, version, tentative et catégorie limitée. Distinguez corrélation nécessaire et simple commodité. Préférez des champs autorisés explicites à la sérialisation d'un objet auquel des données pourraient s'ajouter sans changement de politique. L'événement reste utile même si le message client est plus général.
Suivez tout le parcours jusqu'au stockage. Proxys, middleware, collecteurs d'erreurs, workers et bibliothèques produisent aussi des sorties. Vérifiez URL, en-têtes, exceptions et réponses imbriquées. Utilisez des marqueurs fictifs ressemblant à courriel, jeton et message, puis cherchez-les dans chaque destination. Tester le nettoyage ne prouve pas qu'un autre composant n'a pas enregistré l'original avant.
Planifiez accès et suppression. Désignez qui cherche, exporte et modifie la conservation ; la collecte temporaire doit expirer. Pour consulter l'original, utilisez les droits du système métier plutôt qu'élargir les journaux. Incluez exports et notes copiées dans le périmètre de suppression. Vérifiez que le journal nettoyé aide encore. S'il devient trop vague, ajoutez du contexte structuré sûr plutôt que le contenu personnel intégral. Gardez des incidents nettoyés pour les essais futurs.
Matrice de revue des journaux
| Test | Preuve à inspecter |
|---|---|
| Erreur fournisseur avec jeton | L'application et les sorties aval l'omettent tout en gardant une catégorie utile. |
| Entrée sensible dans l'URL | Proxy et middleware ne divulguent pas la valeur. |
| Expiration du debug temporaire | La collecte revient à son périmètre normal sans nettoyage reposant sur la mémoire. |
| Diagnostic autorisé avec contexte | L'événement permet la corrélation métier sous les droits existants, sans contenu client massif. |
Évaluer le résultat
Quelle question justifie chaque champ ? Qui lit et exporte ? Quand supprime-t-on aussi les copies ? Apportez des erreurs nettoyées à la revue et montrez une investigation réelle sans transmettre le message intégral du client.