Хранимые процедуры против отсутствия хранимых процедур - точка зрения безопасности

Ответ 1

Только с точки зрения безопасности я не вижу никаких преимуществ, которые подход, не относящийся к SP, имел бы по подходу SP, потому что:

• вам необходимо предоставить разрешения непосредственно для базовых таблиц и т.д.
• с sproc, вся информация о реальной базе данных может быть инкапсулирована/скрыта (SP также могут быть зашифрованы)

Ответ 2

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

Теперь разработчики должны иметь больше прав для разработки, но они не должны иметь больше прав на производственной машине, если вы хотите рассмотреть вопрос о безопасности. Правда, разработчик мог написать malicous sp, который делает что-то плохое, когда ставится на prod. Тот же самый разработчик мог бы поместить тот же код в версию приложения и быть скорее пойманным или нет, как если бы они злонамеренно меняли proc. Лично я думаю, что процесс может быть легче поймать, потому что он может быть получен отдельно от кода dbas, что может означать, что менеджер или менеджер по настройке, и dbas имели возможность посмотреть на него как на менеджера, так и на менеджера по управлению конфигурацией. Мы все знаем, что реальность заключается в том, что никто не подталкивает код к prod, имеет время, чтобы пересмотреть каждую его часть лично, поэтому наем надежных разработчиков имеет решающее значение. Имея обзор кода и управление исходным кодом, вы можете найти вредоносное изменение или перевести его обратно в предыдущую версию, но использование кода приложения sps-вице-кода не зависит от разработчиков.

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

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

Ответ 3

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

Чтобы узнать, что учетная запись может делать с хранимыми процедурами, вам нужно посмотреть хранимую процедуру. Каждый раз, когда sproc обновляется, кто-то должен будет посмотреть, что он делает, чтобы убедиться, что что-то не попало "случайно" в него. Реальная проблема с безопасностью в sprocs происходит изнутри организации, а не от злоумышленников-изгоев.

Вот пример:

Предположим, вы пытаетесь ограничить доступ к таблице сотрудников. Без хранимых процедур вы просто запрещаете доступ к таблице. Чтобы получить доступ, кто-то в значительной степени должен явно просить вас предоставить разрешения. Конечно, они могут заставить вас запустить script для предоставления доступа, но большинство людей, по крайней мере, пытаются просмотреть script, который изменяет схему базы данных (при условии, что script не обновляет sproc, о котором я расскажу ниже).

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

Реальная проблема с хранимыми процедурами заключается в том, что они добавляют уровень обфускации в систему. С обфускацией приходит сложность, и со сложностью в конечном итоге становится больше работать, чтобы понять администрирование базовой системы. Большинство людей в ИТ перегружены работой, и все проскальзывает. В этом случае вы не пытаетесь атаковать систему, чтобы получить доступ, вы используете ответственного за систему, чтобы получить то, что вы хотите. Митник был прав, в безопасности люди - проблема.

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

Помните, если я пытаюсь атаковать систему: я не твой друг; Я не интересуюсь вашими детьми или хобби; Я буду использовать вас в любом случае, чтобы получить то, что я хочу; Меня не волнует, предам тебя. Идея "но он был моим другом и почему я доверял ему, чтобы он верил в то, что он делал, правильно", это не утешение после этого.

Ответ 4

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

Ответ 5

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

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

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

Одним из возможных компромиссов может быть использование представлений или доступа к таблицам, чтобы разрешить SELECT, но обрабатывать все остальное (UPDATE, DELETE, INSERT), используя хранимые процедуры - наполовину безопасные, наполовину удобные...

Как это часто бывает - это классический компромисс между удобством (не-sp-подход, возможно, с ORM) и безопасностью (весь подход SProc, вероятно, более громоздкий, но немного безопаснее).

Марк

Ответ 6

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

Обычные запросы, сделанные в пакетах T-SQL, независимо от того, насколько интересны и сколько слоев на слоях генерации кода и ORM находятся за ним, просто не могут быть подписаны и, следовательно, не могут использовать один из наиболее специфичных и мощных механизмов контроля доступа.

Ответ 7

Это несовершенная аналогия, но мне нравится сравнивать таблицы в схеме DB "dbo" с данными "private" в терминологии OO, а Views и сохраненные Procs - "public". Можно даже сделать "общедоступную" схему отдельно от схемы dbo, чтобы сделать различие явным. Если вы будете следовать этой идее, вы получите преимущество безопасности, а также преимущество расширения.

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

Ответ 8

Единственный возможный аргумент в том, что я столкнулся с ситуациями, когда некоторые операторы не могут быть эффективно параметризованы в SP (и требуется динамический sql), и это дает вам возможность впрыска SQL в SQL. Однако это очень узкое соображение, и это редкий случай. По крайней мере, в PostgreSQL я время от времени видел несколько случаев, когда это должно было быть предметом дополнительного обзора.

В целом даже в этих случаях я думаю, что подходы типа SP дают вам преимущество по безопасности, потому что они означают, что приложение может использовать общие механизмы анти-SQL-инъекций, где это могло бы быть невозможно, и ваш SP могут использоваться многими приложениями. Кроме того, если все действия должны проходить через SP, вы можете уменьшить подверженность sql-инъекции и централизовать аудиты для проблем.

В общем, чем меньше пользователь может сделать меньше подверженности безопасности, как обычно. Это означает, что пользователь может сделать меньше с помощью инъекции sql-инъекций.

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

Ответ 9

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

• Шаблоны доступа к данным иногда гораздо важнее, чем конкретная процедура, выполняемая. Мы хотим регистрировать/контролировать/анализировать/поднимать предупреждения/блокировать доступ к данным, когда и как. Мы не всегда можем получить эту информацию при использовании хранимых процедур.

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

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