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

Question

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

Я знаю, что для 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, как использование хранимой процедуры обеспечивает дополнительную безопасность или управление безопасностью?

Answer 1

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

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

Answer 2

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

UPDATE Person.Address SET AddressLine1 = NULL

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

IF @IsFeedbackDefined is Null or @IsFeedbackDefined = false 
Begin
    Return -2   --can not submit feedback
End

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

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

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

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