Вивчаємо мітки доступу до рядків: завдання властивостей стовпця доступу в таблиці, Oracle, Бази даних, статті

Володимир Пржиялковского

Анотація


Ця стаття розглядає деякі особливості кошти Label Security в Oracle. Тут показана можливість секретити службовий стовпець з мітками доступу до рядків, а також розглянуті деякі правила правки міток. У першу чергу стаття зачіпає використання параметра TABLE_OPTIONS процедури APPLY_TABLE_POLICY з пакету
SA_POLICY_ADMIN.

Введення


Label Security є реалізація фірмою Oracle меточние, Або
мандатного методу доступу, відомого фахівцям із захисту даних. Опис Label Security в документації Oracle має характерний довідковий характер, що в даному випадку можна вважати обгрунтованим, так як самий мандатний доступ не придуманий фірмою (Аналогічно тому, як фірма Oracle не придумала SQL або, скажімо, JDBC). У той же час опис мандатної доступу, на яке посилається фірма Oracle, niap.nist.gov/cc-scheme/cc_docs/, Вельми непросто для сприйняття спеціалістом з БД. Кілька більш зрозумілі тексти російською мовою, підготовлені Держтехкомісії при Президентові РФ, Проте і вони розраховані в першу чергу на фахівців з безпеки.

Ця робота призначена показати деякі можливості Label Security саме адміністраторам і розробникам на Oracle, а головне – допомогти їм у самостійному вивченні цієї теми. Без останнього, на жаль, не обійтися: навіть вибіркове розгляд меточние доступу на простих прикладах зажадало відразу серії статей!

Тут буде показана можливість секретити службовий стовпець з мітками доступу до рядках, а також розглянуто деякі можливості редагування конкретних міток. В першу чергу стаття зосереджується на використанні параметра TABLE_OPTIONS процедури APPLY_TABLE_POLICY з пакету
SA_POLICY_ADMIN.

Підготовка до роботи


Передбачається, що є структури та об’єкти, а саме:


Щоб усе це побудувати у своїй БД, досить крок за кроком повторити дії з попередньої статті.

Для зручності роботи в SQL*Plus підготуємо кілька файлів. Файл phonepolicyoptions.sql:

CONNECT lbacsys/lbacsys
BEGIN
SA_POLICY_ADMIN.REMOVE_TABLE_POLICY
(
POLICY_NAME => ’empsec_policy’
, SCHEMA_NAME => ‘scott’
, TABLE_NAME => ‘phone’
, DROP_COLUMN => TRUE
);
END;
/
BEGIN
SA_POLICY_ADMIN.APPLY_TABLE_POLICY
(
POLICY_NAME => ’empsec_policy’
, SCHEMA_NAME => ‘scott’
, TABLE_NAME => ‘phone’
, TABLE_OPTIONS => ‘&1
);
END;
/
UPDATE scott.phone
SET empsec_label

= CASE
WHEN empno IN (
SELECT empno
FROM scott.emp
WHERE job IN ( ‘MANAGER’, ‘PRESIDENT’ )
)
THEN CHAR_TO_LABEL ( ‘EMPSEC_POLICY’, ‘LIMITED’ )
ELSE CHAR_TO_LABEL ( ‘EMPSEC_POLICY’, ‘OPEN’ )
END
;

У цьому сценарії спочатку з політики EMPSEC_POLICY виключається таблиця SCOTT.PHONE, причому завдяки явно вказаному значенню параметра DROP_COLUMN => TRUE службовий (в рамках цієї політики) стовпець EMPSEC_LABEL також віддалиться. Потім політика застосовується до таблиці заново, а її (нові, ті, що нам потрібно) властивості будемо вказувати через параметр для SQL*Plus. Оскільки службовий стовпець у таблиці PHONE відтворюється заново, його доведеться і заново заповнювати, причому (зверніть увагу!) заради зручності завжди однаково.

Інший файл, phones.sql, Послужить для спостереження результату:

SELECT ename, pno
FROM scott.emp LEFT OUTER JOIN scott.phone
USING (empno)
/

Він узятий з попередньої статті, але в силу своєї стислості і заради ясності повторюється тут.

Створимо також файл updateallen.sql:

UPDATE scott.phone
SET
empsec_label
= CHAR_TO_LABEL ( ’empsec_policy’, ‘&1‘ )
WHERE
empno
= ( SELECT empno FROM scott.emp WHERE ename = ‘ALLEN‘ )
/

Кілька інших сценарних файлів буде створено по ходу справи.

Видамо в SQL*Plus:

SQL> SET VERIFY OFF

Можна ставити досліди.

Зникаючий стовпець


У попередній статті обумовлювалося, що службовий стовпець, доданий в результаті застосування політики до таблиці, можна сховати від користувачів. Покажемо, як це зробити. Видамо в
SQL*Plus:

@phonepolicyoptions ‘read_control, hide

Перевірка:

SQL> COLUMN POLICY_NAME FORMAT A22
SQL> COLUMN SCHEMA_NAME FORMAT A12
SQL> COLUMN TABLE_NAME FORMAT A12
SQL> COLUMN TABLE_OPTIONS FORMAT A15 WORD
SQL> SELECT policy_name, schema_name, table_name, table_options
2 FROM dba_sa_table_policies;
POLICY_NAME SCHEMA_NAME TABLE_NAME TABLE_OPTIONS
———————- ———— ———— ————–
EMPSEC_POLICY SCOTT EMP READ_CONTROL,
LABEL_DEFAULT
EMPSEC_POLICY SCOTT PHONE READ_CONTROL,
HIDE

SQL> SAVE showoptions Створено file showoptions.sql
SQL> CONNECT employee/employee З’єднане.
SQL> SELECT column_name FROM all_tab_columns
2 WHERE owner = ‘SCOTT’ AND table_name = ‘PHONE’;
COLUMN_NAME
——————————
EMPNO
PNO

SQL> SAVE showcolumns Створено file showcolumns.sql
SQL> CONNECT head/head З’єднане.
SQL> /
COLUMN_NAME
——————————
EMPNO
PNO


Зверніть увагу: стовпець EMPSEC_LABEL став невидимий, тобто ні у господаря таблиці, ні у користувачів не стало причин здогадуватися, що їм пред’являється тільки частина рядків! Додатковою скритності додає та обставина, що навіть SYS не побачить прихованого стовпця (Перевірте це!) А ось для порівняння, що буде, якщо властивість HIDE «Приберемо» (тобто не вкажемо):

@phonepolicyoptions ‘read_control

Перевірка:

SQL> CONNECT head/head З’єднане.
SQL> @showcolumns
COLUMN_NAME
——————————
EMPNO
PNO
EMPSEC_LABEL

Зверніть увагу на те, що коли стовпчик EMPSEC_LABEL був невидимий, ця обставина не завадила адміністратору Label Security (користувачеві LBACSYS) звернутися до колонки командою
UPDATE scott.phone SET empsec_label = … у файлі
phonepolicyoptions.sql.

Хто і як може змінювати мітки секретності


Умолчательная реакція на зміну мітки звичайним користувачем

Мітку секретності рядки можна поміняти, і адміністратор (Користувач 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
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.
У той же час користувач HEAD, який «бачить все», нового обмеження не помітить:
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 в рамках нашої політики, не дозволяє звичайним користувачам змінювати значення міток доступу в рядках таблиці.


 

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*