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

Размещено на http://www.allbest.ru/

ВСТУП

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

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

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

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

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

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

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

операційний система доступ право

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всі суб'єкти та об'єкти системи повинні бути однозначно ідентифіковані;

Правила доступу суб'єктів до об'єктів визначені зовнішнім відносно системи правилом.

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

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

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

Вразливість щодо атак типу «троянський кінь». Це, зокрема, означає, що система захисту, яка реалізує ДПБ, погано захищає від проникнення вірусів у систему.

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

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

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

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

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. Користувач 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 ролями.

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

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

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

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

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

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

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

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

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

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

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

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 взагалі) визначає три типи прав:

На читання (позначається символом "r" Read), що означає що файл може бути прочитаний;

На запис (позначається символом "w" Write), що означає що файл може бути змінено;

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

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

Користувач або Власник - позначається символом "u" (User), той хто володіє файлом;

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

Інші - позначається символом "o" (Others), і уособлює всіх користувачів, що не є ні членами вказаної групи, ні власниками файлу.[10]

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

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

ls -l myfile

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

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

його ім'я, "myfile";

його дозволи, "-rwxr-x---";

його власника, "george";

його групу "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 параметри:

для кого призначений даний дозвіл ("u" -- для власника, "g" - для групи, "o" - для всіх інших, з них можна утворювати комбінації)

дія, що виконується над дозволом ("+" - додати, "-" - прибрати та "=" - встановити)

сам дозвіл (r для читання, w для запису та x для виконання)

файл або група файлів, до яких впроваджуються дозволи

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

chmod o+r myfile - додати дозвіл на читання файлу myfile для усіх інших користувачів;

chmod ug+rx myfile - додати дозвіл на читання (r) та виконання (x) для власника та групи;

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

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

chmod 755 myfile : rwxr-xr-x, усі права для власника, всі інші можуть тільки читати та виконувати;

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]

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

CI - ознака успадкування дозволів контейнерами (Container Inherit). ACE буде успадкований папками.

ОІ - ознака успадкування дозволів об'єктами (Object Inherit). ACE буде успадкований файлами.

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, r2?R, 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. У результаті проблема гарантованого ненадання права доступу вирішується автоматично. Якщо серед індивідуальних або групових призначень користувача до об'єкту є явний заборону на доступ, то всі інші призначені права відкидаються.

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

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