Discussion :

[Alex70]

Bonjour,

Je cherche sur le forum est sur internet une réponse précise mais comme je ne trouve pas....

J'ai une application vb.net qui se connecte à un SQL server 2016 aucun problème tout fonctionne mais j'ai réalisé plusieurs tests.

Je fais une connexion TEST en rôle serveur public que j'ai mappé directement au rôle de ma base de données en public aussi.
=> Dans mon application je peux modifier mon mot de passe qui se trouve dans une table.
=> Sauf que je ne voudrais pas que cela soit possible (c'est un test), je voudrais qu'il ne soit possible avec cette connexion que la lecture des données.

J'ai donc modifié l'utilisateur au niveau de la base cette fois ci avec le rôle db_datareader.
=> La encore je peux passer une requête Update sur ma base...

Je suis un poil perplexe quand à la création des rôles, des utilisateurs, et des règles...

Je continue mes recherches mais si quelqu'un passe par ici

[SQLpro]

Bonjour,

Je cherche sur le forum est sur internet une réponse précise mais comme je ne trouve pas....

J'ai une application vb.net qui se connecte à un SQL server 2016 aucun problème tout fonctionne mais j'ai réalisé plusieurs tests.

Je fais une connexion TEST en rôle serveur public que j'ai mappé directement au rôle de ma base de données en public aussi.

Aucun intérêt ! Le rôle public étant par nature public, tout le monde y est par défaut sans qu'il soit nécessaire de faire quoi que ce soit.
À défaut, le rôle public n'a aucun privilège d'aucune sorte sur aucun objet.... Donc, TEST ne peut rien faire nulle part.
Et c'est généralement une très mauvaise idée de donner des privilèges au rôle public !

je vous invite à lire l'article que j'ai écrit sur la sécurité, car là vous faites visiblement n'importe quoi :
https://blog.developpez.com/sqlpro/p..._et_utilisateu

=> Dans mon application je peux modifier mon mot de passe qui se trouve dans une table.
=> Sauf que je ne voudrais pas que cela soit possible (c'est un test), je voudrais qu'il ne soit possible avec cette connexion que la lecture des données.

J'ai donc modifié l'utilisateur au niveau de la base cette fois ci avec le rôle db_datareader.
=> La encore je peux passer une requête Update sur ma base...

Je suis un poil perplexe quand à la création des rôles, des utilisateurs, et des règles...

Je continue mes recherches mais si quelqu'un passe par ici

Il faut que votre application se connecte au départ avec le bon compte de connexion et non pas avec sa...

reprenons depuis le début en supposant que votre base s’appelle MaBase :

1) création d'un compte pour se connecter au serveur :

Code :

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

1
2
3
4
5
6
USE master;
GO
CREATE LOGIN CNX_MaConnexionTest
   WITH PASSWORD = 'rantanplan',
        DEFAULT_DATABASE = maBase;
GO

Notez qu'il n'a aucun privilège ni aucun rôle, car c'est inutile dans votre cas...

2) création dans la base cible de l'utilisateur SQL correspondant au compte de connexion :

Code :

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

1
2
3
4
5
USE MaBase 
GO
CREATE USER USR_MaConnexionTest 
   FROM LOGIN CNX_MaConnexionTest;
GO

3) assignation du privilège de lecture sur la base entière à cet utilisateur :

Code :

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

1
2
3
4
USE MaBase 
GO
GRANT SELECT TO USR_MaConnexionTest;
GO

Maintenant votre application doit se connecter avec le compte CNX_MaConnexionTest et le mot de passe rantanplan.

A +

[Alex70]

Merci de votre retour !

Aucun intérêt ! Le rôle public étant par nature public, tout le monde y est par défaut sans qu'il soit nécessaire de faire quoi que ce soit.
À défaut, le rôle public n'a aucun privilège d'aucune sorte sur aucun objet.... Donc, TEST ne peut rien faire nulle part.
Et c'est généralement une très mauvaise idée de donner des privilèges au rôle public !

Ok ok...

J'ai suivi vos instructions donc, mais étonnant dans l'appartenance de l'utilisateur dans le SSMS il n'y a rien de coché.
=> Normal ?

Ps : j'ai lu votre article avant de poster et je peux vous assurer que n'étant ni architecte de données ni responsable des serveurs SQL il reste très vague pour un débutant.
Je me penche pour la première fois sur une question de sécurité sur un SQL Server, donc mes questions et actions peuvent être sans intérêt mais j'essaye de comprendre.

[Alex70]

Bonjour,

Merci pour ta solution, j'ai même réussi à mettre les droits d'update sur 1 champs dans une table grâce à ton article.

C'est résolu, je vais travailler sur ça de mon coté.

[SQLpro]

J'ai suivi vos instructions donc, mais étonnant dans l'appartenance de l'utilisateur dans le SSMS il n'y a rien de coché.
=> Normal ?

Si, si, il y a bien des choses de cochées mais la quantité de boite de dialogue à ouvrir pour voir ces coches rend la chose incompatible avec un cerveau normalement constitué alors qu'avec du code c'est évident (les IHM ont des limites !).

Ps : j'ai lu votre article avant de poster et je peux vous assurer que n'étant ni architecte de données ni responsable des serveurs SQL il reste très vague pour un débutant.
Je me penche pour la première fois sur une question de sécurité sur un SQL Server, donc mes questions et actions peuvent être sans intérêt mais j'essaye de comprendre.

Il aurait déjà fallut se former au langage SQL dont l'aspect sécurité est parfaitement définit. Mon livre sur SQL en parle dans un chapitre particulier :

La connaissance du SQL (et pas que du SELECT...) est une nécessité lorsque l'on veut travailler avec un SGBDR !

A +

[SQLpro]

Bonjour,

Merci pour ta solution, j'ai même réussi à mettre les droits d'update sur 1 champs dans une table grâce à ton article.

C'est résolu, je vais travailler sur ça de mon coté.

Pas de souci. C'est en général plus simple avec les commandes SQL !

A +