Como permitir executar procedimentos armazenados, mas não gravações?

Gostaria de configurar um usuário de "leitura" na minha instância do SQL Server 2012. Eu gostaria de permitir a ele o direito de executar qualquer procedimento armazenado, função ou instrução SQL direta, que recupera dados de todas as tabelas e visualizações, mas não para atualizar ou inserir (ou seja, ler qualquer coisa e escrever nada).

Posso configurar isso sem conceder direitos especificamente a cada função ou procedimento armazenado pelo nome, mas conceder a ele a execução correta em qualquer função ou procedimento armazenado, apenas retirando o direito de modificar tabelas?

Alguma coisa mudará se eu executar o SQL Server 2008?

Esclarecimentos e acréscimos:

Se um procedimento armazenado alterar os dados, o usuário receberá uma mensagem de erro (negando a modificação ou recusando completamente o acesso ao procedimento armazenado).
Se uma solução em potencial envolve negar permissões, não posso conceder determinadas permissões em vez de negar?
Uma negação pode ser aplicada a todas as tabelas, visualizações etc. (existentes agora e no futuro) no banco de dados em uma instrução?

— gt6989b
fonte

Eu sou novo aqui, não hesite em etiquetas Definir como apropriado e de outra forma para editar a pergunta

— gt6989b

@KrisGruttemeyer, esse era o pensamento - ele poderia executá-lo, mas isso resultaria em algum tipo de erro; alternativamente, eu estou ok com ele não sendo permitido para executá-lo, contanto que eu não tenho para especificar uma lista de sp é que ele tem privilégios para executar

— gt6989b

Nesse caso, você precisa ler sobre as permissões do SQL Server. Existem três variantes de permissão - GRANTpara conceder permissões, DENYnegar permissões e REVOKEremover um GRANTou DENY. Sem um GRANTou DENYo usuário pode herdar permissões, digamos, obtendo acesso a um procedimento armazenado.

— JNK

@ gt6989b Se você estiver DENY DELETE, INSERT, UPDATEem um banco de dados ou esquema, acredito que isso afetará apenas tabelas e visualizações.

— JNK

@ gt6989b - Apenas observe que a resposta sugerida nesses comentários acabou incorreta. Veja a resposta de Paul White.

— RLF

Isso não é tão fácil de conseguir quanto você imagina. Uma maneira é criar uma nova função de banco de dados definida pelo usuário, conceder todas as permissões necessárias para essa função e adicionar usuários à nova função. Isso facilita, pelo menos, conceder aos usuários (ou outras funções definidas pelo usuário) esse conjunto de permissões no futuro. Os seguintes passos são um bom começo:

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

Depois disso, Bob terá amplos privilégios somente leitura no banco de dados. Ele poderá ler todas as tabelas, visualizações nessas tabelas e funções em linha. No entanto, ele não poderá executar nenhum procedimento ou usar funções não em linha.

Você precisará conceder permissões específicas à função Leitores para funções e procedimentos seguros aos quais deseja que os Leitores tenham acesso. Pode haver etapas que você pode seguir para facilitar esse processo (como agrupar objetos em um esquema e conceder permissão de execução no esquema em vez de objetos individuais), mas há muitos detalhes para serem abordados aqui.

Uma coisa a ter em atenção é que a falta de privilégios de modificação de dados não impediria o Reader de alterar os dados por meio de um procedimento armazenado no qual ele recebeu permissão de execução, se o procedimento e o objeto que estiver sendo modificado compartilharem um proprietário comum. Nem uma negação explícita seria respeitada neste caso. Esse recurso é conhecido como encadeamento de propriedade .

— Paul White 9
fonte