Управління доступом до DB2 на основі міток: Практичний посібник, частина 1: Представлення про основи LBAC в DB2, Інші СУБД, Бази даних, статті



Вправа 1: Захист рядків


У цій вправі буде показано, як використовувати захист на рівні рядків для управління доступом до рядків у таблиці.


У відділі продажів Global Life Financial існує змагання серед регіональних менеджерів з продажу. Переможцем вважається менеджер, в регіоні якого план продажів перевищується по найбільшій маржі. Керівники компанії контролюють змагальний процес і мають доступ до всіх звітів про продажі, а для підтримки духу суперництва регіональні менеджери можуть просматрівтаь тільки свої дані з продажу.

Рис. 5. Компонент мітки захисту типу TREE


У наступному розділі показано, як реалізувати спроектоване рішення за допомогою команд SQL.


Реалізація рішення по забезпеченню безпеки


Огляд етапів:



  1. Визначення правил і міток захисту;
  2. a. Визначення компонентів міток захисту;
  3. b. Визначення правила захисту;
  4. c. Визначення міток захисту.
  5. Зміна таблиці MEDICAL_RECORD за допомогою додавання стовпця міток захисту для захисту на рівні рядків, маркування конфіденційних стовпців як захищених і призначення таблиці правила захисту.
  6. Оновлення стовпця з мітками захисту в таблиці MEDICAL_RECORD.
  7. Надання користувачам відповідних позначок захисту.

Етап 1: Визначення правил і міток захисту


Вимоги до привілеїв і повноважень


Для виконання команд по створенню правил і міток захисту потрібні повноваження SECADM.


Етап 1a: Визначення компонентів міток захисту


На основі аналізу потрібно два компоненти міток захисту. Компоненти міток захисту можна створити за допомогою наступних команд:







CREATE SECURITY LABEL COMPONENT SLC_LEVEL
SET {“CONFIDENTIAL”}
CREATE SECURITY LABEL COMPONENT SLC_LIFEINS_ORG
TREE {“LIFE_INS_DEPT” ROOT,
“K01” UNDER “LIFE_INS_DEPT”,
“K02” UNDER “LIFE_INS_DEPT”,
“S01” UNDER “LIFE_INS_DEPT”,
“S02” UNDER “LIFE_INS_DEPT”
}

Етап 1b: Визначення правила захисту


Наступний етап після створення компонентів міток захисту полягає в створенні правила захисту. Правило захисту з ім’ям MEDICAL_RECORD_ POLICY, що використовує компоненти міток захисту SLC_LEVEL і SLC_LIFEINS_ORG, можна створити за допомогою наступної команди:






        CREATE SECURITY POLICY MEDICAL_RECORD_POLICY
COMPONENTS SLC_LEVEL, SLC_LIFEINS_ORG
WITH DB2LBACRULES
RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

Етап 1c: Визначення міток захисту


На основі аналізу необхідні такі мітки захисту:



  1. Мітка захисту стовпців.
  2. Чотири мітки захисту рядків.
  3. Користувацька мітка захисту для аналітиків історії хвороби.

Мітка захисту стовпців створюється за допомогою наступної команди:






        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.MED_RECORD
COMPONENT SLC_LEVEL “CONFIDENTIAL”

Мітки захисту рядків створюються за допомогою наступних команд:






        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_K01
COMPONENT SLC_LIFEINS_ORG “K01”

CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_K02
COMPONENT SLC_LIFEINS_ORG “K02”

CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_S01
COMPONENT SLC_LIFEINS_ORG “S01”

CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_S02
COMPONENT SLC_LIFEINS_ORG “S02”


Мітка захисту для медичних аналітиків створюється за допомогою наступної команди:






        CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.MEDICAL_ANALYST
COMPONENT SLC_LEVEL “CONFIDENTIAL”,
COMPONENT SLC_LIFEINS_ORG “K01”, “K02”, “S01”, “S02”

Етап 2: Створення захищеної таблиці SALES


Вимоги до привілеїв і повноважень


ALTER (вилучіть) привілеї таблиці MEDICAL_RECORD:


Адміністратору бази даних слід надати мітку захисту, пов’язану з правилом захисту MEDICAL_RECORD_POLICY. Так як адміністративна активність може зажадати роботи з більшістю рядків і стовпців, можна розглянути питання надання максимальної позначки захисту: MEDICAL_ANALYST. Спочатку мітка захисту адміністратора використовується як значення за замовчуванням для нового стовпця DEPARTMENT_TAG (Див. Етап 3).






        GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.MEDICAL_ANALYST
TO USER <administrator_auth_id>
FOR ALL ACCESS

Для захисту таблиці MEDICAL_RECORD всі стовпці з конфіденційною інформація повинні бути захищені міткою захисту MEDICAL_RECORD_POLICY.MED_RECORD. Для захисту рядків додається новий стовпець для зберігання міток захисту. Таблицю можна захистити за допомогою наступної команди:






        ALTER TABLE MEDICAL_RECORD
ALTER COLUMN MEDICAL_HISTORY
SECURED WITH MEDICAL_RECORD_POLICY.MED_RECORD
ADD COLUMN DEPARTMENT_TAG DB2SECURITYLABEL
ADD SECURITY POLICY MEDICAL_RECORD_POLICY

Після успішного виконання команди таблиця MEDICAL_RECORD захищена.


Таблиця 14. Визначення таблиці MEDICAL_RECORD.




































































Ім’я стовпця


Схема типу


Ім’я типу


Довжина


Шкала


Порожній об’єкт

RECORDID SYSIBM CHARACTER 6 0 Немає
CLIENTNO SYSIBM CHARACTER 6 0 Немає
DEPTNO SYSIBM CHARACTER 6 0 Немає
APPLICATION_
DATE
SYSIBM DATE 4 0 Та
LAST_
UPDATE
SYSIBM DATE 4 0 Немає
MEDICAL_
HISTORY
SYSIBM CLOB 1048576 0 Немає
RISK_
INDEX
SYSIBM SMALLINT 1 0 Немає
DEPARTMENT_
TAG
SYSIBM DB2SECURITY
LABEL
0 0 Немає
The shading shows the protected MEDICAL_HISTORY column and the added DEPARTMENT_TAG column. 

Етап 3: Оновлення стовпця міток захисту


Вимоги до привілеїв і повноважень


Привілей UPDATE для таблиці MEDICAL_RECORD:


Адміністратору бази даних можна надати мітку захисту, яку можна використовувати для оновлення (це зроблено на етапі 2), або можна надати EXEMPTION (звільнення) для доступу з правом WRITE.






        GRANT EXEMPTION ON RULE DB2LBACWRITETREE
FOR MEDICAL_RECORD_POLICY
TO USER <administrator_auth_id>

Спочатку стовпець DEPARTMENT_TAG заповнюється міткою захисту адміністратора (MEDICAL_RECORD_POLICY.MEDICAL_ANALYST), якщо таблиця змінюється. Потім цей стовпець необхідно оновити відповідними позначками захисту для кожного запису. Для цього використовуються наступні команди:






UPDATE MEDICAL_RECORD
set DEPARTMENT_TAG= SECLABEL_BY_NAME (“MEDICAL_RECORD_POLICY”, “DEPT_K01″)
where DEPTNO=”K01”
UPDATE MEDICAL_RECORD
set DEPARTMENT_TAG= SECLABEL_BY_NAME (“MEDICAL_RECORD_POLICY”, “DEPT_K02″)
where DEPTNO=”K02”
UPDATE MEDICAL_RECORD
set DEPARTMENT_TAG= SECLABEL_BY_NAME (“MEDICAL_RECORD_POLICY”, “DEPT_S01″)
where DEPTNO=”S01”
UPDATE MEDICAL_RECORD
set DEPARTMENT_TAG= SECLABEL_BY_NAME (“MEDICAL_RECORD_POLICY”, “DEPT_S02″)
where DEPTNO=”S02”

Оновлена ​​таблиця MEDICAL_RECORD повинна виглядати таким чином.


Таблиця 15. Обвновленная таблиця MEDICAL_RECORD
















































RECORDID


CLIENTNO


DEPTNO


ALLOCATION_DATE


LAST_UPDATE


MEDICAL_HISTORY


RISK_FACTOR


Мітка захисту рядків

000010 K108341 K01 2005/01/05 2005/01/15 0 MEDICAL_RECORD_
POLICY.DEPT_K01
000020 K181245 K01 2005/02/09 2005/02/19 2 MEDICAL_RECORD_
POLICY.DEPT_K01
000030 S245987 S02 2005/02/11 2005/02/21 1 MEDICAL_RECORD_
POLICY.DEPT_S02
000050 S231674 S02 2005/03/23 2005/04/04 1 MEDICAL_RECORD_
POLICY.DEPT_S02

Етап 4: Надання користувачам міток захисту


Вимоги до привілеїв і повноважень


Для виконанню команд з надання користувачам міток захисту потрібні повноваження SECADM.


Після захисту таблиці MEDICAL_RECORD користувачі без міток захисту не мають доступу до цієї таблиці. Щоб надати доступ до таблиці Peter, Andrea і Joseph, надайте їм мітки захисту за допомогою наступних команд:






        GRANT SECURITY LABEL MEDICAL_RECORD_POLICY. MEDICAL_ANALYST
TO USER PETER
FOR ALL ACCESS
GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.DEPT_K01
TO USER Andrea
FOR ALL ACCESS

GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.DEPT_S02
TO USER Joseph
for ALL ACCESS


У наступному розділі показано, наскільки добре діє рішення LBAC по забезпеченню безпеки.


Рішення в дії


У даному розділі описані деякі сценарії, можливі після захисту таблиці MEDICAL_RECORD.


Приклад 1


Аналітик історії хвороби Peter намагається переглянути таблицю MEDICAL_RECORD за допомогою команди:






        SELECT * from INSURANCE.MEDICAL_RECORD;

Команда виконується успішно. Повертаються всі записи MEDICAL_RECORD.


Приклад 2


Andrea, менеджер відділу K01, намагається переглянути таблицю MEDICAL_RECORD за допомогою команди:






SELECT RECORDID, CLIENTNO, DEPTNO, APPLICATION_DATE, LAST_UPDATE, MEDICAL_HISTORY, RISK_INDEX
from INSURANCE.MEDICAL_RECORD;

Команда викликає помилку, тому що порушує правило доступу на READ захищеного стовпця MEDICAL_HISTORY.


Приклад 3


Joseph, менеджер відділу S02, намагається маніпулювати записом в таблиці MEDICAL_RECORD. Спочатку він виконує запит записи:






           SELECT RISK_INDEX from INSURANCE.MEDICAL_RECORD
WHERE CLIENTNO=”S231674″;

Команда виконується успішно. Повертається значення RISK_INDEX.


Потім Joseph намагається оновити значення RISK_INDEX.






        UPDATE INSURANCE.MEDICAL_RECORD
SET RISK_INDEX = 0
WHERE CLIENTNO=”S231674″

Команда викликає помилку, тому що порушує обмеження доступу на читання.
Якщо цю ж команду виконує Peter, вона виконується успішно, бо Peter має право на запис у дані записи.


Приклад 4


Joseph намагається оновити один з стовпців з конфіденційною інфорацію в таблиці MEDICAL_RECORD.






        UPDATE INSURANCE.M

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


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

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

Ваш отзыв

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

*

*