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

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

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

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

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

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

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

Если вы хотите, чтобы учетная запись db выполняла еще больше работы, этой учетной записи также могут потребоваться другие разрешения, например возможность ОБНОВЛЯТЬ и, возможно, УДАЛИТЬ для определенных таблиц.

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

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

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

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

Вот пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

Меня не интересуют ваши дети или хобби; Я буду использовать вас любым способом, чтобы получить то, что я хочу; Меня не волнует, предам ли я тебя. Мысль о том, что «но он был моим другом, и поэтому я доверял ему поверить в то, что он делал правильно», не успокаивает постфактум.

Меня не интересуют ваши дети или хобби; Я буду использовать вас любым способом, чтобы получить то, что я хочу; Меня не волнует, предам ли я тебя. Мысль о том, что «но он был моим другом, и поэтому я доверял ему поверить в то, что он делал правильно», не успокаивает постфактум.

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

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

Это несовершенная аналогия, но мне нравится сравнивать таблицы в схеме «dbo» БД с «частными» данными в терминологии объектно-ориентированного программирования, а представления и хранимые процедуры - с «общедоступными». Можно даже сделать «общедоступную» схему отдельной от схемы dbo, чтобы сделать различие явным. Если вы последуете этой идее, вы получите преимущество в безопасности, а также в расширяемости.

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