Від ролі до поля: гранулярність прав, segregation of duties, контекстуальна авторизація.
Модель прав — це не «дамо доступ цій ролі до цього модуля». Модель прав — це формальний опис того, хто і за яких умов може здійснити кожну операцію над кожним об’єктом. На AC-2 і АС-3 системах експерт перевіряє саме формальну специфікацію — не «налаштування інтерфейсу».
Існує чотири рівні гранулярності, через які проходить будь-яка модель прав:
Користувач X має доступ до модуля «Документообіг». Найгрубший рівень. Достатньо для багатьох внутрішніх систем, не достатньо для систем з обмеженою інформацією. NIST 800-53 AC-3 вимагає більш гранулярного контролю там, де це доцільно.
Користувач X має доступ до своїх документів, не до документів інших підрозділів. Класична фільтрація по власнику / підрозділу / території. Достатньо для більшості АС-2.
Користувач X бачить документ, але не бачить полів «коментар служби безпеки» та «оцінка ризику». Інша роль — бачить ці поля. Для АС-3 з мішаним грифом — обов’язково.
Користувач X бачить поле «коментар», але тільки коментарі, не позначені як «обмежений доступ». Найбільш гранулярний рівень. Рідко потрібний, але існує (наприклад, у CRM з продажами охоронним компаніям або режимним об’єктам).
Два основні підходи до моделювання прав:
| Параметр | RBAC (role-based) | ABAC (attribute-based) |
|---|---|---|
| Принцип | Користувач → роль → права | Атрибути користувача + атрибути об’єкта + контекст → рішення |
| Гнучкість | Низька-середня | Висока |
| Складність налагодження | Низька | Висока |
| Кількість ролей у великій системі | 100-1000+ (role explosion) | 10-30 (атрибути замість ролей) |
| Контекстуальна авторизація | Складно | Природньо |
| Аудит | Простий | Складніший |
| Експерт-перевірка | Перевірка матриці | Перевірка політик |
На практиці чисто RBAC або чисто ABAC зустрічаються рідко. Більшість систем — гібридні: ABAC у частинах, де є контекстуальна логіка, RBAC у простих.
Принцип розділення обов’язків — обов’язкова частина моделі прав. Класичний приклад: особа, що створює платіж, не може його затверджувати. NIST 800-53 AC-5 прямо вимагає SoD-контролі.
Реалізація: матриця заборонених комбінацій ролей/атрибутів. Якщо користувач отримує дві несумісні ролі — система блокує отримання другої.
Типові SoD-правила:
Принцип: рішення про доступ залежить не тільки від користувача та об’єкта, а від поточного контексту. Контекст включає:
Контекстуальна авторизація вимагає, щоб модель прав була не статичною матрицею, а політикою, що обчислюється у момент запиту.
Складна модель: HR-менеджер бачить особисті дані співробітників свого підрозділу. Не бачить заробітну плату членів керівництва. Лікарські довідки — тільки HR-фахівці з підвищеним рівнем допуску. Дані звільнених — доступ за окремим запитом і реєстрацією у журналі.
Документ має гриф (відкритий / обмежений / таємний). Користувач бачить документ, якщо гриф ≤ його рівень допуску. Контекст: документ можна редагувати тільки автору і тільки у статусі «чернетка». Після затвердження — тільки перегляд, навіть автору.
Реєстратор створює запис, верифікатор затверджує, керівник підписує. SoD-правила: один користувач не може бути одночасно реєстратором і верифікатором того ж запису. Аудитор бачить всі записи, але не може їх змінити.
Для експертизи модель прав описують у двох форматах:
Експерт перевіряє: (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.