Personnalisé sp_who/sp_whoUsers

Question

Je dois autoriser un client dans un environnement de développement DW SQL 2K8R2 à visualiser et à tuer des processus, mais je ne souhaite pas lui attribuer VIEW SERVER STATE (il s'agit d'un ancien sql dba et il est considéré comme une menace interne potentielle) . Lorsque j'exécute ce qui suit, il renvoie une ligne comme si l'utilisateur avait exécuté le sp lui-même avec ses autorisations actuelles. Changer le "avec execute as" en "self" (je suis un sysadmin) retourne les mêmes résultats. J'ai également essayé le ci-dessous au lieu d'appeler sp_who, et il ne renvoie qu'une seule ligne. Select * from sysprocesses Il semble que le contexte ne change pas, ou ne persiste pas, tout au long de l'exécution de la procédure. Et c'est pour ne rien dire de la façon dont je vais permettre à cette personne de "tuer" les processus.

Est-ce que quelqu'un a une solution ou des suggestions à ce problème unique?

Answer 1

Cela ressemble certainement à une situation unique. Je me base sur le fait qu'il n'y a pas de solution non-machine/humaine ou de processus métier au problème (par exemple, aucune politique qui peut être mise en place pour refuser au client cet accès et ainsi, en fait, supprimer le problème).

Donc, avec une solution technologique, je ne connais pas de solution purement SQL pour le faire, mais mes connaissances dans le domaine DBA sont limitées. Cependant, ce que vous pouvez faire est:

1. Créer une application Web ASP.NET (probablement Web Forms serait bien ici plutôt que MVC, mais c'est juste mon avis) qui, lorsqu'il est déployé sera configuré pour fonctionner comme une application Pool d'identité en tant que compte de service spécifique créé dans votre AD (par exemple svc_KillProcessAccount). Le compte de service serait alors l'accès donné à la base de données (en tenant compte du moindre privilège requis) et personne n'aurait besoin de connaître le mot de passe sauf la personne qui configurait l'identité du pool d'applications (et nous supposerons cela est une personne de confiance)
2. l'application Web peut utiliser SMO à la liste et kill processus
3. Je dirais aussi l'application Web doit écrire une sorte de piste d'audit ou similaire lorsque les processus ont été vus et tués
4. le web l'application peut également avoir besoin de sécurité autour de lui en termes d'authentification et d'autorisation pour limiter les utilisateurs qui pourraient potentiellement faire usage de i t (par ex. limiter à un seul groupe AD qui est contrôlé par un administrateur quelque part)

Mais qui est beaucoup de bidouiller et une autre application pour maintenir plus d'informations d'audit pour examiner etc etc donc je considérer à moins un investissement modérément important qui ne résoudra (ou ne réglera quasiment) qu'un seul problème (je suppose que cette situation ne se présente pas beaucoup).

Je pense avec SMO et le genre de puissance que l'application aurait besoin de faire attention ici. Donc, je suppose que j'ai donné une solution plutôt compliquée.Peut-être y en a-t-il un plus facile qui utilise plus de SQL sur le tas (comme je l'ai dit, je ne suis pas un expert en la matière), mais si je proposais le genre de solution ci-dessus, autour de savoir si cela valait la peine ou si nous pouvions trouver une sorte de "humain" ou une solution de processus d'affaires au problème.

Désolé, ce dernier paragraphe est un peu opiniâtres - vous ne avez probablement pas besoin de moi pour être tout ce qui épousent :-)

HTH (en quelque sorte au moins) et bonne chance! Nathan