Інтеграція генеративного ШІ (GenAI) у робочі процеси BPM зміщує периметр безпеки від статичних ролей користувачів до динамічного контексту даних. Традиційний контроль доступу на основі ролей (RBAC) залишається базовим шаром, але він більше не здатний самостійно запобігти витоку конфіденційної інформації через ШІ-агентів. Організації постають перед серйозним викликом: коли автономні алгоритми діють від імені користувачів, вони ризикують отримати надмірний доступ до чутливих даних через занадто широкі статичні права. Це змушує архітекторів корпоративних систем переходити від рольових моделей до атрибутивного контролю (ABAC) та безпеки на рівні рядків даних (Row-Level Security, RLS).
Чому RBAC більше не захищає: виклик інтеграції GenAI у бізнес-процеси
Рольова модель доступу (RBAC) десятиліттями визначала стандарти доступу. Архітектура будувалася на простому принципі: приналежність користувача до певної групи (наприклад, «Бухгалтерія») надає йому доступ до визначеного масиву таблиць або документів. Цей підхід ефективний у детермінованих системах, проте сучасна оркестрація бізнес-процесів вимагає більшої гнучкості.
Сьогодні ШІ-агенти інтегруються безпосередньо в оркестрацію процесів для аналізу документів та генерації відповідей. Якщо такий агент працює під узагальненою роллю, він успадковує доступ до всього масиву даних цієї ролі. Проблема полягає в тому, що ШІ-агент оперує лише технічними дозволами і може розкрити інформацію, яка доступна йому функціонально, але не повинна бути показана конкретному користувачеві в його поточному контексті.
Анатомія загрози: як ШІ-агенти стають точкою витоку даних (OWASP LLM02:2025)
Згідно з класифікацією OWASP, а саме положенням OWASP LLM02:2025 (Sensitive Information Disclosure), несанкціоноване розкриття конфіденційної інформації є одним із критичних ризиків для застосунків із генеративним ШІ. Витік часто відбувається через відповіді моделі або інтегровані інструменти (tools/plugins), коли бракує гранулярного контролю доступу до джерела даних.
Розглянемо реальний приклад: ШІ-агент, що обробляє тікети клієнтської підтримки, працює під загальною роллю «Support Agent». Виконуючи складний запит, він випадково отримує доступ до внутрішніх фінансових документів компанії та розкриває їхній вміст, оскільки технічно ці файли не були захищені від ролі підтримки. Традиційний RBAC тут безсилий, адже агент формально діяв у межах дозволених прав.
Рішенням є обмеження доступу не лише за посадою користувача, а й за метаданими документа (наприклад, мітка «Confidential») та контекстом сесії (IP-адреса, робочий час). Якщо поточний контекст не відповідає політиці безпеки, ШІ-агент не повинен мати змоги зчитати документ.
Від рольового до атрибутивного доступу: що таке ABAC та Row-Level Security (RLS)
Подолання цієї вразливості вимагає переходу до динамічного атрибутивного контролю доступу (ABAC). Цей підхід визначає права в реальному часі на основі низки атрибутів суб'єкта (посада, відділ), об'єкта (рівень конфіденційності документа) та середовища (IP-адреса, час запиту).
Механізм Row-Level Security (RLS) дозволяє реалізувати такий контроль безпосередньо на рівні бази даних або ORM-шару. Замість фільтрації даних в інтерфейсі, яку легко обійти через API, RLS модифікує запити на льоту. Наприклад, ШІ-агент зможе побачити лише ті рядки даних, які стосуються поточного клієнта або регіону, і фізично не отримає доступу до решти масиву.
Архітектурний підхід: реалізація контекстної безпеки на рівні платформи UnityBase
У сучасних enterprise-системах безпека має бути інтегрована на рівні ядра платформи. Прикладом такого архітектурного підходу є low-code платформа UnityBase — спільна розробка компаній консорціуму Intecracy Group (де InBase виступає ключовим, але не єдиним розробником). На базі цієї платформи побудовані такі рішення, як Megapolis.DocNet та Scriptum.DMS.
UnityBase використовує єдину модель метаданих домену (Domain metadata), яка поєднує опис даних, API та правила безпеки. Це дозволяє системі застосовувати механізми RLS та списки контролю доступу (ACL) безпосередньо на рівні ORM. Коли ШІ-агент звертається до даних через автоматично згенерований REST API, платформа обмежує вибірку залежно від контексту сесії.
Для об'єктів критичної інфраструктури, банківського та державного секторів, що мають підвищені вимоги до безпеки, офіційна документація рекомендує комерційні редакції Enterprise (EE) або Defence (DE). Вони підтримують атрибутивну безпеку, обмеження доступу за цифровим відбитком пристрою, апаратними токенами та геолокацією. Хоча існує версія OpenUB на ліцензії Apache 2.0, офіційні умови містять застереження щодо її використання в організаціях, пов'язаних із державним сектором України.
Контроль відхилень: використання Process Mining для аудиту безпеки процесів
Відокремлення бізнес-правил від логіки процесу, що реалізується за допомогою стандарту DMN (Decision Model and Notation), дозволяє оновлювати політику прийняття рішень без зміни самого workflow (наприклад, у BPMN 2.0). Проте для динамічного аудиту потрібні інструменти об'єктивного контролю.
Технологія Process Mining використовує журнали подій (event logs) для виявлення фактичного шляху виконання процесів. Аналізуючи логі, організації можуть виявляти вузькі місця, відхилення від еталонних моделей безпеки та несанкціоновані «тіньові» маршрути ШІ-агентів. Це забезпечує фактичну основу для безперервного аудиту (continuous compliance) та своєчасного блокування аномалій.
| Критерій порівняння | RBAC (Role-Based) | ABAC (Attribute-Based) + RLS |
|---|---|---|
| Основа прийняття рішення | Статична роль/група користувача (наприклад, «Бухгалтер») | Динамічні атрибути суб'єкта, об'єкта та середовища (IP, час, статус документа) |
| Реакція на дії ШІ-агентів | Сліпа зона: ШІ отримує всі права ролі, під якою запущений | Контекстна фільтрація: ШІ бачить лише ті рядки даних, які дозволені в поточному запиті |
| Складність адміністрування | Низька на старті, але призводить до «вибуху кількості ролей» при масштабуванні | Вища при проектуванні політик, але легка в масштабуванні через гнучкі правила |
| Рівень гранулярності | Грубий (доступ до сутності/таблиці загалом) | Тонкий (доступ до конкретного запису/рядка в базі даних) |
Поширені питання
Чому традиційного RBAC недостатньо для безпеки процесів з інтегрованим ШІ?
RBAC оперує статичними ролями та не враховує динамічний контекст запиту. Якщо ШІ-агент працює під широкою роллю, він отримує повний доступ до всіх її даних і через некоректний або шкідливий запит може розкрити інформацію, яка не повинна бути доступною в даному контексті.
Як працює Row-Level Security (RLS) у системах документообігу та BPM?
RLS обмежує доступ до даних на рівні окремих записів у базі даних. Механізм автоматично модифікує запити на рівні ORM, додаючи фільтри контексту (наприклад, географічний регіон чи статус документа), що фізично унеможливлює вибірку несанкціонованих даних ШІ-агентами.
Які вимоги до безпеки висувають Enterprise та Defence редакції платформи UnityBase?
Комерційні редакції Enterprise та Defence розширюють можливості платформи за рахунок атрибутивної безпеки, списків контролю доступу (ACL), автентифікації за ключами, апаратними токенами та геолокацією, що є необхідним для критичної інфраструктури та high-load систем.