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

Question

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

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

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

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

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

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

Наша окружающая среда:

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

Answer 1

Не делайте этого. Недавно у нас был опыт VERY BAD, когда «гуру базы данных» решил пойти в другую компанию. Содержание всей логики в процедурах просто ужасно!

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

Answer 2

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

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

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

Правильный дизайн, основанный на домене и домене, находится вне окна.

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

ИМХО:

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

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