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).

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

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

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

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

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

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

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

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