Должна ли безопасность данных выполняться на стороне базы данных?

Question

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

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

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

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

Прямо сейчас мы используем LINQ для нашей ORM. Он кажется легким и быстрым, но, что самое приятное, быстро развивается.

Стоит ли затраты на обслуживание на повышение производительности? Мы дурачим себя, думая, что будет даже заметный прирост производительности? Или мы просто делаем себе кошмар?

Наше окружение:

• Внутренние, не критически важные бизнес-приложения
• C # / ASP.NET 3.5
• Windows 2003
• MS SQL Server 2005
• 35 Веб-приложения среднего размера с примерно 500 пользователями

Answer 1

Не делай этого . Недавно у нас был ОЧЕНЬ ПЛОХОЙ опыт, когда "гуру баз данных" решил пойти в другую компанию. Поддержание всей логики в процедурах просто ужасно !!

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

Answer 2

К сожалению, нет «одного верного ответа». Выбор, который вы должны сделать, зависит от нескольких факторов, таких как:

• Знакомство команды с данными решениями (т. Е. Если большинству из них удобно писать SQL, оно может быть в базе данных, однако, если большинство из них более комфортно с C #, оно должно быть в коде)
• «Политическая власть» каждой партии
• и т.д.

Нет решающего преимущества ни в одном направлении (как вы сказали, прирост производительности минимален), следует помнить о принципе СУХОЙ (не повторяйте себя): не переопределяйте функциональность дважды (в код и в БД), потому что их синхронизация будет кошмаром. Выберите одно решение и придерживайтесь его.

Answer 3

ИМХО:

Уровень обслуживания приложения -> логика и проверка приложения
Уровень данных приложения -> логика данных и безопасность
База данных -> согласованность данных

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

Answer 4

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

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

Модульное тестирование гораздо сложнее, так как платформы, доступные для sprocs модульного тестирования, гораздо менее развиты.

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

И прирост производительности будет крошечным, если таковой будет. Мы говорили об этом здесь .

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

Answer 5

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

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

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

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

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

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

Answer 6

Все зависит от вашего случая, вероятно, лучше не идти по пути SP и делать все DDD (создать модель домена в коде и использовать это).

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

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

Answer 7

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

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

Answer 8

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