2010-07-13 4 views
16

Nous développons une application web utilisant asp.net et sql server. Nous sommes tenus de faire une piste d'audit pour l'application. Si je comprends bien, une piste de vérification serait essentiellement pour tous les Inserts, les mises à jour et les suppressions sur la base de données, n'est-ce pas? Maintenant, la façon d'aborder cela est que j'ai une table de piste d'audit dans la base de données qui se remplit après que chaque insertion, mise à jour ou suppression est lancée (écrire manuellement le script dans la couche d'accès au client). Cependant, les modifications de DB directement lancées à partir de SQL Management Studio NE seront PAS enregistrées (pour des raisons évidentes: P).Audit Trail dans une application web utilisant le serveur sql

Pour répondre à ce que je pourrais créer un déclencheur et qui s'occupe de tout. J'ai également fait quelques recherches sur Google et découvert que SQL Server a la capacité de faire une piste de vérification. Cependant, le problème avec l'utilisation de déclencheurs est que je ne vais pas obtenir les informations de l'utilisateur qui s'est connecté sur le site Web. J'obtiendrai l'utilisateur de sql mais je ne donne pas deux huées à ce sujet, je suis préoccupé par l'utilisateur de site Web.

Une solution que j'ai trouvée était soit a) Avoir une piste de vérification de mon application Web et aussi avoir un déclencheur mis en place. Dans le rapport d'audit, je montre simplement un journal d'audit à partir d'une application Web et un journal d'audit à partir du serveur SQL. Problèmes évidents avec cette approche: sur la tête. Ecrire dans deux ensembles de tables différents sur CHAQUE CHANGEMENT DE DB.

b) J'ai une colonne appelée UserId ON CHAQUE TABLE DB. Ensuite, je crée un déclencheur pour capturer tous les changements de DB. Je passe cet userId sur chaque table que je change (insérer, mettre à jour, supprimer) et l'obtenir cet ID du déclencheur. Retraits évidents: colonne userid inutile dans chaque table

Je m'excuse pour le poste long. Fondamentalement, j'ai besoin d'un journal d'audit qui enregistre tous les changements de db (y compris direct hack à db) mais en même temps me donne les informations de connexion utilisateur pour les modifications de base de données qui ont été faites à partir de l'application web.

Appréciera toute contribution à cet égard.

Un grand merci

xeshu

Répondre

12

Comment il est probable qu'il y aura des changements légitimes apportées à la base de données en exécutant directement des requêtes SQL sur la base de données soit par le biais de studio de gestion SQL ou autrement. Je recommanderais de supposer que toutes les données dans les données sont entrées via votre application et ont l'audit dans votre couche BL. Vous pouvez ensuite simplement limiter l'accès à la base de données aux utilisateurs de confiance. En fin de compte, il doit y avoir un ou plusieurs utilisateurs ayant la permission de modifier le schéma de la base de données, si ces utilisateurs veulent contourner l'audit, ils peuvent simplement désactiver les déclencheurs ou simuler la piste d'audit. S'il existe des raisons légitimes pour exécuter des requêtes SQL directes sur la base de données, par exemple. Vous pouvez limiter cette activité aux utilisateurs de confiance et vous assurer que leurs scripts d'importation remplissent correctement la table d'audit. Tout ce qui mettrait trop de charge de travail sur vos administrateurs de base de données ou sur les utilisateurs de confiance devrait être intégré à l'application de toute façon.

+0

Personnellement, je suis d'accord avec vous 100%. La principale préoccupation est essentiellement si quelqu'un va directement pirater la base de données et commencer à jouer avec les données, mais comme vous le dites, il peut très bien simplement supprimer les déclencheurs tous ensemble, donc il est inutile d'avoir des déclencheurs juste pour 0.00001% de chance ce qui peut très bien être supprimé si le hacker pirater. Bravo pour la réponse :) – xeshu

+0

Audit de la base de données SQL se sent tellement plus sûr pour moi. Je sais d'où vous venez, mais Diebold a reçu une bonne dose de mauvaise presse pour l'audit de leur candidature et non via leur base de données: http://www.bbvforums.org/forums/messages/2197/2368.html – sarnold

+1

dépend de votre application, un système de vote aurait besoin de contrôles beaucoup plus serrés que la plupart des applications. Cela peut sembler plus sûr, mais l'ajout de la journalisation au niveau de la base de données via les déclencheurs SQL n'offre pas en pratique une sécurité supplémentaire de la piste d'audit par rapport à l'audit au niveau de l'application. Toute personne ayant accès à la base de données et aux autorisations associées peut modifier les déclencheurs et insérer/mettre à jour/supprimer des enregistrements dans une table d'audit.Il est plus facile d'empêcher l'accès direct à la base de données et de créer votre sécurité et votre publicité dans l'application que de permettre un accès à certaines bases de données et de gérer des autorisations SQL au niveau fin. –

3

On dirait que vous êtes sur la bonne voie. Cependant, vous n'avez généralement pas une seule table de trace d'audit, mais plutôt une table d'audit pour chaque table. Ainsi, pour chaque modification d'une ligne de la TableA, une nouvelle ligne est ajoutée à TableA_Audit contenant le nouvel état de la TableA, plus la date et le nom de l'utilisateur.

Un déclencheur est normalement utilisé pour cela, mais si vous stockez le nom d'utilisateur de l'application web, je ne sais pas comment passer ces données dans un déclencheur (quelqu'un d'autre peut-il aider?) Dans ce cas, je pourrais être tenté d'utiliser des procédures stockées. Pour chaque table, avoir des procédures stockées pour insérer, mettre à jour et supprimer des lignes. Ces procédures stockées appellent chacune une autre procédure stockée qui insère la ligne dans la table d'audit. De cette façon, vous passez facilement le nom d'utilisateur de l'application Web à la procédure stockée qui insère la ligne dans la table d'audit. Évidemment, l'inconvénient est de devoir gérer un tas de procédures stockées pour chaque table, ce qui peut être un peu fastidieux car vous devez vous assurer qu'elles restent en phase avec les tables (et la couche d'accès aux données de l'application). .

Notez que vous n'avez pas besoin d'une colonne Nom d'utilisateur dans chaque table, uniquement dans chaque table d'audit.

Espérons qu'une partie de ce serait utile.

Vive

David

+0

Oui j'ai aussi pensé à la méthode SP mais je n'ai pas tendance à mettre toute ma logique dans SP, je suis plutôt un scripteur direct qui aime mettre tous les scripts en BLL. (Je déteste sp hehe). – xeshu

3

Je suis d'accord avec les deux autres affiches. En résumé, si vous voulez stocker le nom d'utilisateur de votre application web (c'est-à-dire votre authentification personnalisée), les déclencheurs ne vous aideront PAS à vérifier ce qui se passe. - Mise en garde sauf si vous pouvez utiliser l'authentification intégrée

Ceci est vraiment important si vous souhaitez également utiliser les pistes d'audit pour surveiller les volumes d'activité par utilisateur par exemple. La solution consiste à effectuer tous les DDL via des procédures stockées et dans ces procédures stockées, ajoutez votre logique d'audit (si vous voulez que toute la journalisation soit écrite en T-SQL). Vous pouvez également le faire à partir de l'application et consulter l'une des nombreuses bibliothèques de journalisation disponibles pour ASP.Net, telles que .

4

Merci à tous pour vos réponses. Après quelques googler c'est l'approche que je pense serait approprié: Audit générique Tableau

Audit_Table ( Id, TableName, RECORDID, (lien vers le document en question) ModifiedBy, ModifiedOn, type (I , U ou D) )

Audit_Details_Table ( Id, AuditID, NomChamp, OldValue, NewValue)

Je pense que cela devrait le faire. Des pensées?

+2

Qu'en est-il des valeurs modifiées/modifiées? –

Questions connexes