Антонюк А.О. Теоретичні основи захисту інформації

Подождите немного. Документ загружается.

111

Однак МПБ має дуже серьйозні вади – вона є винятково складною для

практичної реалізації і вимагає значних ресурсів обчислювальної системи. Це

пов’язано з тим, що інформацйних потоків в системі величезна кількість і їх не

завжди можна ідентифікувати. Саме ці вади часто заважають її практичному

використанню.

МПБ піддавалася ретельним форм альним дослідж енням. Існує багато

різних видів цієї політики.

МПБ прийнята всіма розвинутими державами світу. Вона розроблялася,

головним чином, для збереження таємності (тобто конфіденційності)

інформації у війс ьк ов и х о р га ніз ац іях . Питання ж цілісн о ст і з а її д о по м о го ю не

розв’язуються або розв’язуються частково, як побічний результат захисту

таємності.

4.4. Рольова політика безпеки

Розглянемо ще один вид ПБ – рольову ПБ. Рольову політику безпеки

(Role Base Access Control – RBAC) не можна віднести ані до дискреційної, ані

до мандатної, тому щ о керування доступом в ній здійснюється як на основі

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

призначення ролей користувачам та їх активацію під час сеансів [43,74]. Отже,

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

між гнучкістю керування доступом, яка є характерною для ДПБ, і жорсткістю

правил контролю доступу, яка притаманна МПБ.

РПБ базується на наступних властивостях:

• всі суб’єкти і об’єкти повинні бути однозначно ідентифіковані;

• визначено набір ролей в системі;

• кожній ролі встановлено певний обсяг повноважень;

• доступ суб’єктів до об’єктів здійснюється за допомогою певних

правил в рамках певної ролі.

В РПБ класичне поняття суб’єкт заміщується поняттями користувач і роль.

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

обов’язки. Роль – це активно діюча в системі абстрактна суттєвість, з якою

112

пов’язаний обмежений, логично зв’язаний набір повноважень, які необхідні для

здійснення певної діяльності.

РПБ розповсюджена досить широко, тому що вона, на відміну від інших

більш строги х і формальних політик, є дуже близкою до реального життя.

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

особистого імени – вони завжди здійснюють певні службові обов’язки, тобто

виконують деякі ролі, які аж ніяк не пов’язані з їх особистістю.

Тому цілком логично здійснювати керування доступом і призначати

повноваження не реальним користувачам, а абстрактним (не персоніфікованим)

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

Такий підхід до ПБ дозволяє урахувати розділ обов’язків і повноважень між

участниками прикладного інформаційного процесу, оскільки з точки зору РПБ

має значення не особистість користувача, що здійснює доступ до інформації, а

те, які повноваження йому необхідні для виконання й ого службових обов’язків.

Наприклад, в реальній системі обробки інформації можуть працювати

системний адміністратор, менеджер баз даних і прості користувачі.

В такій ситуації РПБ дозволяє розподілити повноваження між цими

ролями відповідно до їх службових обов’язків: ролі адміністратора

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

роботу системи і керувати її конфігурацією, роль менеджера баз даних дозволяє

здійснювати керування сервером БД, а права простих користув ачів

обмежуються мінімумом, необхідним для запуску прикладних програм. Крім

того, кількість ролей в системі може не відповідати кіль кості реальних

користувачів – один користувач, якщо він має різні повноваження, може

виконувати (водночас або послідовно) декілька ролей, а декілька користувачів

можуть користуватись однією і тою ж роллю, якщо вони виконують однакову

роботу.

При використанні РПБ керування доступом здійснюється в дві стадії: по-

перше, для кожної ролі вказується набір повноважень, що представляють набір

прав доступу до об’єктів, і, по-друге, кожному користувачу призначається

113

список доступних йому ролей. Повноваження призначаються ролям відповідно

до принципу наймен ших привілеїв, з якого виникає, що кожний користувач

повинен мати тільки мінімально необхідні для виконнання своеї роботи

повноваження.

В моделі РПБ визн ачаються наступні множини :

• U – множина користувачів;

• R – множина ролей;

• Р – множина повноважень на доступ до об’єктів, що представляється,

наприклад, у вигляді матриці прав доступу;

• S – множина сеансів робот и користувачів з сис темо ю.

Для переліче ни х множин визнача ют ь с я наступні відношення:

PA P R⊆ ×

– відображає множину повноважень на множину ролей,

встановлюючи для кожної ролі набір наданих їй повноважень;

UA U R⊆ ×

– відображає множину користувачів на множину ролей,

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

Правила керування доступом рол ьової політики безпеки визначаю ться

наступними функціями:

user: S→U – для кожного сеанса s ця функція визначає користувача u, який

здійснює цей сеанс роботи з системою: user(s)=u;

roles: S→R – для кожного сеанса s ця функція визначає набір ролей з

множини R, що можуть бути одночасно доступні користувачу u в цьому сеансі:

roles(s)={r | (user(s),r)

∈UA

};

permissions: S→P – для кожного сеан са s ця функція задає набір доступних

в ньому повноважень, який визначається як сукупність повноважен ь всіх ролей,

що приймають участь в цьому сеансі: permissions(s)={p | (p,r)

∈ PA

В якості критерію безпеки рольової моделі використовується наступне

правило: система вважається безпечною, я кщ о будь-який користувач

системи u, що працює в се а нс і s, може здійснити дії, як і вимага ю т ь

повноважень р тільки в тому випадку, коли р

∈

permissions(s).

114

З формулювання критерію безпеки моделі РПБ виникає, щ о управління

доступом здійснюється головним чином не за допомогою призначення

повноважень ролям, а шляхом задання відношення UA, яке признача є ролі

користувачам, і функції roles, що ви зн а чає доступний в сеансі набір ролей.

Тому числені нтерпретації рольової моделі відрізняються видом функцій user,

roles і permission, a також обмеженнями, що накладаються на відношення РА та

UA. В якості прикладів розглядаєт ьс я рольов а політик а управл ін н я доступо м з

ієрархічною о рг ан іза ц ією р о л ей , а так о ж де кіл ьк а т ип о в и х об м еж е н ь н а

відношення PA та UA і функ ц ії user та roles, що найбіл ьш часто зустрічаються

на практиці [l0].

Зокрема, ієрархічна організація ролей являє собою найбільш

розповсюджений тип рольової моделі, оскільки вона дуже точно відображає

реальне відношення підпорядкованості між участниками процесів обробки

інформації і розподіл між ними сфер відповідольності. Ролі в ієрархії

упорядковується за рівнем наданих повноважень. Чим вище роль в ієрархії, тим

більше з нею пов’язано повноважень, оскільки вважається, що коли користувачу

надана деяка роль, то йому автоматично призначаються і всі підпорядковані їй за

ієрархією ролі. Ієрархічна організація ролей є характерною для систем

військового призначення.

Завдяки гнучкості та широким можливостям РПБ суттєво перевершує інші

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

вона практично не гарантує безпеку за допомогою формального доказу, а

тільки визначає характер обмежень, виконання яких і є крітериєм безпеки

системи. Хоча такій підхід дозволяє отримати прості і зрозумілі прави ла

контролю доступу (перевага), які легко застосову вати на практи ці, але

позбавляє систему теоретичної доказової бази (вада). В деяких ситуаціях ця

обставина утруднює використання РПБ, однак, в будь-якому разі, оперувати

ролями набагато зручніше ніж суб’єктами (знову перевага), оскільки це більш

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

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

115

Однією з найважливішіх властивостей РПБ є її нейтральність, тобто вона

надає апарат для виразу політики безпеки, а не накл адає певні обмеження, що

відповідають певній політиці (подібно вимозі однокерованості інформаційного

потоку в МПБ або подібно ДПБ, яка орієнтована в основному на ресурси і

об'єкти.).

Використовуючи РПБ, можна емулювати дискреційне і мандатне

управління доступом. Це дуже важливо, оскільки можна розробляти системи,

що підтримують РПБ і конфігурувати їх у разі потреби для реалізації ДПБ або

МПБ.

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

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

характеристики:

• орієнтація, тобто на який основний чинник скерована;

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

• адміністративна модель, тобто як співввідносить ся з

адміністративною моделлю керування;

• розуміння розробниками і користувачами;

• ступінь надійності;

• реалізація;

• можливість формального доведення.

Таблиця 3. Порівняння ДПБ, МПБ і РПБ

Характеристика

ДПБ

МПБ

РПБ

Орієнтація

Безпосередній доступ

суб’єктів до об’єктів

Орієнтована на

інформаційні потоки

Орієнтована на

організаційні ролі

Підтримка

системою захисту

Децентралізована

Централізована

Адміністративна

модель

Орієнтована на об'єкти

і ресурси

Утруднення при

відображенні на

адміністративну

модель управління

доступом

Відносно легко

відображається на

адміністративну

модель управління

доступом

Розуміння

розробниками і

користувачами

Складна

Проста

Ступінь

надійності

Низка

Висока

116

Реалізація

Проста

Складна

Проста

Можливсть

формального

доведення

Допускає можливість

точного математичного

доказу нерозв’язності

задачі захищеності

Допускає можливість

точного математичного

доказу задачі

захищеності

Не допускає

можливості точного

математичного

доказу

4.5. Монітор безпеки

Позначимо всю множину потоків S між об’єктами КС в усі моменти часу

t∈N

(тобто множина потоків S є об’єднанн ям потоків по всіх моментах

дискретного часу) і розіб’ємо його на дві підмножи ни, які не перетинаються: F і

∅== LFLFS  ,

, де F – підмножина потоків, що характеризують

несанкціонований доступ (зокрема, приховані по ток и), L – підмножина потоків,

що характеризують легальний доступ.

Поділ множини S на множ ини L і F пов'язаний з поняттям «безпеки» КС,

яке має на увазі наявність стану «небезпеки» – небажаних станів КС. Тому далі

вважається, що парн і категорії типу «небезпечний – безп ечний» апріорно задані

для КС і описуються ПБ, а результат застосування П Б до КС – розподіл на

множину «небезпечних» потоків F і м но ж и н у «безпечних» L. По діл на L і F

повинен ураховувати основні властивості захищеної інформації:

конфіденційність, цілісність, доступність, спостереженість [1-2]. Тобто він

може здійснюватися на основі будь-якої з даних фундаментальних

властивостей захищеної інформації (наприклад, потоки з F порушують

цілісність інформації або КС, потоки з F порушують конфіденційність КС і

т.д.). Потоки, що можуть порушити хоча б одну з цих властивостей є

«небезпечними» і, отже, належать до підмножині F. Канали, за якими

реалізуються такі потоки, називають каналами витоку.

Для реалізації процесу розподілу всієї множини потоків S в КС на

підмножини L і F необхідно існування певної активної компоненти КС, яка

повинна, принаймні:

• активізується при виникненні будь-якого потоку;

• здійснює фільтрацію потоків відповідно до нал ежн ості йо го до

множин L або F.

117

Як показує практичний досвід і теоретичні дослідження протягом всієї

історії ро з в ит ку інформаційн о ї безпеки, наявність цієї компоненти є

необхідною умовою функціонування захищених систем і є настільки важливою,

що цю обставину доцільно сформулювати у вигляді наступної аксіоми.

Аксіома 5. В захищеній КС завжди присутня активна компонента, яка

виконує функцію контролю над операціями між об’єктами і фактично

відповідає за реалізацію певної ПБ.

З аксіоми майже автоматично випливає такий наслідок.

Наслідок 1. Для здійснення операцій з об’єктами в захищеній ІТС

необхідна додаткова інформація (і наявність відповідного об’єкта, що її

містить) про дозволені та заборонені операції.

Такою компонентою є монітор безпеки [3] – ком понента КС, яка

активізується при ви никн ення будь-якого потоку від одного об’єкта до іншого і

дозволяє реалізуватися потокам , що належать тільки множин і легального

доступу L. Викор и ст ов у є тьс я також терм іни диспетчер доступу [1-2], мо ніт о р

звернень [41]. Дозвіл потоку в даному випадку розуміється як виконан ня

операції над об’єктом – отримувачем потоку, а заборона – як невиконання

(тобто незмінність об ’єкт а – отримувача потоку). Таким чином, МБ повністю

приймає участь у потоці від об’єкта до об’єкта і основна його цільова функція –

фільтрація інформаційних потоків для забезпечення безпеки КС, тобто

фактично – це механізм реалізації ПБ в КС. Множина об’єктів, що входять до

складу МБ як компоненти КС, повинна містити підмножину проц есів, з якими

повинні бути асоційовані всі інші об’єкти КС, і, звичайно, хоча б одного

користувача. Всі об’єкты КС повинні бути асоційованими з цім користувачем

(якого зазвичай називают ь адм іністр ато ром безп еки ).

В [1-2] відзначено, що реалізація механізмів захисту, а, отже, і МБ, може

бути різною – можуть використовуватися п рограмні або апаратні засоби,

криптографічні перетворення, різні методи пер евірки повноважень і т.д. Вибір

методів і механізмів залишається за розробником і єдиною вим огою є

118

реалізація функції захисту, причому для МБ повинні виконуватися наступні

загальні вимоги [1-2]:

• МБ повинен забезпечувати неперервний і повний захист;

• бути достовірним (захищени м від модифікаці й);

• мати невеликі (відносно) ро зм іри.

Перша вимога відображує і реалізує фундаментальний принцип захисту

інформації. Д л я реалізації др уг о ї вимоги в ІТС повинна існувати система

перевірки та контролю (повна система тестування), яка завжди може

підтвердити достовірність МБ. Нарешті, остання вимога підкреслює основну

роль МБ як допоміжного механізму контролю інформаційних потоків.

Невеликий розмір та об’єми памяті, що їх використовує МБ, потребують менше

обчислювальних ресурсів, отже більша їх частина відводиться на безпосередню

обробку потоків даних.

Проте при проєктуванні захисних механізмів на основі ціх вимог

необхідно вирішити, якими більш конкретними властивостями має володіти

МБ, щоб реально забезпеч ит и контрол ь над усіма потоками, тобто визначити

умови коректного існування об’єктів К С, які забезпечують реалізацію тої чи

іншої ПБ.

Точно сформулювати і формально описати необхідні умови реалізації МБ

дуже важко. Проте можна описати деякі важливі властивості МБ, якими він

завідомо повинен володіти незалежно від кон кретної ПБ. Се ред цих

властивостей зазначимо наступні:

• при реалізації будь-якої ПБ найважливішим кроком є ідентифікація

всіх об’єктів КС. При цьому повинна мати місце унікальність імен об’єктів, що

дозволяє реалізувати механізм ідентифікації і автентифікації (ІА);

• неможливість доступу до об’єктів без участі МБ: якщо в ∀t∈N

для

∀р⊆A об’єкт

OO ∈

отримав в момент t доступ

OO !→!

OO ∈

, то

∃

k>0, k∈N

таке, що в момент t-k, t-k∈N

відбувся запит на доступ, який

позначатимемо

OO !→!

(відсутність обхідних шляхів). Запит на доступ

119

можна також вважати одним з видів доступу від об’єкта

до інших об’єктів.

Очевидно, що в якості об’єктів-отримувачів доступу до

повинні виступ ати

лише активні об’єкти

NiUU ,...,1, =∈

NjPP ,...,1, =∈

;

• обов’язкова наявність механізму ІА: якщо для ∀t∈N

, ∀р⊆A,

∀

tji

OOO ∈,

має місце

OO !→!

, то МБ однозначно визначає належність

до відповідних множин U, P або O;

• обов’язкова присутність в МБ дозвільного механізму, тобто при запиті

OO !→!

tji

OOO ∈,

в залежності від належності потоку до підмножин L

або F приймається відповідне рішення, і доступ від

до

здійсню єть ся або

ні. Належність визначається на основі правил, що декларуються конкретною

ПБ (наприклад, для дискрецій н ої ПБ – це матриця доступу , дл я ма нд ат н ої ПБ –

міточний контроль)

На основі аналізу критеріїв захищеності інформації в КС [2], де описані

послуги щодо забезпечення захисту інформації, які повинні бути реалізовані

при побудові захищ ених КС, а також загальних вимог до МБ, можн а

сформулювати необхідні умови функціонування МБ.

Теорема. Для викон ан ня основних ці льових функцій МБ – активізації при

виникненні будь-якого потоку в КС та фільтрації інформаційних потоків для

забезпечення безпеки КС, в КС повинні бути реалізовані функції:

1. однозначної ідентифікації усіх об’єктів КС;

2. контролю МБ всіх потоків, визначених ПБ, тобто в КС повинні бути

відсутніми обхідні шляхи ПБ (неможливість доступ у до об’єктів без участі

МБ);

3. ідентифікації і автентифі кац ії у сіх об’єктів при доступі їх в КС;

4. обмеження будь-яких доступів до МБ, за винятком запитів (захист МБ

від модифікації);

5. дозвольного механізму.

120

Доведення. Справедливість даного твердження легко доводиться шляхом

припущення від противного для кожної з перерахованих функцій.

Важливим є питання про визначення МБ обчислювальної мережі при

наявності МБ у окремих компонент мережі, яке розглянемо ан а ло г ічн о [41].

Отже, розглянемо мережу, компоненти якої зв'язані каналами зв'язку, а

кожна з компонент несе деякі функції захисту. Основна вимога при аналізі

безпеки розподіленої системи як одного цілого – це загальна політика безпеки.

Тоді питання захищеності розподіленої системи як одного цілого полягає в

організації узгодженої дії компонент захисту по підтримці політики безпеки

всієї мережі. В ирішенню цієї проблеми протистоять небезпеки поруш ення

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

асинхронного функціонування ком понен т захисту.

Припустимо, що в кожному локальному випадку (тобто в к ож ній з

компонент мережі) певним чином підтримуються функції «свого» МБ.

Зрозуміло, що єдина політика безпеки в мережі зовсім не означає, що всі МБ

компонент підтримують одн у і ту ж п олітику і відповідают ь ви мо г ам одн о го

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

від інших.

Розглянемо питання, коли сукупність МБ в компонентах реалізує МБ у

всій розподіленій мережі. Це питання вирішується наступною теоремою [41].

Теорема. Хай виконані наступні умови.

1. Кожен суб'єкт мережі існує тільки в одній («своїй») компоненті

впродовж всього життєвого циклу.

2. Кожен суб'єкт може мати доступ тільки до об'єктів своєї компоненти.

3. Кожна компонента містить віднесений до нєї МБ, який розглядає тільки

звернення суб'єктів цій компоненти до об'єктів цієї ж компоненти.

4. Всі канали, що зв'язують компоненти, не компрометують безпеку

інформації, яка в ни х п р о хо д ит ь.

Тоді сукупність МБ компонент є МБ мережі.