Изучаем метки доступа к строкам: задание свойств столбца доступа в таблице Oracle - Кто и как может изменять метки секретности
ОГЛАВЛЕНИЕ
Кто и как может изменять метки секретности
Умолчательная реакция на изменение метки обычным пользователем
Метку секретности строки можно поменять, и администратор (пользователь LBACSYS) это уже делал. А вот что произойдет, если поменять значение метки попробуют «обычные» пользователи:
CONNECT / AS SYSDBAПроверка:
GRANT INSERT, UPDATE, DELETE ON scott.phone TO minimal;
SQL> CONNECT head/head
Соединено.
SQL> @updateallen OPEN
1 строка обновлена.
SQL> @updateallen LIMITED
1 строка обновлена.
SQL> @updateallen LIMITED
1 строка обновлена.
SQL> @updateallen OPEN
1 строка обновлена.
Вывод: пользователь HEAD беспрепятственно изменяет метку строки, как ему угодно. А пользователь EMPLOYEE ?
SQL> CONNECT employee/employee
Соединено.
SQL> @updateallen OPEN
1 строк обновлено.
SQL> @updateallen OPEN
1 строк обновлено.
SQL> @updateallen LIMITED
1 строк обновлено.
SQL> @updateallen LIMITED
0 строк обновлено.
SQL> @updateallen OPEN
0 строк обновлено.
Очевидно, как только метка становится LIMITED, пользователь EMPLOYEE теряет возможность ее изменять, а когда значение метки - OPEN, он такую возможность имеет. Он даже может сделать строку более секретной, но тогда потеряет к ней доступ.
Запрет делать то, результат чего не увидишь
Ситуация напоминает выводимую таблицу, view, где обладатель права изменять view может добавить через view в базовую таблицу строки, которые сам через view не увидит. Воспрепятствовать этому способно специальное ограничение целостности WITH CHECK OPTION. А можно ли здесь запретить выводить строки из зоны собственной видимости ? Да: для этого в параметре TABLE_OPTIONS достаточно указать специальный режим CHECK_CONTROL использования метки в таблице PHONE. Выдаем в SQL*Plus:
@phonepolicyoptions 'read_control, check_control'Проверка:
SQL> CONNECT employee/employeeВ то же время пользователь HEAD, который «видит все», нового ограничения не заметит:
Connected.
SQL> @updateallen OPEN
1 row updated.
SQL> @updateallen LIMITED
UPDATE scott.phone
*
ERROR at line 1:
ORA-28115: policy with check option violation
SQL> @updateallen OPEN
1 row updated.
SQL> CONNECT head/head
Connected.
SQL> @updateallen OPEN
1 row updated.
SQL> @updateallen LIMITED
1 row updated.
SQL> @updateallen LIMITED
1 row updated.
SQL> @updateallen OPEN
1 row updated.
Жесткий запрет на изменение метки
Другой режим использования метки в TABLE_OPTIONS еще более ограничителен. Он вовсе запрещает изменять значение метки, не важно в сторону ли увеличения или понижения ее секретности. Выдадим:
@phonepolicyoptions 'read_control, label_update'
Проверяем:
SQL> CONNECT employee/employee
Connected.
SQL> @updateallen OPEN
1 row updated.
SQL> @updateallen LIMITED
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
... ... ... ...
SQL> @updateallen OPEN
1 row updated.
SQL> CONNECT head/head
Connected.
SQL> @updateallen OPEN
1 row updated.
SQL> @updateallen LIMITED
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
... ... ... ...
Пример пока лишь доказывает, что метку нельзя сделать более «секретной». Но возможно, разрешено «играть на понижение» секретности ? Проверям снова:
CONNECT lbacsys/lbacsys
Connected.
SQL> @updateallen LIMITED
1 row updated.
SQL> CONNECT head/head
Connected.
SQL> @updateallen LIMITED
1 row updated.
SQL> @updateallen OPEN
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
... ... ... ...
Что и требовалось доказать: режим LABEL_UPDATE использования метки, заданный для таблицы PHONE в рамках нашей политики, не позволяет обычным пользователям изменять значение меток доступа в строках таблицы.