Файл: 10_ua_2_.doc

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

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

---

2.2 Ролеве управління доступом

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

Таким рішенням є ролеве управління доступом (РУДИЙ). Суть його в тому, що між користувачами і їх привілеями з’являються проміжні єства - ролі. Для кожного користувача одночасно можуть бути активними декілька ролей, кожна з яких дає йому певні права (див. рис. 10.2).

Рис. 10.2. Користувачі, об’єкти і ролі.

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

Ролевий доступ розвивається більше 10 років (сама ідея ролей, зрозуміло, значно старше) як на рівні операційних систем, так і в рамках СУБД і інших інформаційних сервісів. Зокрема, існують реалізації ролевого доступу для Web-серверів.

В 2001 році Національний інститут стандартів і технологій США запропонував проект стандарту ролевого управління доступом (див. http://csrc.nist.gov/rbac/), основні положення якого ми і розглянемо.

Ролеве управління доступом оперує наступними основними поняттями:

• користувач (людина, інтелектуальний автономний агент і т.п.);

• сеанс роботи користувача;

• роль (звичайно визначається відповідно до організаційної структури);

• об’єкт (єство, доступ до якого розмежовується; наприклад, файл ОС або таблиця СУБД);

• операція (залежить від об’єкту; для файлів ОС - читання, запис, виконання і т.п.; для таблиць СУБД - вставка, видалення і т.п., для прикладних об’єктів операції можуть бути складнішими);

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

---

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

Між ролями може бути визначено відношення часткового порядку, зване спадкоємством. Якщо роль r2 є спадкоємицею r1, то всі права r1 приписуються r2, а всі користувачі r2 приписуються r1. Очевидно, що спадкоємство ролей відповідає спадкоємству класів в об’єктно-орієнтованому програмуванні, тільки правам доступу відповідають методи класів, а користувачам - об’єкти (екземпляри) класів.

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

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

Рис. 10.3. Фрагмент ієрархії ролей.

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

Статичне розділення обов’язків накладає обмеження на приписування користувачів ролям. В найпростішому випадку членство в деякій ролі забороняє приписування користувача певній безлічі інших ролей. В загальному випадку дане обмеження задається як пара "безліч ролей - число" (де множина полягає, принаймні, з двох ролей, а число повинне бути більше 1), так що ніякий користувач не може бути приписаний вказаному (або більшому) числу ролей із заданої множини. Наприклад, може існувати п’ять бухгалтерських ролей, але політика безпеки допускає членство не більше ніж в двох таких ролях (тут число=3).

---

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

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

Даний проект стандарту містить специфікації трьох категорій функцій, необхідних для адміністрування РУД:

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

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

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

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

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

---

2.3 Управління доступом в Java-середовищі

Java - це об’єктно-орієнтована система програмування, тому і управління доступом в ній спроектовано і реалізовано в об’єктному стилі. З цієї причини розглянути Java-середовище для нас дуже важливо. Докладно про Java-технологію і безпеку Java-середовища розказано в статті А. Таранова і В. Цишевского "Java в три роки" (Jet Info, 1998, 11-12). З дозволу авторів далі використовуються її фрагменти.

Перш за все, зупинимося на еволюції моделі безпеки Java. В JDK 1.0 була запропонована концепція "пісочниці" (sandbox) - замкнутого середовища, в якому виконуються потенційно ненадійні програми (апплети, що поступили по мережі). Програми, розташовані на локальному комп’ютері, вважалися абсолютно надійними, і їм було доступно все, що доступне віртуальній Java-машині.

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

Щоб справитися з цією проблемою, в JDK 1.1 ввели розподіл джерел (точніше, розповсюджувачів) апплетов на надійні і ненадійні (джерело визначалося по електронному підпису). Надійні апплеты прирівнювалися в правах до "рідного" коду. Зроблене послаблення розв’язало проблеми тих, кому прав не вистачало, але захист залишився неешелонованим і, отже, неповної.

В JDK 1.2 сформувалася модель безпеки, що використовується і в Java 2. Від моделі "пісочниці" відмовилися. Оформилися три основні поняття:

• джерело програми;

• право і безліч прав;

• політика безпеки.

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

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

---