¿Cómo permitir ejecutar procedimientos almacenados pero no escrituras?

Me gustaría configurar un usuario "lector" en mi instancia de SQL Server 2012. Me gustaría otorgarle el derecho de ejecutar cualquier procedimiento almacenado, función o instrucción SQL directa, que recupere datos de todas las tablas y vistas, pero no actualizar o insertar (es decir, leer cualquier cosa y no escribir nada).

¿Puedo configurar esto sin dar específicamente derechos a cada función o procedimiento almacenado por nombre, sino más bien otorgarle el derecho de ejecución en cualquier función o procedimiento almacenado, simplemente quitando el derecho de modificar tablas?

¿Cambiará algo si ejecuto SQL Server 2008 en su lugar?

Aclaraciones y adiciones:

Si un procedimiento almacenado cambia datos, el usuario debe recibir un mensaje de error (ya sea negando la modificación o rechazando el acceso al procedimiento almacenado por completo).
Si una posible solución implica negar permisos, ¿no puedo otorgar ciertos permisos en lugar de negarlos?
¿Se puede aplicar una denegación en todas las tablas, vistas, etc. (existentes ahora y en el futuro) en la base de datos en una sola declaración?

— gt6989b
fuente

Soy nuevo aquí, no dude en etiquetas Conjunto según proceda, y de otro modo para editar la pregunta

— gt6989b

@KrisGruttemeyer ese era el pensamiento: podía ejecutarlo pero daría lugar a un error de algún tipo; alternativamente, estoy bien con él no se les permite ejecutarlo, siempre y cuando no tengo para especificar una lista de SP que tiene privilegios para ejecutar

— gt6989b

En ese caso, debe leer sobre los permisos de SQL Server. Hay 3 variantes de permisos: GRANTotorgar permisos, DENYdenegar permisos y REVOKEeliminar un GRANTo DENY. Sin GRANTo DENYel usuario puede heredar permisos, digamos al obtener acceso a un procedimiento almacenado.

— JNK

@ gt6989b Si está DENY DELETE, INSERT, UPDATEen una base de datos o esquema, creo que solo afectará las tablas y las vistas.

— JNK

@ gt6989b - Solo notando que la respuesta sugerida en estos comentarios resultó ser incorrecta. Ver la respuesta de Paul White.

— RLF

Esto no es tan fácil de lograr como podría pensar. Una forma es crear una nueva función de base de datos definida por el usuario, otorgar todos los permisos necesarios para esa función y luego agregar usuarios a la nueva función. Esto al menos facilita dar a los usuarios (u otros roles definidos por el usuario) este conjunto de permisos en el futuro. Los siguientes pasos son un buen comienzo:

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

Después de esto, Bob tendrá amplios privilegios de solo lectura en la base de datos. Podrá leer de todas las tablas, vistas en esas tablas y funciones en línea. Sin embargo, no podrá ejecutar ningún procedimiento ni utilizar funciones no en línea.

Deberá otorgar permisos específicos al rol de Lectores para funciones y procedimientos seguros a los que desea que tengan acceso los Lectores. Puede haber pasos que puede seguir para facilitar este proceso (como agrupar objetos en un esquema y otorgar permiso de ejecución en el esquema en lugar de objetos individuales) pero hay demasiados detalles para cubrir aquí.

Una cosa a tener en cuenta es que la falta de privilegios de modificación de datos no evitaría que un lector cambie los datos a través de un procedimiento almacenado para el que se le ha otorgado permiso de ejecución, si el procedimiento y el objeto que se modifica comparten un propietario común. Tampoco se respetaría una negación explícita en este caso. Esta característica se conoce como encadenamiento de propiedad .

— Paul White 9
fuente