Модель прав — це не «дамо доступ цій ролі до цього модуля». Модель прав — це формальний опис того, хто і за яких умов може здійснити кожну операцію над кожним об'єктом. На AC-2 і АС-3 системах експерт перевіряє саме формальну специфікацію — не «налаштування інтерфейсу».
Рівні гранулярності
Існує чотири рівні гранулярності, через які проходить будь-яка модель прав:
Рівень 1: модуль
Користувач X має доступ до модуля «Документообіг». Найгрубший рівень. Достатньо для багатьох внутрішніх систем, не достатньо для систем з обмеженою інформацією. NIST 800-53 AC-3 вимагає більш гранулярного контролю там, де це доцільно.
Рівень 2: запис
Користувач X має доступ до своїх документів, не до документів інших підрозділів. Класична фільтрація по власнику / підрозділу / території. Достатньо для більшості АС-2.
Рівень 3: поле
Користувач X бачить документ, але не бачить полів «коментар служби безпеки» та «оцінка ризику». Інша роль — бачить ці поля. Для АС-3 з мішаним грифом — обов'язково.
Рівень 4: значення
Користувач X бачить поле «коментар», але тільки коментарі, не позначені як «обмежений доступ». Найбільш гранулярний рівень. Рідко потрібний, але існує (наприклад, у CRM з продажами охоронним компаніям або режимним об’єктам).
RBAC vs ABAC
Два основні підходи до моделювання прав:
| Параметр | RBAC (role-based) | ABAC (attribute-based) |
|---|---|---|
| Принцип | Користувач → роль → права | Атрибути користувача + атрибути об'єкта + контекст → рішення |
| Гнучкість | Низька-середня | Висока |
| Складність налагодження | Низька | Висока |
| Кількість ролей у великій системі | 100-1000+ (role explosion) | 10-30 (атрибути замість ролей) |
| Контекстуальна авторизація | Складно | Природньо |
| Аудит | Простий | Складніший |
| Експерт-перевірка | Перевірка матриці | Перевірка політик |
На практиці чисто RBAC або чисто ABAC зустрічаються рідко. Більшість систем — гібридні: ABAC у частинах, де є контекстуальна логіка, RBAC у простих.
Коли потрібен ABAC замість RBAC
- Кількість ролей перевищує 50 у системі — це симптом role explosion, ABAC скоротить кількість.
- Авторизація залежить від часу: доступ дозволений тільки у робочий час.
- Авторизація залежить від локації: доступ дозволений тільки з мережі підприємства.
- Авторизація залежить від стадії об'єкта: документ у статусі «чернетка» — одні правила, у статусі «затверджено» — інші.
- Multi-tenant: користувач має доступ тільки до записів свого підрозділу.
Segregation of duties (SoD)
Принцип розділення обов'язків — обов'язкова частина моделі прав. Класичний приклад: особа, що створює платіж, не може його затверджувати. NIST 800-53 AC-5 прямо вимагає SoD-контролі.
Реалізація: матриця заборонених комбінацій ролей/атрибутів. Якщо користувач отримує дві несумісні ролі — система блокує отримання другої.
Типові SoD-правила:
- Адміністратор безпеки ≠ системний адміністратор (експерт перевіряє це окремо).
- Виконавець платежу ≠ затверджувач платежу.
- Виконавець закупівлі ≠ приймальник результатів.
- Аудитор журналів ≠ адміністратор (інакше може приховати свої сліди).
Контекстуальна авторизація
Принцип: рішення про доступ залежить не тільки від користувача та об'єкта, а від поточного контексту. Контекст включає:
- Час: «доступ до фінансових звітів — тільки 9:00-18:00 у робочі дні».
- Локація: «доступ до даних з обмеженим доступом — тільки з мережі підприємства».
- Метод автентифікації: «для виконання критичних операцій — двофакторна автентифікація поточної сесії».
- Стадія документа: «коментар можна додати тільки у статусі „на затвердженні"».
- Делегування: «під час відпустки керівника його заступник отримує тимчасові права».
Контекстуальна авторизація вимагає, щоб модель прав була не статичною матрицею, а політикою, що обчислюється у момент запиту.
Приклади з прикладних областей
HR-система
Складна модель: HR-менеджер бачить особисті дані співробітників свого підрозділу. Не бачить заробітну плату членів керівництва. Лікарські довідки — тільки HR-фахівці з підвищеним рівнем допуску. Дані звільнених — доступ за окремим запитом і реєстрацією у журналі.
Документообіг
Документ має гриф (відкритий / обмежений / таємний). Користувач бачить документ, якщо гриф ≤ його рівень допуску. Контекст: документ можна редагувати тільки автору і тільки у статусі «чернетка». Після затвердження — тільки перегляд, навіть автору.
Електронні реєстри
Реєстратор створює запис, верифікатор затверджує, керівник підписує. SoD-правила: один користувач не може бути одночасно реєстратором і верифікатором того ж запису. Аудитор бачить всі записи, але не може їх змінити.
Як описувати модель у ТЗ
Для експертизи модель прав описують у двох форматах:
- Матриця ролей/прав (для частини RBAC): таблиця «ролі × операції», кожна клітина — «дозволено / заборонено».
- Каталог політик (для частини ABAC): формальні правила вигляду «якщо атрибут користувача = X і атрибут об'єкта = Y і контекст = Z, то дозволено».
Експерт перевіряє: (1) відповідність моделі прав вимогам ТЗ; (2) повноту покриття всіх операцій; (3) реалізацію SoD-правил; (4) тестування — кожне правило перевірене окремим тест-кейсом.
UBD реалізує ABAC з гранулярністю до поля у конструкторі форм, без коду. Адміністратор у графічному інтерфейсі визначає атрибути, політики, контекстуальні умови. Кожний запит проходить через policy engine, що обчислює рішення у режимі real-time. Декларації SoD-правил — окремий механізм, перевіряється при призначенні ролей. Це покриває вимоги NIST 800-53 AC-3, AC-5, AC-6 і відповідні розділи НД ТЗІ 2.5-004-99.
UnityBaseDefense — технічна довідка →