Discussion :

[StringBuilder]

Bonjour,

Je ne suis pas du tout familier des droits sans SQL Server.

J'ai la (très mauvaise) habitude de créer les utilisateurs, de leur accorder les droits "sysadmin" au niveau du login, et les mapper sur les différentes bases de données auquelles ils ont accès en "db_owner" avec le schéma "dbo" : normal, habituellement, doit j'autorise des applications éditeur à accéder à la base, soit des développeurs qui doivent pouvoir faire tout et n'importe quoi (en connaissance de cause) sur le serveur.

Seulement là, je dois ouvrir un serveur à des utilisateurs néophytes, qui vont lancer des requêtes SQL sans avoir la moindre idée de ce qu'il font, afin de consulter des données à partir de requêtes toutes faites qu'on leur aura communiqué.

J'ai donc dans l'idée de créer ces comptes avec une interdiction totale de la moindre action sur la base, SAUF un grand SELECT sur des vues qu'on va leur mettre à disposition.

Ainsi, ils ne pourront, normalement, pas faire trop de bêtises.

Spontanément, j'ai créé ce nouveau user de la même manière que d'habitude, puis j'ai voulu lancer les instructions suivantes :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
revoke all to monuser;
 
grant select on dbo.mavue to monuser;

Seulement, le "revoke all" me retourne un message m'indiquant qu'il n'a pas planté, mais qu'il n'a rien fait, car c'est deprecated.

Je dois me taper 1 à 1 toutes les tables/vues/procédures/fonction à révoker ?

[SQLpro]

Lorsque tu créé un utilisateur dans une base, s'il n'est pas sysadmin par son compte de connexion au niveau serveur, il n'a droit à rien. Un simple GRANT SELECT sur la vue suffit donc.

A +

[StringBuilder]

Merci

C'était tout simple en fait... Fallait juste pas mettre le gars "sysadmin" (je savais que c'était une très mauvaise habitude )

[SQLpro]

Merci

C'était tout simple en fait... Fallait juste pas mettre le gars "sysadmin" (je savais que c'était une très mauvaise habitude )

En fait tout compte de connexion enrôlé en tant que sysadmin au niveau serveur devient automatiquement l'utilisateur dbo dans toute base. Et cet utilisateur possède tous les pouvoirs.

C'est effectivement une mauvaise chose qui ne devrait être réservé qu'aux DBA.

A +

[StringBuilder]

Bonjour,

Une petite question subsidiaire : on me demande de limiter l'impact sur les ressources de l'utilisation de ces personnes.

En effet, je vais mettre à disposition de néophytes (qui pourraient bien s'avérer des bidouilleurs acharnés) une série de vue complexes en lecture.

Je ne pourrai pas les empêcher de faire une requête du type :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from vue1, vue2, vue3, vue4... youpi tralala je suis un gros bidouilleur

Et plomber les performances, voir remplir le disque de tempdb

Sur une version 2014 STANDARD, peut-on limiter :
- CPU (% d'occupation ou nombre de coeurs)
- RAM
- Durée requête
- Espace de travail dans tempdb

Histoire que s'ils font n'importe quoi :
- Ils ne plantent pas le serveur
- Ils ne plombent pas les performances du serveur
- Ils puissent tout de même avoir des temps de réponse corrects