Discussion :

[habibdu70]

Bonjour,

J'aimerais savoir comment gérer les droits au niveau des informations d'une table sans utiliser les views ?

Par exemple une table Personn contenant ID, Nom, Prenom, Age.

Si un user1 (du groupe A) réalise un select *, toutes les informations lui seront retournée.

mais si un user2 (du groupe B) réalise la même opération, les informations retourné seront : ID, Nom, Prénon, (par exemple)

C'est donc le fait d'implémenter une sécurité sur la colonne age. (Et sans utiliser les views, et uniquement pour des select (pas de CRUD).).

merci d'avance.

[habibdu70]

J'ai vue que l'on pouvais utiliser cette commande TSQL :
GRANT SELECT ON dbo.Employee (EmployeeID, FirstName, MiddleName, SurName) TO HR_Intern;

Qui va donner accès, au rôle HR_Intern, au colonne cités entre parenthèse de la table Employee.

Mais lorsque, en tant que user appartement à HR_Intern, je réalise cette commande : select * from Employee.

Je vais avoir une erreur, est-ce possible de générer à la place uniquement les valeur auquels ont à le droits ?

merci

[elsuket]

Bonjour,

Il n'est pas possible de filtrer les données exposées à un utilisateur (ou par extension à un rôle de base de données) avec les instructions de base d'octroi de privilèges.

La seule façon de faire est celle que vous avez donnée : créer une vue, et octroyer le droit SELECT sur celle-ci aux utilisateurs ou rôles nécessaires.

Mais lorsque, en tant que user appartement à HR_Intern, je réalise cette commande : select * from Employee.

Je vais avoir une erreur

Laquelle / Pourquoi ?

@++

[habibdu70]

Bonjour,

merci pour votre réponse, mais comme dit sur ce site :
http://www.mssqltips.com/sqlserverti...ions/#comments

On va avoir une erreur du type :
Msg 230, Level 14, State 1, Line 2
The SELECT permission was denied on the column 'SSN' of the
object 'Employee", database 'MSSQLTips', schema 'dbo'.

Moi je préférerais qu'il m'affiche toutes les colonnes dont j'ai accès, de cette manière je pourrais faire un select *, au lieu de spécifier toutes les colonnes.

[elsuket]

Pardonnez-moi, j'ai cru que vous vouliez filtrer les lignes et non pas les colonnes.

Je ne crois malheureusement pas possible de pouvoir abstraire les colonnes retournées suivant l'utilisateur sans vues, autrement qu'en le programmant avec des procédures stockées qui génèrent du code suivant l'utilisateur qui l'exécute (ce qui est très gore).

Pourquoi ne créez vous pas des vues, et vous autorisez tel utilisateur à consulter ces vues ?
D'autre part si vous souhaitez ajouter ou supprimer une colonne à la visibilité d'un utilisateur, il suffit de modifier la vue, ce qui est plus simple que de changer des droits.

En quoi l'étoile est un problème ?

@++

[mikedavem]

J'ai vue que l'on pouvais utiliser cette commande TSQL :
GRANT SELECT ON dbo.Employee (EmployeeID, FirstName, MiddleName, SurName) TO HR_Intern;

Qui va donner accès, au rôle HR_Intern, au colonne cités entre parenthèse de la table Employee.

Mais lorsque, en tant que user appartement à HR_Intern, je réalise cette commande : select * from Employee.

Je vais avoir une erreur, est-ce possible de générer à la place uniquement les valeur auquels ont à le droits ?

merci

Non ce n'est pas possible de faire cela. Il faudra préciser les colonnes dans le SELECT ou utiliser une vue qui est de loin la meilleure solution.

++

[SQLpro]

De toute façon il est parfaitement stupide de ne pas utiliser les vues. Cela ne peut que vous conduire à terme à des problématiques d'évolution du modèle.

A +

[JLCantara]

Bonjour Elsuket,

Rien de stupide (encore une insulte) à ne pas vouloir utiliser les views puisque ça ne peut mener qu'à une cacophonie!!!

Ton problème est simple mais je n'ai que des conseils généraux à te donner: trouve un bon volume traitant de la sécurité sur SQL. Tu pourras alors, comme sur un serveur, créer des groupes d'utilisateurs et bien sûr les utilisateurs. Ensuite, tu n'a qu'à utiliser ces 'objets' pour contrôler tout ce que tu veux et plus encore i.e. visibilité, R/W, etc.

P.S. - Je dis 'un bon volume' car cet aspect de SQL est très souvent mal expliqué (comme dans le mien).

Bonne lecture,
JLCantara.

[JLCantara]

Bonjour Elsuket,

Tu as certainement compris que je m'était trompé de destinataire...

Bonne journée,
JLCantara.

[elsuket]

Oui, pas de problème

@++

[mikedavem]

Tu as certainement compris que je m'était trompé de destinataire...

Bonne journée,
JLCantara.

Non mais il est méchant aussi Elsuket ... tu ne peux pas imaginer

++

[elsuket]

C'est sui qui le dit qu'il est ... nananèreuh

@++

[azur668]

Rien de stupide (encore une insulte) à ne pas vouloir utiliser les views puisque ça ne peut mener qu'à une cacophonie!!!

Pourquoi une cacophonie ?

[habibdu70]

OK super merci les gars, ça marche pour moi.

Effectivement, je suis passé par les views finalement.

merci

[JLCantara]

Pourquoi une cacophonie ?

Bonjour Azur - ici le ciel sidéral est comme le ciel politique: gris,

Sans préjudice pour le joyeux luron qui posait le problème, l'utilisation de formulaire pour gérer les accès est une solution qui ne peut avoir d'avenir. Prenons comme exemple la dernière usine (DomFer) pour laquelle j'ai travaillé: fonctionnement 7 j/s, 24 hres/jr, 85 employés qui ont presque tous accès au système. La BD comportait approx. 700 formulaires: est-il nécessaire de continuer???

SQL Server met à la disposition de l'administrateur de la BD, un 'package' identique à celui du serveur (quel qu'il soit). Alors, pourquoi ne pas créer des groupes puis les peupler d'utilisateurs??? Dès lors, on n'a qu'a créer les permissions de groupes et l'affaire est réglée.

Seulement voilà: moi, le joyeux luron, je ne suis pas un 'expert' et je veux que ça marche au plus sacrant...

J'ai travaillé dans l'informatique de service, ce qui m'a amené à créer/adapter plus de 100 BD avec, au total plus de 50,000 tables. La vie m'a appris qu'un problème simple entraîne la solution la plus générale possible, pas la solution la plus simple, car elle repose nécessairement sur une analyse évolutive de la solution.

Tout cela peut sembler bien théorique mais c'est un placement à long terme: une BD et son utilisation, n'est pas la mer Morte: ça vit, ça évolue... De toute façon. un maximum de contrainte devrait toujours être pelleté en haut pas en bas.

Bonne réflexion,
JLCantara.

[azur668]

l'utilisation de formulaire pour gérer les accès est une solution qui ne peut avoir d'avenir.

Alors, pourquoi ne pas créer des groupes puis les peupler d'utilisateurs??? Dès lors, on n'a qu'a créer les permissions de groupes et l'affaire est réglée.

J'ai peut-être zappé quelque chose, mais je demandait juste pourquoi l'utilisation des vues menait à une cacophonie...

[JLCantara]

J'ai peut-être zappé quelque chose, mais je demandait juste pourquoi l'utilisation des vues menait à une cacophonie...

Bonjour Azur,

La question n'est pas de dire que l'utilisation de formulaires mène à une cacophonie mais leur utilisation pour géré les privilèges d'accès mène à de grandes difficultés d'entretien.

À ce sujet, je te suggère l'article de Pierre Caboche 'SQL Server - Introduction à la Gestion des Droits'. Tu constateras qu'il dit la même chose, mais évidemment, ça demande un peu plus de travail...

Bonne lecture,
JLCantara.