Discussion :

[StripMat]

Bonjour, je m'attaque à la gestion des privilèges sur SQL Server, et il y a quelques petits trucs que je ne maitrise pas bien.

Tout d'abord, je voudrais savoir comment paramétrer un compte de connexions pour que les utilisateurs qui y sont mappés n'ai accès qu'a leurs bases parmis un pool de BDD. Pour l'instant je n'ai réussi qu'a régler l'appartenance au rôle de BDD sur db_denydatawriter et db_denydatareader pour les bases que je ne souhaite pas qu'il y ait un accès, mais la connexion à cette base reste possible, seule les SELECT, INSERT, ... sont bloqués.
De plus, je suis obligé de mapper cette connexion à toutes les BDD existantes pour que le SGBDR y créé un utilisateur, pour qu'ensuite je lui retire ces droits, je trouve sa pas terrible du tout, je voudrais mapper ma connexion SEULEMENT avec les bases autorisées, et que par défaut ce compte de connexion n'ai pas accès aux autres BDD présentent sur le serveur.

Également, j'ai éssayé de gérer plus finement ces privilèges au niveau des tables en utilisant les commandes GRANT et REVOKE mais lorsque je fait un :

Code :

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

REVOKE SELECT ON ComptesBancaires FROM MonUtilisateur

Ben la commande SELECT passe quand même sur ma table CompteBancaires :/
Quand je vais dans les propriétés de mon utilisateur mappé à ma connexion, dans la rubrique Éléments Sécurisables, je ne vois que les tables pour lesquelles j'ai éffectué une commande GRANT, mes commandes REVOKE semblent ne pas passer... Je pourrais régler sa à la main mais à terme je souhaite totalement scripter la création des bdd, des utilisateurs et leurs privilèges.

Je précise que je suis en phase de test et d'apprentissage !

[aieeeuuuuu]

Bonjour,

Êtes-vous passé par des commandes ou par les interfaces graphiques de SSMS pour créer vos connexions et utilisateurs, et pour attribuer les privilèges (lorsqu'on ne connait pas bien, SSMS peut faire plus que l'on ne croit lors de la création de comptes) ?

Par ailleurs, un précision sur REVOKE: cela n'interdit pas l'action, mais retire le privilège, s'il a été accordé.

Par exemple

Code :

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

1
2
 
GRANT SELECT ON dbo.UneTable TO toto

==> toto obtiens le privilège SELECT sur la table UneTable (qui se trouve dans le schéma dbo)

Code :

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

1
2
 
GRANT SELECT ON schema::dbo TO toto

==> toto obtiens le privilège SELECT sur le schéma dbo (et donc sur tous les objet qu'il contient)

puis :

Code :

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

1
2
 
REVOKE SELECT ON dbo.UneTable TO toto

Cela retire le privilège explicitement accordé au début, néanmoins, toto peut toujours effectuer un SELECT sur dbo.UneTable, car il a toujours le privilège sur le schéma dbo

pour interdire une action, c'est plutôt DENY qu'il faudrait utiliser

[StripMat]

Et bien en fait j'ai d'abord essayé de gérer tout sa via SSMS mais comme je devrais ensuite scripter certaines actions, il est impératif que j'en comprenne le sens, donc j'éssai de gérer tout sa via des commandes SQL.

Merci pour ces précisions concernant l'ajout/suppression de privilèges, j'y vois plus claire.

Il y a une chose que j'éssai et qui semble impossible à réaliser, seulement mes sources sont anglophones et j'ai peur d'avoir mal compris.

J'éssai de faire en sorte qu'un utilisateur n'ai accès qu'a certaines bases de données, et qui plus est, qu'il ne voit aucune des autres bases présentes sur mon instance !

J'ai éssayé cela :

Code :

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

DENY VIEW ANY DATABASE TO <Login>

Sa fonctionne, mais apparement, il serait impossible de réattribuer ce droit pour une ou plusieurs bases !?

Une solution que j'ai trouvé sur le net :

Code :

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

1
2
3
4
5
6
7
USE <customersdatabase>
 
ALTER AUTHORIZATION ON DATABASE::<customerdatabase> to <customerlogin>
 
USE MASTER
 
DENY VIEW ANY DATABASE TO <customerlogin>

Sa fonctionne également mais pas pour plusieurs logins, vu qu'il ne peut y avoir qu'un seul dbo par base :/

J'ai lu également que le rôle public accorde à tous ses membres la possibilité de voir et avoir accès à toutes les bases de l'instance, et si je lui retirais ce privilège ?

[SQLpro]

Là vous faites du grand n'importe quoi....

Commencez par lire ceci afin de comprendre la stratégie de sécurité de SQL Server :
http://blog.developpez.com/sqlpro/p7..._et_utilisateu

1) un compte de connexion n'a accès à rien et ne peut rien faire lors de sa création. Il ne pourra faire quelque chose que si :
1.1 - vous attribuez des privilèges de niveau serveur au compte de connexion, auquel cas il pourra faire des opérations de niveau serveur (par exemple créer une base)
1.2 - créer un utilisateur SQL dans chacune des bases ou vous voulez qu'il puisse travailler et lier chaque utilisateur SQL de chacune des bases à ce compte de connexion
1.3 - attribuer à l'utilisateur SQL des privilèges particuliers dans chacune des bases dans laquelle il existe.

2) revoke sert à révoquer (comme son nom l'indique) qu'un privilège précédemment attribué

3) vous devriez suivre un cours d'admin, parce que sanqs cela vous allez faire une usine à gaz indémerdable !

A +