Вивчаємо мітки доступу до рядків в Oracle: завдання властивостей стовпця доступу в таблиці, Криптографія, Security & Hack, статті

Анотація

 

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

Введення

 

У статті “До кожної рядку охоронця приставиш!”Розповідалося про один з двох способів регулювати доступ до окремих частин таблиць в Oracle, а саме про Label Security. Label Security є реалізація фірмою Oracle меточного, або мандатного методу доступу, Відомого фахівцям із захисту даних. Опис Label Security в документації Oracle має характерний довідковий характер, що в даному випадку можна вважати обгрунтованим, тому що самий мандатний доступ не придуманий фірмою (аналогічно тому, як фірма Oracle не придумала SQL або, скажімо, JDBC). У той же час опис мандатного доступу, на яке посилається фірма Oracle, дуже непросто для сприйняття фахівцем по БД. Кілька більш зрозумілі тексти російською мовою, підготовлене Гостехкомиссией при Президентові РФ, Проте і вони розраховані в першу чергу на фахівців з безпеки.

Справжня робота призначена показати деякі можливості 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>

*

*