Пользователь предоставил доступ к хранимой процедуре, но не может выполнить запрос

Question

Я работаю над продуктом, который запускает SQL-сервер, который позволяет некоторым приложениям входить в систему, а их логинам предоставляется разрешение на запуск хранимой процедуры - И НИЧЕГО НЕ ЕЩЕ. Хранимая процедура принадлежит администратору; хранимая процедура берет запрос и выполняет его, затем результаты возвращаются в приложение.

К сожалению, я не могу понять, почему приложение может вызывать хранимую процедуру, к которой ему предоставлен доступ, но хранимая процедура не может выполнить инструкцию SQL, которая была передана в нее.

Хранимая процедура выполняет переданный запрос при входе в систему как администратор, но когда я вхожу в систему как ограниченный пользователь, он выдает исключение в инструкции execute.

Например:

EXEC [Admin].[STORED_PROC] @SQL_STATEMENT = 'SELECT * FROM table_x' 

STORED_PROC выглядит примерно так:

BEGIN TRY 
    EXEC (@SQL_STATEMENT) 
END TRY 
BEGIN CATCH 
    -- some logging when an exception is caught, and the exception is caught here!!! 
END CATCH 

Там нет ничего внутри заявлении попытка поймать за исключением того, что EXEC ... и sql_statement работает, когда я m зарегистрирован как Admin, но не тогда, когда я вошел в систему как Пользователь.

Может ли кто-нибудь помочь мне выяснить, какие разрешения мне необходимо установить, чтобы позволить Пользователю выполнять запросы только через хранимую процедуру?

---

Так был несколько комментариев о позволяя сырые операторы SQL, которые будут выполняться с помощью хранимой процедуры поражения цели с помощью хранимого прока ... но на самом деле то, что мы на самом деле делаем, мы пропускание зашифрованный SQL-запрос в хранимый proc, а сохраненный proc получает расшифрованный оператор и THEN он выполняет его.

Так что да, на самом деле необработанные SQL-запросы не являются безопасными, и они преследуют цель хранимых процессов, но я не знаю, как шифровать SQL-запросы, которые передаются через ODBC и запускаться с SQL Server до 2005 года.

В любом случае, я попытался установить некоторые минимальные меры предосторожности, чтобы иметь хотя бы базовую безопасность.

Answer 1

Поскольку вы используете динамический SQL, SQL-сервер не может сказать, какие таблицы вы используете, так что вы должны предоставить SELECT, права на все таблицы, а также

Answer 2

Пользователи также должны иметь ВЫБЕРИТЕ грант на столах

Answer 3

Предоставление необработанного SQL для передачи в хранимую процедуру, а затем выполнение - это сама суть отсутствия безопасности данных.

Безопасность SQL Server структурирована таким образом, что произвольные биты SQL выполняются в собственном контексте безопасности. Если у вас нет разрешения на запуск запроса ad hoc, у вас также нет разрешения запускать его через хранимую процедуру. В этом SQL Server избавляет вас от себя.

Answer 4

Поскольку ваша система разрешает доступ к сохраненным процессам и ничего больше (что хорошо для целей безопасности и не должно изменяться), вы просто не можете ни при каких обстоятельствах использовать динамический SQL, поскольку права не находятся на уровне таблицы, а ваши dbas вряд ли изменит это. Это не только предотвращает атаки SQL Injection, но и предотвращает возможное внутреннее мошенничество, поэтому любое рабочее место, которое считает это важным, не будет идти на компромисс, чтобы облегчить вам жизнь. Вам просто нужно перепроектировать, чтобы никогда не делать ничего динамически. У вас нет другого выбора.Если вы пишете procs, чтобы делать то, что хотите, в первую очередь, нет необходимости отправлять encypted sql.

Answer 5

Когда динамический SQL используется через EXEC или sp_executesql в пределах SP, разрешения EXEC на SP не позволяют запускать произвольный код в динамическом sql. Вам либо необходимо предоставить SELECT (yuck), либо вы можете олицетворять другого пользователя, используя EXECUTE AS или SETUSER.

При использовании обычного SQL EXEC разрешений работает нормально, переопределение недопустимо SELECT persmissions. Если у вас есть , тем не менее, я считаю, что это превосходит его.

Сказав это, я все еще не уверен, что вы должны использовать EXECUTE AS, когда источником SQL является за пределами SP (или вне базы данных). Для генерации кода или динамического sql, который безопасен извне, EXECUTE AS может быть полезным инструментом

Answer 6

Это, скорее всего, из-за разных схем, т.е. пользователь, который входит в систему, не является частью схемы администратора, или, по крайней мере, я надеюсь, что нет.

Метод безопасности, который позволяет получить доступ к типу доступа, который вы хотите достичь, то есть разрешить доступ к объектам, принадлежащим одной и той же схеме, называется цепочкой прав собственности.

Этот принцип лучше не объясняется в сообщении.

Вот ссылка от Microsoft, которая объясняет концепцию.

http://msdn.microsoft.com/en-us/library/ms188676(SQL.90).aspx

Вот выдающаяся статья о безопасности, приводятся примеры и пошаговые, для цепочки владения, среди других методов.

http://www.sommarskog.se/grantperm.html

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

Cheers, John