8.6. Рольове керування доступом
При великій кількості користувачів традиційні підсистеми керування доступом стають украй складними для адміністрування. Число зв'язків у них пропорційно добутку кількості користувачів на кількість об'єктів. Необхідні рішення в об'єктно-орієнтованому стилі, здатні ці складнощі понизити.
Таким рішенням є рольове керування доступом (РКД). Суть його в тому, що між користувачами і їхніми привілеями з'являються проміжні сутності -ролі. Для кожного користувача одночасно можуть бути активними кілька ролей, кожна з яких дає йому певні права (див. рис. 8.2).
Право
доступу 1 Право доступу 2 ••• Право
доступу М
Рис. 8.2. Користувачі, об'єкти й ролі Рольовий доступ нейтральний стосовно конкретних видів прав і способів їхньої перевірки; його можна розглядати як об'єктно-орієнтований каркас, що полегшує адміністрування, оскільки він дозволяє зробити підсистему розмежування доступу керованою при якій завгодно великій кількості користувачів, насамперед за рахунок установлення між ролями зв'язків, аналогічних успадкуванню в об'єктно-орієнтованих системах. Крім того, ролей повинно бути значно менше, ніж користувачів. У результаті число адміністрованих зв'язків стає пропорційним сумі (а не добутку) кількості користувачів й об'єктів, що один по одному величини зменшити вже неможливо.
Рольовий доступ розвивається більше 10 років (сама ідея ролей, зрозуміло, є значно старшою) як на рівні операційних систем, так і у рамках СУБД й інших інформаційних сервісів. Зокрема, існують реалізації рольового доступу для Web-серверів.
У 2001 році Національний інститут стандартів і технологій США запропонував проект стандарту рольового керування доступом (див. http://csrc.nist.gov/rbac/), основні положення якого ми й розглянемо.
Рольове керування доступом оперує наступними основними поняттями: • користувач (людина, інтелектуальний автономний агент і т.п.);
сеанс роботи користувача;
роль (звичайно визначається відповідно до організаційної структури);
об'єкт (сутність, доступ до якої розмежовується; наприклад, файл ОС або таблиця СУБД);
операція (залежить від об'єкта; для файлів ОС - читання, запис, виконання й т.п.; для таблиць СУБД - вставка, видалення й т.п., для прикладних об'єктів операції можуть бути більш складними);
право доступу (дозвіл виконувати певні операції над певними об'єктами).
Ролям приписуються користувачі й права доступу; можна вважати, що вони (ролі) іменують відносини "багато хто до багатьох" між користувачами й правами Ролі можуть бути приписані багатьом користувачам; один користувач може бути приписаний декільком ролям. Під час сеансу роботи користувача активізується підмножина ролей, яким він приписаний, у результаті чого він стає власником об'єднання прав, приписаних активним ролям. Одночасно користувач може відкрити кілька сеансів.
Між ролями може бути визначене відношення часткового порядку, так зване успадкуванням. Якщо роль г2 є спадкоємицею гі, то усі права гі приписуються г2, а всі користувачі г2 приписуються гі. Очевидно, що успадкування ролей відповідає успадкуванню класів в об'єктно-орієнтованому програмуванні, тільки правам доступу відповідають методи класів, а користувачам - об'єкти (екземпляри) класів.
Відношення успадкування є ієрархічним, причому права доступу й користувачі поширюються по рівнях ієрархії назустріч один одному. У загальному випадку успадкування є множинним, тобто в однієї ролі може бути кілька попередниць (і, природно, трохи спадкоємиць, яких ми будемо називати також спадкоємицями).
Можна уявити собі формування ієрархії ролей, починаючи з мінімуму прав (і максимуму користувачів), приписуваних ролі "співробітник", з поступовим уточненням складу користувачів і додаванням прав (ролі
"системний адміністратор", "бухгалтер" і т.п.), аж до ролі "керівник" (що, втім, не виходить, що керівникові надаються необмежені права; як й іншим ролям, відповідно до принципу мінімізації привілеїв, цієї ролі доцільно дозволити тільки те, що необхідно для виконання службових обов'язків). Фрагмент подібної ієрархії ролей показаний на рис. 8.3.
Рис. 8.3. фрагмент ієрархії ролей
Для реалізації ще одного згадуваного раніше важливого принципу інформаційної безпеки вводиться поняття поділу обов'язків, причому у двох виглядах: статичному й динамічному.
Статичний поділ обов'язків накладає обмеження на приписування користувачів ролям. У найпростішому випадку членство в деякій ролі забороняє приписування користувача певній сукупності інших ролей. У загальному випадку дане обмеження задається як пара "безліч ролей - число" (де безліч складається, принаймні, із двох ролей, а число повинне бути більше 1), так що ніякий користувач не може бути приписаний зазначеному (або більшому) числу ролей із заданої кількості. Наприклад, може існувати п'ять бухгалтерських ролей, але політика безпеки допускає членство не більш ніж у двох таких ролях (тут число=3).
При наявності успадкування ролей обмеження набуває більш складного вигляду, але суть залишається простою: при перевірці членства в ролях потрібно враховувати приписування користувачів ролям-спадкоємицям.
Динамічний поділ обов'язків відрізняється від статичного тільки тим, що розглядаються ролі, одночасно активні (у різних сеансах) для даного користувача (а не ті, котрим користувач статично приписаний). Наприклад, один користувач може відігравати роль і касира, і контролера, але не одночасно; щоб стати контролером, він повинен спочатку закрити касу. Тим самим реалізується так зване тимчасове обмеження довіри, що є аспектом мінімізації привілеїв.
Розглянутий проект стандарту містить специфікації трьох категорій функцій, необхідних для адміністрування РКД:
Адміністративні функції (створення й супровід ролей та інших атрибутів рольового доступу): створити/видалити роль/користувача, приписати користувача/право ролі або ліквідувати існуючу асоціацію, створити/видалити відношення успадкування між існуючими ролями, створити нову роль і зробити її спадкоємицею/попередницею існуючої ролі, створити/видалити обмеження для статичного/динамічного поділу обов'язків.
Допоміжні функції (обслуговування сеансів роботи користувачів): відкрити сеанс роботи користувача з активацією якого мається на увазі набір ролей; активувати нову роль, деактивувати роль; перевірити правомірність доступу.
Інформаційні функції (одержання відомостей про поточну конфігурацію з обліком відносин успадкування). Тут проводиться поділ на обов'язкові й необов'язкові функції. До числа перших належать одержання списку користувачів, приписаних ролі, і списку ролей, яким приписаний користувач.
Усі інші функції віднесені до розряду необов'язкових. Це одержання інформації про права, які приписані ролі, про права заданого користувача (якими він володіє як член певної сукупності), про активні на данний момент сеансу ролі і права, про операції, які роль/користувач правочинні зробити з заданим об'єктом, про статичний/динамічний розподіл обов'язків.
Можна сподіватися, що запропонований стандарт допоможе сформувати єдину термінологію й, що більш важливо, дозволить оцінювати РУД-продукти з єдиних позицій, по єдиній шкалі.