Мандатна СХЕМА УПРАВЛІННЯ ДОСТУПОМ

Методи мандатної управління доступом застосовуються до тих баз даних, в яких зберігається інформація має досить статичну і жорстку структуру, що властиво, наприклад, деяким військовим або урядовим організаціям Як зазначалося вище, в розділі 171, основна ідея полягає в тому, що кожному обєкту даних присвоюється певний класифікаційний рівень (Classification level) (або необхідний гриф секретності, наприклад Цілком таємно, Таємно, Для службового користування і тд), а кожному користувачеві надається рівень допуску (Clearance level) з градаціями, аналогічними існуючим класифікаційним рівням Передбачається, що ці рівні утворюють строгу ієрархічну систему (наприклад,

“Цілком таємно > Таємно > Для службового користування і тд) Тоді виходячи з цих положень можна сформулювати два дуже простих правила, вперше запропоновані Беллом (Bell) Іла-Падула (LaPadula) [173]

1 Користувач i може виконати вибірку даних обєкта j тільки в тому випадку, якщо його рівень допуску більше класифікаційного рівня обєкта j або дорівнює йому {Проста властивість безпеки – simple security property)

2 Користувач i може модифікувати обєкт j тільки в тому випадку, якщо його уро вень допуску дорівнює класифікаційному рівню обєкта j (Зоряне властивість – star property)

Перше правило досить очевидно, тоді як друге вимагає додаткових пояснень Насамперед, слід зазначити, що іншим чином друге правило можна сформулювати так: За визначенням будь-яка інформація, записана користувачем i, автоматично набуває класифікаційний рівень, який дорівнює рівню допуску користувача i . Подібне правило необхідно, наприклад, для того, щоб запобігти запис секретних даних, виконувану користувачем з рівнем допуску Секретно, в файл з меншим рівнем класифікації, що порушить всю систему секретності

Примітка Відносно лише операцій власне записи (INSERT), у другому правилі достатньо було б вимагати, щоб рівень допуску користувача i був

менше класифікаційного рівня обєкта j або дорівнює йому, і саме це правило часто наводиться в літературі Але тоді користувачі могли б записувати те, що потім самі не змогли б прочитати (Хоча буває так, що дехто насилу може прочитати навіть власний рукописний текст .. Можливо, застосування більш слабкої форми другого правила все-таки не зовсім позбавлене сенсу)

Особливо велику увагу методам мандатної управління доступом стало приділятися на початку 1990-х років Справа в тому, що відповідно до вимог Міністерства оборони США, будь-яка використовувана в цьому відомстві СУБД повинна неодмінно підтримувати схему мандатної управління доступом Тому розробникам СУБД довелося вступити в суперництво за якнайшвидшу розробку методів такого управління Обовязкові вимоги до цієї схеми були викладені у двох важливих публікаціях Міністерства оборони, які отримали неформальні назвиПомаранчева книга (Orange Book) [1721] і Бузкова книга (Lavender Book) [1722] В Помаранчевої книзі перерахований набір вимог захисту для деякоїнадійної обчислювальної бази(Trusted Computing Base – ТСВ), а в Бузковий книзі дається інтерпретація цих вимог відносно систем баз даних

Визначені в Помаранчевій і Бузковий книгах методи мандатної управління доступом насправді є частиною більш загальної класифікації рівнів захисту,

які в дуже стислій формі викладаються нижче Насамперед, у цих документах визначаються чотири класу безпеки – А, В, С і D Грубо кажучи, клас D серед них найменш безпечний, клас С – більш безпечний, ніж клас D, і тд Кажуть, що клас D

забезпечує мінімальну, клас С – виборчу, клас В – мандатну і клас А –

перевірену захист Нижче коротко розглядаються класи С, У і А

■&nbsp Виборча захист Клас С ділиться на два підкласу, С1 і С2 (де підклас С1 менше безпечний, ніж підклас С2), кожен з яких підтримує виборче керування доступом, в тому сенсі, що управління доступом здійснюється за

розсуд власника даних (точно так, як описано вище, в розділі 172) Крім того, ці класи характеризуються зазначеними нижче особливостями

■ Відповідно до вимог класу С1, необхідно відокремити права владе ня від прав доступу, тобто поряд з підтримкою концепції спільного доступу до даних користувачам дозволяється мати власні захищені дані

■ Відповідно до вимог класу С2, необхідно додатково органі зовать підтримку облікових записів, побудовану на основі процедур примене ня підписів, аудиту та ізоляції ресурсів

■&nbsp&nbsp&nbsp&nbsp Мандатна захист Клас В включає вимоги до методів мандатної управ ління доступом і ділиться натри підкласу – В1, В2 і ВЗ (де В1 є найменш, а ВЗ – найбільш безпечним подклассом) Визначення вказаних підкласів наведені нижче

■ Відповідно до вимог класу В1, необхідно організувати захист з використанням міток (Це означає, що кожен обєкт даних в системі повинен мати мітку з позначенням присвоєного йому класифікаційного рівня – Таємно, Для службового користування і тд) Додатково потрібно також передбачити неформальне опис правил захисту

■ Відповідно до вимог класу В2, додатково потрібно преду дивитися формальне опис правил захисту Крім того, необхідно забез печити виявлення і виключення каналів витоку інформації Таким каналом може бути, наприклад, можливість логічного висновку відповіді на неприпусти мий запит з відповіді на допустимий запит (див розділ 174) або можливість розкриття секретних відомостей на підставі даних про час, який за трачівается на виконання деяких допустимих обчислень (див аннота цію до [1714])

■ Відповідно до вимог класу ВЗ, необхідно додатково забезпе чить підтримку аудиту та відновлення даних, а також призначити адмініст ратора захисту

■&nbsp&nbsp&nbsp&nbsp Перевірена захист Клас А є найбільш безпечним, і, згідно з його тре бованіям, необхідно математичне доказ того, що обраний хутра нізм захисту є прийнятним і забезпечує адекватну підтримку уста новлених обмежень захисту ()

В даний час деякі комерційні СУБД підтримують мандатну схему захисту рівня В1 Крім того, вони зазвичай підтримують виборчу схему захисту рівня С2

Термінологія СУБД, в яких підтримується мандатна схема захисту, часто називають системами з багаторівневим захистом [1715], [1718], [1723] (див наступний підрозділ, Багаторівневий захист) У цьому ж сенсі іноді використовується термін система, яка заслуговує довіри (trusted system) [1719], [1721], [1722]

Багаторівневий захист

Припустимо, що потрібно застосувати ідеї мандатної схеми управління доступом до змінної відносини постачальників S Для визначеності і простоти будемо вважати, що одиницею даних, на рівні якої вимагається контролювати доступ, є окремий кортеж цієї змінної відносини Тоді кожен кортеж повинен бути відзначений

Рис 171 Мінлива відносини S з присвоєними значеннями класифікаційного рівня (приклад)

відповідним класифікаційним рівнем, наприклад так, як показано на рис 171 (Тут значення 4 в стовпці LEVEL означає рівень Цілком таємно, 3 – Таємно, 2 – Для службового користування .)

Тепер припустимо, що користувачі з і U2 мають рівні доступу 3 (Секретно) і 2 (Для службового користування), відповідно Тоді змінна відносини S для цих користувачів буде виглядати по-різному Запит на вибірку відомостей про всі постачальниках з боку користувача з поверне чотири кортежу з даними про постачальників з номерами S1, S2, S3 і S5 Аналогічний запит з боку користувача U2 поверне два кортежу з даними про постачальників з номерами S1 і S3 Більш того, в результатах виконанняобох запитів будуть відсутні відомості про постачальника з номером S4

Розібратися в наведених вище твердженнях можна, застосувавши метод модифікації запиту Розглянемо наведений нижче запит (Отримати відомості про постачальників з Лондона)

S  WHERE  CITY  =   London

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

S WHERE CITY = London AND LEVEL &lt допуск користувача

Аналогічні міркування будуть справедливі і по відношенню до операцій оновлення Наприклад, користувач з не знає про існування кортежу для постачальника з номером S4, тому наведена нижче команда INSERT може здатися йому цілком прийнятною

INSERT INTO S RELATION { TUPLE { S#    S# ( S4 ), SNAME NAME ( Baker ), STATUS 25,

CITY  Rome } }

Система не повинна відкидати команду INSERT, оскільки в цьому випадку користувач U3 в кінцевому рахунку дізнається про існування постачальника з номером S4 Таку команду система прийме, але модифікує її і призведе до наступного вигляду

INSERT INTO S RELATION { TUPLE {S#     S # ( S 4), SNAME  NAME (

‘Baker )&gt STATUS 25,

CITY   Rome, LEVEL

3 } }

Зверніть увагу на те, що в даному випадку первинним ключем для змінної відносини постачальників є вже не атрибут {S #}, а комбінація атрибутів

{S#,LEVEL}

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

Ще про термінологію Модифікована зазначеним чином змінна відносини постачальників є прикладом багаторівневої змінної відносини Та особливість, що одні й ті ж дані по-різному виглядають для різних користувачів, називається поліконкретізаціей (Polyinstantiation) У наведеному вище прикладі з оператором INSERT

запит на вилучення даних про постачальника з номером S4 поверне різні результати для користувача U4 з правом доступу до зовсім секретних матеріалів і для користувача U3, що має лише право доступу до секретних матеріалів Третій результат, відмінний від двох попередніх, буде наданий користувачеві U2, котрий володіє правом доступу до матеріалів для службового користування

Оператори оновлення (UPDATE) і видалення (DELETE) обробляються системою аналогічно (тут ми не будемо їх обговорювати, оскільки більш детально вони розглядаються в деяких роботах, перелічених у списку літератури для цієї глави)

Питання Як ви думаєте, чи не порушують ці підходи згаданий вище інформаційний принцип Обгрунтуйте свою відповідь

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*