Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Політика безпеки.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Посібник
Предмет:
Засоби захисту інформації
Частина тексту файла (без зображень, графіків і формул):
Політика безпеки
Розділ присвячено одному з фундаментальних понять інформаційної безпеки - політиці безпеки.
4.1. Поняття політики безпеки
Фундаментальним поняттям захисту інформації є політика безпеки (ПБ), або політика захисту. Важливість цього поняття важко переоцінити - існують ситуації, коли правильно сформульована політика є чи не єдиним механізмом захисту від НСД.
З ПБ пов'язується поняття оптимальності рішень з організації та підтримки системи захисту. Іноді вдається досягти загально прийнятного розуміння оптимальності прийнятого рішення і навіть довести його існування. Однак, коли розв'язок багатоальтернативний, то загально прийнятного розуміння оптимальності немає, а в тих випадках, коли розглядається питання про оптимальний у якомусь сенсі розв'язок, то його існування, частіше за все, вдається довести лише в окремих задачах [7].
Подібна ситуація існує і в задачах захисту інформації, оскільки неоднозначним є рішення про те, що система захищена. Крім того, система захисту - не самоціль, а має лише підпорядковане значення і має виконувати підпорядковану функцію порівняно з головною метою обчислювального процесу. Наведемо приклади.
Приклад 4.1. Нехай два відділи в деякій організації ведуть розробки двох проблем. Кожний з відділів користується своїми базами даних, у тому числі і для збору інформації про вирішення проблем. Припустимо, що серед множин задач першого і другого відділів виявилися однакові. На жаль, звичайний офіцер служби безпеки, що дозволяє чи забороняє доступ до баз, не в змозі встановити, що в двох базах накопичується інформація з вирішення одного і того ж завдання. Розглянемо різні рішення офіцера щодо забезпечення безпеки інформації.
Якщо він дозволить доступ відділів до баз один одного, то співробітники одного з них, взявши інформацію з іншої бази чи зі своєї, анонімно, і тому безкарно, зможуть продати цю інформацію, тому що немає персональної відповідальності (неможливо встановити, хто саме продав інформацію з даної бази). При цьому безкарність іноді може навіть стимулювати злочин.
Якщо він не дозволить доступ відділів до баз один одного, то виникає небезпека збитків через недоступність інформації (одні вирішили завдання, а інші - ні; тоді завдання іншого відділу виявиться невирішеним, через що можливі великі збитки для фірми, тому що відповідну проблему могли вирішити конкуренти).
Очевидно, що в обох випадках досягається зменшення однієї небезпеки за рахунок зростання іншої.
Приклад 4.2. Нехай у базі даних збирається інформація про здоров'я приватних осіб, яка у більшості країн вважається конфіденційною. База даних потрібна, тому що ця інформація дозволяє ефективно робити діагностику. Якщо доступ до цієї бази з точки зору захисту інформації сильно обмежений, то в такій базі не буде користі для лікарів, які ставлять діагнози, і не буде користі від самої бази. Якщо доступ відкрити, то можливий витік конфіденційної інформації, за який через суд може бути поданий великий позов. Яким має бути оптимальне рішення?
Результатом рішення в наведених прикладах та інших аналогічних задачах є вибір правил розподілу і збереження інформації, а також поводження з інформацією, що й називається політикою безпеки.
Під поняттям ПБ інформації розуміється організована сукупність документованих керівних рішень, спрямованих на захист інформації й асоційованих з нею ресурсів системи. ПБ викладає систему поглядів, основних принципів, практичних рекомендацій і вимог, що закладаються в основу реалізованого в системі комплексу заходів із захисту інформації.
Формування ПБ є дуже складним аналітичним процесом, який важко формалізувати. Існують різні типи конкретних політик, причому деякі з них передбачають достатньо високий рівень формалізації. Більше того, існують точні доказові методи оцінки ПБ.
Дотримання ПБ має забезпечити виконання того компромісу між альтернативами, який вибрали власники цінної інформації для її захисту. Вочевидь, будучи результатом компромісу, ПБ ніколи не задовольнить усі сторони, що беруть участь у взаємодії з інформацією, що захищається. У той же час вибір ПБ - це кінцеве вирішення проблеми: що - добре і що - погано при роботі з цінною інформацією. Після прийняття такого рішення можна будувати захист, тобто систему підтримки виконання правил ПБ. Таким чином, побудована система захисту інформації добра, якщо вона надійно підтримує виконання правил ПБ. Навпаки, система захисту інформації погана, якщо вона ненадійно підтримує ПБ.
Таке вирішення проблеми захищеності інформації та проблеми побудови системи захисту дозволяє залучити точні математичні методи. Тобто довести, що дана система в заданих умовах підтримує ПБ. У цьому суть доказового підходу до захисту інформації, який дозволяє говорити про «гарантовано захищену систему». Смисл «гарантованого захисту» в тому, що при дотриманні початкових умов свідомо виконуються всі правила ПБ. Термін «гарантований захист» уперше зустрічається в стандарті міністерства оборони США щодо вимог до захищених систем («Оранжева книга»).
Відзначимо відмінність ПБ від уживаного поняття НСД. Перша відмінність полягає в тому, що політика визначає як дозволені, так і недозволені доступи. Друга відмінність - ПБ за своїм визначенням конструктивна, може бути основою визначення деякого автомата чи апарата для своєї реалізації.
Приклад 4.3. Сформулюємо просту політику безпеки в деякій установі. Ціль, що стоїть перед захистом - забезпечення таємності інформації. ПБ полягає в наступному: кожен користувач послуговується своїми і тільки своїми даними, не обмінюючись з іншими користувачами. Легко побудувати систему, що підтримує цю політику. Кожен користувач має свій персональний комп'ютер у персональній охоронюваній кімнаті, куди не допускаються сторонні особи. Легко бачити, що сформульована вище політика реалізується в цій системі. Будемо називати таку політику тривіальною розмежувальною (дискреційною) політикою.
ПБ визначається неоднозначно і, звичайно, завжди пов'язана з практичною реалізацією системи і механізмів захисту. Наприклад, ПБ у прикладі 4.3 може цілком змінитися, якщо в організації немає достатнього числа комп'ютерів і приміщень для підтримки цієї політики.
Побудова політики безпеки звичайно відповідає таким крокам:
крок. В інформацію вноситься структура цінностей і проводиться аналіз ризику.
крок. Визначаються правила для будь-якого процесу користування даним видом доступу до елементів інформації, що має дану оцінку цінностей.
Однак реалізація цих кроків є складним завданням. Результатом помилкового чи бездумного визначення правил ПБ, як правило, є руйнування цінності інформації без порушення політики. Таким чином, навіть добра система захисту може бути «прозорою» для зловмисника при поганій ПБ.
Розглянемо приклади.
Приклад 4.4. Нехай банківські рахунки зберігаються в зашифрованому вигляді у файлах ЕОМ. Для зашифрування, природно, використовується блокова система шифру, що для надійності реалізована поза комп'ютером і оперується за допомогою довіреної особи. Прочитавши в книгах про добрі механізми захисту, служба безпеки банку переконана, що якщо шифр стійкий, то зазначеним способом інформація добре захищена. Справді, прочитати її при надійному шифрі неможливо, але службовець банку, що знає стандарти заповнення рахунків і має доступ до комп'ютера, може замінити частину шифротексту у своєму рахунку на шифротекст у рахунку багатого клієнта. Якщо формати збіглися, то рахунок такого службовця з великою імовірністю зросте. У цьому прикладі гра йде на те, що в такій ситуації небезпека для цілісності інформації є значно вищою від небезпек для порушення таємності, а обрана ПБ добре захищає від порушень таємності, але не орієнтована на небезпеку для цілісності.
Приклад 4.5. Якщо невдало вибрати ПБ, то можна показати, користувач, що не має доступу до секретної інформації, реалізує витоку секретних даних про те, де в пустелі знаходиться колодязь водою (нехай, для простоти, у розглянутій місцевості є тільки оді колодязь). Отже, інформація про карту будь-якої ділянки пустелі є не секретною, але координати колодязя є секретною інформацією, одержання секретної інформації користувач робить послідовність запитів у базу даних, причому кожен наступний запит (можна говорити кроки алгоритму користувача) визначається відповіддю на попередній.
/ крок. Розбивається район (для зручності - прямокутник) на тикальні смуги і робиться запит на ці ділянки в базу даних. Відповідно до вибраної ПБ відповідь подається у двох формах:
• відмова від показу карти, якщо вона секретна, оскільки користувачеві, що не має допуску до секретної інформації, база даних, природно, не повинна її показувати;
• представлення карти на екрані, якщо ділянка не містить колодязя.
Якщо є відмова в доступі, то висновок - в даній смузі є колодязь.
2 крок. Смуга, де є колодязь (тобто де є відмова в доступі), розбивається на окремі ділянки по горизонталі, і знову робиться запит у базу даних. Відмова знову означає, що в даній ділянці є колодязь.
У результаті обчислюються координати колодязя, причому це можна зробити з будь-якою заданою точністю (залежно від рівня дискретизації ділянок пустелі). Таким чином, ПБ дотримана, однак відбувся витік секретної інформації.
Зрозуміло, що ПБ можна підкоригувати таким чином: нехай будь-який користувач одержує карту за запитом, але користувач з допуском до секретної інформації одержує карту з нанесеним колодязем, а користувач без такого доступу - без колодязя. У цьому випадку канал, побудований вище, не працює і ПБ надійно захищає інформацію.
Згідно з [17] під ПБ інформації слід розуміти набір законів, правил, обмежень, рекомендацій і т. ін., які регламентують порядок обробки інформації і спрямовані на захист інформації від певних загроз. Термін «політика безпеки» може бути застосований щодо організації, АС, ОС, послуги, що реалізується системою (набору функцій), і т. ін. Чим дрібніший об'єкт, до якого застосовується даний термін, тим конкретнішими і формальнішими стають правила. Далі для скорочення замість словосполучення «політика безпеки інформації» може використовуватись словосполучення «політика безпеки», а замість словосполучення «політика безпеки інформації, що реалізується послугою» - «політика послуги» і т. ін.
ПБ інформації в АС є частиною загальної політики безпеки організації і може успадковувати, зокрема, положення державної політики у галузі захисту інформації. Для кожної АС ПБ інформації може бути індивідуальною і залежить від технології обробки інформації, що реалізується, особливостей ОС, фізичного середовища і багатьох інших чинників. Тим більше одна й та сама АС може реалізовувати декілька різноманітних технологій обробки інформації. Тоді і ПБ інформації в такій АС буде складеною, і її частини, що відповідають різним технологіям, можуть істотно відрізнятись.
ПБ інформації, що реалізуються різними КС, будуть відрізнятися не тільки тим, що реалізовані в них функції захисту можуть забезпечувати захист від різних типів загроз, а й у зв'язку з тим, що ресурси КС можуть істотно відрізнятись. Так, якщо операційна система оперує файлами, то СУБД має справу із записами, розподіленими в різних файлах.
Для визначення і формалізації процесу розробки ПБ в деякій організації звичайно необхідно розробляти два комплекти документів [28]:
1. Узагальнена політика (program-level).
2. Проблемно-орієнтована (окрема) політика (issue-specific). Основна функція узагальненої ПБ є визначення програми ЗІ, призначення відповідальних за її виконання осіб, формулювання цілей і об'єктів захисту, а також вироблення схеми для забезпечення додержання розроблених правил і вказівок. Компонентами узагальненої ПБ вважаються призначення, сфера поширення, визначення цілей ЗІ, розподіл відповідальності за виконання і методи забезпечення додержання правил.
Проблемно-орієнтована ПБ необхідна для виділення певних проблемних сфер і визначення позицій організації щодо них.
Якщо узагальнена ПБ описує глобальні аспекти ЗІ і її схему, то окремі ПБ розробляються для деяких видів діяльності й у деяких випадках для конкретних систем (наприклад, для захисту електронної кореспонденції). Таким чином, окремі ПБ стандартизують роботу і зменшують потенційний ризик, який виникає при некоректному використанні інформаційних ресурсів. Проблемно-орієнтована ПБ частково визначає керівні принципи при створенні функціональних інструкцій для співробітників організації. Формуючи окрему ПБ, виділяють такі її компоненти: формулювання проблеми, визначення позиції організації, визначення сфери поширення, ролей і відповідальності, а також призначення осіб для контактів у даному питанні. Частина ПБ, яка регламентує правила доступу користувачів і процесів до ресурсів КС, складає правила розмежування доступу (ПРД) (access mediation rules).
Створення життєздатної ПБ - важливе і складне завдання, яке вимагає розуміння цілей ЗІ, а також потенційної користі від її розробки. Тому необхідно розробляти структурні підходи для формування ПБ, які включали б способи розподілу обов'язків, підходи для розробки узагальненої й окремих компонент у вигляді узгодженої політики ЗІ, а також рекомендації щодо формування на її основі наборів функціональних інструкцій. Політика ЗІ допомагає визначити стандарти, керівні інструкції і правила для всіх працівників в організації.
Таким чином, до складу будь-якої СЗІ обов'язково має входити ПБ та набір апаратних і програмних компонент, використання яких регламентовано політикою, що забезпечує збереження інформації. Для більшої впевненості в надійності СЗІ необхідна також наявність строгих доказів її повноти і коректності.
Основними етапами формального підходу до перевірки СЗІ на повноту і коректність є:
визначення об'єктів і цілей захисту;
розробка політики;
доведення того, що при її додержанні інформація не компрометується відповідно до п. 1;
визначення набору функцій для підтримки політики;
доведення того, що набір функцій забезпечує додержання політики;
вибір апаратного і програмного забезпечення для реалізації функцій ЗІ.
Для формального доведення у пунктах 3 і 5 можуть використовуватися математичні методи, якщо сама ПБ була визначена достатньо строго, можливо, у термінах деякої формальної мови. Популярні підходи до формалізації ґрунтуються на станах системи або на її діях. У підході, який ґрунтується на станах, функціонування системи розглядається як послідовність станів, де стан - це набір значень множини змінних. Підхід, який ґрунтується на діях, розглядає діяльність системи у вигляді набору реакцій на події. Ці два різних підходи в певному сенсі еквівалентні. Дії можуть бути змодельовані зміною стану, а стани можуть бути представлені класами еквівалентності послідовностей дії. Однак описані підходи звичайно базуються на різних формальних теоріях. Моделювання станів у більшості випадків ґрунтується на логіці, а специфікації представляються формулами в деякій логічній системі. При моделюванні дії звичайно користуються алгеброю, а специфікаціями є об'єкти, з якими оперують алгебраїчними методами. Основою доведень, які проводяться в п. З і 5, як правило, є набір теорем. Однак проводити подібний аналіз для кожної системи складно і дорого. Крім того, методика проведення аналізу державних систем - конфіденційна інформація. Вихід було знайдено в тому, що умови теорем, які доводять підтримку ПБ, формулюються без доведення у вигляді стандарту. Саме такий підхід уперше застосували американці 1983 року, опублікувавши відкрито проект стандарту з ЗІ в електронних системах обробки даних («Оранжева книга»), де сформульовано вимоги гарантованої підтримки двох класів політик - дискреційної та мандатної. Пізніше цей метод було застосовано в 1987 р. для опису гарантовано захищених розподілених мереж, у яких підтримуються ті самі політики, а в 1991 p.- для опису вимог гарантовано захищених баз даних. Цей же шлях використали канадці і європейські держави, створивши свої стандарти з ЗІ. В Україні також розроблено стандарт захисту, аналогічний канадському. Наведені вище підходи до формалізації політики ЗІ дають можливість проаналізувати розроблені стандарти на повноту і коректність.
4.2. Види політик безпеки
Серед ПБ найбільш відомі дискреційна, мандатна та рольова. Перші дві досить давно відомі і досліджені [6,7], а рольова політика є недавнім досягненням теорії та практики захисту інформації [32].
Основою дискреційної політики безпеки (ДПБ) є дискреційне управління доступом (Discretionary Access Control - DAC), яке визначається двома властивостями:
всі суб'єкти і об'єкти повинні бути однозначно ідентифіковані;
права доступу суб'єкта до об'єкта системи визначаються на основі деякого зовнішнього відносно системи правила.
Назва пункту є дослівним перекладом терміна Discretionary policy, ще один варіант перекладу - розмежувальна політика. Ця політика - одна з найпоширеніших у світі, в системах по умовчанню мається на увазі саме ця політика.
ДПБ реалізується за допомогою матриці доступу (access matrix), яка фіксує множину об'єктів та суб'єктів, доступних кожному суб'єкту.
Існує декілька варіантів завдання матриці доступу.
Листи можливостей (privilege list, profile): для кожного суб'єкта створюється лист (файл) усіх об'єктів, до яких він має доступ.
Листи контролю доступу (access control list): для кожного об'єкта створюється список усіх суб'єктів, що мають доступи до нього.
До переваг ДПБ можна віднести відносно просту реалізацію відповідних механізмів захисту. Саме цим зумовлений той факт, що більшість поширених сьогодні захищених АС забезпечують виконання положень ДПБ. Крім того, при її реалізації досягається велика економія пам'яті, оскільки матриця доступів звичайно буває дуже розрядженою.
Однак багатьох проблем захисту ця політика розв'язати не може. Наведемо найбільш суттєві вади ДПБ.
Один із найсуттєвіших недоліків цього класу політик - те, що вони не витримують атак за допомогою «Троянського коня». Це, зокрема, означає, що СЗІ, яка реалізує ДПБ, погано захищає від проникнення вірусів у систему й інших засобів прихованої руйнівної дії.
Наступна проблема ДПБ - автоматичне визначення прав. Так як об'єктів багато і їх кількість безперервно змінюється, то задати заздалегідь вручну перелік прав кожного суб'єкта на доступ до об'єктів неможливо. Тому матриця доступу різними способами агрегується, наприклад, як суб'єкти залишаються тільки користувачі, а у відповідну клітину матриці вставляються формули функцій, обчислення яких визначає права доступу суб'єкта, породженого користувачем, до об'єкта. Звичайно, ці функції можуть змінюватися з часом. Зокрема, можливе вилучення прав після виконання деякої події. Можливі модифікації, які залежать від інших параметрів.
Ще одна з найважливіших проблем при використанні ДПБ – це проблема контролю поширення прав доступу. Найчастіше буває, що власник файла передає вміст файла іншому користувачеві і той, таким чином, набуває права власника на цю інформацію. Отже, права можуть поширюватися, і навіть якщо перший власник не хотів пере дати доступ іншому суб'єкту до своєї інформації, то після декількох кроків передача прав може відбутися незалежно від його волі. Виникає задача про умови, за якими в такій системі деякий суб'єкт рано чи пізно отримає необхідний йому доступ.
При використанні ДПБ виникає питання визначення правил поширення прав доступу й аналізу їх впливу на безпеку АС. У загальному випадку при використанні ДПБ перед органом, який її реалізує і який при санкціонуванні доступу суб'єкта до об'єкта керується деяким набором правил, стоїть задача, яку алгоритмічно розв'язати неможливо: перевірити, призведуть його дії до порушень безпеки чи ні.
Отже, матриця доступів не є тим механізмом, який дозволив би реалізувати ясну і чітку СЗІ в АС. Більш досконалою ПБ виявилася мандатна ПБ.
Основу мандатної (повноважної) політики безпеки (МПБ) становить мандатне управління доступом (Mandatory Access Control - МАС), яке передбачає, що:
всі суб'єкти і об'єкти повинні бути однозначно ідентифіковані;
задано лінійно упорядкований набір міток секретності;
кожному об'єкту системи присвоєна мітка секретності, яка визначає цінність інформації, що міститься в ньому - його рівень секретності в АС;
кожному суб'єкту системи присвоєна мітка секретності, яка визначає рівень довіри до нього в АС - максимальне значення мітки секретності об'єктів, до яких суб'єкт має доступ; мітка секретності суб'єкта називається його рівнем доступу.
Основна мета МПБ - запобігання витоку інформації від об'єктів з високим рівнем доступу до об'єктів з низьким рівнем доступу, тобто протидія виникненню в АС інформаційних каналів зверху вниз. Вона оперує, таким чином, поняттями інформаційного потоку і цінності (певним значенням мітки секретності) інформаційних об'єктів.
Цінність інформаційних об'єктів часто дуже важко визначити. Однак досвід показує, що в будь-якій АС майже завжди для будь-якої пари об'єктів X та У можна сказати, який із них більш цінний. Тобто можна вважати, що таким чином фактично визначається деяка однозначна функція с(Х), яка дозволяє для будь-яких об'єктів X і Y сказати, що коли Y більш цінний об'єкт, ніж X, то c(Y) > с(Х). І навпаки, з огляду на однозначність, якщо c(Y) > с(Х), то Y - більш цінний об'єкт, ніж Х. Тоді потік інформації від Х до X дозволяється, якщо с(Х) < с(Y), і не дозволяється, якщо с(Х) > с(Y).
Таким чином, МПБ має справу з множиною інформаційних потоків, яка ділиться на дозволені і недозволені дуже простою умовою - значенням наведеної функції. Інакше кажучи, управління потоками інформації здійснюється через контроль доступів.
МПБ в сучасних системах захисту на практиці реалізується мандатним контролем. Він реалізується на найнижчому апаратно-програмному рівні, що дозволяє досить ефективно будувати захищене середовище для механізму мандатного контролю. Пристрій мандатного контролю називають монітором звернень. Мандатний контроль ще називають обов'язковим, оскільки його має проходити кожне звернення суб'єкта до об'єкта, якщо вони знаходяться під захистом СЗІ. Організується він так: кожний об'єкт має мітку з інформацією про свій рівень секретності; кожний суб'єкт також має мітку з інформацією про те, до яких об'єктів він має право доступу. Мандатний контроль порівнює мітки і приймає рішення про допуск.
Найчастіше МПБ описують у термінах, поняттях і визначеннях властивостей моделі Белла-Лападула [5]. У рамках цієї моделі доводиться важливе твердження, яке вказує на принципову відмінність систем, що реалізують мандатний захист, від систем з дискреційним захистом: якщо початковий стан системи безпечний і всі переходи системи зі стану до стану не порушують обмежень, сформульованих ПБ, то будь-який стан системи безпечний.
Наведемо ряд переваг МПБ порівняно з ДПБ.
Для систем, де реалізовано МПБ, характерним є більш високий ступінь надійності. Це пов'язано з тим, що за правилами МПБ відстежуються не тільки правила доступу суб'єктів системи до об'єктів, а й стан самої АС. Таким чином, канали витоку в системах такого типу не закладені первісно (що є в положеннях ДПБ), а можуть виникнути тільки при практичній реалізації систем внаслідок помилок розробника.
Правила МПБ більш ясні і прості для розуміння розробниками і користувачами АС, що також є фактором, який позитивно впливає на рівень безпеки системи.
МПБ стійка до атак типу «Троянський кінь».
МПБ допускає можливість точного математичного доведення, що дана система в заданих умовах підтримує ПБ.
Однак МПБ має дуже серйозні вади - вона складна для практичної реалізації і вимагає значних ресурсів обчислювальної системи. Це пов'язано з тим, що інформаційних потоків у системі величезна кількість і їх не завжди можна ідентифікувати. Саме ці вади часто заважають її практичному використанню.
МПБ прийнята всіма розвинутими державами світу. Вона розроблялася, головним чином, для збереження секретності (тобто конфіденційності) інформації у військових організаціях. Питання ж цілісності за її допомогою не розв'язуються або розв'язуються частково, як побічний результат захисту секретності.
Розглянемо ще один вид ІІБ - рольову ПБ. Рольову політику безпеки (РПБ) (Role Base Access Control - RBAC) не можна віднести ані до дискреційної, ані до мандатної, тому що керування доступом у ній здійснюється як на основі матриці прав доступу для ролей, так і за допомогою правил, які регламентують призначення ролей користувачам та їх активацію під час сеансів [32]. Отже, рольова модель є цілком новим типом політики, що базується на компромісі між гнучкістю керування доступом, яка є характерною для ДПБ, і жорсткістю правил контролю доступу, яка притаманна МПБ.
У РПБ класичне поняття суб'єкт заміщується поняттями користувач і роль. Користувач - це людина, яка працює з системою і виконує певні службові обов'язки. Роль - це активно діюча в системі абстрактна сутність, з якою пов'язаний обмежений, логічно зв'язаний набір повноважень, необхідних для здійснення певної діяльності.
РПБ є досить поширеною, тому що вона, на відміну від інших більш строгих і формальних політик, є дуже близькою до реального життя. Справді, користувачі, що працюють у системі, діють не від свого власного імені - вони завжди здійснюють певні службові обов'язки, тобто виконують деякі ролі, які аж ніяк не пов'язані з їх особистістю.
Тому цілком логічно здійснювати керування доступом і призначати повноваження не реальним користувачам, а абстрактним (не персоніфікованим) ролям, які представляють учасників певного процесу обробки інформації. Такий підхід до ПБ дозволяє врахувати розподіл обов'язків і повноважень між учасниками прикладного інформаційного процесу, оскільки з точки зору РПБ має значення не особистість користувача, що здійснює доступ до інформації, а те, які повноваження йому необхідні для виконання його службових обов'язків. Наприклад, у реальній системі обробки інформації можуть працювати системний адміністратор, менеджер баз даних і прості користувачі.
У такій ситуації РПБ дає змогу розподілити повноваження між цими ролями відповідно до їх службових обов'язків: ролі адміністратора призначаються спеціальні повноваження, які дозволять йому контролювати роботу системи і керувати її конфігурацією; роль менеджера баз даних дає змогу здійснювати керування сервером БД; а права простих користувачів обмежуються мінімумом, необхідним для запуску прикладних програм. Крім того, кількість ролей у системі може не відповідати кількості реальних користувачів - один користувач, якщо він має різні повноваження, може виконувати (водночас або послідовно) кілька ролей, а кілька користувачів можуть користуватись однією і тією ж роллю, якщо вони виконують однакову роботу.
При використанні РПБ керування доступом здійснюється в дві стадії: по-перше, для кожної ролі вказується набір повноважень, що являють собою набір прав доступу до об'єктів, і, по-друге, кожному користувачу призначається список доступних йому ролей. Повноваження призначаються ролям відповідно до принципу найменших привілеїв, з якого випливає, що кожний користувач повинен мати тільки мінімально необхідні для виконання своєї роботи повноваження.
У моделі РПБ визначаються такі множини:
U- множина користувачів;
R - множина ролей;
Р - множина повноважень на доступ до об'єктів, що подається, наприклад, у вигляді матриці прав доступу;
S - множина сеансів роботи користувачів із системою.
Для перелічених множин визначаються такі відношення:
PAPxR – відображає множину повноважень на множину ролей, встановлюючи для кожної ролі набір наданих їй повноважень;
UAUxR – відображає множину користувачів на множину ролей, визначаючи для кожного користувача набір доступних йому ролей.
Правила керування доступом рольової політики безпеки визначаються такими функціями:
user: S —» U — для кожного сеансу s ця функція визначає користувача и, який здійснює цей сеанс роботи з системою: user(s) = и;
roles: S —» R- для кожного сеансу s ця функція визначає набір ролей з множини R, що можуть бути одночасно доступні користувачу и в цьому сеансі:
roles(s) = {r |(user(s), r) UA};
permissions: S —» Р - для кожного сеансу s ця функція задає набір доступних у ньому повноважень, який визначається як сукупність повноважень усіх ролей, що беруть участь у цьому сеансі: permissions(s) = {р | (р,r) РА}. Як критерій безпеки рольової моделі використовується таке правило: система вважається безпечною, якщо будь-який користувач системи, що працює в сеансі s, може здійснити дії, які вимагають повноважень р тільки в тому випадку, коли р permission(s).
З формулювання критерію безпеки моделі РПБ випливає, що управління доступом здійснюється головним чином не за допомогою призначення повноважень ролям, а шляхом завдання відношення UA, яке призначає ролі користувачам, і функції roles, що визначає доступний у сеансі набір ролей. Тому численні інтерпретації рольової моделі відрізняються видом функцій user, roles і permission, а також обмеженнями, що накладаються на відношення РА та UA. Як приклади розглядається рольова політика управління доступом з ієрархічною організацією ролей, а також кілька типових обмежень на відношення РА та UA і функції user та roles, що найчастіше зустрічаються на практиці.
Зокрема, ієрархічна організація ролей являє собою найпоширеніший тип рольової моделі, оскільки вона дуже точно відображає реальне відношення підпорядкованості між учасниками процесів обробки інформації і розподіл між ними сфер відповідальності. Ролі в ієрархії упорядковуються за рівнем наданих повноважень. Чим вища роль в ієрархії, тим більше з нею пов'язано повноважень, оскільки вважається, що коли користувачу надана деяка роль, то йому автоматично призначаються і всі підпорядковані їй за ієрархією ролі. Ієрархічна організація ролей є характерною для систем військового призначення.
Завдяки гнучкості та широким можливостям РПБ суттєво перевершує інші політики, хоча іноді її певні властивості можуть виявитися негативними. Так, вона практично не гарантує безпеки за допомогою формального доведення, а тільки визначає характер обмежень, виконання яких і є критерієм безпеки системи. Хоча такий підхід дозволяє отримати прості і зрозумілі правила контролю доступу (перевага), які легко застосовувати на практиці, але позбавляє систему теоретичної доказової бази (вада). В деяких ситуаціях ця обставина утруднює використання РПБ, однак, у будь-якому разі, оперувати ролями набагато зручніше, ніж суб'єктами (знову перевага), оскільки це більше відповідає поширеним технологіям обробки інформації, які передбачають розподіл обов'язків і сфер відповідальності між користувачами.
Крім того, РПБ може використовуватися одночасно з іншими ПБ, коли повноваження ролей, що призначаються користувачам, контролюються ДПБ або МПБ, що дає змогу будувати багаторівневі схеми контролю доступу.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора