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

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

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

Ответ 1

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

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

Ответ 2

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

UPDATE Person.Address SET AddressLine1 = NULL

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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