«Безопасный» SQL для доверенного персонала - черный список, белый список, ничего из вышеперечисленного?

Question

Обратите внимание, это чисто гипотетическое; сама идея дает мне heebie-jeebies. Я бы предпочел иметь интерфейс управления базами данных, который охватывает все возможные ситуации. Но я подумал о том, можно ли сделать это безопасно, и в конечном итоге привязал себя ко всем узлам. Отсюда вопрос.

В любом случае: Предположим, что я хотел, чтобы некоторые пользователи моего сайта искать часть базы данных, введя «сырыми» SQL:

• доверенный (и вошедшего в, очевидно) персонал только
• читать только доступ к соответствующим таблицам
• никакого доступа к другим таблицам
• не Possiblity работать небезопасную/запрещенную SQL, случайно или иначе

Все таблицы имеют префикс области, к которой они относятся, например, videos_, photos_, forum_. Я хотел бы предоставить этим пользователям доступ на чтение к определенным разделам, но не разрешать им изменять данные напрямую, введя SQL, даже если я доверяю им, чтобы вносить изменения через интерфейс.

Я бы хотел заблокировать даже этих доверенных пользователей, скажем, всех таблиц forum_ - иначе они могли бы читать личные сообщения всех пользователей, сообщения в форумах администратора и т. Д.!

Требование «доверенного пользователя» позаботится об этом, они должны быть в определенной группе, чтобы увидеть или использовать это. Это скорее «безопасный SQL».

Это так же просто, как соединение с другим пользователем БД, который имеет только права на чтение и только на правых таблицах?

Или я бы включил черный список (и отклонил SQL, если он содержит) forum_, DROP, ALTER, UPDATE, CREATE, INSERT и т. Д.?

Или белый список SELECT, FROM, WHERE, соответствующие имена таблиц и имена полей? Это звучит безопаснее, пока я не подумаю о необходимости WHERE field_name = «Произвольный текст здесь».

Или какая-то комбинация? (Скажем, использование журнала «черного списка» SQL, хотя известно, что оно кастрировано.)

Или убежать от крика?

Как бы вы справились с этим? Действительно ли это можно сделать безопасно?

Answer 1

Многие RDMS системы реализуют «схемы», которые (для SQL Server) по существу являются контейнерами в базах данных, содержащих объекты базы данных (например, таблицы - «dbo» - это схема по умолчанию, если ни одна не указана). После настройки вы можете назначить права доступа для входа в схемы и все объекты, содержащие therin, поэтому, если таблица будет добавлена, они автоматически получат (или будут лишены) доступ к ней с помощью схемы.

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

Answer 2

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

Answer 3

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

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

Answer 4

Пожалуйста, не пытайтесь вручную filterплохой SQL (на словах, как insert, delete и т.д ...).Это звучит как ужасный план!

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

Answer 5

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