Самым большое преимущество безопасности, чтобы не использовать хранимые процедуры ясность. Вы точно знаете, что может сделать учетная запись, видя, какой доступ к имеющимся таблицам. При хранящихся процедурах это не обязательно. Если учетная запись имеет возможность выполнить процедуру X, это ограничивает учетную запись для ее выполнения и не ударяет по базовой таблице, но X может сделать что угодно. Он может отбрасывать таблицы, изменять данные, удалять данные и т. Д.
Чтобы узнать, что учетная запись может делать с хранимыми процедурами, вы должны посмотреть хранимую процедуру. Каждый раз, когда sproc обновляется, кто-то должен будет посмотреть, что он делает, чтобы убедиться, что что-то не попало «случайно» в него. Реальная проблема с безопасностью в sprocs происходит изнутри организации, а не от злоумышленников-изгоев.
Вот пример:
Допустим, вы пытаетесь ограничить доступ к таблице сотрудников. Без хранимых процедур вы просто запрещаете доступ к таблице. Чтобы получить доступ, кто-то в значительной степени должен явно просить вас предоставить разрешения. Конечно, они могут заставить вас запустить сценарий для предоставления доступа, но большинство людей по крайней мере пытаются просмотреть сценарий, который изменяет схему базы данных (при условии, что скрипт не обновляет sproc, о чем я расскажу ниже).
Существуют потенциально сотни хранимых процедур для приложения. По моему опыту, они обновляются довольно часто, добавьте сюда поле, удалите его. Для того, чтобы кто-то просматривал количество скриптов процедуры обновления, все время становится сложным, и в большинстве организаций команда базы данных начинает только быстро смотреть на процедуру (или не смотреть на все это) и перемещать ее. Здесь возникает реальная проблема. Теперь, в этом примере, если кто-то из ИТ-персонала хочет разрешить доступ к таблице, этот человек просто должен проскользнуть в строке кода, предоставляющей доступ или делая что-то еще. В идеальном мире это поймает. Большинство из нас не работают в совершенном мире.
Реальная проблема с хранимыми процедурами заключается в том, что они добавляют уровень обфускации в систему. С обфускацией приходит сложность, и со сложностью в конечном итоге становится больше работать, чтобы понять администрирование базовой системы. Большинство людей в ИТ перегружены работой, и все проскальзывает. В этом случае вы не пытаетесь атаковать систему, чтобы получить доступ, вы используете ответственного за систему, чтобы получить то, что вы хотите. Митник был прав, в безопасности люди - проблема.
Большинство нападений на организацию происходят изнутри. Каждый раз, когда вы вводите сложность в какую-либо систему, появляются дыры, вещи можно упускать из виду. Не верьте, подумайте о том, где вы работаете. Пройдите шаги, которые вы попросите получить доступ к системе. Довольно скоро вы понимаете, что вы можете заставить людей игнорировать вещи в нужный момент. Ключом к успешному проникновению в систему с вовлеченными людьми является то, что кажется безобидным, но действительно подрывным.
Помните, что если я пытаюсь атаковать систему: я не твой друг; Я не интересуюсь вашими детьми или хобби; Я буду использовать вас в любом случае, чтобы получить то, что я хочу; Меня не волнует, предам тебя. Идея «но он был моим другом, и именно поэтому я верил ему, что он верит в то, что он делает, правильно», это не утешение после этого факта.
+1 для абстракции («инкапсулировано/скрыто») –