Использование представлений и триггеров для безопасности вместо хранимых процедур

Question

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

Другая идея состоит в том, чтобы покрыть всю базу данных представлениями - поэтому вряд ли у кого-то есть доступ к самим таблицам, они просто выполняют операции CRUD с представлениями. Таким образом, если вы хотите предоставить кому-то доступ к определенным столбцам, вы можете создать для них представление, содержащее эти столбцы, или просто вычисление. Если вам нужно навязать логику операциям обновления и удаления (то есть не допустить, чтобы кто-то влиял на более чем 2% всех строк в таблице), вы можете сделать это с помощью триггера instead of.

Чтобы не попасть в общие ловушки триггеров, (1) триггеры должны обновлять только таблицы, но не другие представления. (2) Триггеры никогда не ставятся на столы. (3) Представления не могут получить доступ к другим представлениям. (4) Если по какой-то причине вы не можете делать то, что хотите, следуя первым трем правилам, создайте хранимую процедуру.

Выгода, которую я вижу от реализации безопасности таким образом, заключается в том, что вам нужно только создать представление и, возможно, некоторые триггеры (средний случай - 2 дополнительных объекта), тогда как если вы идете по маршруту хранимой процедуры, вы всегда будете создавать как минимум 3 или 4 дополнительных объекта (в зависимости от того, создаете ли вы процедуры для выбора). Кроме того, наши сопоставления NHibernate были бы проще, потому что нам не нужно было бы отображать три процедуры для каждого объекта.

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

Answer 1

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

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

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

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

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

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

Answer 2

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