Как разрешить выполнять хранимые процедуры, а не писать?

Я хотел бы настроить «читающего» пользователя на моем экземпляре SQL Server 2012. Я хотел бы предоставить ему право на выполнение любой хранимой процедуры, или функции, или прямого оператора SQL, который извлекает данные из всех таблиц и представлений, но не обновляет и не вставляет (т.е. читает что-либо и ничего не пишет).

Могу ли я установить это, не предоставляя конкретных прав для каждой функции или хранимой процедуры по имени, а предоставив ему право на выполнение любой функции или хранимой процедуры, просто забрав право изменять таблицы?

Изменится ли что-нибудь, если я вместо этого запущу SQL Server 2008?

Разъяснения и дополнения:

Если хранимая процедура изменяет данные, пользователь должен получить сообщение об ошибке (либо отказать в модификации, либо полностью отказаться от доступа к хранимой процедуре).
Если потенциальное решение предполагает отказ в разрешениях, могу ли я просто не предоставлять определенные разрешения вместо отказа?
Можно ли применить deny ко всем таблицам, представлениям и т. Д. (Существующим сейчас и в будущем) в базе данных одним оператором?

— gt6989b
источник

Я новичок здесь, пожалуйста, не стесняйтесь устанавливать теги соответствующим образом и в противном случае редактировать вопрос

— gt6989b

@KrisGruttemeyer это была мысль - он мог выполнить это, но это привело бы к некоторой ошибке; в качестве альтернативы, я согласен с тем, что ему не разрешено его выполнять, если мне не нужно указывать список sp, у которых есть права на запуск

— gt6989b

В этом случае вам нужно прочитать о разрешениях SQL Server. Существует 3 варианта разрешений - GRANTдля предоставления разрешений, DENYдля отклонения разрешений и REVOKEдля удаления GRANTили DENY. Без GRANTили DENYпользователь может наследовать разрешения, скажем, от получения доступа к хранимой процедуре.

— JNK

@ gt6989b Если вы DENY DELETE, INSERT, UPDATEиспользуете базу данных или схему, я считаю, что это повлияет только на таблицы и представления.

— JNK

@ gt6989b - Просто отметьте, что предлагаемый ответ в этих комментариях оказался неверным. Смотрите ответ Пола Уайта.

— RLF

Это не так легко достичь, как вы думаете. Одним из способов является создание новой пользовательской роли базы данных, предоставление всех разрешений, необходимых для этой роли, а затем добавление пользователей в новую роль. Это, по крайней мере, упрощает предоставление пользователям (или другим пользовательским ролям) этого набора разрешений в будущем. Следующие шаги являются хорошим началом:

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

После этого Боб будет иметь широкие права только для чтения в базе данных. Он сможет читать из всех таблиц, просмотров этих таблиц и встроенных функций. Однако он не сможет выполнять какие-либо процедуры или использовать не встроенные функции.

Вам нужно будет предоставить специальные разрешения роли «Читатели» для безопасных функций и процедур, к которым вы хотите, чтобы читатели имели доступ. Могут быть предприняты шаги, чтобы упростить этот процесс (например, группирование объектов в схему и предоставление разрешения на выполнение схемы вместо отдельных объектов), но здесь слишком много деталей, чтобы охватить их.

Следует помнить, что отсутствие привилегий на изменение данных не помешало бы Читателю изменять данные с помощью хранимой процедуры, на которую было предоставлено разрешение на выполнение, если изменяемая процедура и объект имеют общего владельца. В этом случае также не будет соблюдаться явное отрицание. Эта функция называется цепочкой владения .

— Пол Уайт 9
источник