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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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