В эпоху работы информационных ресурсов компаний в интернет (а не только в локальных сетях) особенно остро встает вопрос о контроле доступа к базе данных. Проблема состоит из трех самостоятельных частей:
Важно понимать, что пользователь вносит в базу не отдельные записи, а целые графы. Графы разных пользователей (разных ролей) слабо пересекаются, таким образом все записи базы данных (из всех таблиц) распадаются на слабо взаимодействующие классы. Будем называть такие классы департаментами. Можно только указывать (оператором CREATE DEPARTMENT), что новое имя департамента введено, или изъято (оператором DROP DEPARTMENT). [3].
CREATE DEPARTMENT dp;Резонно предоставить пользователю (роли) одинаковые права на все записи одного департамента, а имя департамента указывать в самих записях в поле специального типа LEGAL [4].
CREATE TABLE a (... , a5 LEGAL, ...); CREATE TABLE b (... , b7 LEGAL, ...); INSERT INTO a VALUES (... , dp, ...); INSERT INTO b VALUES (... , dp, ...); BESTOW select ON dp FOR usr; BESTOW update ON dp FOR rolename;Изымать права на департамент будем другим оператором
VANISH select ON dp FOR usr; VANISH update ON dp FOR rolename;Если на какую-либо операцию с записью у пользователя нет прав, то запись для данного пользователя не существует: например, отсутствие права SELECT означает невидимость записи, отсутствие права UPDATE – что запись “read only”. Само это поле доступно для изменения только тем, у кого есть право PUBLISH на департамент, которому принадлежит запись.
BESTOW publish ON dp FOR rolename; VANISH publish ON dp FOR rolename;Если в записи нет поля типа LEGAL, или оно равно NULL, то пользователь имеет все права на эту запись. Для удобства пользователя (да и администрирования базы данных) при создании пользователя укажем, каким департаментом по умолчанию он метит все создаваемые и обновляемые данные. Этот департамент по умолчанию будем указывать в параметре TRACE.
CREATE USER usr1 IDENTIFIED BY pwd1 TRACE dp1;
[1] Делегированием полномочий на колонку
[3] Изменять департаменты невозможно
(ALTER DEPARTMENT), т.к. они не имеют никаких параметров
[4] В записи может существовать только одно поле типа данных LEGAL
P.S.
Статья является руководством по реализации идей с.148, 187-190 pdf-документа.
Тюрин Дмитрий, dmitryturin@yandex.ru