Керування доступом на основі ролей

Керування доступом на основі ролей (англ. Role Based Access Control, RBAC) — розвиток політики вибіркового керування доступом, при якому права доступу суб'єктів системи на об'єкти групуються з урахуванням специфіки їх застосування, утворюючи ролі[1][2].

Формування ролей покликане визначити чіткі і зрозумілі для користувачів комп'ютерної системи правила розмежування доступу. Рольове розмежування доступу дозволяє реалізувати гнучкі та динамічно змінні в процесі функціонування комп'ютерної системи правила розмежування доступу.

Таке розмежування доступу є складовою багатьох сучасних комп'ютерних систем. Як правило, даний підхід застосовується в системах захисту СУБД, а окремі елементи реалізуються в мережевих операційних системах. Рольовий підхід часто використовується в системах, для користувачів яких чітко визначено коло їх посадових повноважень і обов'язків.

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

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

Історія

Елементарні форми моделі RBAC були здійснені в багатьох спеціальних формах на багатьох системах, починаючи з 1970-х років. Контроль доступу на основі ролей, який використовується в даний час, відбувається з моделі, запропонованої Феррайоло (англ. Ferraiolo) і Куном (англ. Kuhn) (1992) і як зразкова модель пізніше вдосконалена Санді (англ. Sandhu), Койн, Фейнштейн і Йомала (1996).

  • 1992 рік — стаття Феррайоло і Куна, яка визначає RBAC за допомогою доступу тільки через ролі, ієрархії і обмеження. формальна модель;
  • 1994 рік — DTOS розташовував дослідний зразок RBAC, на прототипі моделі, запропонованої Феррайоло, Кун, Гаврилья (англ. Gavrila)
  • 1994 рік — стаття Nyanchama і Osborn визначає модель;
  • 1994 рік — IBM подає (в Європі) першу заявку на патент в області RBAC, цитує Феррайоло і Куна;
  • 1995 рік — Феррайоло, Кугіні (англ. Cugini), Кун розширили формальну модель, ввівши визначення форм поділу обов'язків;
  • 1996 рік — метод Санді для того, щоб здійснити МАС на основі RBAC;
  • 1997-1998 роки — Sybase, Безпечне Обчислення, Siemens оголошує про продукти RBAC, які базуються безпосередньо на моделі
  • 1997 рік — безпечне обчислення включає модель Феррайоло-Куна RBAC в американську Глобальну Команду DoD і Систему управління; виходить стаття Куна на тему поділу обов'язків, необхідних і достатніх умов для безпеки поділу;
  • 1997 рік — стаття Осборна заснована на відносинах між RBAC і багаторівневою безпекою мандатної моделі політики безпеки; анотація ролі, що зв'язує RBAC і багаторівневу безпеку
  • 1998 рік — RBAC — метод Куна для того, щоб здійснити RBAC на системі МАС;
  • 1999 рік — Барклей (англ. Barkley), Феррайоло, Кун відкривають вихідний дослідний зразок RBAC для розвинених веб-серверів;
  • 2000 рік — Санді, Феррайоло, Кун публікують статтю, що визначає об'єднані моделі RBAC, і пропонують стандарт RBAC;
  • 2004 рік — Американський національний інститут стандартів і Міжнародний комітет по стандартам інформаційних технологій (ANSI / INCITS) приймають запропоновану Санді, Феррайоло і Куном модель RBAC як єдиний стандарт.

Базова модель RBAC

Для визначення моделі RBAC визначаються наступні умови:

  • S = Суб'єкт = Людина або автоматизований агент (множина користувачів);
  • R = Роль = Робоча функція або назва, яка визначається на рівні авторизації (множина ролей);
  • P = Дозволи = Затвердження режиму доступу до ресурсу (множина прав доступу на об'єкти системи);
  • SE = Сесія = Відповідність між S, R та / або P
  • SA = Призначення суб'єкта
  • PA: R → 2p — функція, що визначає для кожної ролі множину прав доступу; при цьому для кожного p ∈ P існує r ∈ R така, що p ∈ PA (r);
  • RH = Частково впорядкована ієрархія ролей. RH може бути ще записана так:
    • Один суб'єкт може мати кілька ролей.
    • Одну роль можуть мати декілька суб'єктів.
    • Одна роль може мати кілька дозволів.
    • Один дозвіл може належати кільком ролям.

Ролі призначаються суб'єктам, внаслідок чого суб'єкти отримують ті чи інші дозволи через ролі. RBAC вимагає саме такого призначення, а не прямого призначення дозволів суб'єктам, інакше це призводить до складно контрольованих відносин між суб'єктами і дозволами[3].

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

Використовуючи нотацію теорії множин:

  • , при цьому дозволи призначаються зв'язкам ролей у відношені «багато до багатьох».
  • , при цьому суб'єкти призначаються зв'язкам ролей і суб'єктів у відношені «багато до багатьох».

Позначення: x ≥ y означає, що x успадковує дозволи y.

Суб'єкт може мати множину одночасних сесій з різними дозволами.

Можливості та застосування

Технологія керування доступом на основі ролей досить гнучка і сильна, щоб змоделювати як вибіркове керування доступом (DAC)[4], так і мандатне керування доступом (MAC)[5].

До розробки RBAC, єдиними відомими моделями управління доступом були MAC і DAC: якщо модель була MAC, то вона була DAC, і навпаки. Дослідження в 90-х показали, що RBAC не потрапляє ні в ту, ні в іншу категорію.

Ролі створюються всередині організації для різних робочих функцій. Певним ролям присвоюються повноваження (permissions) для виконання тих чи інших операцій. Штатним співробітникам (або іншим користувачам системи) призначаються фіксовані ролі, через які вони отримують відповідні привілеї для виконання фіксованих системних функцій. На відміну від управління доступом на основі контексту (англ. Context-based access control, CBAC), реалізація RBAC в чистому вигляді не враховує поточну ситуацію (таку як, наприклад, звідки було встановлено з'єднання).

RBAC відрізняється від списків контролю доступу (англ. Access control lists, ACL), які використовуються в традиційних вибіркових системах управління доступом, тим, що може давати привілеї на складні операції зі складовими даними, а не тільки на атомарні операції з низькорівневими об'єктами даних. Наприклад, список контролю доступу може надати або позбавити права запису у якомусь системному файлу, але він не може обмежити те, яким чином цей файл може бути змінений. Система, заснована на RBAC, дозволяє створити таку операцію як відкриття «кредиту» у фінансовому додатку або заповнення запису «тест на рівень цукру в крові» в медичному додатку.

Концепції ієрархії ролей і обмежень дозволяють створити або змоделювати контроль доступу на основі решітки (англ. Lattice-based access control, LBAC) засобами RBAC. Таким чином, RBAC може бути основою і розширенням LBAC.

В організаціях з різнорідною IT-інфраструктурою, що містять десятки і сотні систем і додатків, допомагає використання ієрархії ролей і успадкування привілеїв. Без цього використання RBAC стає вкрай заплутаним. У статті «Додаткові ролі: практичний підхід до обслуговування користувачів підприємства» обговорюються стратегії, альтернативні великим масштабом присвоєння привілеїв користувачам[6].

Сучасні системи розширюють стару модель NIST[7] обмеженнями RBAC для розгортання на великих підприємствах.

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

RBAC широко використовується для управління призначеними для користувача привілеями в межах єдиної системи або єдиного додатку. Список таких систем включає в себе Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R / 3, Lotus Notes і безліч інших.

Примітки
  1. Ferraiolo D. F., Kuhn D. R. (October 1992). "Role Based Access Control". 15th National Computer Security Conference: 554—563.
  2. Sandhu R., Coyne E. J., Feinstein H. L., Youman C. E. (August 1996). «Role-Based Access Control Models». IEEE Computer (IEEE Press) 29 (2): 38–47.
  3. Editor, CSRC Content. Role Based Access Control - FAQs. csrc.nist.gov (EN-US). Процитовано 7 квітня 2018.
  4. Ravi Sandhu, Qamar Munawer (October 1998). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control: 47—54.
  5. Sylvia Osborn, Ravi Sandhu, Qamar Munawer(2000). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security (TISSEC): 85—106.
  6. Systems, Hitachi ID. Beyond Roles: A Practical Approach to Enterprise IAM. hitachi-id.com (англ.). Процитовано 7 квітня 2018.
  7. Sandhu R., Ferraiolo D.F. and Kuhn D.R. (July 2000). "The NIST Model for Role Based Access Control: Toward a Unified Standard". 5th ACM Workshop Role-Based Access Control: 47—63.

Література
  • David., Ferraiolo,; Richard., Kuhn, D. (2007). Role-based access control (вид. 2nd ed). Boston: Artech House. ISBN 9781596931138. OCLC 427509709.

Посилання
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.