Собственно вопрос применимости тех или иных решений к веб-строительству.

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

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

2. Роли. В случае развесистого сайта и большого количества действий - группируем действия и обзываем их "ролями", далее оперируем ролями. В итоге получаем "ролевую модель доступа".

Но. Ни первый подход ни второй, не решает задачу ограничения доступа к однородным данным.

С чем и столкнулся, разбирая очередную проблему очередного сайта, у которого по сути - 3 режима доступа: "кто попало", "сотрудник сайта" и "суперадмин" (программист). По сути, любой сотрудник сайта видит все задачи, всех других сотрудников... а уж "программист" ... :) Тут, частично оно решается "хардкодом": в ряде урл сайта, выдача блокируется явно по ФИО юзера. То есть доступ только "автору" и программисту (ген. дир. тоже кодить умеет ...).

3. Дискреционная модель доступа. Можем пойти "наоборот": каждому набору данных приписываем некие базовые правила доступа для CRUD операций. В этом случае, возникает проблема, что для каждой записи данных по сути надо держать ровно столько правил доступа, сколько посетителей на сайте. Последних можно скучковать в группы, выделить автора-владельца набора и ограничиться ровно одной группой. Тогда мы приходим к модели доступа а-ля Линукс: "хозяин-группа-прочие".

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

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

Казалось бы "всё замечательно". Соединение ролевой модели доступа к действиям и защиты экземпляра данных по ключу - вот оно "самое то" решение. Ан нет, не тут-то было:

Вот в таком, совмещенном варианте, недавно столкнулся со следующей проблемой:

Есть сайт (точнее внутренняя, я бы сказал CRM-система), в которой расписаны роли юзверей, есть 2 ключа: "публичный" и "приватный", согласно которым роль отдает данные на просмотр ... возникло желание "расплодиться" ... то есть выделить в самостоятельный филиал часть сотрудников, а стало быть, создать третий ключ "данные филиала"... создали. Старый "приватный" ключ - оставили как "данные центра".

... и тут выясняется, что теперь вновь испеченным сотрудникам филиала ... внезапно стали недоступны все ... их же приватные данные! А если их снабжать старым приватным ключом - то они преспокойно получают доступ ко всем новым данным центрального офиса... как вариант решения - разделить старый ключ на 2, соответственно пробежавшись по всем 364 таблицам этой БД и обновив приватный ключик по какому-то правилу ... оказалось, что для практически каждой таблицы - правило своё.

... ушло 3 месяца на создание 2-х ключей.

Вопрос: вот и заинтересовался, а есть какие-то более современные решения?

----------
в поиске интересной работы. Если есть вакансия - пишите в почту.

и опять в ответ тишина...

вопрос "слишком сложен" или "секретен"? Или я его изложил "слишком длинно" или "непонятно"? или все спецы "уже отдыхают"?

никто не откликнется? :)

Dimitry Sibiryakov , а без оскорблений и выпучивания собственного ЧСВ - обсуждать уже не получается? :(

1. Это "не у меня", об чём ясно было написано.

2. Там не было даже одной тысячи пользователей. Проблема не в количестве юзверей ... было около 10 гектар разного рода данных, которые надо стало ПЕРЕРАЗМЕТИТЬ, разделив доступ. В конце-концов, было применено "половинчатое" решение, а именно: было введено 2 новых ключа в дополнение к старому, и адаптер доступа и все ХП БД были переписаны с условий `key_id` = XXX, на `key_id` IN(связка ключей). Конечно, "оторвать руки" тому кто так не сделал сразу ... но это вопрос другого топика.

Как оказалось, идей "ключей доступа" - сильно проблематична в части РАЗДЕЛЕНИЯ старых данных по новым правилам... впрочем и даже в Линуксе, изменение доступов делается тупям chmod -R новое_правило куда/* и, если этих "куда" многа ... то админ сидит и тупо ручками переназначает всю дискреционную модельку...

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

P.S.

Поднял этот вопрос именно как вопрос ПРОЕКТИРОВАНИЯ БД... потому что для себя и сейчас, как раз занялся проектированием этой части ядра тут http://arhat.su/market, поднял свои старые заметки (2010г.) по вопросу, и понял что вопрос атрибутирования данных у меня там был решен лишь частично ... и опять же НЕ в разрезе деления ключей.

Просто хочется сделав однажды - больше не возвращаться к вопросу... :)

apapacy,

Да, всё именно так. Хочется декларативную модель и такую, чтобы не приходилось в каждом контроллере каждого урла рожать кучу проверок. Модуль доступа должен быть один, точнее 2: первый проводит аутентификацию запроса и решает допустимость данного действия в контексте юзверя ... эта сторона у меня решена ещё в коде sso сервера для mediam.ru. Там, сам сервер - ваще не имеет никаких проверок. Перед активизацией конкретного контроллера происходит обращение к администратору доступа (отдельный сервер), если такового ещё не было (кеширование) и халпер аутентификации сам решает пускать дальше или нет.

А вот второе место - это CRUD адаптер к БД и/или ХП в самой БД ... они должны уметь выбирать/изменять ТОЛЬКО допустимый набор данных ... и вот тут, долгое время мне казалось что система ключей решает все вопросы ... пока не увидел как плохо оно "делится" в последствии.

Dimitry Sibiryakov,

читал. БД - MySQL ... выбросить БД и заменить на оракул или поделки мелкософта - не предлагать. Postgre - как вариант "в рассмотрении", но там тоже вопрос деления данных - не менее проблемен как понял... ваши предложения? :)

Dimitry Sibiryakov,

есть и вьюхи и триггеры. И даже есть возможность в приложении перехватывать запросы к БД в адаптере к базе и там тоже дополнять запросы (моё приложение, как хочу, так и леплю) ... что и показано было на случае с ключами доступа. Проблема "глыбже"...

skyANA,

и? Не понял нифига... :)

Переформулирую проблему, ибо она относится к большому классу решений:

Row Level Security (RLS) в большинстве систем решается добавлением идента пользователя или другой метки (см. класс доступа в первом посту) к каждой записи данных. Как правило, такая метка - одна. В ФС Линукс - их три на каждый файл/директорию (аналогия: запись/таблица).

Множетственный доступ решается через "связки ключей", то есть нужный пользователь имеет весь требуемый ему набор ключей и доступ происходит по ИЛИ, точнее дополнением запроса условием AND `key_id` IN(моя_связка)...

при статическом распределении ключей - это нормальное решение: не требуется дополнительных выборок/запросов к БД, можно использовать механизм Вьюх или ХП, локализовав в одном месте все дополнения. Или даже пользоваться "встроенными" в СУБД средствами...

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

Проблема при динамическом назначении ключей, и особенно при разделении доступа к данным, помеченным тем или иным ключом.

Хотелось бы получить некий декларативный механизм, не требующий дополнительных обращений к БД, и который бы позволял путем изменения своей декларативной части (и только) изменять назначаемую RLS в широких пределах.

Вот. Как понимаю, это вопрос - чисто проектирования. Приглашаю к обсуждению спецов в конструктивном русле.

Dimitry Sibiryakov,

или Вы сознательно поверхностно рассматриваете вопрос или уж не знаю... ;)

И? что мне такого даст это поле владельца?

Конкретная задача в рамках начатого проекта:

Есть каталог фирм. Я регистрируюсь в системе и связываю себя со "своей фирмой" и добавляю "свои товары" на продажу. Пока проблем нет. Каждый товар будет подписан "моим" ключом доступа и/или в вашем поле owner будет прописан "мой" идент, как владельца. Соответственно, право изменения будет доп. контролироваться подписью каждой товарной строки.

Теперь. Я нафигачил 20тыс. товарных строк и мне надо оперативно(!) ими управлять ... ну вот акцию провожу: сегодня 100шт "по три", а завтра 100 других штук, но "по 5"... и я, как собственник, хочу добавить в систему своего помощника, и делегировать ему "часть" доступа к товарным строкам ... и?

Как ваше поле owner позволит мне это сделать?
Запихать всех помощников в группу ко мне?

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

и этот процесс "не зависит" от названия поля owner_id оно или key_id ... :)

skyANA,

Хочется решить вопрос (пере-)разделения доступа "малой кровью"... :)

Впрочем, накопал про ABAC, похоже это то решение, которое делал для медиама, но в части RLS... пока разбираюсь.

skyANA,

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

бизнес-логика, конечно решает всё. Вот как раз и не хочется её пускать в нижний уровень... в частности, сервер sso у медиама, вполне способен решать вопрос доступа и на сторонние сайты ... ваще без какой-либо "бизнес-логики" в доступе. Но, он конечно же не способен решать вопросы RLS.

Вот и хочется, сваять ядро доступа к БД так, чтобы потом не париться с бизнес-логикой. :)

Dimitry Sibiryakov,

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

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