Outiller un audit de base de données
Chez OCTO nous réalisons beaucoup d’audits d’applications et ceux-ci comportent de plus en plus souvent un volet sur la base de données. Les motivations des audits sont diverses : le modèle de données est-il conforme à l’état de l’art ou à un standard d’entreprise ? Représente-t-il des risques pour l’application (performances, intégrité) ? Sera-t-il capable de supporter le lancement d'une telle fonctionnalité, triplant le nombre d’utilisateurs et la volumétrie ? Dans 10 ans et après 10 générations de prestataires, sera-t-il toujours lisible ? Comment mesurer la qualité des procédures stockées ?
Toutes ces questions font appel à l’expertise de l’auditeur. Néanmoins, devant un modèle monolithique de centaines de tables et de procédures stockées, il est évident qu’un outillage adéquat permet de gagner beaucoup de temps.
Cette idée a fait son chemin dans la tête de l’un d’entre nous (Désiré) : d’un outil personnel écrit en Java est né YODA[1], ou Yin OCTO Database Analyzer. Aujourd’hui YODA est fait par des OCTOs (5 contributeurs à ce jour), pour des OCTOs amenés à réaliser des audits de bases de données. Les utilisateurs sont aussi contributeurs, soit par l’ajout de fonctionnalités, soit par des retours du front sur l’outil : prise en main, stabilité, couverture fonctionnelle, idées d’amélioration, qualité de la doc.
Mais que permet de faire YODA exactement ? Il permet tout d’abord d’aspirer un modèle de données entier (structure) via une connexion à la base à auditer, ou en interprétant des ordres DDL (CREATE TABLE, CREATE PROCEDURE, ...) stockés dans des scripts SQL.
Une fois cette étape de collecte faite, plus besoin de connexion à la base : les informations sont maintenues dans une petite base de données locale, sur laquelle la phase d’exploitation peut s'appuyer. Celle-ci produit un rapport d’appréciation sur la base d'origine, en faisant passer le méta-modèle collecté dans une série d’analyseurs. Le rapport rassemble :
des métriques factuelles sur le modèle (nombre de tables, de colonnes, de lignes, d’index, ...) ou sur le code des procédures stockées (nombre de lignes, taux de commentaires, complexité cyclomatique, ...) ;
des vérifications de règles données en amont (respect des conventions de nommage de l’entreprise, ...) ;
des soupçons d’anti-patterns (clefs étrangères non indexées, tables sans clefs primaires, absences de forme normale, ...) -- ce sont plus des faits saillants portés à l’attention de l’auditeur, charge à lui de confirmer les alertes avec son expertise, le contexte et sa connaissance de l’architecture de l’application.
Ces analyseurs sont pour la plupart indépendants du moteur SGBD cible. Nous avons beaucoup d’autres idées en stock, des analyseurs combinant données, informations sur le modèle et code SQL, pour une approche globale de l'audit de base de données. Le code de YODA est conçu de telle sorte que l’ajout d’un analyseur soit le plus simple possible.
Comme toutes nos applications internes, le modèle de diffusion de YODA à l’intérieur d’OCTO est très proche de l’open source. A notre connaissance l’outil a très peu d’équivalents ailleurs et justement aucun en open source. Un jour l’ouvrir à l’extérieur d’OCTO, pourquoi ne pas ?
Et vous, outillez-vous vos audits de bases de données ? Avec quoi ?
[1] Georges, si tu nous lis : YODA est le nom interne de notre projet