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

Особенности в том, что часто к БД обращается по сути ровно один пользователь - 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 запросов к БД, тока потому что требуется выгрести "всё дерево прав" (и свобод)... прежде чем решить "а можна"? И уж тем более, постараться избежать доп. джойнов с таблицами прав... как в случаях косвенного описания классов доступов.

Кот Матроскин,

чем проще - тем лучше. :)

skyANA,

пасибки за ссыль, особенно интересны комменты (прямо как тут в другом разделе однажды було) :)

С NoSQL базами общался только с mumps, да и то давно и поверхностно... скажем так: "на сегодня" меня интересуют реляционные решения. :)

Dimitry Sibiryakov,

да, вы конечно правы. Можно и подождать 5 секунд... в общем, спасибо за помощь и участие в обсуждении.

(Что тут ничего и ни с кем толком нельзя обсуждать - я понял ещё со времен полемики с ЧАЛом)

В общем, спасибо и давайте закроем тему.

skyANA,

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

Меня интересует плоскость "действие-данные", особенно в части организации RLS "на стороне данные"... и, поскольку данные - это РСУБД, то работа с ними - нижний уровень ПО (ядро), которое или находится в самой БД в виде ХП или это слой адаптера к БД ... самый нижний слой приложения. И ему должно быть "пофиг" хто запросил, чагой-т запросил...

Задача организовать перехват из верхних уровней так, чтобы его наличие было максимально прозрачно для верхнего уровня. В этой части разные джойны к таблицам прав - есть зло, поскольку в ряде случаев потребуется создание сложных, составных запросов, где "джойнить" надо будет к внутреннему телу подзапроса, и не первой свежести, пардон вложенности. Прикажете "парсить", чтобы приджойнить в нижнем уровне? (одно такое чудо в ХП - уже видел: парсер запроса силами Скуля, чтобы найти куда прилепить свою часть - нечто) :)

То есть, все эти решения - по сути крест на производительности. (призывы "обождать" - они все отсюдова. А нет другого способа. Пока нет.)

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

Вот и думаю далее старых, добрых списков доступа ... :)

Впрочем, спасибо всем, первая часть вашего ответа (не понял И не хочу) объясняет почему тут обсуждать бессмысленно. Тока потеря времени.

Спасибо, ещё раз всем, тему можно закрыть.

ViPRos,

Пойдет и так, пойдет и как в SELinux ... это, скажем так, "верхний уровень" систем доступа, развитие "списков доступа" в сторону ролевых моделей.

Меня, сейчас, интересует НИЖНИЙ уровень, то что называют Row Level Security (пасибо Диме, не знал что оно ТАК называется) ... то есть атрибутирование каждой записи и формат такого атрибутирования, который позволил бы пользовать его "малой кровью", то есть без отдельных дополнительных выборок, джойнов и апдейтов ... идеально только дописывая свою часть WHERE в каждый запрос на выборку.

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

Пасибки, не сразу "въехал" (старею). :)

ViPRosя тебе там аж 2 типа фильтров показал (линейный и структурный (хотя можно все делать только через структурный)) :), которые автоматически дописываются к селекту в зависимости от роли и контекста

Фильтра заметил, а вот то что они "дописываются" - нет. :)

Вот, примерно из этой оперы что-то и ищу...

Дело в том, что моё старое изменение классической ролевой модели (дополнение ролей и действий политикой и контекстом исполнения: ТЗ от 2010г., реализация в 2011-2012г для sso.mediam.ru - студентом под моим надзором) вполне позволяет построить систему защиты так, чтобы принимать решения на уровне стороннего сервера ещё ДО начала обработки запроса. Примерно как в SELinux или других местах: есть отдельный сервер юзверей, доменов, политик, действий, контекста... который принимает запрос от базового сервера на исполнение действия и отдает ему контекст юзверя и политику запроса и подчиненных сразу, для кеширования и решение "можно или нельзя". Пока у базового сервера контекст и политика кешированы он, далее, сам принимает решения ... как только вышли за рамки кеша (переход на некешированный урл) - спрашивает заново (это чтобы часто не лазить). В базовом сервере до начала исполнения запроса (действия) работает "хелпер", который принимает решение по принципу пересечения контекста юзверя из кеша и запроса с параметрами... совпадает? можно, нет? "пошел нафик, с новым годом". Дабы кеш не раздувался непомерно (всего политиками для mediam.ru описано около 3500 урлов и контекстами около 5000 юзверей было на 2012год), есть его прокисание со временем. Сам хелпер минимизирован, там команд 30 на PHP "от силы"...

То есть там нет ваще никакого вмешательства в само исполнение запроса и тем более его обращений к БД. Защита полностью прозрачна для главного сервера.

Но, поскольку я не могу математически доказать полноту такой защиты ... хочется построить "дополнительный слой" ... и вот в качестве него, я и хочу сделать DAC или его разновидность. За неимением лучшего, пока остановился на традиционных ключах доступа и владельце записи.

Помнится у Вас был разработан собственный framework для работы с БД ... встраивание фильтров идет в процессе конструирования запросов (есть какой-то конструктор ... типа Zend_Db_Select или по типу Yii) или обеспечивается "перехват" готового запроса и его дополнение в едином месте (адаптер к БД) или это происходит на уровне логики в ХП, а все обращения только через АПИ этого набора ХП?

Дополню.

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

Например, я - администратор фирмы ХХХ. У меня пришел новый продажник, а стало быть заявки по части товаров теперь стали "его", а не того, другого продажника. Или мне надо открыть доступ к "спец товарам" для группы "мои покупатели" ... или известить только их о начале акции ... или и таких моментов - море! (и все они НЕ реализованы на большинстве товарно-ценовых порталов ... как раз в силу ущербности моделей данных в их основе)

То есть, делегирование прав - нормальное динамическое действие системы.

Решением расширенной ролевой модели - мне достаточно изменить группы, роли, контексты, политики ... то есть всё то, что НЕ относится к самим данным. Это - легко. А вот КАК потом перенастроить DAC оперативно для заданной пачки записей ...

ViPRos,

Это надо попереваривать ...

Такой вопрос: сами конечные данные по цехам, участкам ... уж не знаю что там у вас хранится ... они имеют какие-то атрибуты, метки, ключи доступа и т.д., связанные с системой доступа к ним?

ViPRos,

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

Всё равно, пасибки. Вы, с вашими фильтрами подкинули мне одну идейку, как помочь обычным ключам доступа стать полезнее при динамическом делегировании прав. Всё, ужо сижу "пробоваю"... :)