Come consentire l'esecuzione di stored procedure ma non le scritture?

Vorrei impostare un utente di "lettura" sulla mia istanza di SQL Server 2012. Vorrei concedergli il diritto di eseguire qualsiasi stored procedure, funzione o istruzione SQL diretta, che recupera i dati da tutte le tabelle e viste, ma non per aggiornare o inserire (ovvero leggere qualsiasi cosa e non scrivere nulla).

Posso configurarlo senza dare specificatamente i diritti a ciascuna funzione o procedura memorizzata per nome, ma piuttosto concedergli l'esecuzione su qualsiasi funzione o procedura memorizzata, togliendomi il diritto di modificare le tabelle?

Cambierà qualcosa se eseguo invece SQL Server 2008?

Chiarimenti e aggiunte:

Se una procedura memorizzata modifica i dati, l'utente dovrebbe ricevere un messaggio di errore (negando la modifica o rifiutando completamente l'accesso alla procedura memorizzata).
Se una potenziale soluzione prevede il rifiuto delle autorizzazioni, non posso semplicemente concedere determinate autorizzazioni invece di negare?
È possibile applicare un rifiuto su tutte le tabelle, viste, ecc. (Esistenti ora e in futuro) nel database in un'unica istruzione?

— gt6989b
fonte

Sono nuovo qui, non esitare a impostare i tag nel modo appropriato e altrimenti a modificare la domanda

— gt6989b

@KrisGruttemeyer era quello il pensiero: poteva eseguirlo ma avrebbe comportato un errore di qualche tipo; in alternativa sono d'accordo con il fatto che non gli sia permesso di eseguirlo, a condizione che non debba specificare un elenco di sp che ha i privilegi per eseguire

— gt6989b

In tal caso, è necessario leggere le autorizzazioni di SQL Server. Esistono 3 varianti di autorizzazione: GRANTconcedere autorizzazioni, DENYnegare autorizzazioni e REVOKErimuovere un GRANTo DENY. Senza un GRANTo DENYl'utente può ereditare le autorizzazioni, ad esempio ottenere l'accesso a una procedura memorizzata.

— JNK,

@ gt6989b Se sei DENY DELETE, INSERT, UPDATEsu un database o uno schema, credo che influenzerà solo le tabelle e le viste.

— JNK,

@ gt6989b - Solo notando che la risposta suggerita in questi commenti si è rivelata errata. Vedi la risposta di Paul White.

— RLF,

Questo non è facile da ottenere come potresti pensare. Un modo è creare un nuovo ruolo di database definito dall'utente, fornire tutte le autorizzazioni necessarie per quel ruolo, quindi aggiungere utenti al nuovo ruolo. Questo almeno rende più semplice assegnare agli utenti (o altri ruoli definiti dall'utente) questo insieme di autorizzazioni in futuro. I seguenti passaggi sono un buon inizio:

-- 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;

Successivamente, Bob avrà ampi privilegi di sola lettura nel database. Sarà in grado di leggere da tutte le tabelle, viste su quelle tabelle e funzioni in linea. Tuttavia, non sarà in grado di eseguire alcuna procedura o utilizzare funzioni non in linea.

Dovrai concedere autorizzazioni specifiche al ruolo Lettori per funzioni e procedure sicure a cui desideri che i Lettori abbiano accesso. Potrebbero essere necessari alcuni passaggi per semplificare questo processo (come il raggruppamento di oggetti in uno schema e la concessione dell'autorizzazione di esecuzione sullo schema anziché sui singoli oggetti), ma ci sono troppi dettagli da trattare qui.

Una cosa da tenere presente è che la mancanza di privilegi di modifica dei dati non impedirebbe a un Reader di modificare i dati tramite una procedura memorizzata su cui è stata concessa l'autorizzazione di esecuzione, se la procedura e l'oggetto che vengono modificati condividono un proprietario comune. Né un rifiuto esplicito sarebbe rispettato in questo caso. Questa funzione è nota come concatenamento della proprietà .

— Paul White 9
fonte