Управління доступом на основі ролей переваги, практика, особливо - real itsm все про itil,

Привіт, шановні відвідувачі порталу! Мене звуть Олександр Омельченко, я - но вий сотрудн ик компанії Cleverics. Буду займатися проектами по впровадженню рішень IDM і управління доступом. У зв'язку з появою нового напряму в компанії, хочу розповісти докладніше про пов'язані з управлінням доступом поняття. Сьогодні поговоримо про найбільш популярною на сьогоднішній день моделі надання доступу - управління доступом на основі ролей, відомої як RBAC (Role Based Access Control).

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

Ключовою особливістю рольової моделі є те, що весь доступ до інформаційних систем і ресурсів надається тільки через ролі. Роль - це набір прав доступу. Користувачі отримують доступ тільки через присвоєні їм ролі.

Ідея надання доступу на основі ролей виникла з необхідності угруповання наборів прав в якісь окремі сутності, які чітко давали б зрозуміти, який доступ є у користувача, з якими було б зручніше і зрозуміліше працювати в разі змін як положення користувача в організації, так і набору прав доступу користувача. Історично склалося, що набори прав стали прив'язувати до посад співробітників, по суті - до функціональних ролей. Звідси з'явилося поняття ролі. Перші додатки, що реалізують рольове управління доступом користувачів, почали з'являтися ще в 1970х роках. У той час це були досить прості системи і додатки. Не було єдиної моделі, яка описує як саме доступ надається користувачеві на основі його ролі в організації. Системи розроблялися різними організаціями без узгоджених визначень і стандартів.

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

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

• Можливість побудови ієрархії ролей з успадкуванням набору прав. Це дозволяє спростити рольову модель, особливо в організаціях з різнорідної інфраструктурою, де використовується багато інформаційних систем. З використанням ієрархії немає необхідності повторно вказувати права в декількох подібних ролях, досить помістити їх в одну велику роль, як дочірні, вказавши лише унікальні права для кожної ролі.
• Просто і ефективно здійснюється надання однакових прав великій кількості користувачів - досить призначити користувачам одну роль.
• При необхідності зміни набору прав великій кількості користувачів досить змінити набір прав в ролі.
• Можливість реалізації принципу поділу повноважень (SoD - Segregation of Duties). Це значно знижує ризик надання користувачам надлишкових повноважень, наприклад, коли дві ролі не можуть бути в один момент часу призначені одному користувачеві.

Особливості

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

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

• В такому випадку важко визначити "розумно малий" набір ролей, які відповідають за права доступу основної маси користувачів.
• Непрактично створювати стільки ж ролей скільки користувачів - це рівносильно ручного управління доступом.

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

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

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

Практика застосування

Раніше ми побачили, чому управління правами користувачів на основі рольової моделі може бути складним і дорогим, і навіть після успішного впровадження доставити багато проблем як ІТ, так і бізнесу.

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

Резюмуючи, можна сказати наступне - RBAC є корисним рішенням для деяких конкретних проблем: управління користувачами в одному каталозі або управління великими групами користувачів з однаковими правами. Але RBAC, як єдина модель надання доступу, не підходить для більш загальної проблеми управління правами великої кількості різноманітних користувачів і динамічного доступу користувачів у багатьох системах.