Certainement depuis l’avènement des bases de données les administrateurs ont voulu savoir ce qu’il se passait sur leurs serveurs. Qui ne s’est pas posé ou n’a pas eu à répondre à cette question : “qui fait quoi sur la base de données” ? La question vaut pour les données, “qui a modifié tel enregistrement ?”, mais aussi sur les objets, “qui a modifié cette procédure ?”, aussi bien qu’au niveau serveur : “qui s’est logué en dernier ?”…
On peut trouver dans n’importe quel système d’information ou application une routine, un module ou un dispositif à vocation d’audit. Du plus artisanal au plus sophistiqué, tous répondent au même but, traquer tracer les actions des utilisateurs.
Une des problématiques de l’audit est d’être le moins intrusif possible. En effet, il arrive souvent que l’on doivent auditer notre base une fois en production. Pour adresser ce problème, on s’appuie donc sur les fonctions natives de la base de données. Au fil des versions, SQL Server a fourni des moyens pour faire de l’audit.
Par exemple, on peut évidemment citer l’ancêtre, l’outil préféré des développeurs (-sic-), les TRIGGER qui permettent de couvrir une partie du besoin car jusqu’à la version 2005, ils ne tracent que les actions sur les données. Depuis SQL Server 2005, il y a les DDL Triggers pour interférer sur les manipulations d’objets.
Evidemment, l’arsenal s’est étoffé ; événements, AUDIT, Change Tracking, Change Data Capture, etc.
Les événements ont fait leur apparition dans la précédente version mais la version 2008 a vu leur montée en puissance avec les Extended Events car tout dans la base génère un événement qui s’accompagne d’un wagon d’informations.
Nouveauté de la version 2008, l’objet AUDIT, est dédié à l’audit dans la base de données.
Sans oublier des outils puissants pouvant tenir lieu d’audit qui sont les fonctionnalités de surveillance des modifications : Change Tracking et Change Data Capture.
Bref, pour vous retrouver parmi toutes ces fonctionnalités, Bewise vous propose une série d’articles sur le sujet en vous présentant les différentes techniques pour faire de l’audit dans SQL Server. L’objectif est de balayer techniquement les solutions mais aussi d’apporter des éléments de réponses pour faire le choix de la technique qui convient le mieux à votre besoin.
Puis nous terminerons par une petite synthèse.
PS : vous aurez compris, nous n’aborderons pas les triggers. Non pas que la solution soit à bannir mais parce qu’elle commence à dater et que le sujet est bien souvent maîtrisé. N’hésitez pas à nous contacter pour des informations sur ce sujet particulier.