Accorder l'autorisation SELECT sur la vue, mais pas sur les objets sous-jacents

J'ai souvent lu que l'un des buts de VUE, c'est la sécurité: afin de permettre à certains utilisateurs d'accéder à la table sous-jacente, et d'autres utilisateurs d'un dérivé de vue seulement. Avec cela à l'esprit, j'ai conçu plusieurs points de vue que l'offre limitée des jeux de données pour les utilisateurs externes.

Tous très bien, mais en pratique cela ne fonctionne pas. Après je vous l'accorde SELECT de la permission d'un point de vue, les utilisateurs ne peuvent pas y accéder, à moins que j'accorde SELECT sur tous les objets sous-jacents trop. Même histoire pour les procédures stockées. Le résultat net est non-fonctionnel, pour que je me retrouve encore l'octroi de l'accès à des données sensibles à la mauvaise utilisateurs, ainsi que gênant, car il est facile d'oublier un objet et les utilisateurs de revenir pour se plaindre que le point de vue "ne fonctionne pas".

Est-il un moyen de subvention SELECT autorisations sur une vue ou d'une procédure stockée sans avoir à exposer les objets sous-jacents trop?

InformationsquelleAutor thomaspaulb | 2010-11-09
  1. 22

    Le même utilisateur qui est propriétaire de la vue aussi propre, les tables sous-jacentes? Si non, le propriétaire des tables doit accorder la vue titulaire de l'autorisation with GRANT OPTION. Si le même utilisateur possède à la fois les tables et la vue, puis l'octroi de l'autorisation sur la vue doit être suffisante.

    • Ah, maintenant je comprends ce qu'il se passe. J'ai deux bases de données, et les problèmes ne surviennent que si je intégrer des références à l'autre de la base de données dans une vue définie dans une base de données. Il a à voir avec la propriété.
    • Par l'octroi de SUBVENTION, mais quand les propriétaires sont différents, nous donner des autorisations de faire plus que simplement sélectionner - est-ce la seule façon de l'obtenir pour fonctionner dans de telles situations (sans l'octroi de l'accès aux objets sous-jacents)?
    InformationsquelleAutor Graeme Perrow
  2. 3

    Si vous avez votre point de vue à un autre schéma que celui de la table, vous devez accorder à l'utilisateur d'accéder à la table de base, "AUTORISER" le propriétaire des tables, afin de l'afficher comme ceci:

    ALTER AUTHORIZATION ON reporting.MyViewName TO dbo

    Dans l'exemple ci-dessus dbo est l'utilisateur possédant les tables de la reporting.MyViewName est l'accès

    InformationsquelleAutor uTILLIty
  3. 2

    Vous pouvez trouver les informations dans ce forum utile.

    Le dernier post a les détails de ce qui a été exécuté pour accorder des autorisations à un point de 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;

    FYI - Pour les procédures stockées, vous devriez être à l'octroi de l'EXEC de la procédure.

    InformationsquelleAutor NotMe