29561

РОЗРОБКА МОДЕЛІ РОЛЬОВОЇ ПОЛІТИКИ БЕЗПЕКИ НА ОСНОВІ ІНДИВІДУАЛЬНО–ГРУПОВОГО РОЗМЕЖУВАННЯ ПРАВ ДОСТУПУ

Курсовая

Информатика, кибернетика и программирование

2 Базова модель рольового розмежування прав доступу 19 РОЗДІЛ II. Побудова моделі на основі рольової політики розмежування прав доступу 22 2.1 Використання моделей розмежування прав доступу в операційних системах.

Украинкский

2013-08-21

84.48 KB

13 чел.

МІНІСТЕРСТВО ОСВІТИ, НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

ВОЛИНСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ

ІМЕНІ ЛЕСІ УКРАЇНКИ

Кафедра прикладної математики

КУРСОВА РОБОТА З КУРСУ

«ТЕОРЕТИЧНІ ОСНОВИ КОМП’ЮТЕРНОЇ БЕЗПЕКИ»

РОЗРОБКА МОДЕЛІ РОЛЬОВОЇ ПОЛІТИКИ БЕЗПЕКИ НА ОСНОВІ

ІНДИВІДУАЛЬНО–ГРУПОВОГО РОЗМЕЖУВАННЯ ПРАВ ДОСТУПУ

Виконав:

студент 43 групи

математичного факультету

Шостак Дмитро Валерійович

Науковий керівник:

Старший викладач

Кафедри прикладної математики

Гопанчук Сергій Олександрович

Луцьк – 2011


Зміст

ВСТУП - 4 -

РОЗДІЛ I. Теоретичні відомості про моделі політик безпеки - 5 -

1.1 Основні поняття - 5 -

1.2 Дискреційна модель - 9 -

1.2.1 Загальні відомості про дискреційну політику безпеки - 9 -

1.2.2 Модель Харрісона–Руззо–Ульмана - 10 -

1.2.3 Модель Take-Grant - 10 -

1.3 Мандатна модель - 12 -

1.3.1 Загальні відомості про мандатну політику безпеки - 12 -

1.3.2 Модель Белла - ЛаПадула - 13 -

1.4 Рольова модель - 15 -

1.4.1 Основні дані про рольову політику безпеки - 15 -

1.4.2 Базова модель рольового розмежування прав доступу - 19 -

РОЗДІЛ II. Побудова моделі на основі рольової політики розмежування прав доступу - 22 -

2.1 Використання моделей розмежування прав доступу в операційних системах. - 22 -

2.1.1 Політика безпеки в ОС типу *nix - 22 -

2.1.2 Права доступу до файлів в ОС типу Windows - 28 -

2.2 Побудова моделі на основі індивідуально-групового розмежування прав доступу - 29 -

2.2.1 Індивідуально-групове розмежування прав доступу - 29 -

2.2.2 Побудова моделі індивідуально-групового розмежування прав доступу - 38 -

Висновки - 41 -

Література - 42 -


ВСТУП

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

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

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

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

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


РОЗДІЛ I. Теоретичні відомості про моделі політик безпеки

1.1 Основні поняття

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

Інформаційна безпека ─ це комплекс заходів, які забезпечує для охоплюваної ним інформації наступні фактори:

─ конфіденційність ─ властивість, яка гарантує, що інформація недоступна і не може бути розкрита несанкціонованими особами, об’єктами чи процесами. Можливість ознайомитись з інформацією мають лише ті особи, які володіють відповідними повноваженнями;

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

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

Термін політика безпеки може бути застосований до організації, комп’ютерної системи, операційної системи (ОС), послуги, що реалізується системою (набору функцій) для забезпечення захисту від певних загроз, і т.д. Чим дрібніший об'єкт, щодо якого вживається цей термін, тим конкретніші й формальніші стають правила.

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

Технології обробки інформації безперервно удосконалюються, а разом з ними змінюються і практичні методи забезпечення інформаційної безпеки. Дійсно універсальних методів захисту не існує, багато в чому успіх при побудові механізмів безпеки для реальної системи буде залежати від її індивідуальних особливостей, облік яких погано подається формалізації. Тому часто інформаційну безпеку розглядають як певну сукупність неформальних рекомендацій з побудови систем захисту інформації того чи іншого типу.[3]

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

До кінця 70-х років були розроблені вихідні моделі безпеки комп'ютерних систем, що забезпечують ті чи інші з трьох складових безпеки інформації, та програмно-технічні рішення побудови і функціонування захищених комп'ютерних систем, зокрема, технології та протоколи парольної аутентифікації, криптографічні методи та засоби захисту інформації і т. д. Однією з найбільш відомих робіт, що представила узагальнений аналіз теоретичних і практичних аспектів захисту комп'ютерної інформації того періоду стала вийшла в 1977 році книга Л.Дж. Хоффмана "Сучасні методи захисту інформації".[2]

Створені моделі дискреційного і мандатного розмежування доступу послужили методологічною основою для розробки перших стандартів безпеки комп'ютерних систем, зокрема, відомої "оранжевої книги", вперше опублікованої в 1983 р.

Сутність загроз інформаційної безпеки зводиться, як правило, до нанесення того чи іншого збитку підприємству (організації). Прояви можливого збитку можуть бути найрізноманітнішими:

─ моральна і матеріальна шкода діловій репутації організації;

─ моральний, фізичний чи матеріальний збиток, пов'язаний з розголошенням персональних даних окремих осіб;

─ матеріальний (фінансовий) збиток від розголошення конфіденційної інформації;

─ матеріал (фінансовий) збиток від необхідності відновлення порушених інформаційних ресурсів, які захищаються;

─ матеріальні збитки (втрати) від неможливості виконання взятих на себе зобов'язань перед третьою стороною;

─ моральний і матеріальний збиток від дезорганізації в роботі всього підприємства. [8]

Дії, які можуть завдати шкоди інформаційній безпеці організації, можна також розділити на кілька категорій:

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

2. «Електронні» методи впливу, які здійснюються хакерами. До таких методів відносяться: несанкціоноване проникнення в комп'ютерні мережі, DOS атаки;

3. Комп'ютерні віруси. Окрема категорія електронних методів впливу -комп'ютерні віруси та інші шкідливі програми. Проникнення вірусу на вузли корпоративної мережі може призвести до порушення їх функціонування, втрат робочого часу, втрати даних, викраденні конфіденційної інформації і навіть прямим розкраданням фінансових коштів. Вірусна програма, яка проникла в корпоративну мережу, може надати зловмисникам частковий або повний контроль над діяльністю компанії.

4. «Природні» загрози. На інформаційну безпеку компанії можуть впливати різноманітні зовнішні фактори. Так причиною втрати даних може стати неправильне зберігання, крадіжка комп'ютерів і носіїв, форс-мажорні обставини і т.д.

Таким чином, у сучасних умовах наявність розвиненої системи інформаційної безпеки стає однією з найважливіших умов конкурентоспроможності і навіть життєздатності будь-якої компанії.[8]


1.2 Дискреційна модель

1.2.1 Загальні відомості про дискреційну політику безпеки

Основою дискреційної політики безпеки (ДПБ) є дискреційне управління доступом (Discretionary Access Control - DAC). Дискреційне управління доступом володіє двома основними властивостями:

  1. Всі суб’єкти та об’єкти системи повинні бути однозначно ідентифіковані;
  2. Правила доступу суб’єктів до об’єктів визначені зовнішнім відносно системи правилом.

Основою дискреційного розподілу прав доступу є матриця прав доступу. Матриця доступів – це матриця розмірності S*O, у котрій рядки відповідають суб’єктам, а стовпці – об’єктам. При цьому кожен елемент матриці доступів M[s,o] визначає права доступу суб’єкта до об’єкту.

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

Щодо недоліків ДПБ, то їх можна поділити на такі основні типи:

  1. Вразливість щодо атак типу «троянський кінь». Це, зокрема, означає, що система захисту, яка реалізує ДПБ, погано захищає від проникнення вірусів у систему.
  2. Автоматичне визначення прав. Оскільки об'єктів багато і їх кількість безперервно змінюється, то задати заздалегідь вручну перелік прав кожного суб'єкта на доступ до об'єктів неможливо. Тому матриця доступу різними способами агрегується, наприклад, суб'єктами залишаються тільки користувачі, а у відповідну клітину матриці вставляються формули функцій, обчислення яких визначає права доступу суб'єкта, породженого користувачем, до об'єкта.
  3. Контроль поширення прав доступу. Найчастіше буває так, що власник файла передає вміст файла іншому користувачеві і той відповідно набуває права власника на цю інформацію. Отже, права можуть поширюватись, і навіть перший власник не хотів передати доступ іншому суб'єкту до своєї інформації, то після кількох кроків передача прав може відбутися незалежно від його волі. Виникає задача про умови, за якими в такій системі певний суб'єкт рано чи пізно отримає необхідний йому доступ.
  4. При використанні ДПБ виникає питання визначення правил поширення прав доступу й аналізу їх впливу на безпеку АС. У загальному випадку при використанні ДПБ органом, який її реалізує і який при санкціонуванні доступу суб'єкта до об'єкта керується певним набором правил, стоїть задача, яку алгоритмічно неможливо розв'язати: перевірити, призведуть його дії до порушень безпеки чи ні.

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

1.2.2 Модель Харрісона–Руззо–Ульмана

Модель Харрісона–Руззо–Ульмана (ХРУ) є однією з перших формальних моделей. У моделі довільна комп’ютерна система з дискреційним управлінням доступом описується певною кількістю матриць доступів, кожна з яких відповідає стану системи, і командами перетворення матриць доступів. Кожна з команд задається певною кількістю параметрів, умовою виконання і кінцевої послідовністю примітивних операторів, перетворюючих матрицю доступів. Застосування команди переводить систему із стану в подальший стан.

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

Методом представлення даних є матриця доступу. Метою моделювання є представлення прав доступу

1.2.3 Модель Take-Grant

Іншим із прикладів моделі дискреційного розмежування прав доступу є модель Take-Grant.

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

На другому етапі розглядається розширена модель Take-Grant, в якій аналізуються умови реалізації в комп’ютерних системах інформаційних потоків. Ціль моделі - дати відповідь на питання про можливості одержання прав доступу суб’єктом системи на об’єкт у стані, описаному графом доступів. У цей час модель Take-Grant одержала продовження як розширена модель Take-Grant , у якій розглядаються шляхи виникнення інформаційних потоків у системах з дискреційним розмежуванням доступу.

Позначимо елементи моделі:

O – множина об’єктів

S – множина суб’єктів

R = {r1, r2, r3, r4, ..., rn } U {t,g} – множина прав доступу

t – право брати

g – право давати

G = (S, O, E) – кінцевий граф

У класичній моделі Take-Grant описуються чотири де-юре правила перетворень графів доступів:

take (r, X, Y, Z) Суб’єкт Z бере у об’єкта X права r на об’єкт Y,

grant (r, X, Y, Z) Суб’єкт Z дає об’єкту X права r на об’єкт Y,

create(r, х, у), Суб’єкт X бере r-доступний об’єкт Y

remove (r, х, у) . Суб’єкт Х видаляє r-доступний об’єкт Y.

Методом представлення даних для даної моделі є граф доступу. Метою моделювання є аналіз шляхів поширення прав доступу.

1.3 Мандатна модель

1.3.1 Загальні відомості про мандатну політику безпеки

Мандатна політика безпеки – це політика безпеки, котра основана на мандатному розмежуванні прав доступу(Mandatory Access Control), яке визначається чотирма умовами:

  1. Всі суб’єкти та об’єкти системи однозначно ідентифіковані;
  2. Задано лінійно впорядкований набір рівнів конфіденційності інформації;
  3. Кожному об’єкту системи присвоєно рівень конфіденційності, котрий відповідає цінності вмісту об’єкта;
  4. Кожному суб’єкту системи присвоєно рівень доступу, котрий визначає рівень довіри до нього в комп’ютерній системі.

Основна ціль мандатної політики безпеки – це запобігання витоку інформації від суб’єктів з високим рівнем доступу до суб’єктів з нижчим рівнем доступу, тобто протидія виникненню в комп’ютерній системі інформаційних потоків «зверху вниз».

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

1. Користувач i має доступ до об'єкта j, тільки якщо його рівень допуску більше або дорівнює рівню класифікації об'єкта j.

2. Користувач i може модифікувати об'єкт j, тільки якщо його рівень допуску дорівнює рівню класифікації об'єкта j.

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

1.3.2 Модель Белла - ЛаПадула

Модель Белла - ЛаПадула (Bell-LaPadula), призначена для керування суб’єктами, тобто активними процесами, що запитують доступ до інформації, і об'єктами, тобто файлами, поданнями, записами, полями або іншими сутностями даної інформаційної моделі.

В моделі об’єкти піддаються класифікації, а кожен суб’єкт зараховується до одного з рівнів допуску до класів об'єктів. Класи й рівні допуску спільно називаються класами або рівнями доступу. Клас доступу складається із двох компонентів. Перший з них – це ієрархічний компонент. Другий компонент являє собою деяку множину неієрархічних категорій, які можуть ставитися до будь-якого рівня ієрархії, своєрідний опис рівня ієрархії.

Так, у військових відомствах США застосовується наступна ієрархія класів (зверху вниз):

– абсолютно секретно;

– секретно;

– конфіденційно;

– без грифа таємності.

Другий компонент міг би, наприклад, приймати значення з наступного списку:

– тільки з допуском по ядерній зброї;

– не для іноземних урядів;

– не для підрядників.

Інший приклад ставиться до приватної компанії, де можливі такі рівні ієрархії (зверху вниз):

– секретно;

– для обмеженого поширення;

– конфіденційно;

– для службового користування;

– для необмеженого поширення.

Другий компонент для тієї ж компанії міг би включати такі категорії:

– не для субпідрядників;

– фінансові дані корпорації;

– дані по зарплаті.

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

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

Методом представлення даних є визначення двох компонентів. Перший з них - це ієрархічний компонент. Другий компонент являє собою деяку множину неієрархічних категорій.

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

1.4 Рольова модель

1.4.1 Основні дані про рольову політику безпеки

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

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

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

Таким чином, політика розмежування доступу в комп'ютерних системах, що автоматизують ті чи інші організаційно-технологічного чи організаційно-управлінські процеси, повинна будуватися на основі функціонально-рольових відносин, що складаються в предметної області КС.

Вперше подібний підхід був розглянутий в кінці 70-х – початку 80-х роках у дослідженнях з процесів розмежування доступу корпорації IBM і отримав назву рольового управління доступом. На початку 80-х років була представлена модель Лендвера-Макліна, що зустрічається в літературі також під назвою MMS-моделі (Military Message System) , що поєднує дискреційний і мандатний принципи розмежування доступу з використанням поняття та механізму ролей. Трохи пізніше з'явилися і формальні визначення рольових основ управління доступом (Role-Based Access Control – RBAC). [7]

Основою рольових моделей, як зазначалося, є введення в суб'єктно-об'єктну модель КС додаткової категорії активних сутностей – ролей. Можна дати наступне формальне визначення ролей:

Роль ─ це активно діюча в системі абстрактна сутність, з якою пов'язаний обмежений, логічно зв'язаний набір повноважень, необхідних для здійснення певної діяльності.

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

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

Справді, по суті, користувачі, що працюють у системі, діють не від свого власного імені ─ вони завжди виконують певні службові обов'язки, тобто виконують деякі ролі, які аж ніяк не пов'язані з їх особистістю. Тому цілком логічно здійснювати керування доступом і призначати повноваження не реальним користувачам, а абстрактним (не персоніфікованим) ролям, які представляють учасників певного процесу обробки інформації. Такий підхід до ПБ дозволяє врахувати розподіл обов'язків і повноважень між учасниками прикладного інформаційного процесу, оскільки з точки зору РПБ має значення не особистість користувача, що здійснює доступ до інформації, а те, які повноваження йому необхідні для виконання його службових обов'язків.

Наприклад, у реальній системі обробки інформації системний адміністратор, менеджер баз даних і прості користувачі. У такій ситуації РПБ дає змогу розподілити повноваження між цими ролями відповідно до їх службових обов'язків: ролі адміністратора призначаються спеціальні повноваження, які дозволять йому контролювати роботу системи і керувати її конфігурацією, роль менеджера баз даних дозволяє здійснювати керування сервером БД, а права простих користувачів необхідним для запуску прикладних програм. Крім того, кількість ролей у системі може не відповідати кількості реальних користувачів ─ один користувач, якщо він має різні повноваження, може виконувати (водночас або послідовно) кілька ролей, а кілька користувачів можуть користуватися однією й тією ж роллю, якщо вони виконують однакову роботу.

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

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

У той же час в таких широко поширених різновидах систем, як СКБД, детальні специфікації функціонально-логічних процедур над даними використовуються повсюдно. Основу обробки даних у реляційних СКБД складають запити, відокремлюються в окремі іменовані операції над даними (інструкції SELECT, INSERT, UPDATE, DELETE), об'єкти даних (таблиці) і результати обробки. Сконструйовані і виражені мовою SQL запити зберігаються в БД разом з даними і становлять окрему групу об'єктів (сутностей) бази даних. Користувачам системи надаються права запускати визначені запити, які можна інтерпретувати як дискреційний спосіб надання повноважень з обробки даних.

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

Введення ролей призводить до двоетапної організації системи розмежування доступу:

I. Створення ролей і визначення їх повноважень (прав доступу до об'єктів);

II. Призначення ролей користувачам системи.

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

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

1. Авторизація в даному сеансі користувача з однієї або декількома дозволеними (призначеними на другому етапі організації доступу) для нього ролями;

2. Дозвіл або заборона суб'єктам користувача доступу до об'єктів системи в рамках повноважень відповідних ролей, з котрими авторизований в даному сеансі користувач.

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

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

1.4.2 Базова модель рольового розмежування прав доступу

У цій моделі комп’ютерна система представляється сукупністю наступних множин:

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

- множини ролей R;

- множини повноважень P;

- множини сеансів С роботи користувачів із системою.

Множина повноважень P у загальному вигляді задається спеціальними механізмами, що об'єднують операції доступу та об'єкти доступу, наприклад, запитами на обробку даних у СУБД, або іншими іменованими процедурами обробки даних, в тому числі можливо високого логічного рівня.

Рольові відносини встановлюються наступними відображеннями множини повноважень системи:

FPR: P x R – відображення множини повноважень на множину ролей;

FUR: U x R - відображення множини користувачів на множину ролей.

Відображення FPR і FUR забезпечують перший і другий етапи процесів організації системи рольового доступу. При цьому відображення FUR може реалізовуватися механізмами однією з базових політик розмежування доступу - матрицею "Користувачі-Ролі", або на основі співвідношення ступенів допуску користувачів і грифів конфіденційності ролей, або на основі співвідношення дозволених тематик користувача і тематики ролей.

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

Fuser: C → U – значенням функції u = Fuser(c) є користувач u U, що здійснює даний сеанс з роботи з системою;

Froles : C → R – значенням функції R = Froles(c) є набір ролей R  R з доступних користувачеві, по яких користувач працює (здійснює доступ) у даному сеансі c С;

Fpermissions: C → P – значенням функції P = Fpermissions(c) є набір повноважень P P, доступних за всіма ролям, задіяним користувачем у даному сеансі з С;

Основне правило (критерій безпеки) рольового доступу визначаєтся наступним чином: 

Система функціонує безпечно, тоді і тільки тоді, коли будь-який користувач u U, що працює в сеансі c С, може здійснювати дії (операції, процедури) в рамках повноваження p P, при умові:

p P, де P = Fpermissions(c).

Неважко помітити, що основний акцент у процесах організації та управління доступом при рольової політиці полягає в особливостях відображення множини користувачів на множину ролей FUR і обмежень, які накладаються на функцію авторизації Froles(C) користувача в даному сеансі p дозволеними йому відношенням FUR ролями.

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

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

Ще однією суттєвою обставиною є можливі відносини між ролями, в тому, числі можлива передача (делегування) повноважень і прав від одних ролей іншим ролям.

Залежно від особливостей вирішення даних питань виділяють кілька різновидів рольових моделей:

• з ієрархічною організацією системи ролей;

• з взаємовиключними на будь-які (всі) сеанси ролями (модель статичного розподілу обов'язків);

• з взаємовиключними на один сеанс ролями (модель динамічного розподілу обов'язків);

• з кількісними обмеженнями за ролями;

• з групуванням ролей і повноважень.


РОЗДІЛ II. Побудова моделі на основі рольової політики розмежування прав доступу

2.1 Використання моделей розмежування прав доступу в операційних системах.

2.1.1 Політика безпеки в ОС типу *nix

Операційна система GNU/Linux, як і UNIX та інші Unix-подібні комп'ютерні операційні системи, взагалі розцінюються як добре захищені. Однак, віруси можуть потенційно пошкодити незахищені системи на Linux і впливати на них, і навіть, можливо, поширюватися на інші системи. Як й інші Unix-подібні ОС, GNU/Linux є багатокористувацькою системою, де користувачам надаються певні привілеї і є реалізована деяка форма контролю доступу.

У GNU/Linux доступ до файлів обмежений. Користувачу необов'язково мати однакові права на редагування, виконання і читання. Фактично кожен файл має інформацію про те хто є його власником, його дозволи (або права, від англійської permisions) та іншу інформацію, що визначає кому і що саме можна робити з файлом.[12]

Особливістю GNU/Linux є те, що звернення до будь якого об'єкту відбувається як до файлу. Як наслідок, директорії мають такий самий набір властивостей та дозволів як і звичайний файл.

У GNU/Linux кожен користувач має свій власний обліковий запис і є членом однієї чи декількох груп. Одночасно з цим кожен файл у системі належить якомусь користувачу а також користувацькій групі. За для розмежування доступу GNU/Linux (та й будь-який Unix взагалі) визначає три типи прав:

  1. На читання (позначається символом "r" Read), що означає що файл може бути прочитаний;
  2. На запис (позначається символом "w" Write), що означає що файл може бути змінено;
  3. На виконання (позначається символом "x" eXecute), що означає що файл може бути виконано, або якщо це директорія, що у ній виконувати пошук.

Для кожного файлу усі три права (читання, запису та виконання) надаються для трьох типів користувачів:

  1. Користувач або Власник - позначається символом "u" (User), той хто володіє файлом;
  2. Група — позначається символом "g" (Group), і уособлює всіх користувачів що належать до групи до якої належить файл (адже файл належить як і групі і користувачеві одночасно).
  3. Інші — позначається символом "o" (Others), і уособлює всіх користувачів, що не є ні членами вказаної групи, ні власниками файлу.[10]

Уся інформація, що відноситься до прав доступу файлу зберігається як атрибути файла, тобто становить з ним одне ціле, і може бути переглянута за допомогою команди "ls -l":

Приклад виводу інформації:

ls -l myfile

-rwxr-x--- 1 george administrators 10 2006-03-09 21:31 myfile

Вивід, який надає команда "ls -l" дає досить багато інформації про "myfile":

  1. його ім'я, "myfile";
  2. його дозволи, "-rwxr-x---";
  3. його власника, "george";
  4. його групу "administrators";

Перший символ просто показує якого типу файл. Наприклад: "-" звичайний файл; "d" директорія; "l" символьне посилання; "s" сокет; "p" іменований потік (named pipe); "c" символьний пристрій (небуферизований) ;"b" блочний пристій (буферизований). У нашому випадку myfile є звичайним файлом.

Роздивимось інші дев'ять символів "rwxr-x---". Перші три символи вказують, чи дозволено читання, зміна чи виконання для власника цього файлу. Якщо так, то відповідні символи (r, w або x) будуть відображені, інакше вони будуть замінені знаками "-". Так само наступні три символи вказують чи дозволені ці дії для користувачів групи (у нашому випадку administrators). Зрештою останні три символи вказують дозволи для усіх інших користувачів.

Отже для нашого випадку набір дозволів файлу myfile "rwxr-x---" означає, що george має права виконувати всі три операції над цим файлом (читати, змінювати та виконувати), користувачі групи administrators можуть тільки читати (r) або виконувати (x) цей файл але не змінювати, а всі інші користувачі з цим файлом не можуть робити ніяких операцій.[11]

Зміна дозволів відбувається з допомогою команди chmod. Ви можете змінювати дозволи своїх файлів (або чужих, якщо ви увійшли до системи як суперкористувач root) за допомогою команди "chmod". Синтаксис цієї команди дуже простий. Наприклад george вирішив надати адміністраторам право на зміну файлу, він вводить команду:

chmod g+w myfile

де g вказує що змінюються дозволи групи, w вказує на дозвіл на зміну файлу, а "+" вказує що зазначений дозвіл треба додати. Після виконання цієї команди адміністратори мають право запису до цього файлу та дозвіл вносити зміни у його зміст. Команда "chmod" приймає 4 параметри:

  1. для кого призначений даний дозвіл ("u" – для власника, "g" – для групи, "o" – для всіх інших, з них можна утворювати комбінації)
  2. дія, що виконується над дозволом ("+" – додати, "-" – прибрати та "=" – встановити)
  3. сам дозвіл (r для читання, w для запису та x для виконання)
  4. файл або група файлів, до яких впроваджуються дозволи

Декілька прикладів використання команди chmod:

  1. chmod o+r myfile - додати дозвіл на читання файлу myfile для усіх інших користувачів;
  2. chmod ug+rx myfile - додати дозвіл на читання (r) та виконання (x) для власника та групи;
  3. chmod a-rwx myfile - прибрати всі права для всіх користувачів системи, включаючи власника;

Команда chmod також має інший синтаксис, що досить популярний серед системних адміністраторів, це запис у вісімковій системі. Замість використання символів u, g, o, a, r, w та x можна скористатися вісімковим числом. Головна перевага такого запису це те що відбувається встановлення повного набору дозволів файлу одночасно (для власника, групи та інших). Таке встановлення дозволів, замість додавання та видалення, не дасть вам випадково чогось пропустити. Кожному дозволу відповідає значення:

дозвіл

значення

0

х

1

w

2

r

4

Якщо вам потрібна комбінація дозволів, то значення додаються. Тобто дозволи можуть приймати значення від 0 (не дано жодного дозволу) до 7 (дозвіл на будь-які дії):

дозволи

значення

дозволи

значення

– – –

0

r – –

4

– – x

1

r – x

5

– w –

2

r w –

6

– w x

3

r w x

7

Врешті, значення задаються для кожного типу користувачів (власника, групи та інших) та ці три цифри (від 0 до 7) подаються разом у вигляді вісімкового числа. Це число ви і можете використовувати у команді "chmod".[11] Наприклад:

chmod 750 myfile

750 означає 7 (rwx) для власника, 5 (r-x) для групи та 0 (---) для інших. Як результат будемо мати дозволи "rwxr-x---". Ця команда еквівалентна такій:

сmod u=rwx,g=rx myfile

chmod o-rwx myfile

Приклади використання такого формату запису:

  1. chmod 755 myfile : rwxr-xr-x, усі права для власника, всі інші можуть тільки читати та виконувати;
  2. chmod 644 myfile : rw-r--r--, власник може читати та змінювати, всі інші тільки читати;

Ви можете передати ваш файл у власність іншому користувачеві, або змінити групу, якій цей файл належить, використовуючи команди відповідно chown та chgrp.[10]

Як приклад, якщо Джордж вирішив віддати файл myfile Роберту, він просто набирає команду:

chown robert myfile

Або якщо пізніше Роберт вирішить зробити цей файл доступним лише користувачам групи senioradmin замість administrators, він дає команду:

chgrp senioradmin myfile

Якщо SGID (Set Group Identification: встановити ідентифікацію групи) атрибут встановлено на директорії, то файли створені у цій директорії будуть належати тій же самій групі, що й директорія, не залежно від групи користувача, що створює файл. Якщо ж SGID не встановлено, то файли будуть належати групі користувача, що створює файл.[11]

Щоб встановити або скинути SGID на директорії використовуйте наступні команди:

chmod g+s directory; chmod g-s directory

За звичай коли користувач виконує якийсь файл, то процес, що виникає під час виконання має ті ж самі права що й користувач, що його запускає. Фактично процес наслідує усі його права. Але якщо ви встановите SUID атрибут на виконуваний файл то процес що буде запущений буде мати права не того користувача, що запустив файл, а того хто володіє файлом.

Як наслідок, коли користувач запустить скрипт, то процес буде використовувати права Джорджа, як власника скрипта, замість прав користувача що запускає. Це вирішує проблему запису до логу, коли ніхто не має права записувати у лог файл але будь–хто має право виконати скрипт, що пише у лог.[12]

Коли атрибути SUID або SGID встановлено, то це буде відображатися символом "s", що замінить "x" у дозволах власника або групи.

Зазвичай, коли umask має значення 0000, нові файли здобувають дозволи 666 (-rw-rw-rw-) а директорії 777 (drwxrwxrwx). Як наслідок, зі значенням umask 0022, нові файли будуть мати дозволи 644 або -rw-r--r-- (666 - 022 = 644) а директорії 755 або drwxr-xr-x (777 - 022 = 755). [10, 11]

Для того щоб змінити значення umask просто дайте команді umask вісімкове число як аргумент. Наприклад, якщо ви хочете щоб усі ваші нові директорії мали дозволи rwxr-xr--- а файли rw-r----- (750 та 640 відповідно), вам треба використати значення umask що видалить усі дозволи для інших та дозвіл на запис для групи: 027. Команда буде виглядати так: umask 027[11]

2.1.2 Права доступу до файлів в ОС типу Windows

Керування правами доступу до інформації дозволяє обмежувати дії, які користувачі можуть виконувати з файлами. Керування правами доступу до інформації обмежує кількість користувачів і програм, що мають права на доступ до цих файлів. За допомогою керування правами доступу до інформації можна також обмежити права користувачів, яким дозволяється читати файли, таким чином, щоб вони не могли виконувати дії, зокрема друкувати копії файлів або копіювати текст із них.[12]

Перегляд та зміна списків управління доступом Access Control Lists(ACL) для файлів та папок.

Списки контролю доступу застосовуються лише до файлів, що зберігаються на відформатованих в NTFS дисках, кожен ACL визначає, які користувачі (або групи користувачів) можуть читати або змінювати файл. Коли створюється новий файл, то він зазвичай успадковує ACL з папки, в якій йог обуло створений. Синтаксис команди наступний:

CACLS шлях_до_файлу [опції]

Тут опції можуть набувати таких значень:

/T   Пошук шляху включаючи всі вкладені папки.

/ E   Редагувати ACL (лишити існуючі права без змін)

/ C   Продовжити при отриманні помилок про відмову в доступі

/ G користувач:дозвіл    Надати права доступу, які можуть набувати значень: R Читати; W Створити; C Змінювати (запис/читання); F Повний контроль.

/ R користувач    Скасування доступу указаного користувача прав (дійсні лише з / E).

/ P користувач:дозвіл    Замінити права доступу, дозвіл може бути: N жодних; R Читати; Створити W; C Зміна (запис / читання); F Повний контроль.

/ D користувач   Заборона на доступ для користувача.[13]

У всіх варіантах вище "користувач" може бути як іменем користувача, так і іменем робочої групи (локальної або глобальної). Ви можете вказати більше однієї пари «користувач:дозвіл» в одній команді. Також можна обирати декілька файлів. Якщо ім'я користувача або групи містить пробіли, то воно повинне бути оточеним лапками, наприклад " Authenticated Users ". Якщо опції не вказані, то CACLS буде відображати списки ACL для файлу(ів). [13, 14]

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

  1. CI – ознака успадкування дозволів контейнерами (Container Inherit). ACE буде успадкований папками.
  2. ОІ – ознака успадкування дозволів об'єктами (Object Inherit). ACE буде успадкований файлами.
  3. IO-ознака виключного успадкування дозволів (Inherit Only). ACE не буде застосовний до поточного файлу / папки.[13]

2.2 Побудова моделі на основі індивідуально-групового розмежування прав доступу

2.2.1 Індивідуально-групове розмежування прав доступу

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

Основні положення моделі індивідуально-групового розмежування доступу зводяться до наступного: система являється сукупністю наступних наборів сутностей:

- Множини об'єктів доступу O (o1, o2, ..., oM);

- Множини користувачів U (u1, u2, ..., uN);

- Множини робочих груп користувачів G (g1, g2, ..., gK);

- Множини прав доступу і привілеїв R (r1, r2, ..., rJ);

- Матрицею доступу A із розмірністю ((N + K) x M), кожна клітинка якої специфікує права доступу і привілеї користувачів або їх робочих груп до об'єктів з кінцевого набору прав доступу і привілеїв R (r1, r2, ..., rJ), тобто A [u, o] R, A [g, o] R.

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

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

Групові відносини в системі встановлюються відображенням множини користувачів на множину робочих груп:

FUG : U x G – таке, що одна робоча група об'єднує декількох користувачів, а один користувач може входити в кілька робочих груп.

Висловлюючись мовою моделей організації даних, можна відзначити, що між сутностями "Робочі групи " і сутностями "Користувачі" встановлюються зв'язки "Багато-до-Багатьох". Дана обставина обумовлена тим, що якщо робочі групи розглядати як агрегування повноважень для виконання користувачами певних функціональних завдань (обов'язків), то в реальних ситуаціях один користувач послідовно, або на постійній основі може виконувати відразу декілька завдань (обов'язків), і йому тим самим необхідні права відразу декількох робочих груп. З іншого боку, подібні завдання можуть вирішуватися відразу кількома користувачами, і, звідси, одна робоча група об'єднує декількох користувачів

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

Функціонування системи індивідуально-групового розмежування доступу ґрунтується на введенні та використанні наступних функцій:

fgroups: U→ G: значенням функції fgroups(u) = G є набір робочих груп G = {gu1, gu2,…} G, в котрі користувач u входить по відношенню FUG;

fusers: G → U: значенням функції fusers(g) є набір користувачів U = {ug1, ug2,…} U, котрих робоча група g включає по відношенню FUG.

В практичному плані реалізація функції fgroups та fusers проводиться за допомогою побудови бінарної матриці "Користувачі - Робочі Групи", комірки якої заповнюються при встановленні відношення FUG.

Управління індивідуально-груповим доступом в системі здійснюється на основі наступного правила (критерію безпеки) індивідуально-групового доступу:

Система функціонує безпечно, тоді і тільки тоді, коли будь-який користувач u U по відношенню до будь-якого об'єкту o O може здійснювати доступ з правами R, що не виходять за межі сукупності індивідуальних прав A [u, o] і прав робочих груп A [g(u)i, o], в які користувач входить по відношенню FUG:

R   {A[u,o] A[gu1, o] A[gu2, o] …}, де

{ gu1, gu2,…} = fgroups(u).

Таким чином, права доступу користувача до об'єкта складаються з його індивідуальних прав і прав усіх робочих груп, в які він включений по відношенню FUG.

При цьому слід зазначити, що робочі групи в повному розумінні слова не є ролями, так як, хоча й представлені в матриці доступу окремими рядками, тим не менш, не реалізуються у вигляді окремих і самостійно діючих суб'єктів доступу КС. У практичному плані це означає, що в КС не ініціалізуются окремі суб'єкти доступу (процеси, запущені програми, і т. п.), що діють від імені робочих груп. Інакше кажучи, в системі індивідуально-групового доступу діють тільки суб'єкти користувачів, права яких у процесах доступу до об'єктів визначаються на основі сукупності індивідуальних і групових прав.

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

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

Зміст і, якщо так можна висловитися, сила моделей індивідуально-групового доступу, визначили їх надзвичайно широке поширення. Через агрегування суб'єктів доступу (користувачів) до робочих груп вдається істотно спростити проектування (синтез) та управління (аналіз) системи дискреційного розмежування доступу в ситуаціях з великою кількістю користувачів і великою кількістю об'єктів доступу, тому що в дискреційних системах, нагадаємо, потрібне окреме і явне "прописування" в матриці доступу (у списках доступу об'єктів) дозволів на доступ для будь-якої пари "Суб'єкт (користувач)-об'єкт" і з будь-якого методу доступу (читання, запис і т. д.). Тому надання користувачам прав доступу до об'єктів через робочої групи дозволяє істотно зменшити кількість індивідуальних призначень, спростити, порядок проектування і аналіз системи колективного доступу до ресурсів системи.

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

У рамках теоретико-множинної моделі прав і привілеїв (множина R) всі конкретні права доступу і привілеї (елементи множини R) рівнозначні і незалежні. Проте в реальності це не завжди так. Наприклад, право Modify "сильніше", тобто охоплює права Write і Read. У більшості випадків можна вважати, що відносини "сили" (охватності) прав (методів) доступу рефлексивно, антисиметрична і транзитивним. У формальному плані це означає, що на множині R встановлюється відношення часткового порядку:

FRR : R x R - відношення, що визначає відносну силу (охватность) одних прав доступу по відношенню до інших прав і задає оператор домінування ≥ таке, що якщо для r1, r2 R, r1 ≥ r2, то право (метод доступу) r1 сильніше, ніж r2, тобто охоплює, включає потоки інформації, що викликаються методом доступу r2.

У результаті просте об'єднання наборів прав при використанні правила доповнюється таким обмеженням:

r1, r2R,  r1 ≥  r2   r2 R      r2 R  , де

R  = {A[u, o] A[gu1, o] A[gu2, o] …};

u і o - користувач і об'єкт доступу, відповідно;

{gu1, gu2,…} = fgroups(u) – набір робочих груп, до яких включено користувач u.

Теоретико-множинне об'єднання індивідуальних і груповихвих прав доступу з урахуванням даного обмеження будемо позначати >. Таким чином, підсумковий набір прав суб'єкта-користувача в системі індивідуально-групового розмежування доступу визначається наступним співвідношенням:

R  = {A[u, o] > A[gu1, o] > A[gu2, o] > …}.

Істотним чинником при визначенні прав доступу, що складаються з кількох можливостям доступу (наприклад, за індивідуальними та груповими призначень; за прямим призначенням до об'єкта і по спадкоємною прав доступу до об'єкта від контейнера), є забезпечення в певних випадках гарантованого ненадання (гарантованого заборони) певному користувачеві визначеного права доступу до певного об'єкту.

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

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

Дозвіл даної проблеми здійснюється двома способами:

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

• введенням специфічного права доступу, іменованого "заборона доступу".

Перший спосіб ґрунтується на введенні для кожного члена робочої групи індивідуального "фільтра" спадкування групових прав.

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

Для права, яке вводиться – "заборона доступу" встановлюється самий високий пріоритет щодо часткового порядку на множині прав доступу R. У результаті проблема гарантованого ненадання права доступу вирішується автоматично. Якщо серед індивідуальних або групових призначень користувача до об'єкту є явний заборону на доступ, то всі інші призначені права відкидаються.

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

Ясно, що з урахуванням сутності робочих груп, як об'єднань користувачів, подібні відносини повинні бути виключно транзитивними. Інакше кажучи, ситуації, коли група А входить до групи В, група В входить до групи С, а група С входить до групи А, неприпустимі і безглузді.

Зрозуміло також, що відносини робочих груп повинні бути антисиметричні – якщо група A входить до групи В, то група В, у свою чергу, не може входити в групу А. Крім того, змістом групи як об'єднанню користувачів не суперечить твердження, що група входить сама в себе, інакше кажучи, відносини груп рефлексивні.

Звідси випливає, що на множині робочих груп G можна встановлювати таке відношення:

FGG: G x G - відношення часткового порядку, що визначає ієрархію (вкладеність) робочих груп і задає оператор домінування ≥ такий, що

Якщо для g1, g2 G,  g1 ≥ g2, то g1 включає g2.

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

f hgroups: G → G: значенням функції f hgroups (g) є набір робочих груп {gg1, gg2,…} G, котрі робоча група g включена по відношенню FGG.

У практичному плані реалізація функції f hgroups спільно з функціями fgroups і fusers може здійснюватися на основі розширення бінарної матриці "Користувачі-Групи" рядками, які відповідатимуть робочим групам системи, тобто побудовою матриці "(Користувачі + Групи)-Групи".

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

У практичних системах проблема транзитивності відносин у системі взаємопов'язаних робочих груп вирішується двома способами:

• побудовою графа включення груп, пошуком та вилученням (розривом) з нього циклів;

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

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

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

Повний набір прав і повноваження Rg робочої групи користувачів g до об'єкта o визначаються сукупністю набору прав і привілеїв A [g, o], безпосередньо наданих цій групі, і набором прав і привілеїв робочих груп A [gg i, o], в які за відношенню FGG може входити дана робоча група:

R g(o) {A[g, o] > A[gg1, o] > A[gg2 , o] > ,…}, де  

{gg1, gg2,…} = f hgroups(g).

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

R   {A[u, o] >R gu1(o) >R gu2(o) > ,…}

де   R gui(o) –  повний перелік прав робочої групи gi, в котру входить користувач u.

Модель індивідуально-групового розмежування прав доступу володіє істотними можливостями при організації колективного доступу до ресурсів в складних системах з великою кількістю користувачів і великою кількістю складно організованих і численних ресурсів. Разом з тим, її використання крім слабкості захисних властивостей дискреційного принципу розмежування доступу, на якому вона ґрунтується, таїть і деякі інші "підводні" камені, такі як надмірність і дублювання в наданні прав доступу користувачів до об'єктів системи. Крім того, в ряді випадків проектування системи робочих груп представляє нетривіальну задачу, і вимагає застосування додаткових теоретико-графових алгоритмів і просторово-векторних моделей.

2.2.2 Побудова моделі індивідуально-групового розмежування прав доступу

Спроба реалізації даного програмного продукту призначена для демонстрації моделі одного з підвидів рольової політики безпеки, а саме індивідуально-групового розмежування прав доступу до файлів. Для реалізації даної моделі політики безпеки обрано середовище програмування Delphi 2007. Це пов’язано з тим, що найкращі навички програмування здобуті саме в цьому середовищі. Також Delphi 2007, на мій погляд, повністю дозволяє виконати поставлені задачі – побудувати демонстраційний приклад для ілюстрування роботи з індивідуально-груповим розмежуванням прав доступу.

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

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

Другим є модуль файлового менеджера. Він дає змогу обрати файл із робочої піддиректорії Work_dir та надати доступ до нього у відповідності із наявними правами доступу користувача або групи, до якої він входить. До прав доступу належать права на запис, читання, видалення файлу. Дані права зберігаються разом із списком файлів директорії Work_dir у робочому файлі «files» в директорії програми. Також у цьому вікні користувач може створити новий файл, задавши йому ім’я у відповідному полі та натиснувши кнопку «Створити файл». Поточному користувачу буде надано необмежені права доступу на створюваний файл.

Третім модулем є вікно адміністраторської панелі. Цей модуль забезпечує можливість зміни повноважень користувачів. Від імені адміністратора можливо задати користувачу належність до групи і цим самим змінити його права доступу. Доступ до файлового менеджера користувачу не надається. Із вікна адміністраторської панелі можна переглянути журнал подій, котрі відбувалися в системі.

Журнал подій дозволяє адміністратору переглядати події, котрі відбулися в системі, що дозволяє аналізувати стан системи. В ході роботи програми в файл «log» вноситься службова інформація щодо стану системи. В вікні журналу подій можна спостерігати інформацію з цього файлу. Інформація про кожну подію містить 3 компоненти: який користувач працював із системою в поточний момент, час та дата події та власне сам опис події. У випадку, коли не потрібно переглядати усю інформацію з журналу, є можливість фільтрувати виведену інформацію. Для цього в нижній частині вікна передбачено основні компоненти вмісту журналу. Можна прибрати галочки навпроти певних даних – тоді інформацію про них не буде показано в журналі.

Запустивши програму, ви потрапляєте до головного вікна програми. Якщо ви маєте створені логін та пароль – введіть їх в відповідні поля та натисніть «Увійти». В протилежному випадку введіть нові дані та натисніть кнопку «Новий користувач». Буде створеного нового користувача та вас буде перенаправлено на вікно файлового менеджера.

Вікно файлового менеджера в лівій частині містить список файлів робочої папки(Work_dir). Справа вказано цінність файлу, а також можливості роботи з файлами (створити файл, видалити файл).

При залогіненні від імені адміністратора, буде відкрито вікно адмінпанелі. На ній вказано дані про користувачів, можливість змінювати належність до груп користувачів. Також передбачено можливість перегляду журналу аудиту, при натисненні кнопки «переглянути лог».

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

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


Висновки

Отже, в ході створення даної курсової роботи було проведено вивчення та аналіз існуючих політик безпеки. Показано основи дискреційного та мандатного розмежування прав доступу, більш детально розглянуто розмежування доступу на основі ролей. Для кожної з політик безпеки описано приклади конкретних реалізацій. Розглянуто модель Харрісона–Руззо–Ульмана, Take-Grant, Белла – ЛаПадула.

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

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

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


Література

  1. Модели безопасности компьютерных систем: Учеб. пособие для студентов высших учебных заведений / Петр Николаевич Девянин. — М.: Издательский центр «Академия», 2005. — 144 с. ISBN 5-7695-2053-1
  2. ОБЗОРНЫЕ ЛЕКЦИИ ПО МОДЕЛЯМ БЕЗОПАСНОСТИ КОМПЬЮТЕРНЫХ СИСТЕМ П.Н. Девянин Институт криптографии, связи и информатики, г. Москва, Россия
  3. В.Л. Цирлов Основы информационной безопасности автоматизированных систем ISBN 978-5-222-13164-0 Феникс 2008
  4. Ярочкин В.И. Информационная безопасность: учебник для студентов вузов – М. Гаудеамус, 2ое изд. – 2004
  5.  Девянин П.Н.Модели безопасности компьютерных системISBN: 5-7695-2053-1 Издательский центр "Академия" 2005
  6.  http://ru.wikipedia.org/wiki/Информационная_безопасность
  7.  http://ru.wikipedia.org/wiki/Политика_безопасности
  8. «Теоретические основы компьютерной безопасности» профессор кафедры алгебры и дискретной математики Н.А. Гайдамакин Екатеринбург 2008 http://elar.usu.ru/bitstream/1234.56789/1778/6/1335332_schoolbook.pdf 
  9. http://www.otzzi.com/Finformation/Fpolituka-informacijnoji-bezpeku-.doc
  10.  http://www.nbuv.gov.ua/portal/natural/Mtit/2010_52/14.pdf
  11.  http://ipeacocks.blogspot.com/2009/04/gnulinux.html
  12.  http://www.linuxforums.org/security/file_permissions.html
  13.  http://wiki.univ.uzhgorod.ua/index.php/Розмежування_доступу_до_ресурсів_ОС
  14.  http://ss64.com/nt/cacls.html
  15.  http://en.wikipedia.org/wiki/Cacls

 

А также другие работы, которые могут Вас заинтересовать

15368. Анализ развития перестрахования в России 247.5 KB
  Содержание Введение 1. Понятие перестрахования и его назначение 1.1 Сущность и теоретические основы перестрахования 1.2 Виды перестрахования 1.3 Функции перестрахования 1.4 Нормативноправовая основа перестрахования 2. Анализ развития перестрахования в России ...
15369. Повышение эффективности производства подсолнечника на примере ООО Лосево 1.28 MB
  Основы экономики производства подсолнечника 5 Народнохозяйственное значение производства подсолнечника 5 Состояние и основные тенденции развития рынка 9 подсолнечника в России Краткая характеристика ООО Лосево
15370. Понятие и виды освобождения от наказания 191.5 KB
  Проявившиеся в последнее время тенденции широкого применения к лицам, впервые совершившим преступления не только небольшой, но и средней тяжести, института освобождения от наказания, нуждается в дальнейшем изучении с целью выявления необходимости последующего изменения уголовного закона и эффективности его применения
15371. Правовые основы доходов и расходов, финансирования 187 KB
  Термин «государственные доходы» употребляется в литературе и правовых актах в двояком значении. С одной стороны, этим термином обозначается определенная группа экономических распределительных отношений, а с другой – материальные носители этих отношений – финансовые ресурсы государства
15372. Принципы гражданского процессуального права 205 KB
  Данная курсовая работа состоит из: введения, в котором описываются задачи, цели, предмет и объект данного научного исследования; основной части, состоящей из трех глав. Первые две главы раскрывают непосредственно содержание принципов гражданского судопроизводства
15373. Психология мотивации человека 163.5 KB
  Введение Проблема мотивации и мотивов поведения в деятельности – одна из основных в психологии. Вряд ли найдется такая область психологии которая не затрагивала бы мотивационного процесса. В настоящее время мотивация как психическое явление трактуется поразному....
15374. Развитие толерантности в системе образования - как объективная потребность современного общества 225 KB
  Курсовая работа Тема: Развитие толерантности в системе образования как объективная потребность современного общества. Развитие толерантности является объективной потребностью современного общества. В услов
15375. Разработка целевого рынка витаминных препаратов 775 KB
  Целью данной работы является разработка целевого рынка витаминных препаратов для гипотетической фирмы на рынке Санкт-Петербурга. Для этого будет проведено маркетинговое исследование рынка витаминных препаратов
15376. Оценка бюджетной эффективности инновационного проекта 308.5 KB
  Введение Современный бизнес является инновационным. Развитие невозможно без инноваций а инновации в свою очередь – без инвестиций. Для финансирования инновационно-инвестиционных проектов используются разнообразные источники и механизмы в том числе и кредиты. Дл