вопрос по проектированию БД

pitrik2

есть некая система
ею будут пользоваться люди, каждый со своим логином/паролем и со своим набором привилегий
такие БД я обычно делал так: создавал табличку юзеров, табличку объектов, табличку ролей и табличку прав
а тут встретил совсем другой подход
вместо таблички юзеров используются юзеры СУБД
вместо таблички объектов - объекты БД: вьюхи, ХП
а вот таблицы ролей и прав - как у меня
для всех вьюх стоит GRANT SELECT TO PUBLIC;
в каждой такой вьюхе в условие выбора добавляется

    -- проверка прав

    AND (EXISTS(SELECT 1

                 FROM sec_users us, sec_u_rights ur

                    WHERE us.usr_uid   = UID            AND

                          us.state     = 1   AND

                          ur.usr_id    = us.id          AND

                          ur.ri        = 4120       AND

                          ur.right     = 1)

        )

типа нету прав и тогда SELECT ничего не возвращает
редактирование данных в базе осуществляется через ХП, в начале каждой стоит проверка, что UID имеет соотв. права
а вопрос собственно такой, прав ли я что посчитал того кто это сделал идиотом?

kruzer25

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

Boris1980

Если нет прав, зачем пускать select и грузить базу? Права на выполнение операции чуть раньше нужно проверить.
Если у человека нет каких-то прав в системе, то ему и диалог этого интерфейса незачем показывать.
Табличка user'ов тебе все равно понадобится. ФИО и прочие данные ты где хранить будешь?

pitrik2

ФИО и прочие данные ты где хранить будешь?

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

Slavaga

Может в базе таким образом реализован контроль доступа к информации на уровне строк? Насколько мне известно он примерно так и делается: web-страница .

Boris1980

Вот он ключевой момент.

Иногда предикат безопасности может оказаться настолько сложным, что оптимизатор СУБД не сможет самостоятельно построить оптимальный план выполнения запроса. В таких случаях может потребоваться ручное преобразование выражения предиката в более адекватную форму. Пока что мы будем считать, что оптимизатор идеален, и все выражения будут представлены в наиболее удобном для чтения виде.

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

tokuchu

При больших объемах данных, мне кажется, правильней использовать первый подход из статьи.

Сливать клиенту постоянно большие объёмы данных, а так же при этом постоянно проводить их выборку из базы?

Boris1980

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

tokuchu

Моя идея в том чтоб дать пользователю в фильтрах на выборку указать только допустимые для него значения.

А если обманет?
Эти значения в фильтрах - ведь тоже из базы берутся и потом фильтруются под клиента. Где?
Держать логику в базе не так уж и плохо - в них для этого есть средства. На сколько я себе представляю - это из-за php+mysql стало модно всё логику, авторизацию и т.п. на чём-нибудь вроде php делать.

sinet

Похоже на реализацию руками ораклового FGAC.

такие БД я обычно делал так: создавал табличку юзеров, табличку объектов, табличку ролей и табличку прав

А как ты сам контролировать будешь, чтобы пользователь не смог получить лишние данные?

Marinavo_0507

Держать логику в базе не так уж и плохо - в них для этого есть средства.

Ага, образца 1970-x годов.

aleks058

А как ты сам контролировать будешь, чтобы пользователь не смог получить лишние данные?

ИМХО, этим должен слой бизнес-логики заниматься.

Boris1980

А если обманет?
Эти значения в фильтрах - ведь тоже из базы берутся и потом фильтруются под клиента. Где?

Хочешь подстраховаться, проверь еще раз перед выполнением sql-запроса. Зачем для каждой строчки вычислять можно ее отобрать или нет, должен быть простой признак.

tokuchu

Хочешь подстраховаться, проверь еще раз перед выполнением sql-запроса.

А где проверять-то?

Зачем для каждой строчки вычислять можно ее отобрать или нет, должен быть простой признак.

А как проверять, если не каждую? Где-то её всё-равно проверять надо. Это скорее из области того где бизнес-логика находится - в БД, на application-сервере или на клиенте.

sinet

А где должен находиться этот слой?

ava3443

Ага, образца 1970-x годов.

давно уже вроде на Java можно хранимые процедуры писать
p.s. Я не за логику в базе, просто насколько я понимаю, если нужно сделать решение с security labels, которое будет относительно просто сертифицировать - придётся делать именно так как описал топикстартер (т.е. использовать юзеров БД). Ведь сертифицировать собственную бизнес-логику будет наверняка труднее, чем показать, что ты используешь уже сертифицированные средства СУБД (к примеру, Oracle Label Security)

Marinavo_0507

> давно уже вроде на Java можно хранимые процедуры писать
имел опыт общения с ораклом лет 7 назад
процедуры на яве были одновременно менее удобны и тормознее, чем на pl/sql , то есть наблюдался регресс по сравнению с технологией 70-х
может, с тех пор они сделали лучше, но момент был упущен - ведь как раз в то время и набирали популяность разные пыхыпы

mbolik1

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

mbolik1

Нет не прав, если система была написана до Oracle 8i то это единственный способ реализовать построчный доступ к данным. Не понятно зачем он использовал свои роли, а не роли базы данных.
Твой подход ещё хуже ты зачем-то полностью дублируешь функционал базы данных: там и так есть объекты, пользователи, роли, и права.

aleks058

А где должен находиться этот слой?

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

Boris1980

Проверить допустимые параметры наверное можно в процедуре, которая запускает sql-запрос. Разве нет?

Boris1980

Смотря какая проверка будет реализована. Если будет написана вычисляемая функция строки, то как бы полный скан таблицы не получился.

Ivan8209

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

sinet

Лазить напрямую можно и не давать.
Не понятно, зачем заново реализовывать существующий в базе функционал.
Авторизацию и констрэинты тоже из БД на сервер приложений переносить?
Не получим ли мы увеличение времени разработки, проблемы с производительностью и снижение безопасности?

Boris1980

Ну если уж напрямую к базе подключиться, то можно много всего навертеть.

Ivan8209

> Ну если уж напрямую к базе подключиться,
> то можно много всего навертеть.
Если авторизация сделана в СУБД, а не в примочке сбоку, то хрен.
---
...Я работаю антинаучным аферистом...

aleks058

Я считаю так.
В БД должы быть ключи, индексы и внешние ключи.
Можно еще в БД раздать пользователям простейшие права типа "No access, read only, read+write".
Все остальное (row level security, блокировки и т.п.) уже лучше реализовывать не на SQL и не в БД, а на сервере приложений на любимом языке программирования.

tokuchu

Проверить допустимые параметры наверное можно в процедуре, которая запускает sql-запрос. Разве нет?

Можно. А чем это будет отличаться? Логика будет в БД, к процедуре и запросам тоже доступ надо разделять.

tokuchu

Все остальное (row level security, блокировки и т.п.) уже лучше реализовывать не на SQL и не в БД, а на сервере приложений на любимом языке программирования.

Блокировки... ну-ну.
Доступ к базе данных может быть не только из одного приложения к тому же.