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

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

Я знаю, что для SQL Server вы можете защитить таблицы и даже столбцы от операций CRUD.

Например:

 --// Logged in as 'sa'
 USE AdventureWorks;
 GRANT SELECT ON Person.Address(AddressID, AddressLine1) to Matt;
 GRANT UPDATE ON Person.Address(AddressLine1) to Matt;

 --// Logged in as 'Matt'
 SELECT * from Person.Address;                       --// Fail
 SELECT AddressID, AddressLine1 from Person.Address; --// Succeed
 UPDATE Person.Address SET AddressLine1 = '#____ 2700 Production Way' 
        WHERE AddressID = 497;                       --// Succeed

Учитывая, что вы можете защитить таблицы и даже столбцы от операций CRUD, как использование хранимой процедуры обеспечивает дополнительную безопасность или управление безопасностью?


person Matt Brunell    schedule 07.01.2009    source источник
comment
Вероятно, потому, что он эффективен в наиболее критическом типе безопасности, если вы являетесь dba, - он защищает базу данных от запросов, написанных программистами с использованием процедурного кода. (полушутя ...)   -  person dkretz    schedule 09.01.2009


Ответы (9)


Потому что, ограничивая весь доступ к этим сохраненным процессам, вы установили определенный интерфейс к базе данных, через который должен происходить весь доступ ... Поскольку у вас будет ОТКАЗАТЬ Прямые операции выбора, вставки, обновления и удаления для таблиц и представлений , никто не может напрямую писать sql собственного дизайна, который делает все, что он хочет ... Если вы хотите ограничить вставки в таблицу сотрудников, где сотрудник назначен более чем на три проекта, только для тех сотрудников, у которых оценка больше, чем 85 на тесте на квалификацию, то вы можете записать это ограничение в sproc SaveEmployee и заставить его генерировать исключение для любого клиентского кода, который пытается это сделать ...

Конечно, вы МОЖЕТЕ сделать то же самое, используя код на стороне клиента, но использование sProcs упрощает разработку и управление процессом, потому что все это в одном месте, и ВСЕ приложения, которые пытаются получить доступ к этой системе базы данных, ДОЛЖНЫ соответствовать любым ограничениям и / или меры безопасности, которые вы определяете в SProc ... Ни один мошеннический разработчик, пишущий новое отдельное клиентское приложение, которое попадает в базу данных, не может игнорировать или обходить ограничение или обеспечение безопасности в SProc, если этот SProc является ЕДИНСТВЕННЫМ СПОСОБОМ для вставки или обновления записывать...

person Charles Bretana    schedule 07.01.2009
comment
Это жульничество, а не румяна ... если только они не разрабатывают новую линию макияжа;) - person Tom H; 09.01.2009
comment
ха! Спасибо ... Я исправил орфографическую ошибку ... (Я из того возраста, когда нас не учили печатать ... и я так и не научился ... Так что я использую три пальца. И делаю много опечаток! ) - person Charles Bretana; 09.01.2009

Возможно, вы не захотите давать Мэтту карт-блан для непосредственного обновления определенных таблиц или столбцов. Что, если бы Мэтт решил сделать это:

UPDATE Person.Address SET AddressLine1 = NULL

Упс. Мэтт забыл предложение WHERE и просто обработал вашу базу данных. Или, может быть, Мэтт просто разозлился на своего босса и решил уйти в конце дня. Или, может быть, пароль Мэтта не так безопасен, как должен был быть, и теперь он есть у хакера.

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

person Tom H    schedule 07.01.2009
comment
Хм ... не уверен, действительно ли это для безопасности ... Защита вашей базы данных от ошибок разработчиков ... Резервное копирование? - person Peter Gfader; 27.01.2010
comment
Сценарии, описанные выше, можно использовать, например, для получения всех SSN или номеров кредитных карт из базы данных. Не говоря уже о том, что восстановление из резервных копий требует времени и денег, а также может вызвать простои вашего приложения. - person Tom H; 27.01.2010

Хранимые процедуры обеспечивают дополнительную безопасность, позволяя пользователям выполнять операции CRUD (вставка, обновление, удаление), но только ограниченным образом. Например, разрешить пользователю Мэтту обновлять адреса одних строк, но не других.

Он позволяет добавлять проверки данных, чтобы убедиться, что вставленные данные являются действительными, а не случайным мусором. Для большинства вещей вы можете использовать ограничения и / или триггеры, чтобы выполнить часть этой работы, но есть ограничения. Хранимые процедуры повышают безопасность, гарантируя, что выполняемые операции разрешены пользователем.

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

person Thomas Jones-Low    schedule 07.01.2009

В SQL Server вам не нужно предоставлять прямой доступ к таблицам, если вы правильно используете сохраненные процедуры (что означает отсутствие динамического SQl). Это означает, что ваши пользователи могут делать только то, что определено процедурами. Если в вашей базе данных есть какие-либо финансовые данные или данные конфиденциального характера, только наименьшее возможное количество людей (обычно только dbas) должно иметь прямой доступ к таблицам. Это серьезно снижает риск мошенничества или недовольных сотрудников, которые уничтожат ваши критически важные данные, или сотрудников, которые украдут личную информацию для совершения кражи личных данных. С точки зрения бухгалтерского учета, это необходимый внутренний контроль, и удобство разработчика или личное желание делать все динамически из пользовательского интерфейса должны перекрываться небезопасностью данных. К сожалению, во многих компаниях это не так. Большинство разработчиков, похоже, беспокоятся только о внешних угрозах для своих данных, но внутренние часто гораздо более критичны.

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

person HLGEM    schedule 08.01.2009
comment
С точки зрения бухгалтерского учета это необходимый внутренний контроль, и удобство разработчика или личное желание делать все динамически из пользовательского интерфейса должны быть сведены на нет небезопасностью данных. К сожалению, во многих компаниях это не так. Большинство разработчиков, похоже, беспокоятся только о внешних угрозах для своих данных, но внутренние угрозы зачастую гораздо более критичны. Ага! - person Joshua Drake; 13.09.2016

В большинстве (всех?) СУБД вы можете «ПРЕДОСТАВИТЬ» доступ к определенным таблицам определенным пользователям. Хранимая процедура может запускаться от имени другого пользователя с более широким доступом. Но хранимая процедура - это не то же самое, что предоставление доступа ко всей таблице, скорее, она может сначала проверить некоторые вещи и вернуть только те строки, которые соответствуют вашим конкретным требованиям безопасности.

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

person Frank Flynn    schedule 07.01.2009

Хранимая процедура лучше, потому что безопасность хранимой процедуры (IIRC) будет важнее безопасности таблиц / столбцов.

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

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

person casperOne    schedule 07.01.2009

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

Обратите внимание, что мы говорим о «безопасности, контролируемой администратором баз данных», а не о сайте, системном администраторе или программном модуле, которые полезны и являются частью общей инфраструктуры безопасности.

person dkretz    schedule 08.01.2009

Первое преимущество, подробно обсуждаемое здесь, - это лучший контроль над разрешениями - пользователи могут быть ограничены определенными строками, а не только столбцом (что, кстати, чертовски важно для управления в большой системе); SP могут применять бизнес-логику и транзакционную логику; данные могут быть получены только в зависимости от других данных (например, соединения); обновления могут быть ограничены отдельными строками за раз; и Т. Д.

Во-вторых, это может обеспечить дополнительный уровень защиты от SQL-инъекции (хотя и не полный и не автоматический). Хотя это может быть нарушено из-за динамического SQL внутри SP или из-за неправильных вызовов конкатенации, SP действительно применяет типы параметров и многое другое, отделяя код от данных.

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

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

person AviD    schedule 08.01.2009

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

Например, у вас есть система обратной связи. Отзыв можно отправить только после того, как администратор запустил кампанию обратной связи. Это просто обновление флага в какой-то таблице. Затем, когда пользователь приходит, чтобы отправить отзыв, SP может проверить, установлен ли флаг.

Select @IsFeedbackDefined = IsFeedbackDefined From sometable where ID = @ID

IF @IsFeedbackDefined is Null or @IsFeedbackDefined = false 
Begin
    Return -2   --can not submit feedback
End
person Ken Yao    schedule 20.01.2009