Le journal d’audit : la réponse à « qui l’a fait », pas à « que s’est-il passé »

La supervision et le journal d’audit sont deux choses différentes, et on les confond. La supervision répond à « que s’est-il passé » : le disque s’est rempli, un service est tombé, la charge a monté. Le journal d’audit répond à qui l’a fait. La valeur du second apparaît les jours qu’on n’espère jamais.

Trois moments

Quelque chose a changé et personne ne se souvient de l’avoir changé. La réponse est le plus souvent « toi, il y a trois semaines », et c’est un soulagement plutôt qu’une accusation : un changement inconnu inquiète bien plus qu’un changement connu.

Deux personnes travaillent sur la même machine et chacune suppose que c’est l’autre. Dans ce cas, la seule chose qui met fin à la discussion est l’enregistrement.

Quelque chose a vraiment mal tourné et il vous faut l’ordre des événements. L’état final vous dit ce qui s’est passé ; l’ordre vous dit comment. Sans le second, la même chose se reproduit.

« C’est root » n’est pas une réponse

Si tout le monde se connecte avec le même compte, le nom dans l’enregistrement est le même pour tous. L’enregistrement continue de répondre à « que s’est-il passé » mais cesse de répondre à « qui l’a fait ». C’est pourquoi un journal d’audit est sans importance sur une installation à une personne et devient critique le jour où une deuxième arrive.

Ce qui ne doit pas s’y trouver

Le corps de la requête. Mots de passe, clés et jetons y passent. Un enregistrement qui capture tout signifie un nouvel endroit où vivent vos secrets, et cet endroit est en général moins protégé parce qu’il compte comme « juste un journal ».

Un journal d’audit a besoin de cinq choses : qui, quoi, quand, sur quoi, et le résultat. Quand vous voulez en ajouter une sixième, demandez d’abord si elle porte un secret.

L’endroit où il se trouve décide s’il est une preuve

Un enregistrement que seule l’application peut écrire et réécrire est un carnet, pas une preuve. Si l’application elle-même est compromise, elle corrige aussi l’enregistrement.

C’est pourquoi l’enregistrement doit aussi atterrir là où l’application ne peut pas aller. Le journal propre au système existe pour cela : l’application y écrit mais ne peut pas y supprimer.

Durée de conservation

Un journal d’audit gardé trois jours répond à « qui l’a fait hier » et à rien d’autre. Or la plupart de ces questions arrivent des semaines plus tard, car l’effet d’un changement n’est en général pas visible tout de suite. Conservez le journal d’audit selon une autre logique que vos sauvegardes : il prend peu de place et reste utile longtemps.

Ce que fait Atlas

Atlas n’écrit que cinq choses dans le journal d’audit : qui, quoi, quand, sur quoi, résultat. Le corps de la requête n’est jamais écrit, car une requête de connexion porte un mot de passe et il n’y a aucun intérêt à ce que ce mot de passe existe une seconde fois dans un fichier de journal.

L’enregistrement atterrit à deux endroits à la fois. L’un est le journal propre au système : Atlas y écrit mais ne peut ni y prendre ni y modifier. L’autre est un fichier dans le dossier de données du produit, que les mises à jour ne suppriment pas. Vous n’avez donc pas à descendre dans le journal du système pour lire l’enregistrement, mais il y est quand vous en avez besoin.

Un détail petit mais significatif : l’horodatage est écrit tout à la fin de l’enregistrement. Ainsi, même si le côté qui crée l’enregistrement transmet son propre horodatage, il ne peut pas l’écraser. Rien n’essaie cela aujourd’hui, mais dans un journal d’audit, l’ordre juste tient à la nature même de la chose.

Et les requêtes refusées sont enregistrées aussi, pas seulement celles qui ont abouti. L’information « quelqu’un a essayé et cela n’a pas marché » figure donc également dans l’enregistrement ; le plus souvent, c’est exactement la phrase recherchée.