До кожної рядку охоронця приставиш!, Oracle, Бази даних, статті

Одним розповідь здавався довгий,
інші стверджували, що він занадто короткий,
більшість же, як завжди,
скромно мовчала …
М. Горький. Публіка

Одні стверджували, що він [будинок]
триповерховий, інші – що чотирьох.
А. і Б. Стругацькі. Град приречений


Зміст



Анотація


У статті Кожному (користувачеві) своє (дане в таблиці). Частина 2 говорилося про те, що в СУБД Oracle є механізм virtual private database, що дозволяє по-різному обмежувати різними користувачам доступ до частин однієї і тієї ж таблиці. Тут розповідається про іншому механізмі, призначеному для рішення тієї ж задачі, про так званому засобі Label Security.


Введення


Механізм virtual private database (VPD) в Oracle дозволяє регламентувати доступ до частин таблиці, але використовує для цього досить примітивну систему понять. У версії 8.1.7 в Oracle з’явилося інше засіб, Label Security, система понять якого більш продумана і краще пристосована під завдання захисту частин таблиці. Технічно воно спирається на VPD, але реалізує підхід, відомий в ІТ під назвою “Мандатної управління доступом”, що регулює в даному випадку доступ до окремих рядках таблиць різним категоріям користувачів. Реалізація відповідає ISO/IEC 15408 Common Criteria.


Кожен рядок потрібної таблиці позначається спеціальною міткою, що допускає згодом зміна. Користувачам видається дозвіл працювати з рядками, поміченими тільки певними мітками. При розборі запиту до таблиці СУБД виконає перевірки звичайних повноважень доступу (видаються командою GRANT), а при виконанні запиту відфільтрує з таблиці лише рядки зі значеннями міток, дозволеними для користувача. Логічно це виглядає як автоматичне додавання предиката AND P (метка_строкі, контекст_сеанса) в конструкцію WHERE запиту. В кінцевому рахунку не призначені для нього рядки користувач не зможе ні побачити, ні змінити.


Label Security – додаткова можливість Oracle. Для того, щоб нею користуватися, потрібно:


(А) завести при установці ПО СУБД Oracle потрібні компоненти і
(Б) завести необхідні структури в БД.


Перше робиться установником OUI, а друге – конфігуратором БД DCA або простим прогоном сценарію catols.sql з каталогу $ ORACLE_HOME / rdbms / admin. Спостережуваний результат – новий користувач LBACSYS і ціла серія належних йому об’єктів, включаючи пакети, імена яких починаються з “SA_”.


Простий приклад


Дані для регламентованого доступу


Нехай у співробітників з таблиці EMP є телефони:


CONNECT scott/tiger


CREATE TABLE phone AS SELECT empno FROM emp;


ALTER TABLE phone ADD (pno VARCHAR(20));


ALTER TABLE phone ADD PRIMARY KEY (empno, pno);


UPDATE phone
SET pno = TRUNC(dbms_random.value(100, 999))
//”-“
//TRUNC(dbms_random.value(1000, 9999));


Якісь з них будуть загальнодоступними, а якісь ні, але про це буде повідомлено пізніше.


Заведемо користувачів Oracle, що представляють співробітника і адміністративна особа. Дамо їм мінімум необхідних для даного прикладу повноважень:


CONNECT / AS SYSDBA


CREATE USER employee IDENTIFIED BY employee;


CREATE USER head IDENTIFIED BY head;


CREATE ROLE minimal;


GRANT CREATE SESSION TO minimal;


GRANT SELECT ON scott.phone TO minimal;


GRANT SELECT ON scott.emp TO minimal;


GRANT minimal TO employee, head;


GRANT UPDATE ON scott.phone TO lbacsys;


GRANT UPDATE ON scott.emp TO lbacsys;


Політика безпеки


Створимо політику безпеки, регулюючу доступ користувачів EMPLOYEE і HEAD до номерів телефонів. Вона буде базуватися на значенні мітки в стовпці EMPSEC_LABEL, який ми спеціально додамо в таблицю телефонів пізніше:


CONNECT lbacsys/lbacsys


BEGIN
SA_SYSDBA.CREATE_POLICY
(POLICY_NAME => “EMPSEC_POLICY”
, COLUMN_NAME => “EMPSEC_LABEL”);
END;
/


Відключити, знову включити і видалити політику безпеки можна процедурами DISABLE_POLICY, ENABLE_POLICY і DROP_POLICY.


Визначимо в рамках політики безпеки два рівні секретності:


BEGIN
SA_COMPONENTS.CREATE_LEVEL
(POLICY_NAME => “EMPSEC_POLICY”
, LEVEL_NUM => 1000
, SHORT_NAME => “OPEN”
, LONG_NAME => “Open level”);


SA_COMPONENTS.CREATE_LEVEL
(POLICY_NAME => “EMPSEC_POLICY”
, LEVEL_NUM => 2000
, SHORT_NAME => “LIMITED”
, LONG_NAME => “Limited level”);
END;
/


Кожен рівень задається трійкою <номер, коротка назва, розгорнуте назва>. Номер носить технічний характер, а розгорнутий назва – характер коментаря (але до 30 символів).


Передбачається, що створювані рівні лінійно впорядковані відповідно до номером. Змістовно за рівнем зручно бачити ступінь секретності, причому чим вище ступінь секретності (“відкриті дані” -> “Обмежений доступ” -> “секретно” …), тим більший потрібно зв’язати з нею номер.


Заводимо мітки доступу


Задані в рамках політики EMPSEC_POLICY рівні секретності використовуємо для формування міток доступу. Саме мітки і будуть регламентувати доступ до рядків таблиці. У нашому простому випадку кожна мітка відповідають просто рівню секретності:


BEGIN
SA_LABEL_ADMIN.CREATE_LABEL
(POLICY_NAME => “EMPSEC_POLICY”
, LABEL_TAG => 10000
, LABEL_VALUE => “OPEN”
, DATA_LABEL => TRUE);


SA_LABEL_ADMIN.CREATE_LABEL
(POLICY_NAME => “EMPSEC_POLICY”
, LABEL_TAG => 20000
, LABEL_VALUE => “LIMITED”
, DATA_LABEL => TRUE);
END;
/


Номер мітки LABEL_TAG має технічний зміст, вибирається довільно і безвідносно до номерів рівнів. Його навіть можна породжувати автоматично спеціальною функцією TO_DATA_LABEL. Значення TRUE для DATA_LABEL вказує, що міткою можна буде позначати рядки таблиць.


Приписуємо мітки доступу користувачам


Користувачеві EMPLOYEE дамо право доступу тільки до “відкритим” рядках, а користувачеві HEAD – до “відкритим” і “обмеженого користування”:


BEGIN
SA_USER_ADMIN.SET_USER_LABELS
(POLICY_NAME => “EMPSEC_POLICY”
, USER_NAME => “EMPLOYEE”
, MAX_READ_LABEL => “OPEN”);


SA_USER_ADMIN.SET_USER_LABELS
(POLICY_NAME => “EMPSEC_POLICY”
, USER_NAME => “HEAD”
, MAX_READ_LABEL => “LIMITED”);
END;
/


Приписуємо мітки доступу рядках


Для цього спочатку “застосуємо політику доступу” до таблиці PHONE в цілому:


BEGIN
SA_POLICY_ADMIN.APPLY_TABLE_POLICY
(POLICY_NAME => “EMPSEC_POLICY”
, SCHEMA_NAME => “SCOTT”
, TABLE_NAME => “PHONE”
, TABLE_OPTIONS => “LABEL_DEFAULT, READ_CONTROL, WRITE_CONTROL”);
END;
/


В результаті вона автоматично виявиться поповнена стовпцем EMPSEC_LABEL, зазначеним на самому початку для нашої політики EMPSEC_POLICY. Його можна легко спостерігати командою SQL * Plus DESCRIBE. Якщо ж в параметрі TABLE_OPTIONS в число властивостей через кому включити HIDE, новий службовий стовпець звичайним користувачам видно не буде. У цьому ж параметрі властивість WRITE_CONTROL можна для нашого випадку спокійно опустити.


Тепер з’явилася можливість розмітити конкретними позначками конкретні рядки:


UPDATE scott.phone
SET empsec_label = CHAR_TO_LABEL(“EMPSEC_POLICY”, “OPEN”);


UPDATE scott.phone
SET empsec_label = CHAR_TO_LABEL(“EMPSEC_POLICY”, “LIMITED”)
WHERE empno IN (SELECT empno
FROM scott.emp
WHERE job IN (“MANAGER”, “PRESIDENT”));


Замість звернення до функції CHAR_TO_LABEL (“EMPSEC_POLICY”, “OPEN”) можна було відразу вказати число 10000, номер мітки, так як саме число буде зберігатися в полі мітки фактично; аналогічно ж і в другій команді UPDATE. Однак для змістовної ясності зручніше скористатися функцією.


Перевіряємо, як працює


SQL> CONNECT employee/employee
Connected.
SQL> SELECT ename, pno
2 FROM scott.emp LEFT OUTER JOIN scott.phone
3 USING (empno);


ENAME PNO
———- ——————–
SMITH 409-2351
ALLEN 625-1171
WARD 506-9715
MARTIN 108-8113
SCOTT 187-3972
TURNER 609-2430
ADAMS 421-3324
JAMES 550-4204
FORD 713-9878
MILLER 924-5401
KING
CLARK
BLAKE
JONES


14 rows selected.


SQL> SAVE phones REPLACE
Wrote file phones.sql
SQL> CONNECT head/head
Connected.
SQL> /


ENAME PNO
———- ——————–
SMITH 409-2351
ALLEN 625-1171
WARD 506-9715
JONES 600-1573
MARTIN 108-8113
BLAKE 738-6815
CLARK 650-1728
SCOTT 187-3972
KING 393-8155
TURNER 609-2430
ADAMS 421-3324
JAMES 550-4204
FORD 713-9878
MILLER 924-5401


14 rows selected.


Вправа. Видати слідом за попереднім:


CONNECT scott/tiger
/
CONNECT lbacsys/lbacsys
/


Пояснити результати.


Нехай тепер в рамках тієї ж політики EMPSEC_POLICY частина співробітників також секретними, наприклад співробітники відділу розробок RESEARCH:


BEGIN
SA_POLICY_ADMIN.APPLY_TABLE_POLICY
(POLICY_NAME => “EMPSEC_POLICY”
, SCHEMA_NAME => “SCOTT”
, TABLE_NAME => “EMP”
, TABLE_OPTIONS => “LABEL_DEFAULT, READ_CONTROL”);
END;
/


UPDATE scott.emp
SET EMPSEC_LABEL = CHAR_TO_LABEL(“EMPSEC_POLICY”, “OPEN“);


UPDATE scott.emp
SET EMPSEC_LABEL = CHAR_TO_LABEL(“EMPSEC_POLICY”, “LIMITED”)
WHERE deptno
IN (SELECT deptno FROM scott.dept WHERE dname = “RESEARCH”);


Нова перевірка:


SQL> CONNECT employee/employee
SQL> @phones


ENAME PNO
———- ——————–
ALLEN 625-1171
WARD 506-9715
MARTIN 108-8113
TURNER 609-2430
JAMES 550-4204
MILLER 924-5401
BLAKE
KING
CLARK


9 rows selected.


SQL> CONNECT head/head
SQL> /


ENAME PNO
———- ——————–
SMITH 409-2351
ALLEN 625-1171
WARD 506-9715
JONES 600-1573
MARTIN 108-8113
BLAKE 738-6815
CLARK 650-1728
SCOTT 187-3972
KING 393-8155
TURNER 609-2430
ADAMS 421-3324
JAMES 550-4204
FORD 713-9878
MILLER 924-5401


14 rows selected.


Більш складна логіка


Описана вище найпростіша в рамках Label Security логіка розмежування доступу до окремих рядках допускає розвиток в декількох напрямках.


Більш складна структура мітки доступу


Важливим розвитком є ​​можливість формувати мітку доступу більш складним шляхом, ніж чим на основі лише рівня секретності. До складу мітки можна ще включати наступні компоненти:



І розділи даних, і групи користувачів описуються трійками <номер, коротка назва, розгорнуте назва>, проте на відміну від рівня секретності номери тут не несуть ніякого прикладного сенсу і вибираються довільно.


Таким чином, в загальному випадку мітка доступу може мати вигляд:


рівень: раздел1, розділ2, …: группа1, Группа2 …


У версії 10.1 інформацію про рівні, розділах даних і групах користувачів стало можливим поміщати в сервер імен OID / LDAP, що істотно для цінності самого підходу.


На відміну від простих міток, відповідних рівнів доступу, складові мітки мають більш складні правила впорядкування, а й забезпечують більшу функціональність.


Мітки сеансу


Використалася вище процедура SA_USER_ADMIN.SET_USER_LABELS приписує мітку доступу користувачеві. На ділі це не зовсім так: вона приписує мітку сеансам, породжуваним від імені цього користувача. За ходу сеансу зв’язку з СУБД цю мітку сеансу можна змінити процедурою SA_SESSION.SET_LABEL, правда в межах, які є можливість вказати процедурою SA_USER_ADMIN.SET_USER_LABELS, що в прикладі вище не використовувалося.


Інші ускладнення


До числа інших ускладнень і доповнень описаної логіки можна віднести інверсні групи, можливість скасовувати фільтрацію рядків мітками, можливість створення “довірчих” програмних одиниць, що звертаються до захищених рядках; можливість вказувати для таблиці, наданої стовпцем з міткою безпеки, додатковий предикат відбору рядків за своїм бажанням, а також ряд інших можливостей.


Зауваження по технології


Для роботи з розміченими рядками розумно завести спеціального адміністративного користувача на додаток до LBACSYS і передати йому необхідні повноваження для роботи з об’єктами LBACSYS.


Довідкову інформацію про заведених мітки, групах і т. д. можна отримати з довідкових таблиць користувача LBACSYS: DBA (USER) _SA_POLICIES, DBA_SA_LEVELS, DBA_SA_LABELS та ін


Для зручності роботи до складу ПО Oracle включена програма Policy Manager з графічним інтерфейсом.

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


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

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

Ваш отзыв

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

*

*