Управління доступом до DB2 на основі міток: Практичне керівництво



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


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


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

Рис. 1. Старші керівники можуть переглядати всі записи, регіональні менеджери – лише рядки для свого регіону


У змаганнях беруть участь чотири регіони. Два з беруть участь регіонів "Центр-Північ" і "Центр-Південь" фактично є субрегионами регіону "Центр" і отримують інструкції з продажу від головного менеджера цього регіону. (Примітка: Регіон "Центр" не включений у змагання, його головний менеджер є зацікавленим спостерігачем). Два старших керівника, керуючі відділом продажів, діють як адміністратори змагань. Учасники змагань та їх ролі представлені в наступній таблиці.


Таблиця 1. Учасники змагань та адміністратори



































Назва


Посада


Змагання

Paul старший віце-президент (старший керівник) Адміністратор
Bob Віце-президент (старший керівник) Адміністратор
Sam Менеджер з продажу регіону "Східне узбережжя" Учасник
Nick Менеджер з продажу регіону "Західне узбережжя" Учасник
Sean Головний менеджер регіону "Центр" Спостерігач
Becky Менеджер з продажу регіону "Центр-південь" Учасник
Marc Менеджер з продажу регіону "Центр-Південь" Учасник

Всі дані про змагання зберігаються в таблиці SALES. Цю таблицю необхідно створити, і вона повинна бути аналогічна існуючої таблиці PERFORMANCE.


Таблиця 2. Опис таблиці PERFORMANCE













































Ім'я стовпця


Схема типу


Ім'я типу


Довжина


Шкала


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

SALES_DATE SYSIBM DATE 4 0 Так
SALES_PERSON SYSIBM VARCHAR 15 0 Так
REGION SYSIBM VARCHAR 15 0 Так
SALES SYSIBM INTEGER 4 0 Так
MARGIN SYSIBM INTEGER 4 0 Так

У наступному розділі проаналізуємо вимоги до безпеки.


Аналіз обмежень даних


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



  1. Регіональним менеджерам з продажу наданий доступ на с правом READ / WRITE (ЧИТАННЯ / ЗАПИСИ) тільки до записів для своїх регіонів.
  2. Головний менеджер регіону "Центр" може переглядати записи регіонів "Центр-північ" і "Центра-південь".
  3. Керівники мають доступ на читання всіх записів.

На основі цього сценарію підведемо підсумок до вимог з безпеки:


Таблиця 3. Вимоги з безпеки



















Посада


Доступ на читання (READ)


Доступ на ЗАПИС (WRITE)

Регіональні менеджери з продажу Тільки записи для свого регіону Тільки записи для свого регіону
Головний менеджер регіону "Центр" Тільки записи для регіонів "Центр-північ" і "Центр-Південь" Немає доступу
Керівники Усі записи Немає доступу

На основі аналізу прийнято рішення забезпечити захист даних про продажі на рівні рядків. Для захисту таблиці на рівні рядків LBAC дозволяє привласнити кожному рядку мітку захисту. Потім можна надати користувачам мітки захисту, що відкривають їм доступ до відповідних рядках таблиці. У такому випадку слід створити таблицю SALES на основі існуючої таблиці PERFORMANCE (Таблиця 2), але з додатковим стовпцем для мітки захисту рядків.


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






































SALES_DATE


SALES_PERSON


REGION


SALES


MARGIN


Мітка захисту

31.12.04 LEE Східне узбережжя 2000 50  
31.12.04 GOUNOT Західне узбережжя 1000 40  
29.01.05 LUCCHESSI Центр-Південь 3000 30  
29.01.05 LEE Центр-північ 2000 45  

Далі на основі аналізу спроектуємо рішення LBAC щодо забезпечення безпеки.


Проектування рішення щодо забезпечення безпеки


У даній вправі спроектуємо мітки захисту, керуючі доступом до даних у таблиці SALES. При проектуванні міток захисту необхідно розглянути наступні питання:



  1. Мітки захисту рядків.
  2. Користувальницькі мітки захисту, надані користувачам для відповідного доступу.
  3. Компоненти міток захисту для створення міток захисту.

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


На основі аналізу визначено, що для кожного регіону потрібно мітка захисту для управління доступом до даних цього регіону. Тому потрібно чотири мітки захисту, по одній для кожного регіону продажів. Компоненти міток захисту для створення цих міток захисту можна розробити, використовуючи як елементів регіони продажів. Всі регіони мають однакове значення, тому для цього компонента мітки захисту можна використовувати оператор SET.


Користувальницькі мітки захисту для регіональних менеджерів


Відповідні мітки захисту, що призначаються рядках, надаються регіональним менеджерам для забезпечення доступу до даних свого регіону. Доступ менеджерів до таких даних має статус "READ / WRITE".


Мітка захисту для головного менеджера


Головний менеджер регіону "Центр" може переглядати дані регіонів "Центр-північ" і "Центр-Південь", тому його мітка захисту повинна мати більший пріоритет у порівнянні з мітками захисту рядків для цих субрегіонів. Так як в даному випадку мова йде про ієрархію, можна розглянути використання ARRAY або TREE для іншого компонента міток захисту.


Головний менеджер не має права на запис у таблицю SALES, тому необхідно використовувати деякі обмеження на рівні таблиці при відкликанні у цього користувача привілеїв INSERT, UPDATE і DELETE. Такі типи обмежень не є частиною компонента мітки захисту або самої мітки захисту, але їх необхідно використовувати при GRANT (надання) користувачам міток захисту.


Користувальницькі мітки захисту для керівників


Керівники можуть переглядати всі дані про продажі. Один із способів полягає в наданні керівникам всіх міток захисту, але це навряд чи можна назвати найбільш ефективним методів. Інший спосіб – Використання ієрархічної структури, в якій мітки захисту, надані керівникам, мають більший пріоритет у порівнянні з мітками захисту, що використовуються для захисту рядків. Така ієрархія повинна відповідати організаційній структурі компанії, тому вона занадто складна для ARRAY, і необхідно розглянути використання елемента TREE.


Керівники, як і головний менеджер, не мають права на ЗАПИС (WRITE) в таблицю SALES, тому необхідно використовувати обмеження на запис.


Компоненти міток захисту


Оскільки доступ до даних заснований на поділі по географічних регіонах компанії Global Life Financial, компонент мітки захисту можна створити за допомогою структури TREE з регіонами в якості елементів.

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


Використовуючи для створення компонента міток захисту вузли в деревоподібної структурі, можна створити чотири мітки захисту рядків: по одній для кожного регіону. Наприклад, мітку захисту для додавання до запису про продажі у регіоні "Західне узбережжя" можна розробити з використанням елементу "WEST_COAST" з компонента міток захисту.


Для надання керівникам доступу до всієї таблиці SALES їх мітки захисту повинні мати більш високий рівень привілеїв у порівнянні з менеджерами з продажу. Мітка захисту, створена з використанням елемента "SALES_ORGANIZATION", означає, що користувач, якому надана мітка захисту, має доступ до всіх записів таблиці з позначками захисту, створеними за допомогою елементів, що знаходяться нижче в деревоподібної структурі.


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


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


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



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

    • Визначення компонентів міток захисту;
    • Визначення правила захисту;
    • Визначення міток захисту.

  2. Створення захищеної таблиці SALES за допомогою додавання стовпця для мітки захисту і призначення таблиці правила захисту;
  3. Надання користувачам відповідних позначок захисту.

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


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


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


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


На основі аналізу вирішено, що можна використовувати компонент позначок захисту типу TREE з регіонами продажів як елементів. Компонент міток захисту SLC_REGION типу TREE з елементами показаний на малюнку 2, його можна створити за допомогою такої команди:







CREATE SECURITY LABEL COMPONENT SLC_REGION
TREE {“SALES_ORGANIZATION” ROOT,
“CENTRAL” UNDER “SALES_ORGANIZATION”,
“CENTRAL_NORTH” UNDER “CENTRAL”,
“CENTRAL_SOUTH” UNDER “CENTRAL”,
“WEST_COAST” UNDER “SALES_ORGANIZATION”,
“EAST_COAST” UNDER “SALES_ORGANIZATION”
}

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


Після створення компонента міток захисту необхідно створити правило захисту. Правило захисту SALES_REGION_POLICY, що використовує компонент SLC_REGION, можна створити за допомогою такої команди:






        CREATE SECURITY POLICY SALES_REGION_POLICY
COMPONENTS SLC_REGION
WITH DB2LBACRULES
RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

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


На основі аналізу вирішено, що мітка захисту потрібна для кожного регіону продажів (всього чотири), для головного менеджера і для керівників. Кожна мітка захисту заснована на правилі захисту SALES_REGION_POLICY, створеному на етапі 1b. Необхідні мітки захисту створюються за допомогою наступних команд:






        CREATE SECURITY LABEL SALES_REGION_POLICY.CENTRAL_SOUTH
COMPONENT SLC_REGION “CENTRAL_SOUTH”

CREATE SECURITY LABEL SALES_REGION_POLICY.CENTRAL_NORTH
COMPONENT SLC_REGION “CENTRAL_NORTH”

CREATE SECURITY LABEL SALES_REGION_POLICY.EAST_COAST
COMPONENT SLC_REGION “EAST_COAST”

CREATE SECURITY LABEL SALES_REGION_POLICY.WEST_COAST
COMPONENT SLC_REGION “WEST_COAST”

CREATE SECURITY LABEL SALES_REGION_POLICY.CENTRAL
COMPONENT SLC_REGION “CENTRAL”

CREATE SECURITY LABEL SALES_REGION_POLICY.SALES_ORG_READ
COMPONENT SLC_REGION “SALES_ORGANIZATION”


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


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


Можливість створення таблиць:


Для забезпечення безпеки таблиці SALES на рівні рядків потрібно стовпець типу DB2SECUIRTYLABEL для міток захисту і зв'язку таблиці з правилом захисту SALES_REGION_POLICY.






        CREATE TABLE SALES (SALES_DATE DATE,
SALES_PERSON VARCHAR (15),
REGION VARCHAR (15),
SALES INTEGER,
MARGIN INTEGER,
REGION_TAG DB2SECURITYLABEL)
SECURITY POLICY SALES_REGION_POLICY

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


Таблиця 5. Опис захищеної таблиці SALES




















































Ім'я стовпця


Схема типу


Ім'я типу


Довжина


Шкала


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

SALES_DATE SYSIBM DATE 4 0 Так
SALES_PERSON SYSIBM VARCHAR 15 0 Так
REGION SYSIBM VARCHAR 15 0 Так
SALES SYSIBM INTEGER 4 0 Так
MARGIN SYSIBM INTEGER 4 0 Так
REGION_TAG SYSIBM DB2SECURITYLABEL 0 0 Ні

Після заповнення даними з таблиці PERFORMANCE таблиця SALES виглядає наступним чином.


Таблиця 6. Кожному рядку присвоєна мітка захисту, керуюча доступом на основі регіону






































SALES_DATE


SALES_PERSON


REGION


SALES


MARGIN


Мітка захисту

31.12.04 LEE Східне узбережжя 2000 50 SALES_REGION_POLICY.EAST_COAST
31.12.04 GOUNOT Західне узбережжя 1000 40 SALES_REGION_POLICY.WEST_COAST
29.01.05 LUCCHESSI Центр-Південь 3000 30 SALES_REGION_POLICY.CENTRAL_SOUTH
29.01.05 LEE Центр-північ 2000 45 SALES_REGION_POLICY.CENTRAL_NORTH

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


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


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


Після захисту таблиці SALES користувачі без міток захисту не мають доступу до цієї таблиці. Щоб надати регіональним менеджерам доступ до регіональних даними в таблиці SALES, надайте кожному менеджерові мітку захисту, відповідну регіону продажів з правом на READ / WRITE (ЧИТАННЯ / ЗАПИС). Наприклад, Nick є менеджером з продажу в регіоні "Західне узбережжя", йому потрібно надати мітку захисту SALES_REGION_POLICY.WEST_COAST. Головному менеджеру Sean надайте мітку захисту SALES_REGION_POLICY.CENTRAL з правом читання. Керівникам Paul і Bob надайте мітку захисту SALES_REGION_POLICY.SALES_ORG_READ з правом читання всіх записів у таблиці.






        GRANT SECURITY LABEL SALES_REGION_POLICY.EAST_COAST
TO USER Sam FOR ALL ACCESS

GRANT SECURITY LABEL SALES_REGION_POLICY.WEST_COAST
TO USER Nick FOR ALL ACCESS

GRANT SECURITY LABEL SALES_REGION_POLICY.CENTRAL_NORTH
TO USER Becky FOR ALL ACCESS

GRANT SECURITY LABEL SALES_REGION_POLICY.CENTRAL_SOUTH
TO USER Marc FOR ALL ACCESS

GRANT SECURITY LABEL SALES_REGION_POLICY.CENTRAL
TO USER Sean FOR READ ACCESS

GRANT SECURITY LABEL SALES_REGION_POLICY.SALES_ORG_READ
TO USER Paul FOR READ ACCESS

GRANT SECURITY LABEL SALES_REGION_POLICY.SALES_ORG_READ
TO USER Bob FOR READ ACCESS


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


Рішення в дії


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


Приклад 1


Sam, менеджер з продажу регіону "Східне узбережжя", намагається додати дані в таблицю SALES:






        INSERT into INSURANCE.SALES VALUES (
“2005-02-28”,
“LUCCHESSI”,
“East-Coast”,
344,
40,
SECLABEL_BY_NAME ("SALES_REGION_POLICY", "SL_EAST_COAST"));

Команда виконується успішно. Строка результату містить:


("2005-02-28", "LUCCHESSI", "East-Coast", 344,40, <SALES_REGION_POLICY.EAST_COAST>)


Приклад 2


Sam намагається вставити дані про продажі іншого регіону:






        INSERT into INSURANCE.SALES VALUES (
“2005-02-28”,
“Brian”,
“Central-South”,
344,
28,
SECLABEL_BY_NAME ("SALES_REGION_POLICY", "SL_CENTRAL_SOUTH"))

Команда викликає помилку, тому що Sam не надана мітка захисту SALES_REGION_POLICY.CENTRAL_SOUTH.


Примітка: Якщо в команді CREATE SECURITY POLICY не задана опція RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL, команда виконується успішно. Але мітка захисту Sam з правом на запис буде записуватися в останній стовпець замість SL_CENTRAL_SOUTH.


Приклад 3


Sam намагається вставити дані про продажі, використовуючи надану мітку захисту:






        INSERT into INSURANCE.SALES (
SALES_DATE, SALES_PERSON, REGION, SALES, MARGIN)
VALUES (
“2005-02-12”,
“Peter”,
“East-Coast”,
450,
40)

Команда виконується успішно. Повертаються два рядки, додані в прикладах 1 і 2:


("2005-02-28", "LUCCHESSI", "East-Coast", 344,40, <SALES_REGION_POLICY.EAST_COAST>)
("2005-02-12", "Peter", "East-Coast", 450,40, <SALES_REGION_POLICY.SL_EAST_COAST>)


Приклад 4


Marc, менеджер з продажу регіону "Центр-Південь", намагається додати до таблиці дані про продажі:






        INSERT into INSURANCE.SALES (
SALES_DATE, SALES_PERSON, REGION, SALES, MARGIN)
VALUES (
“2005-02-25”,
“Brian”,
“Central-South”,
390,
43,
SECLABEL_BY_NAME ("SALES_REGION_POLICY", "SL_CENTRAL_SOUTH"));

Команда виконується успішно. Строка результату містить:


("2005-02-25", "Brian", "Central-South", 390,43, <SALES_REGION_POLICY.SL_CENTRAL_SOUTH>)


Потім Marc намагається переглянути таблицю за допомогою команди:






        SELECT sales_date, sales_person, region, sales, margin,
varchar (SECLABEL_TO_CHAR ("SALES_REGION_POLICY", REGION_TAG), 30)
from INSURANCE.SALES

Повертаються рядки з мітками захисту SALES_REGION_POLICY.CENTRAL_SOUTH:


("2005-02-25", "Brian", "Central-South", 390,43, <SALES_REGION_POLICY.CENTRAL_SOUTH>)


Приклад 5


Sam намагається переглянути дані про продажі по іншому регіонові за допомогою команди:






        SELECT sales_date, sales_person, region, sales, margin,
varchar (SECLABEL_TO_CHAR ("SALES_REGION_POLICY", REGION_TAG), 30)
from INSURANCE.SALES where REGION=”Central-South”

Рядки не повертаються. Рядок із значенням "Центр-Південь" в стовпці регіону захищена міткою захисту SALES_REGION_POLICY.SL_CENTRAL_SOUTH. Мітка захисту з правом на читання, наявна в Sam, не надає прав на читання таких рядків.


Приклад 6


Sam намагається переглянути дані з таблиці INSURANCE.SALES за допомогою наступної команди:






 SELECT sales_date, sales_person, region, sales, margin,
varchar (SECLABEL_TO_CHAR ("SALES_REGION_POLICY", REGION_TAG), 30)
from INSURANCE.SALES;

Повертається рядок з міткою SALES_REGION_POLICY.SL_EAST_COAST як значення REGION_TAG:


("2005-02-28", "LUCCHESSI", "East-Coast", 344,40, <SALES_REGION_POLICY.SL_EAST_COAST>)
("2005-02-12", "Peter", "East-Coast", 450,40, <SALES_REGION_POLICY.SL_EAST_COAST>)


Приклад 7


Becky, менеджер з продажу регіону "Центр-південь", намагається додати дані про продажі для іншого регіону, використовуючи надану мітку захисту:






        INSERT into INSURANCE.SALES (
SALES_DATE, SALES_PERSON, REGION, SALES, MARGIN)
VALUES (“2005-01-28”,
“Owen”,
“Central-North”,
300,
36,
SECLABEL_BY_NAME ("SALES_REGION_POLICY", "SL_CENTRAL_NORTH"));

Команда виконується успішно. Строка результату містить:


("2005-01-28", "Owen", "Central-North", 300,36, <SALES_REGION_POLICY.SL_CENTRAL_NORTH>)


Потім Becky намагається переглянути таблицю за допомогою команди:






        SELECT sales_date, sales_person, region, sales, margin,
varchar (SECLABEL_TO_CHAR ("SALES_REGION_POLICY", REGION_TAG), 30)
from INSURANCE.SALES

Повертаються рядки з мітками захисту SALES_REGION_POLICY.CENTRAL_NORTH:


(“2005-01-28″,”Owen”,”Central-North”,300,36,SL_CENTRAL_NORTH)


Приклад 8


Sean, головний менеджер регіону "Центр", намагається переглянути дані про продажі в регіонах:






        SELECT sales_date, sales_person, region, sales, margin,
varchar (SECLABEL_TO_CHAR ("SALES_REGION_POLICY", REGION_TAG), 30)
from INSURANCE.SALES

Команда повертає рядки з мітками захисту SALES_REGION_POLICY.SL_CENTRAL_SOUTH або SALES_REGION_POLICY.SL_CENTRAL_NORTH:


("2005-02-25", "Brian", "Central-South", 390,43, <SALES_REGION_POLICY.SL_CENTRAL_SOUTH>)
("2005-01-28", "Owen", "Central-North", 300,36, <SALES_REGION_POLICY.SL_CENTRAL_NORTH>)


Приклад 9


Paul, старший керівник, намагається переглянути дані про продажі за допомогою команди:






        SELECT sales_date, sales_person, region, sales, margin,
varchar (SECLABEL_TO_CHAR ("SALES_REGION_POLICY", REGION_TAG), 30)
from INSURANCE.SALES

Команда виконується успішно і повертає всі рядки таблиці INSURANCE.SALES:


("2005-02-28", "LUCCHESSI", "East-Coast", 344,40, <SALES_REGION_POLICY.EAST_COAST>)
("2005-02-12", "Peter", "East-Coast", 450,40, <SALES_REGION_POLICY.SL_EAST_COAST>)
("2005-02-25", "Brian", "Central-South", 390,43, <SALES_REGION_POLICY.SL_CENTRAL_SOUTH>)
("2005-01-28", "Owen", "Central-North", 300,36, <SALES_REGION_POLICY.SL_CENTRAL_NORTH>)


Вправа 2: Захист стовпців


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


Відділ кадрів компанії Global Life Financial хотів би надати доступ співробітникам, менеджерам і службовцям відділу кадрів доступ до даних у таблиці EMPLOYEE. У цій таблиці міститься інформація з різним рівнем важливості, тому необхідно використовувати деякі обмеження доступу:


Рис. 3. Рівні доступу до таблиці EMPLOYEE


Деякі користувачі, що мають доступ до таблиці, представлені в наступній таблиці.


Таблиця 7. Персонал з доступом до таблиці EMPLOYEE.















Ім'я


Посада

Jen Співробітники відділу кадрів
Noel Менеджер
Sunny Постійні співробітники

Існуючої таблиці EMPLOYEE присвоєні мітки захисту, що вказують рівень важливості стовпців.


Таблиця 8. Класифікація стовпців в таблиці EMPLOYEE.





















































































































Ім'я стовпця


Схема типу


Ім'я типу


Довжина


Шкала


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

(C) EMPNO SYSIBM CHARACTER 6 0 Ні
(U) FIRSTNME SYSIBM VARCHAR 12 0 Ні
(U) MIDINIT SYSIBM CHARACTER 1 0 Ні
(U) LASTNAME SYSIBM VARCHAR 15 0 Ні
(U) WORKDEPT SYSIBM CHARACTER 3 0 Так
(U) PHONENO SYSIBM CHARACTER 4 0 Так
(U) GENDER SYSIBM CHARACTER 1 0 Так
(U) GENDER SYSIBM CHARACTER 1 0 Так
(C) HIREDATE SYSIBM DATE 4 0 Так
(C) JOB SYSIBM CHARACTER 8 0 Так
(C) EDLEVEL SYSIBM SMALLINT 2 0 Ні
(H) BIRTHDATE SYSIBM DATE 4 0 Так
(H) SALARY SYSIBM DECIMAL 9 0 Так
(H) BONUS SYSIBM DECIMAL 9 0 Так
(H) COMM SYSIBM DECIMAL 9 0 Так
Клас захисту стовпців: (U) несекретний, (C) конфіденційний, (H) суто конфіденційний

У наступному розділі проаналізуємо вимоги до безпеки.


Аналіз обмежень даних


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



  1. Будь-які користувачі з доступом до таблиці EMPLOYEE можуть переглядати стовпці з несекретної інформацією.
  2. Менеджери також можуть переглядати всі стовпці з конфіденційною інформацією.
  3. Персоналу відділу кадрів має доступ з правом READ / WRITE до все стовпцях таблиці.

На основі цього сценарію підведемо підсумок до вимог з безпеки:


Таблиця 9. Вимоги з безпеки



















Посада


Доступ на читання (READ)


Доступ на ЗАПИС (WRITE)

Співробітники відділу кадрів Всі Всі
Менеджери Конфіденційні і несекретні стовпці Немає доступу
Постійні співробітники Несекретні стовпці Немає доступу

Далі на основі аналізу спроектуємо рішення LBAC щодо забезпечення безпеки.


Проектування рішення щодо забезпечення безпеки


У даній вправі спроектуємо мітки захисту, керуючі доступом до стовпцях в таблиці EMPLOYEE. При проектуванні міток захисту необхідно розглянути наступні питання:



  1. Мітки захисту стовпців з різним ступенем важливості.
  2. Користувальницькі мітки захисту, надані користувачам для відповідного доступу.
  3. Компоненти міток захисту для створення міток захисту.

Мітки захисту стовпців


На основі аналізу визначено, що кожному стовпцю необхідно прикріпити мітку захисту на основі важливості інформації. Тому потрібно три мітки захисту, по одній для кожного рівня важливості: HIGHLY CONFIDENTIAL, CONFIDENTIAL і UNCLASSIFIED. Це проста ієрархія, тому подумайте про використання для компонента міток захисту ARRAY.


Користувальницькі мітки захисту для співробітників компанії


Постійні співробітники мають доступ тільки до несекретної інформації. Якщо несекретні стовпці захищені міткою захисту UNCLASSIFIED, цю мітку необхідно надати постійним співробітникам.


Постійним співробітникам заборонений запис в таблицю EMPLOYEE, тому на рівні таблиці необхідно використовувати деякі обмеження при відкликанні у цих користувачів привілеїв INSERT, UPDATE і DELETE при НАДАННЯ (GRANT) ім міток захисту.


Користувальницькі мітки захисту для менеджерів


Менеджери мають доступ до несекретної і конфіденційної інформації. Якщо несекретні стовпці захищені міткою захисту CONFIDENTIAL, цю мітку необхідно надати менеджерам. Для міток захисту можна використовувати ARRAY. Якщо порядок елементів у масиві (CONFIDENTIAL, UNCLASSIFIED), то менеджери з міткою захисту CONFIDENTIAL мають доступ до все інформації на рівні CONFIDENTIAL і нижнім рівнями (в даному випадку UNCLASSIFIED).


Менеджерам також заборонений запис в таблицю EMPLOYEE, тому на рівні таблиці необхідно використовувати деякі обмеження при відкликанні у цих користувачів прівіленій INSERT, UPDATE і DELETE.


Користувальницькі мітки захисту для співробітників відділу кадрів


Співробітники відділу кадрів мають вищий рівень доступу до таблиці EMPLOYEE і мають доступ до всієї інформації. Якщо суто конфіденційні стовпці захищені міткою захисту HIGHLY CONFIDENTIAL, такі мітки необхідно надати співробітникам відділу кадрів. У даному випадку для міток захисту можна використовувати МАСИВ (ARRAY). Якщо в масиві (HIGHLY CONFIDENTIAL, CONFIDENTIAL, UNCLASSIFIED) має значення порядок, то співробітники відділу кадрів з наданою міткою захисту HIGHLY CONFIDENTIAL мають доступ до всієї інформації на рівні HIGHLY CONFIDENTIAL і на нижніх рівнях (у даному випадку CONFIDENTIAL і UNCLASSIFIED).


Доступ до даних у таблиці EMPLOYEE table повинен мати право READ / WRITE (ЧИТАННЯ / ЗАПИСИ).


Компоненти міток захисту


Доступ до даних заснований на лінійній ієрархії, тому компонент позначок захисту можна створити за допомогою МАСИВУ (ARRAY) з порядком HIGHLY CONFIDENTIAL, CONFIDENTIAL, UNCLASSIFIED.


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


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


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



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

    • Визначення компонентів міток захисту;
    • Визначення правила захисту;
    • Визначення міток захисту.

  2. Зміна таблиці EMPLOYEE за допомогою присвоєння всіма стовпцями міток захисту і призначення таблиці правила захисту;
  3. Надання користувачам відповідних позначок захисту.

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


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


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


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


На основі аналізу вирішено, що компонент позначок захисту типу "масив" можна використовувати для впорядкованого набору елементів: HIGHLY CONFIDENTIAL, CONFIDENTIAL і UNCLASSIFIED. Компоненти міток захисту можна створити за допомогою наступних команд:







CREATE SECURITY LABEL COMPONENT SLC_LEVEL
ARRAY ["HIGHLY CONFIDENTIAL", "CONFIDENTIAL", "UNCLASSIFIED"]

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


Після створення компонента міток захисту необхідно створити правило захисту. Правило захисту ACCESS_EMPLOYEE_POLICY, що використовує компонент SLC_LEVEL, можна створити за допомогою такої команди:






        CREATE SECURITY POLICY ACCESS_EMPLOYEE_POLICY
COMPONENTS SLC_LEVEL
WITH DB2LBACRULES
RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

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


На основі аналізу вирішено, що мітка захисту потрібна для кожного типу класифікації (всього три типи). Кожна мітка захисту заснована на правилі захисту ACCESS_EMPLOYEE_POLICY, створеному на етапі 1b. Необхідні мітки захисту створюються за допомогою наступних команд:






 CREATE SECURITY LABEL ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
COMPONENT SLC_LEVEL “HIGHLY CONFIDENTIAL”

CREATE SECURITY LABEL ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
COMPONENT SLC_LEVEL “CONFIDENTIAL”

CREATE SECURITY LABEL ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
COMPONENT SLC_LEVEL “UNCLASSIFIED”


Етап 2: Зміна таблиці EMPLOYEE


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


Змінити (ALTER) привілеї таблиці EMPLOYEE:


Для захисту таблиці EMPLOYEE на рівні стовпців необхідно змінити стовпці, призначивши відповідні мітки захисту, і пов'язати таблицю з правилом захисту ACCESS_EMPLOYEE_POLICY.






        ALTER TABLE EMPLOYEE
ALTER EMPNO SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
ALTER FIRSTNME SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
ALTER MIDINIT SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
ALTER LASTNAME SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
ALTER WORKDEPT SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
ALTER PHONENO SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
ALTER GENDER SECURED WITH ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
ALTER HIREDATE SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
ALTER JOB SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
ALTER EDLEVEL SECURED WITH ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
ALTER BIRTHDATE SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
ALTER SALARY SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
ALTER BONUS SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
ALTER COMM SECURED WITH ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
ADD SECURITY POLICY ACCESS_EMPLOYEE_POLICY

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


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


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


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


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






 GRANT SECURITY LABEL ACCESS_EMPLOYEE_POLICY.HIGHCONFIDENTIAL
TO USER Jen
FOR ALL ACCESS

GRANT SECURITY LABEL ACCESS_EMPLOYEE_POLICY.CONFIDENTIAL
TO USER Noel
FOR READ ACCESS

GRANT SECURITY LABEL ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED
TO USER Sunny
FOR READ ACCESS


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


Рішення в дії


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


Приклад 1


Jen, співробітник відділу кадрів, намагається переглянути таблицю EMPLOYEE за допомогою наступної команди:






        SELECT * from EMPLOYEE;

Команда виконується успішно.


Приклад 2


Менеджер Noel намагається переглянути таблицю EMPLOYEE за допомогою команди:






        SELECT * from HR.EMPLOYEE;

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


Потім Noel намагається переглянути лише стовпці з несекретної і конфіденційною інформацією:






        SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT,
PHONENO, HIREDATE, JOB, EDLEVEL
from HR.EMPLOYEE;

Команда виконується успішно.


Приклад 3


Постійний співробітник Sunny намагається переглянути таблицю EMPLOYEE за допомогою команди:






           SELECT FIRSTNME, LASTNAME, PHONENO from HR.EMPLOYEE;

Команда виконується успішно, так як Sunny має позначку захисту ACCESS_EMPLOYEE_POLICY.UNCLASSIFIED і намагається переглянути лише несекретну інформацію.


Потім Sunny намагається переглянути стовпці з конфіденційними даними:






        SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME,
WORKDEPT, PHONENO, HIREDATE, JOB, EDLEVEL
from HR.EMPLOYEE;

Команда викликає помилку, тому що порушує обмеження доступу на читання.


Вправа 3: Захист рядків і стовпців


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


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


Історії хвороб і індекс ризику зберігаються в таблиці MEDICAL_RECORD.

Рис. 4. Рівні доступу до таблиці MEDICAL_RERORT.


Далі в таблиці перераховані співробітники, що мають доступ до таблиці MEDICAL_RERORT.


Таблиця 10. Персонал, який має доступ до таблиці MEDICAL_RECORD.





















Назва


Посада

Peter Аналітик історії хвороб
Andrea Менеджер відділу K01
Sara Менеджер відділу K02
Kevin Менеджер відділу S01
Joseph Менеджер відділу S02

У таблиці MEDICAL_RERORT до стовпцях з конфіденційною інформацією мають доступ тільки аналітики історії хвороб. Доступ менеджерів обмежений записами клієнтів, які належать до відділу менеджера.


Таблиця 11. Визначення таблиці 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 Ні
Примітка: У заштрихованому стовпці міститься конфіденційна інформація.

У наступному розділі проаналізуємо вимоги до безпеки.


Аналіз обмежень даних


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



На основі цього сценарію підведемо підсумок до вимог з безпеки:


Таблиця 12. Вимоги з безпеки















Посада


Доступ на читання (READ)


Доступ на ЗАПИС (WRITE)

Аналітик історії хвороб Усі записи Усі записи
Менеджери Записи про клієнтів свого відділу, тільки стовпчики з несекретної інформацією Немає доступу

Для обмеження доступу до стовпцях з конфіденційною інформацією, стовпці можна захистити за допомогою міток захисту. Для обмеження доступу менеджерів тільки записами свого відділу кожному рядку можна присвоїти мітку захисту, що вказує відділ. Обмеження на запис для менеджерів можна виконати за допомогою оглядів прав на запис в таблицю. Нижче в таблиці 13 показано, як мітка захисту додається до колонку MEDICAL_HISTORY і служить для управління доступом до категорії посад.


Таблиця 13. Додається мітка захисту рядка для керування доступом по відділу.
















































RECORDID


CLIENTNO


DEPTNO


ALLOCATION_DATE


LAST_UPDATE


MEDICAL_HISTORY


RISK_FACTOR


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

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

Далі на основі аналізу спроектуємо рішення LBAC щодо забезпечення безпеки.


Проектування рішення щодо забезпечення безпеки


У даній вправі спроектуємо мітки захисту, керуючі доступом до даних у таблиці MEDICAL_RECORD. При проектуванні рішення щодо забезпечення безпеки необхідно врахувати наступне:



  1. Мітки захисту рядків і стовпців;
  2. Користувальницькі мітки захисту, надані користувачам для відповідного доступу;
  3. Компоненти міток захисту для створення міток захисту.

Мітки захисту стовпців


Для захисту стовпців з конфіденційною інформацією потрібно використовувати мітки захисту стовпців. Компонент мітки захисту для створення такої мітки захисту може бути просто елементом з ім'ям CONFIDENTIAL. Використання SET виглядає доцільним, тому що є тільки один елемент.


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


На основі аналізу визначено, що для кожного відділу потрібно мітка захисту для управління доступом до даних. Тому потрібно чотири мітки захисту, по одній для кожного відділу. Усі відділи мають однакове значення, тому для цього компонента мітки захисту можна використовувати оператор SET.


Користувацька мітка захисту для аналітиків історії хвороби


Аналітик історії хвороб має доступ READ / WRITE до всіх записів для всіх відділів, включаючи стовпчики з конфіденційною інформацією. Тому дана мітка захисту повинна включати елементи мітки захисту стовпців і мітки захисту рядків. Так як аналітик історії хвороби має доступ до всіх записів для всіх відділів, це вказує на наявність ієрархії, тому для міток захисту рядків краще використовувати тип ДЕРЕВО (TREE).


Користувальницькі мітки захисту для менеджерів


Відповідні мітки захисту, що призначаються рядках, надаються менеджерам відділів для забезпечення доступу до даних свого відділу. Менеджери мають доступ до даних з правом ЧИТАННЯ (READ), за винятком конфіденційних стовпців.


Компоненти міток захисту


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


Для міток захисту стовпців потрібно компонент позначок захисту типу SET, з одним елементом "CONFIDENTIAL".


Для міток захисту рядків потрібно компонент позначок захисту типу TREE, з кореневим елементом "LIFE_INS_DEPT", в якості дочірніх елементів використовуються імена відділів "K01", "K02", "S01", "S02".

Рис. 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>

*

*