Концепція автоматизації бізнес-процесів тривалий час розвивалася під гаслом швидкості виконання та зниження операційних витрат. Проте сучасні реалії управління ризиками, зокрема впровадження жорстких вимог європейської директиви NIS2, зміщують фокус. Сьогодні суто операційної швидкості вже недостатньо — критично важливою стає доказова цілісність, або Digital Provenance (цифрове походження даних та рішень). Відсутність механізмів, які дозволяють беззаперечно довести аудиторам, як саме, ким і на основі якої логіки було прийнято рішення або змінено дані в системі, перетворюється на критичний технічний борг.
Для CTO, CIO, архітекторів систем та офіцерів з інформаційної безпеки (CISO) підприємств критичної інфраструктури це означає необхідність перегляду підходів до проектування корпоративних рішень. Традиційне логування в реляційних базах даних більше не задовольняє вимоги регуляторів щодо простежуваності (data lineage) та незмінності журналів аудиту (immutable audit trail).
Чому NIS2 змінює правила гри: від захисту периметра до доказової цілісності процесів
Директива NIS2 вимагає від організацій не просто захищати периметр мережі, а впроваджувати наскрізне управління ризиками та забезпечувати доказову стійкість бізнес-процесів. Якщо раніше безпека процесу погодження фінансових транзакцій оцінювалася наявністю WAF та засобів контролю доступу, то під час NIS2-аудиту ключове питання звучить інакше: «Як ви можете довести, що цей процес не був модифікований зсередини, а дані не зазнали несанкціонованих змін на шляху від ініціації до фінального рішення?»
Аудит автоматизованого процесу погодження фінансових транзакцій вимагає можливості відновити повний ланцюжок змін даних (data lineage). Проте більшість компаній, які не мають вбудованого механізму Digital Provenance, змушені вручну збирати лог-файли з різних систем. Такий підхід робить швидке підтвердження цілісності процесу майже неможливим.
Анатомія технічного боргу: чому звичайних системних логів недостатньо для аудиту
Типова архітектурна помилка — використання виключно стандартних системних логів (application logs) або тригерів реляційних баз даних як джерела аудиторського сліду. З погляду регуляторних вимог, такий підхід має фундаментальні недоліки:
- Відсутність бізнес-контексту: Технічний лог бази даних фіксує факт зміни рядка, але не пояснює, в рамках якого бізнес-процесу це відбулося і яке саме бізнес-правило спрацювало.
- Вразливість до модифікацій: Логування, яке ведеться без криптографічного захисту або не у WORM-сховищах, може бути легко модифіковане або видалене користувачами з привілейованими правами (наприклад, DBA).
- Невідповідність фактичного виконання задекларованим правилам: Технічне логування не дозволяє автоматично виявляти несанкціоновані обхідні шляхи (shadow-процеси) в бізнес-логіці, які виникають через розбіжність між моделлю та реальними діями користувачів.
Щоб усунути цей технічний борг, архітектура системи повинна гарантувати незмінність аудиторського сліду та забезпечувати чітке розділення логіки потоку (workflow) від логіки прийняття рішень.
Архітектура Digital Provenance: поєднання BPMN 2.0, DMN та незмінних аудиторських слідів
Надійна архітектура довіри (Governance) базується на використанні відкритих виконуваних стандартів. Це дозволяє уникнути жорсткого кодування (hardcoding) бізнес-правил та створює єдине джерело істини.
1. Виконуваний стандарт BPMN 2.0
Стандарт Business Process Model and Notation (BPMN 2.0.2 опублікований як міжнародний стандарт ISO/IEC 19510:2013 організацією Object Management Group) є виконуваним стандартом, який одночасно документує процес та керує ним. Коли процес керується process engine (наприклад, рушієм Camunda), кожен стан інстансу процесу стає видимим і фіксується автоматично, гарантуючи, що реальне виконання відповідає регламенту.
2. Розділення логіки за допомогою DMN
Стандарт Decision Model and Notation (DMN) дозволяє винести бізнес-правила з програмного коду в окремі таблиці рішень. Наприклад, розділення логіки розрахунку лімітів кредитування від логіки потоку процесу дозволяє швидко оновлювати ці правила без ризику порушення цілісності workflow. Це робить ІТ-аудит прозорим: система фіксує не лише результат, а й версію DMN-таблиці та вхідні параметри, що призвели до автоматичного рішення.
3. Забезпечення Immutable Audit Trail
Технологія блокчейн не є єдиним чи обов'язковим способом реалізації immutable audit trail. У корпоративних системах незмінність досягається на рівні архітектури через криптографічне хешування транзакцій, використання WORM-сховищ або захищених журналів аудиту з суворим контролем доступу на рівні рядків (Row-Level Security) та атрибутів.
Process Mining як інструмент виявлення shadow-процесів та відхилень
Process mining дозволяє відновити реальний перебіг процесів з event logs, виявляючи приховані (shadow) маршрути та вузькі місця, які не відображені в офіційних схемах. За даними Celonis, використання process mining часто виявляє, що реальні процеси відхиляються від задокументованих моделей у 20-значна частина випадків.
Варто зазначити, що Process Mining не є засобом активного захисту від кібератак. Це інструмент діагностики та видимості, що виявляє відхилення (compliance monitoring) і забезпечує можливість перевірки фактичного перебігу процесів під час аудиту.
Вбудована безпека на рівні платформи: реалізація вимог NIS2 за допомогою UnityBase та Scriptum
Впровадження архітектури Digital Provenance «з нуля» створює значне навантаження на розробку. Раціональним підходом є використання enterprise-платформ, де механізми аудиту та безпеки вбудовані на рівні ядра.
Для побудови таких систем доречно використовувати low-code платформу UnityBase. Платформа є спільною розробкою компаній консорціуму Intecracy Group (де InBase виступає ключовим, але не єдиним розробником). UnityBase пропонує архітектурні механізми, які спрощують підготовку до NIS2-аудиту:
- Domain metadata: Єдина метамодель для даних, API та інтерфейсу (Admin UI), що унеможливлює модифікацію даних в обхід прикладних правил.
- Вбудований Audit Trail (DataHistory): Платформа автоматично фіксує будь-які зміни критичних атрибутів, зберігаючи автора, час та попередні значення для забезпечення наскрізного data lineage.
- Гнучка модель безпеки: Підтримка Role-Based Access Control (RBAC), Row-Level Security (RLS) та Attribute-Level Security (доступна в комерційних редакціях EE/DE), що дозволяє чітко розмежувати права доступу на найнижчому рівні.
На базі платформи UnityBase побудована система автоматизації процесів Scriptum, яка працює з BPMN-рушієм Camunda. Їх поєднання забезпечує розподіл бізнес-логіки та потоку робіт, а також автоматичне документування стану інстансів процесу. Впровадження Digital Provenance завдяки готовому стеку механізмів дозволяє скоротити час на підготовку до аудиту з тижнів до годин.
Рівні зрілості Digital Provenance в автоматизованих процесах для NIS2
| Рівень зрілості | Характеристики логування | Вплив на відповідність NIS2 | Технічна реалізація |
|---|---|---|---|
| Рівень 0 (Хаотичний) | Логування відсутнє або ведеться у текстові файли, які можна вручну модифікувати. Відсутній зв'язок між бізнес-контекстом і технічними подіями. | Критичний ризик. Неможливість довести цілісність системи аудиторам. | Локальні неструктуровані лог-файли. |
| Рівень 1 (Фрагментарний) | Логування ведеться в БД. Є базовий аудит змін, але відсутній data lineage (неможливо відтворити ланцюжок прийняття рішень). | Низька відповідність. Значні витрати часу на розслідування інцидентів. | Тригери бази даних, фрагментовані таблиці логів. |
| Рівень 2 (Регламентований) | Використовується BPMN-рушій. Процеси задокументовані, логування ведеться на рівні кроків процесу, але правила прийняття рішень (DMN) зашиті в коді. | Часткова відповідність. Прозорий потік робіт, але складно перевірити логіку конкретного рішення. | BPMN-платформи з базовим історіюванням виконання. |
| Рівень 3 (Доказовий / NIS2-ready) | Повний immutable audit trail. Розділення workflow (BPMN) та бізнес-правил (DMN). Автоматичний контроль data lineage на рівні доменної моделі. | Висока готовність до аудиту. Швидкий доступ до доказової бази. | Використання механізмів на кшталт UnityBase (RLS/Audit Trail) та систем автоматизації (Scriptum з Camunda). |
Відповідність вимогам директиви NIS2 вимагає не лише наявності організаційних політик безпеки, а й впровадження доказової цілісності безпосередньо в ІТ-архітектуру. Поєднання виконуваних стандартів BPMN 2.0 та DMN із вбудованими механізмами DataHistory на базі сучасних low-code платформ усуває технічний борг і створює надійний фундамент довіри до автоматизованих рішень.
Поширені питання
Що таке Digital Provenance і чому це критично для відповідності директиві NIS2?
Digital Provenance — це доказова цілісність та можливість простежити походження даних і рішень у системі. Для NIS2 це критично, оскільки організація повинна мати можливість технічно довести регуляторам, що жоден етап критичного процесу чи стан даних не був несанкціоновано змінений.
Як розділення стандартів BPMN 2.0 та DMN допомагає пройти ІТ-аудит?
DMN дозволяє винести логіку прийняття рішень в окремі таблиці, незалежні від потоку процесу (BPMN). Це дає змогу аудиторам чітко бачити, яка версія правил і які вхідні параметри призвели до конкретного рішення в системі, не аналізуючи при цьому програмний код.
Як забезпечити незмінність аудиторського сліду (immutable audit trail) у корпоративних системах?
Незмінність забезпечується не тільки блокчейном, а й класичними архітектурними підходами: криптографічним хешуванням, використанням WORM-сховищ та вбудованим історіюванням на рівні доменної моделі (наприклад, через механізм DataHistory та Row-Level Security у платформі UnityBase).