Как лучше сформировать Access List в SQL?

Question

[FloorZ]

Есть некое сферетическое приложение, которое работает с SQL.
Пользователи предварительно авторизуются в нем и может взаимодействовать с каким то перечнем таблиц.
Есть задача, сделать некий ACL с группами, в котором будет определено, какие таблицы и какие столбцы член группы может редактировать, читать и т.д.
Как в таком случае правильнее сформировать Access List?
1 - Держать таблицу с группами, держать для каждой таблицы еще одну таблицу, с перечнем групп и какая из групп что может делать.
2 - Держать таблицу с группами, а для каждой группы иметь свою таблицу с перечнем таблиц где прописаны разрешения.
3 - Что-то еще?

Comments

[nonname]

Задача вообще непонятна. Если я правильно понял, то смысл задачи в том как реализовать механизмы управления правами доступа в самописной СУБД?

[FloorZ]

nonname: в приложении, которое работает с СУБД.

[FloorZ]

nonname: представь, у тебя есть какая нибудь SQL база. В ней 4 таблицы. Плюс таблица пользователей. Пользователь авторизуется в приложении, и ему нужно изменить данные в таблице "А" через приложение естественно. Но приложение должно как то проверить "А разрешено ли ему это редактировать?". В итоге приложение где то должно проверить, а можно ли ему это. Короче говоря откуда то извлечь информацию, можно ли юзеру это знать.

И тут стоит вопрос, как подобное распределение прав обычно реализовывать лучше. При том хочу не просто права ограничить к каким то таблицам, а к конкретным колонкам.

Answer 1

[nonname]

У тебя есть функционал в приложении, ты можешь просто внутри него запретить делать что-то, например запретить использовать какую либо сущность. Хранить нужно будет таблицу с группами и таблицу с правами доступа, грубо говоря 1 строка в таблице прав содержит внешний ключ на таблицу с группой и допустим ещё 2 столбца булевый allow/deny и объект либо сущность. Теперь при доступе к объекту у тебя будет проверка принадлежности юзера к группе или группам join по ключам с таблицей прав с фильтром по названию объекта, с сортировкой по deny чтобы было вверху, и читаешь сверху, нашёл deny - значит запрет, нашёл allow - разрешить, ничего не нашёл - запрет.

Answer 2

[Марат]

Если ваше приложение не должно работать с многими разнообразными СУБД, то может лучше переформулировать вопрос на:
"Какая СУБД позволяет ограничивать доступ на чтение-модификацию-удаление в таблицах с точностью до выдачи таких разрешений на уровень отдельных полей таблиц?".
Например, MSSQL (и другие) давно делает это стандартными средствами.
Можете вытаскивать эти данные из служебных таблиц или через встроенные процедуры.
И СУБД, естественно сама контролирует введенные вами же правила.

Если хочется самому реализовывать. То смоделируйте в таблицах и далее нормализуйте:
Пользователи
Группы
Роли (Администратор, Read-only, Guest ...)

Справочник объектов БД (справочник: таблица, хранимая процедура, поле таблицы ...)
Объекты БД ( название таблицы, название поля таблицы со ссылкой на эту же таблицу, параметр хран процедуры...)
Свойства объектов (поля, параметры храним процедур)
Справочник операций над объектами (запуск хран процедур, удаление записи в таблице, модификация ПОЛЯ таблицы ...)
Операции над объектами(к какой роли привязана какая операция из справочника + над каким объектом)
Журнал аудита(Кто, Что, Когда - ссылки на Пользователя, Объект и Операцию + дата).
и т.п.