Journal d’audit

Retracer une opération ultérieurement

Un journal d’audit enregistre des événements applicatifs sélectionnés pour leur importance dans la traçabilité. Il doit permettre de savoir qui a tenté ou réalisé quelle action sur quel objet, à quel moment et avec quel résultat. Cela comprend un horodatage adapté et une référence d’interaction reliant les événements associés. Un compteur général d’erreurs ne répond pas à ces questions.

Dans un portail fictif de projets, user-17 tente de passer le rôle sur project-8 de viewer à editor. Le serveur refuse la tentative et consigne le résultat denied. En ne lisant que le changement demandé, on pourrait croire qu’il a eu lieu. Le résultat montre que cette tentative n’a accordé aucun nouveau droit.

Protéger la valeur probante du journal

L’équipe définit les événements nécessaires et les personnes autorisées à lire, écrire ou supprimer les enregistrements. Mots de passe, jetons d’accès et documents confidentiels complets n’ont pas leur place dans ce journal comme compléments pratiques. La durée de conservation exige aussi une règle justifiée.

Nommer un fichier journal d’audit ne le rend ni complet ni infalsifiable. Protection contre les modifications et suppressions non autorisées, détection des altérations et surveillance des défaillances de journalisation font partie de la mise en œuvre. Une entrée perdue ou modifiée après coup peut orienter une enquête dans la mauvaise direction.

Sources

• OWASP — Logging