Знакомтесь - LBAC и SECADM
Label Based Access Control и Security Administrator, который рулит LBAC'ом
ID SECADM'a не может совпадать с ID SYSADM

Label ассоциируется с пользовательской сессией и строкой данных.
Правила сравнения security labels позволяют производить разрешения доступ на уровне строк, колонок, и всяческих их сочетаний.

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

Используются policy для задания компонент которые составляют каждую label, и правила доступа (правила на чтение и правила на изменение).

Если Array, то для получения доступа пользовательская security labеl должна быть больше или эквивалентна security label объекта (строки/колонки/ячейки)
Если Set, то компонент пользовательской метки должен содержать компонент объектовой метки.
Если Tree, то пользовательская метка должна содержать как минимум один компонент объектовой метки (или предка такого эелемента в иерархии).


И вообще - ВНИМАНИЕ!
Это отдельная песнь как по своим удивительным возможностям, так и по сложности!
Во избежание криков "Куда нафик делись мои данные!!!!!!!" и "Почему все дико тормозит!!!!" необходимо таки выделить и обучить SECADM'a иначе ТРУБА!
Щас немного еще накидаю, с примерчиками, если получится.
Но тут целая книга - руководство....
Опасная вещь....

что DBADM, что SECADM - оба не имеют доступа к данным, если они защищены.
будь вы самый супер-прочее SYSADM, но если LBAC не дает доступ - данных вам не видать

к защищаемой таблице добавляется поле с типом DB2SECURITYLABEL (row level), и/или к каждой колонке SECURED WITH mySecLabel
Это поле содержит encoded label что делает сравнение меток очень эффективным.
селект этого поля показывает его encoded вариант.

Ну а теперь подумаем немного, порассуждаем.
Родительская таблица DEPARTMENT на ней row level granuality.
Дочерняя EMPLOYEE на ней row level granuality.
Юзеру надо удалить строку с родительской таблицы, для которой в дочерней есть строка НЕВИДИМАЯ для него.
И чего делать?
Если разрешить удаление только из родительской - integrity нарушается.
Если reject удаление - безопастность нарушается, нельзя пользователю знать, что в родительской естть строка удовлетворяющая условиям.
А если вставка строки? В дочернюю? Для которой в родительской есть строка, но НЕВИДИМАЯ?
Ну ситуации могут разные быть.
На них есть правила поведения LBAC, в доке описано

а вот возьмем случАй с Check Constraint.
Мне вот надо check constraint на таблицу, а НЕ все строки мне ВИДИМЫ...
ну и Primary Key тоже constraint.
Тоже правила поведения LBAC на этот случай описаны.

Ну вот к примеру мне надо вставить значение, есть уникальный индекс, мое значение противоречит ему, а строка его содержащая мне НЕВИДИМА?
Во задача!
Вывалить меня по ошибке constraint violation?
Дык это же прямое нарушение безопастности!!!
Мне знать не положено, есть такое значение или нет.

ну и наконец оптимизатор и наш любимый ISCAN (index only access).
Ну выбрал оптимизатор его.
А security label column не входит в состав индекса - оп-па, нарушение безопастности!!!!!
И фиг нам по всей морде, а не index only access!

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

Не проняло?
У меня так мороз по коже, как представлю крики разгневанных пользователей....
Может не смог чего рассказать, но по каким-то мне неведомым причинам много чего почемечно confidential
Будем готовить семинары....
Че делать-то...
Доку хоть бы публичную...
Всем заинтересованным.

Да, совсем забыл, на все эти прелести, на сложные ирерархии пользователей, с массивами и вкупе с наборами, с доступом по колонкам и/или строкам, со всеми этими наворотами по отдельности и взятыми вместе, берем всю это круть по созданию сложных полиси доступа, и вешаем поверх всего этого EXEMPTIONS!!!!!!!
Вот уж искренне непонимаю - а ЭТО зачем влепили?!
И так думать надо, почему у пользователя есть доступ или нету, а тут еще и ЭТО!
Ну вывод прост - аналогов нет, и скоро вряд ли будет (mainfraim'щиков просьба не выступать)

Yo - судя по тому, что рассказали ораклисты - не выглядит.
Вот вы как спец по ораклу сможете на основе доки уточнить ограничения? Технические?
Просто вот вчера на скорую руку уже были высказаны некоторые технические ограничения оракл имплементации.
По назначению и основным концепсиям выглядит очень похоже. Вполне похоже на плагиат идеи.
А по имплементации - нет.
Надо бы опытного ораклиста послушать, очень интересно.

Тут вопрос сложный.
Всегда использовался уровень приложения для организации иурархического доступа. С одной стороны перенос этого в базу позволит упростить прикладной уровень.
С другой стороны нет никакой интеграции с Tivoly Directory Server где хранятся учетные записи пользователей. И получается что все-равно придется пользовать авторизацию на уровне приложения.

на текущий момент детали реализации конфиденциальны.
Так чта.... Надо ждать, когда опубликуют.

кстати, вот надыбал ресурсов на почитать, читаю, и вижу, что реализация действительно разная.
http://www.databasejournal.com/features/oracle/article.php/10893_3065431_1
Ну вот хотя бы это

The label column is in essence a simple NUMBER datatype that stores the values that are decoded by OLS during access mediation to determine if the row is accessible to the user's session.


Надо глянуть вот по ссылкам здесь
http://www.oracle.com/technology/deploy/security/db_security/htdocs/ols.html

я к тому цитату привел, что в реализации IBM не происходит декодинга для проверки на доступ.

ну по поводу высказывания о сравнении того, что еще не выпущено, это ожидаемое высказывание - я таких тонны начитал по поводу юкона :)
А по поводу того, как labels сравниваются - побитовое сравнение.
Да, вот пробую найти по поводу колонок в оракле.
Ну а про те же яйца - Yo, давайте на инженерном уровне общатся.
Если вам пофлеймить - go to cравнение баз данных

Yo - ну я больше на различие в имплементации напирал.
Но сравнивать действительно лучше после выхода - все еще может много раз переменится.

пока не нашел ничего в OLS про защиту колонок. Ну и соответсвенно про совместное использование защиты колонок и строк.
Кстати, защита всех колонок таблицы эквивалентна защите label'ой всей таблицы.
Пока продолжаю чтение.
Блин, про XML писать надо - рука не подымается...

но у оракл дополнительная колонка с security label управляется автоматом - оракл сам ее создает.
в db2 ее надо включать в create table. И для колонки тоже, щас примерчик, ну что-то типа

вот интересный материал по OLS
http://www.lc.leidenuniv.nl/awcourse/oracle/network.920/a96578/toc.htm
и VPD это не то, во что "выродился" OLS.
Там в архитектурной части поясняется.

ну дайте ссылок на новую, я что нагуглил, то и читаю