Il n'existe aucun outil capable d'analyser un journal de requêtes et de vous dire ce qui sera exécuté maintenant et pour toujours sur la base de ce journal, tout simplement parce qu'il n'y a aucun moyen de savoir si le journal de requêtes est une liste exhaustive de toutes les requêtes susceptibles d'être générées par le logiciel.
Vous devez examiner le code réel qui effectue la requête pour faire cette détermination.
Si vous n'avez pas accès au code réel, la meilleure chose à faire dans votre situation est de créer des comptes par application qui n'ont accès qu'à la ou aux bases de données nécessaires à l'application spécifique, et qui ne peuvent pas exécuter de DDL Cela permettra au moins d'éliminer les Petites tables Bobby (et franchement, tout système dans lequel le code exécute des déclarations DDL est probablement fondamentalement défectueux et doit être soigneusement réévalué pour garantir des autorisations adéquates).
Faites-le dans votre environnement de développement (vous en avez un, n'est-ce pas ?) et testez pour vous assurer que vos applications fonctionnent correctement. Méfiez-vous en particulier des noms d'utilisateur/mots de passe codés en dur que vous pourriez ne pas détecter.
Si vous n'avez pas la chance de disposer d'un environnement de développement, testez-le en dehors des heures de bureau, en désactivant l'accès aux applications concernées pour tous les utilisateurs, à l'exception de votre équipe interne de développement/test.
Ensuite, vous pouvez décider s'il est utile d'imposer des restrictions supplémentaires à certaines parties de l'application (par exemple, les comptes en lecture seule, les comptes qui ne peuvent être utilisés que par les utilisateurs de l'application et les utilisateurs de l'application). INSERT o UPDATE mais pas DELETE etc.)
