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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Решающего преимущества в любом направлении нет (как вы сказали, прирост производительности минимален), единственное, о чем следует помнить, это принцип DRY (Don't Повторяйтесь):не переопределяйте функциональность дважды (в коде и в БД), потому что синхронизировать их будет кошмаром.Выберите одно решение и придерживайтесь его.

Answer 3

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

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

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

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

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

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

Answer 4

ИМХО:

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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