web-dev-qa-db-fra.com

Accordez l'autorisation SELECT sur une vue, mais pas sur les objets sous-jacents

Je lis souvent qu'un des objectifs d'une VUE est la sécurité: permettre à certains utilisateurs d'accéder à la table sous-jacente, et à d'autres utilisateurs de n'utiliser qu'une vue dérivée. Dans cet esprit, j'ai conçu plusieurs vues qui fournissent des ensembles de données restreints aux utilisateurs externes.

Tout va bien, mais dans la pratique, cela ne fonctionne pas. Après avoir accordé SELECT l'autorisation sur une vue, les utilisateurs ne peuvent y accéder que si j'accorde également SELECT sur tous les objets sous-jacents. Même histoire pour les procédures stockées. Le résultat net est non fonctionnel, car je finis toujours par accorder l'accès à des données sensibles aux mauvais utilisateurs, ainsi que gênant, car il est facile d'oublier un objet et les utilisateurs reviennent pour se plaindre que la vue "ne travail".

Existe-t-il un moyen d'accorder des autorisations SELECT sur une vue ou une procédure stockée sans avoir à exposer également les objets sous-jacents?

sqlsecuritytsqlsql-server-2008
24
thomaspaulb

Le même utilisateur propriétaire de la vue possède-t-il également les tables sous-jacentes? Si ce n'est pas le cas, le propriétaire des tables doit accorder au propriétaire de la vue l'autorisation WITH GRANT OPTION. Si le même utilisateur possède à la fois les tables et la vue, l'octroi d'une autorisation sur la vue devrait être suffisant.

22
Graeme Perrow

Si vous avez vos vues dans un schéma différent de la table, vous devez soit accorder à l'utilisateur l'accès à la table de base, "AUTORISER" le propriétaire des tables à la vue comme ceci:

ALTER AUTHORIZATION ON reporting.MyViewName TO dbo

Dans l'exemple ci-dessus dbo est l'utilisateur propriétaire des tables reporting.MyViewName accède

3
uTILLIty

Vous pourriez trouver les informations dans ce forum utiles.

Le dernier message contient les détails de ce qui a été exécuté pour accorder des autorisations à une vue, mais pas les tables sous-jacentes:

CREATE USER [Reports] FOR LOGIN [Reports] WITH DEFAULT_SCHEMA = Reports
CREATE SCHEMA Reports AUTHORIZATION Reports --Auth as Reports was the key piece of information that I had missed.
GO
CREATE ROLE Reporting AUTHORIZATION db_securityadmin
GO
exec sp_addrolemember @rolename = 'Reporting', @membername = 'Reports'
GO
GRANT CREATE VIEW TO Reporting
GRANT CREATE TABLE TO Reporting

GRANT SELECT, VIEW DEFINITION ON [dbo].[zName] TO Reporting;

Pour info - Pour les procédures stockées, vous devez accorder EXEC à la procédure.

2
NotMe