web-dev-qa-db-fra.com

Comment permettre d'exécuter des procédures stockées mais pas d'écrire?

Je souhaite configurer un utilisateur "en lecture" sur mon instance SQL Server 2012. Je voudrais lui donner le droit d'exécuter toute procédure stockée, ou fonction, ou instruction SQL directe, qui récupère les données de toutes les tables et vues, mais pas de mettre à jour ou d'insérer (c'est-à-dire de lire quoi que ce soit et d'écrire rien).

Puis-je configurer cela sans donner spécifiquement des droits à chaque fonction ou procédure stockée par nom, mais plutôt lui accorder le droit d'exécution sur n'importe quelle fonction ou procédure stockée, en lui retirant simplement le droit de modifier les tables?

Est-ce que quelque chose changera si j'exécute SQL Server 2008 à la place?

Clarifications et ajouts:

  1. Si une procédure stockée modifie des données, l'utilisateur devrait recevoir un message d'erreur (soit refusant la modification, soit refusant complètement l'accès à la procédure stockée).
  2. Si une solution potentielle implique de refuser des autorisations, puis-je simplement ne pas accorder certaines autorisations au lieu de les refuser?
  3. Un refus peut-il être appliqué à toutes les tables, vues, etc. (existantes maintenant et à l'avenir) dans la base de données en une seule instruction?
sql-serversql-server-2008sql-server-2012permissions
11
gt6989b

Ce n'est pas aussi facile à réaliser que vous ne le pensez. Une façon consiste à créer un nouveau rôle de base de données défini par l'utilisateur, à accorder toutes les autorisations nécessaires à ce rôle, puis à ajouter des utilisateurs au nouveau rôle. Cela facilite au moins l'octroi aux utilisateurs (ou à d'autres rôles définis par l'utilisateur) de cet ensemble d'autorisations à l'avenir. Les étapes suivantes sont un bon début:

-- The user-defined role containing all required permissions
CREATE ROLE Readers AUTHORIZATION dbo;

-- Give read-only access to all tables,
-- views on those tables, and in-line
-- functions
ALTER ROLE db_datareader ADD MEMBER Readers;

-- Example: add a user (Bob) to the role
ALTER ROLE Readers ADD MEMBER Bob;

Après cela, Bob aura de larges privilèges en lecture seule dans la base de données. Il pourra lire à partir de toutes les tables, les vues sur ces tables et les fonctions en ligne. Cependant, il ne pourra exécuter aucune procédure ni utiliser de fonctions non intégrées.

Vous devrez accorder des autorisations spécifiques au rôle Lecteurs pour les fonctions et procédures sécurisées auxquelles vous souhaitez que les lecteurs aient accès. Il peut y avoir des étapes que vous pouvez suivre pour faciliter ce processus (comme le regroupement d'objets dans un schéma et l'octroi d'une autorisation d'exécution sur le schéma au lieu d'objets individuels), mais il y a trop de détails à couvrir ici.

Une chose à savoir est que le manque de privilèges de modification des données n'empêcherait pas un lecteur de modifier les données via une procédure stockée sur laquelle il a été autorisé à exécuter, si la procédure et l'objet en cours de modification partagent un propriétaire commun. Un refus explicite ne serait pas non plus respecté en l'espèce. Cette fonctionnalité est connue sous le nom de Chaîne de propriété .

15
Paul White 9