Контроль цілісності є одним із базових елементів захищеної інформаційної системи. Для державного сектору, критичної інфраструктури та систем з обмеженим доступом важливо не лише реалізувати механізми захисту, а й довести їхню наявність, керованість і відповідність документації під час експертизи.
У межах української нормативної бази ключовим документом для оцінювання захищеності комп’ютерних систем від несанкціонованого доступу є НД ТЗІ 2.5-004-99. Саме в цьому контексті UnityBaseDefense розглядається як платформна основа UnityBase для побудови захищених інформаційних систем із підтвердженим рівнем гарантій Г-3.
Для систем рівня Г-3 контроль цілісності — це не окрема функція, а частина загальної доказової бази: архітектури, документації, журналів подій, процедур супроводу та контролю змін.
Антон Марреро, Президент, Softline IT
Роль UnityBaseDefense
UnityBaseDefense — це full-stack платформа для побудови інформаційних систем, у яких модель доступу складніша, ніж проста схема “роль → модуль”. Платформа реалізує авторизацію на рівні застосунку: кожне звернення до даних проходить через прикладну політику, з урахуванням ролі користувача, контексту, стану запису та визначених правил доступу.
Такий підхід важливий для реєстрів, кадрових систем, документообігу, шлюзів обміну та інших систем, де права доступу мають обчислюватися не лише на рівні екрана чи таблиці, а на рівні конкретного запису або поля.
Що саме контролюється
Контроль цілісності в архітектурі такого класу охоплює кілька рівнів:
- програмні компоненти — серверне ядро, модулі, бібліотеки, службові скрипти;
- конфігурації — параметри системи, політики доступу, профілі безпеки;
- моделі даних — структури сутностей, форми, правила валідації, маршрути процесів;
- бази даних — схеми, службові таблиці, журнали транзакцій, критичні записи;
- журнали аудиту — дії користувачів, адміністраторів і системних процесів.
Технічні засоби реалізації
Для контролю цілісності можуть використовуватися криптографічні хеші, цифрові підписи, контроль еталонних конфігурацій, централізоване журналювання та SIEM-інтеграція. Практична цінність цих механізмів полягає не в самому факті їх наявності, а в тому, що вони включені в регламент експлуатації та можуть бути перевірені.
-
Хешування та контрольні суми.
Для критичних файлів, конфігурацій і пакетів оновлення можуть застосовуватися SHA-256, SHA-384 або SHA-512. -
Цифрові підписи.
Для підтвердження походження компонентів і незмінності оновлень можуть використовуватися чинні механізми ЕЦП та інтеграція із сертифікованими засобами криптографічного захисту. -
Audit trail.
Дії користувачів, адміністраторів і системні події фіксуються у журналі, який використовується для перевірок, розслідувань і аналізу інцидентів. -
Контроль конфігурацій.
Поточний стан системи порівнюється з еталонним профілем. Відхилення мають бути пояснені як санкціонована зміна, технічна помилка або потенційний інцидент. -
SIEM-інтеграція.
Події порушення цілісності можуть передаватися до Splunk, Elastic Security або іншої SIEM-системи для кореляції з іншими ознаками компрометації.
Для платформного рішення важливо мати не просто список функцій безпеки, а контрольований життєвий цикл: хто змінив, що змінив, коли змінив і чи відповідає зміна затвердженій конфігурації.
Михайло Віговський, Член Наглядової ради, Intecracy Group
Zero Trust на рівні застосунку
Багато Zero Trust-рішень працюють як зовнішній шар: IAM, ZTNA, service mesh або політика доступу на периметрі. UnityBaseDefense використовує інший акцент — перевірку доступу всередині прикладної логіки, де система має повний контекст даних.
Це дозволяє ухвалювати рішення не лише за роллю користувача, а й за станом запису, підрозділом, історією доступу, типом операції та політиками конкретного прикладного рішення.
- Never trust, always verify. Авторизація обчислюється на кожен запит.
- Assume breach. Система виходить із припущення, що окремий вузол або сесія можуть бути скомпрометовані.
- Least privilege by design. Права доступу задаються гранулярно — до рівня записів і полів.
- Identity-first authentication. Підтримуються LDAP / Active Directory, SSO, ЕЦП та PKI-інтеграції.
Г-3 і доказовість захисту
Рівень гарантій Г-3 означає, що під час експертизи перевіряється не лише наявність заявлених функцій безпеки, а й відповідність реалізації документації, проектні матеріали, результати тестування, аналіз вразливостей і стійкість функцій безпеки до спроб обходу.
Тому для архітектора важливо мати платформні докази ще до старту прикладного проєкту: опис моделі доступу, механізми журналювання, підхід до захисту каналу клієнт-сервер, інтеграцію з криптографічними засобами та процедури супроводу.
Постквантова готовність
У 2026 році коректніше говорити не про завершену міграцію на постквантову криптографію, а про crypto-agility — готовність архітектури до поступової заміни криптографічних механізмів. Для довгоживучих державних систем це означає інвентаризацію криптографії, відокремлення криптографічних механізмів від бізнес-логіки та можливість у майбутньому підтримати ML-KEM, ML-DSA або SLH-DSA там, де це буде нормативно й технічно доречно.
Для державних систем головне — не використати найновіший алгоритм першим, а побудувати архітектуру так, щоб перехід на нові криптографічні механізми був керованим і перевірюваним.
Юрій Сивицький, Член Наглядової ради, Intecracy Group
Контроль цілісності в UnityBaseDefense слід розглядати як частину ширшої архітектури захищеної платформи рівня Г-3. Йдеться не лише про хеші, підписи чи журнали, а про систему доказів: контроль змін, гранулярну авторизацію, audit trail, документовані процедури, on-prem розгортання та інтеграцію з криптографічними засобами.