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

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

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 оперативно для заданной пачки записей ...