У цій статті наведено повне пояснення керування доступом на основі ролей (RBAC), а також покроковий посібник із розгортання, підтримки та розширення RBAC для задоволення потреб вашої організації. Ви дізнаєтеся про ролі, як їх визначити та як їх використання для регулювання доступу може допомогти захистити вашу мережу, зменшити адміністративні витрати та забезпечити відповідність нормативним вимогам. Ми також побачимо кілька прикладів керування доступом на основі ролей. Давайте розпочнемо.
Що таке керування доступом на основі ролей (RBAC)?
Концепція надання дозволів людям на основі їх ролі в організації називається керуванням доступом на основі ролей (RBAC). Він забезпечує базовий, контрольований підхід до керування доступом, який менш схильний до помилок, ніж індивідуальне надання дозволів користувачам.
Коли ви використовуєте RBAC для керування доступом до ролей, ви вивчаєте вимоги своїх користувачів і групуєте їх у ролі на основі спільних обов’язків. Потім для кожного користувача ви призначаєте одну або кілька ролей і один або кілька дозволів для кожної ролі. Оскільки користувачам більше не потрібно керувати без розбору, зв’язки «користувач-роль» і «роль-дозволи» спрощують виконання призначень користувачам.
Історія управління доступом на основі ролей
Принаймні з 1970-х років люди використовували ролі та обов'язки для контролю доступу до комерційних комп'ютерних систем. Ці методи, однак, були спеціальними і часто доводилося змінювати в кожному окремому випадку для кожної нової системи.
Дослідники з Американського національного інституту стандартів (NIST) не почали визначати систему, відому як контроль доступу на основі ролей, до 1992 року. У тому ж році Феррайоло та Кун опублікували статтю, що визначає механізм контролю доступу загального призначення, придатний для цивільних і комерційного використання, закладаючи основу для моделі, яку ми використовуємо сьогодні.
Протягом 1990-х і на початку 2000-х Феррайоло, Кун та інші удосконалили RBAC, спираючись на попередню роботу з дослідження економічних переваг RBAC, вказавши уніфіковану модель і, що найважливіше, визначили розподіл форм мита. RBAC був офіційно прийнятий як галузевий стандарт NIST у 2004 році.
Як працює рольовий контроль доступу RBAC?
Перш ніж розгортати RBAC у бізнесі, організації слід ретельно визначити дозволи для кожної ролі. Це включає точне визначення дозволів у категоріях, перелічених нижче:
- Дозволи на зміну даних (наприклад, читання, запис, повний доступ)
- Доступ до використання програмного забезпечення компанії
- Дозволи в межах програми
Щоб отримати максимальну віддачу від RBAC, ви повинні спочатку змоделювати ролі та дозволи. Частиною цього є призначення всіх обов’язків персоналу на певні посади, які встановлюють відповідні привілеї. Потім організація може призначити посади на основі завдань співробітників.
Організації можуть використовувати керування доступом на основі ролей, щоб призначити одну або кілька ролей кожному користувачеві або призначити дозволи окремо. Ідея полягає в тому, щоб встановити дозволи, які дозволять користувачам виконувати свої обов’язки без внесення додаткових налаштувань.
Технології керування ідентифікацією та доступом (IAM) використовуються організаціями для впровадження та моніторингу RBAC. IAM насамперед обслуговує великі організації, реєструючи, відстежуючи та оновлюючи всі ідентифікаційні дані та дозволи. Процес надання дозволу відомий як «ініціалізація», а процес скасування дозволу відомий як «деініціалізація». Цей тип системи вимагає встановлення єдиного та стандартизованого набору ролей.
Що таке роль RBAC керування доступом на основі ролей?
Ролі — це семантика в архітектурі RBAC, яку організації можуть використовувати для створення своїх привілеїв. Повноваження, відповідальність, центр витрат, бізнес-підрозділ та інші фактори можна використовувати для визначення ролей.
Роль — це групування привілеїв користувачів. Традиційні групи, які є сукупностями користувачів, не є такими ж, як ролі. Дозволи не пов’язані безпосередньо з ідентифікаторами в контексті RBAC, а радше з ролями. Оскільки вони організовані навколо керування доступом, ролі заслуговують більшої довіри, ніж групи. Ідентичність змінюється частіше, ніж характеристики та діяльність у звичайному бізнесі.
Модель керування доступом на основі ролей RBAC
Стандарт RBAC визначає три форми контролю доступу: основний, ієрархічний і обмежений.
#1. Основний RBAC
Основна модель визначає ключові компоненти будь-якої рольової системи контролю доступу. Хоча фундаментальний RBAC можна використовувати як окремий підхід до контролю доступу, він також служить основою як для ієрархічної, так і для обмеженої моделей.
У результаті всі RBAC повинні дотримуватися трьох правил, наведених нижче:
- Вибір ролі або призначення: Особа може використовувати дозвіл, лише якщо вона вибрала або отримала роль.
- Авторизація ролі: Активна роль суб'єкта повинна бути санкціонована.
- Авторизація дозволів: Суб’єкт може використовувати лише дозволи, дозволені для його активної ролі.
#2. Ієрархія RBAC
Вважаючи, що ваш захист уже зламано, ви можете зайняти сильнішу позицію безпеки проти потенційних атак, зменшуючи ефект зламу. Обмежте «радіус вибуху» можливої шкоди, спричиненої зламом, шляхом сегментації доступу та зменшення поверхні атаки, підтвердження наскрізного шифрування та моніторингу вашої мережі в режимі реального часу.
#3. Обмежений RBAC
Цей третій стандарт RBAC розширює розподіл ролей у основній моделі. Відносини розподілу обов'язків класифікуються як статичні або динамічні.
- Один користувач не може нести взаємовиключні обов’язки у відносинах зі статичним розподілом обов’язків (SSD) (як визначено організацією). Це гарантує, що, наприклад, одна особа не зможе одночасно зробити та схвалити покупку.
- Користувач за моделлю динамічного розподілу обов’язків (DSD) може мати суперечливі ролі. Однак користувач не може виконувати обидва завдання в одному сеансі. Це обмеження допомагає контролювати проблеми внутрішньої безпеки, наприклад, реалізуючи правило двох осіб, яке вимагає від двох унікальних користувачів авторизувати дію.
Приклади керування доступом на основі ролей
RBAC дозволяє контролювати, що можуть робити кінцеві користувачі як на широкому, так і на детальному рівнях. Ви можете вказати, чи є користувач адміністратором, спеціалістом або кінцевим користувачем, і ви можете зіставити обов’язки та дозволи на доступ до організаційних посад ваших співробітників. Дозволи надаються лише за наявності достатнього доступу, щоб працівники могли виконувати свої завдання.
Що робити, якщо опис кінцевого користувача зміниться? Можливо, вам знадобиться надати їх роль іншому користувачеві вручну, або ви можете призначити ролі групі ролей або використати політику призначення ролей, щоб додати або видалити членів групи ролей.
Інструмент RBAC може містити такі позначення:
- Сфера ролі управління – обмежує елементи, які може обробляти рольова група.
- Рольова група управління – Ви можете додавати та видаляти учасників із групи ролей керування.
- Роль управління – це типи завдань, які може виконати певна рольова група.
- Призначення управлінської ролі - Це процес призначення ролі рольовій групі.
Коли користувача додають до групи ролей, він отримує доступ до всіх ролей у цій групі. Коли їх видаляють, доступ обмежується. Користувачі також можуть бути призначені до численних груп, якщо їм потрібен тимчасовий доступ до певних даних або програм, а потім видалені після завершення проекту.
Інші можливості доступу користувача можуть включати:
- Ключовий контакт для певного облікового запису або ролі.
- Білінг – доступ до платіжного рахунку для одного кінцевого користувача.
- Технічні користувачі - це ті, хто виконує технічні обов'язки.
- Адміністративний доступ надається користувачам, які здійснюють адміністративну діяльність.
Альтернативи RBAC: типи контролю доступу
Замість керування доступом на основі ролей можна використовувати інші механізми контролю доступу.
Список контролю доступу (ACL)
Список керування доступом (ACL) — це таблиця, у якій перераховано дозволи, пов’язані з обчислювальними ресурсами. Він інформує операційну систему про те, які користувачі мають доступ до об'єкта і які дії вони можуть виконувати з ним. Кожен користувач має запис, який пов’язаний із властивостями безпеки кожного елемента. Для класичних систем ЦАП зазвичай використовується ACL.
ACL проти RBAC
З точки зору безпеки та адміністративних витрат, RBAC перевершує ACL для більшості бізнес-додатків. ACL більше підходить для реалізації безпеки на рівні окремого користувача та для низькорівневих даних, але RBAC краще підходить для системи безпеки всієї компанії, яку контролює адміністратор. Наприклад, ACL може дозволити доступ для запису до певного файлу, але не може визначити, як файл буде змінено користувачем.
Контроль доступу на основі атрибутів (ABAC)
ABAC оцінює набір правил і політик, щоб контролювати дозволи доступу на основі певних якостей, таких як інформація про середовище, систему, об’єкт або користувача. Він використовує булеву логіку, щоб дозволити або заборонити людям доступ на основі складної оцінки атомарних або заданих властивостей та їхніх зв’язків.
На практиці це дає змогу визначати правила на розширеній мові розмітки керування доступом (XACML), які використовують такі комбінації ключ-значення, як Роль=Керівник і Категорія=Фінансовий.
ABAC проти RBAC
RBAC базується на попередньо визначених ролях, тоді як ABAC є більш динамічним і використовує контроль доступу на основі зв’язків. RBAC можна використовувати для загального визначення елементів керування доступом, тоді як ABAC забезпечує більшу деталізацію. Система RBAC, наприклад, надає доступ усім менеджерам, тоді як політика ABAC надає доступ лише менеджерам у фінансовому відділі. ABAC виконує складніший пошук, який вимагає більше процесорної потужності та часу, тому використовуйте його лише тоді, коли RBAC недостатньо.
Переваги RBAC
- Управління та аудит доступу до мережі мають вирішальне значення для інформаційної безпеки. Доступ може і повинен бути дозволений на основі необхідності знати. Безпекою легше керувати завдяки сотням або тисячам співробітників, обмежуючи непотрібний доступ до важливої інформації на основі заявленої ролі кожного користувача в бізнесі. Серед інших переваг:
- Буде скорочено адміністративну та ІТ підтримку. Коли працівник приймається на роботу або змінює посаду, ви можете використовувати RBAC, щоб зменшити вимоги до паперової роботи та зміни пароля. Натомість ви можете використовувати RBAC для швидкого додавання та передачі ролей між операційними системами, платформами та програмами. Це також зменшує ймовірність помилок під час надання дозволів користувача. Однією з багатьох економічних переваг RBAC є скорочення часу, витраченого на адміністративну діяльність. RBAC також полегшує інтеграцію сторонніх користувачів у вашу мережу, призначаючи їм попередньо визначені ролі.
- Підвищення ефективності роботи. RBAC забезпечує спрощений підхід із логічними визначеннями. Замість того, щоб намагатися адмініструвати контроль доступу нижчого рівня, усі ролі можна узгодити з організаційною структурою підприємства, дозволяючи користувачам виконувати свої обов’язки більш ефективно та автономно.
- Підвищення комплаєнсу. Федеральні, державні та муніципальні обмеження застосовуються до всіх організацій. Компанії можуть легше відповідати законодавчим і нормативним стандартам конфіденційності та конфіденційності за допомогою системи RBAC, оскільки ІТ-відділи та керівники можуть керувати тим, як доступ до даних та їх використання. Це особливо важливо для медичних і фінансових організацій, які обробляють велику кількість конфіденційних даних, таких як PHI та PCI.
Найкращі практики впровадження RBAC
Впровадження RBAC у вашій організації не слід легковажити. Існує кілька загальних етапів, які необхідно пройти, щоб залучити команду до справи, не створюючи непотрібної плутанини чи роздратування на робочому місці. Ось кілька ідей для початку.
- Поточний статус: Складіть список кожного програмного забезпечення, апаратного забезпечення та додатків, які мають захист. Для більшості з них потрібен пароль. Однак ви можете включити серверні кімнати, які знаходяться під замком. Фізична безпека може бути важливою складовою захисту даних. Також укажіть, хто має доступ до кожної з цих програм і місць. Це дасть вам уявлення про поточну ситуацію з даними.
- Поточні обов'язки: Навіть якщо у вас немає офіційного списку та списку ролей, визначити, чим займається кожен окремий член команди, може бути так само просто, як коротка розмова. Намагайтеся організувати команду таким чином, щоб не перешкоджати творчості чи поточній культурі (якщо це подобається).
- Створити політику: Будь-які зміни мають бути задокументовані для перегляду всіма теперішніми та майбутніми працівниками. Навіть якщо ви використовуєте рішення RBAC, наявність документа, у якому чітко сформульована ваша нова система, допоможе вам запобігти проблемам.
- Зміни: Коли відомі поточний статус безпеки та ролі (і політика діє), настав час впровадити зміни.
- Постійно адаптуйтесь: Цілком імовірно, що перша ітерація RBAC потребуватиме деяких змін. На початку вам слід часто оцінювати свої обов’язки та стан безпеки. Спершу оцініть, наскільки добре працює ваш творчий/виробничий процес, а потім – наскільки безпечний ваш процес.
Висновок
Захист даних є важливою бізнес-функцією будь-якої корпорації. Система RBAC може гарантувати, що інформація компанії відповідає законам про конфіденційність і конфіденційність. Крім того, він може забезпечити важливу бізнес-діяльність, наприклад доступ до інтелектуальної власності, що має конкурентний вплив на організацію.
Контроль доступу на основі ролей. Поширені запитання
Які три основні правила для RBAC?
Такі компоненти RBAC, як дозволи для ролей, зв’язки «користувач-роль» і «роль-роль», спрощують призначення користувачів.
Чому використовується ACL?
Зменшення мережевого трафіку для покращення продуктивності мережі. Рівень безпеки мережі, який визначає, до яких розділів сервера/мережі/служби користувач може отримати доступ, а до яких ні. Детальне відстеження трафіку, що входить і виходить із системи.
Яка різниця між контролем доступу на основі ролей і контролем доступу на основі правил?
Рівні доступу працівників не визначаються засобами контролю доступу на основі правил, які мають превентивний характер. Натомість вони працюють для запобігання небажаному доступу. Рольові моделі є проактивними в тому, що вони пропонують співробітникам набір умов, за яких вони можуть отримати схвалений доступ.
- ДИСКРЕЦІЙНИЙ КОНТРОЛЬ ДОСТУПУ: визначення та приклади
- ОБОВ’ЯЗКОВИЙ КОНТРОЛЬ ДОСТУПУ MAC: як це працює
- Інструменти керування Active Directory: що це таке та все, що вам потрібно про це знати
- ВІДДІЛ МАРКЕТИНГУ: Огляд, структура, ролі, очікування (+безкоштовні поради)
- Віртуальний адміністративний помічник: вакансії, послуги, компанії, вимоги та все, що вам потрібно.
посилання
