Journaux d'audit : quoi consigner, comment les garder intacts et qui peut les lire

Ce que c'est

La fiche OWASP Logging Cheat Sheet (citée) demande que chaque entrée indique quand, où, qui et quoi : horodatages de l'événement et de sa journalisation, application et hôte, identité de l'utilisateur ou de la machine à l'origine de l'action et son adresse source, type d'événement, objet concerné, résultat et motif. Sa liste d'événements à toujours journaliser comprend les authentifications réussies et échouées, les échecs d'autorisation, les actions d'administration des utilisateurs, l'usage de privilèges administratifs, l'accès aux données sensibles, l'utilisation et la rotation des clés, et les changements de configuration. Un journal d'audit est le sous-ensemble qui documente les actions effectuées pour le compte d'un principal, c'est-à-dire d'une identité de sécurité ; il est conservé comme registre plutôt que comme sortie de diagnostic.

Pourquoi c'est important

Un journal d'audit n'a de valeur que s'il est complet pour les actions qui comptent et s'il ne peut pas être discrètement modifié par la personne dont il enregistre les actions. La liste des attaques contre les journaux dressée par la fiche comprend les attaques qui empêchent les écritures ou endommagent le journal pour effacer les traces de l'attaquant, et celles qui provoquent la journalisation d'une identité erronée pour dissimuler le responsable.

Comment l'appliquer

• Émettre les événements d'audit depuis la couche applicative, où le principal et l'objet sont connus, sous forme d'enregistrements structurés à schéma stable : acteur, type d'acteur, action, type et identifiant de l'objet, résultat, motif, identifiant de requête, horodatage en UTC.
• Consigner l'acteur sous la forme d'un identifiant, pas d'un nom d'affichage, et mentionner explicitement les cas d'emprunt d'identité (« l'administrateur X agissant en tant qu'utilisateur Y »).
• Ne pas écrire les identifiants de session, les jetons d'accès, les mots de passe, les clés ou les données personnelles complètes ; la fiche les classe parmi les données à exclure ou à masquer.
• Acheminer rapidement les entrées vers un stockage que l'application ne peut pas modifier : une table en ajout seul accessible par un rôle de base de données en écriture seule, ou un stockage d'objets avec verrou de rétention. Amazon S3 Object Lock (cité) décrit un modèle à écriture unique et lectures multiples dont le mode de conformité empêche tout utilisateur d'écraser ou de supprimer les données pendant la période de rétention.
• Ajouter un mécanisme permettant de détecter les altérations, par exemple une chaîne de hachage ou des empreintes signées périodiques, et le vérifier à intervalles planifiés.
• Restreindre la lecture à un groupe désigné, journaliser chaque lecture et revoir périodiquement la liste des privilèges, comme le demande la fiche.
• Définir la durée de rétention à l'avance et supprimer les données selon le calendrier prévu ; conserver des données d'audit au-delà de leur finalité constitue en soi un risque.

Pièges

Mélanger les enregistrements d'audit avec des journaux applicatifs soumis à une rotation au bout d'une semaine. Journaliser l'intention (« suppression demandée ») mais pas le résultat. Des messages en texte libre qui ne peuvent pas être interrogés par des requêtes. Faire confiance, dans l'événement, à un identifiant utilisateur fourni par le client. Un journal immuable que personne ne lit avant l'incident.