[Conseil] Log les évenements sur une autre db?

Bonjour,
Je recherche un conseil....

Je suis entrain de créer une base de données pour enregistrer les
événements de l'activité du serveur et des bases de données.

J’ai des trigger sur les tables qui vont enregistrer les événements.
J’ai des trigger sur les bases de données (Changement de structure)
qui vont enregistrer les événements.
Trigger sur le serveur pour enregistrer les login admin qui se
connecte
Trigger sur le serveur pour enregistrer les changements d’options du
serveur.

De cette manière j’ai une trace de toutes les modifications du
serveur.

Mais j’ai un souci de sécurité :
Les utilisateurs sont connectés sur un « active directory ». Chaque
utilisateur est identifié lorsqu’il se connecte à la db par l’AD.
Ces utilisateur appartiennent à un groupe qui accède à la db avec
leurs spécifications (Laurent-Ecriture et pas d’écriture sur la table
XX…).

Lorsqu’un utilisateur modifie une table qui est protégé par un trigger un événement est lancé pour mettre l'infos dans une table qui se trouve dans une autre db.
Bien sur,j’ai un message d’erreur pour me dire que cet utilisateur n’a pas
accès à cette Base de données ou même a la tabl. Ce qui
est normal. Mais comment je pourrais faire pour éviter ce
message en toute sécurité?

Dois-je ajouter les utilisateurs dans la db de log en insert? Pas génial …car
ca veut dire qu’ils peuvent avoir un accès a la db de log.

Dois-je passer par une procédure stocké ? Mais comment faire un
impersonate avec un login AD ?

Il y a aussi les "alerts" mais je ne sais pas comment je peux faire passer des params entre l'alert et le trigger(J'aimerais que ce soit du XML).

Où il y a surement d’autres solutions. Je suis en pleine recherche
sur le web mais je ne trouve pas grand-chose sur le sujet.


Merci de vos conseilles.

Il est particulièrement mauvais d'utiliser la sécurité intégrée NT (mappage d'utilisateur OS avec SQL) pour attaquer des bases de données applicatives. En effet, posez vous la question de savoir qui se connecte au serveur :
1) l'utilisateur M. DURAND
2) l'application X de l'utilisateur DURAND
???

Vos problèmes se résoudrons tout seul lorsque vous aurez modifié votre modèle de sécurité pour qu'il se calque à la réalité. Ce ne sont pas des utilisateurs personnes physique qui manipulent les bases de données, mais bien des applications....

En l'état votre problème est difficilement soluble, sauf à dépersonnaliser la sécurité.

A +

C’est un gros souci car c'est une plique d'entreprises(Anglaise) de plus les applications doit chainer la sécurité. Car d'après nos analyses en sécurité, On doit travailler sur une sécurité pessimiste ce qui veut dire que l'on doit gérer la sécurité au niveau application et aussi base de données. Car on peut avoir bcp de client différent(Parfois même Access , Excell…).
Ceci dit on a des logins dans l’AD qui sont générique.
Mais comment faire alors pour enregistrer l'activité de chaque utilisateur. Si le login est par application ?
Donc si je comprends bien c'est au niveau Application qu'il faudrait le faire. Mais pour cela c'est très difficile car on travaille avec plusieurs dizaines App qui ne gère pas tous ca(malheureusement quick and dirty).
Alors j'ai un gros souci........

En attende de vos conseilles sur ma façon de réagir au prochain meeting avec les Dev.

Si vous êtes en application client lourd, le nom d'utilisateur, comme la MAC adresse de la machine cliente est visible dans les tables de process. Il n'y a donc aucun problème pour ce faire.

N'oubliez pas non plus que le nom d'utilisateur NT ne suffit pas à s'assurer que c'est bien M. Untel qui a taper sur son clavier. Ceci a pu être fait à son insu...

A +

Je pense que la Mac adresse sera ma solution car toute nos machines sont identifiées géographiquement par Mac Adresse. Et chaque machines appartiennent a un et un seul user......


Donc je vais chercher dans cette voix .........

Code:

---

SELECT net_adress FROM sys.sysprocesses WHERE spid = @@SPID

---

Vous donne la mac address associé au process de la requête en cours.

A +

Encore une fois grand merci ..........