Реєстр об’єктів критичної інформаційної інфраструктури з air-gapped контуром

Тип системи: галузевий державний реєстр з двоконтурною архітектурою. Клас АС — АС-3 (з обробкою інформації різних грифів обмеженого доступу). Унікальна особливість — наявність ізольованого сегменту, не підключеного до жодних зовнішніх мереж, з регламентованим однонаправленим обміном.

§ 01 — Постановка задачі

За Законом України № 1882-IX «Про критичну інфраструктуру» та Постановою КМУ № 943 від 09.10.2020 ведеться перелік об’єктів критичної інформаційної інфраструктури (КІІ). Перелік містить дві категорії відомостей: загальні (назва оператора, тип об’єкта, віднесення до категорії важливості) та чутливі (конкретні технічні параметри, моделі загроз, плани реагування — інформація, оприлюднення якої може створити пряму загрозу безпеці).

Реєстр повинен забезпечити: ведення переліку, оновлення даних операторами, аналітичну роботу галузевих регуляторів, обмін інформацією з міжнародними партнерами (у частині несекретних даних), реагування на інциденти.

§ 02 — Модель загроз

Цільові атаки на сам реєстр з метою отримання карти критичної інфраструктури.
Інсайдерська загроза від співробітників регулятора або операторів — у разі компрометації облікових даних.
Атаки на канал передачі між оператором об’єкта і реєстратором.
Кореляційні атаки: зловмисник може отримати загальнодоступний фрагмент реєстру і скомбінувати з відкритими джерелами, отримуючи чутливі висновки.
Затримка реакції на інцидент: у разі компрометації — критично важливо швидко обмежити поширення.

§ 03 — Відповідність нормативам

ЗУ № 1882-IX, КМУ № 943, КМУ № 518 (про категорії важливості), НД ТЗІ 2.5-004-99 (АС-3), КМУ № 712 (2025). Міжнародні рамки: NIST CSF, ENISA Threat Landscape, NIS2 Article 21.

§ 04 — Архітектурне рішення

4.1. Двоконтурна архітектура

Чітке фізичне розділення на два контури:

Зовнішній контур (open registry): публічна частина реєстру, обмежений зовнішній доступ, дані категорії «загальнодоступні». Підключений до Інтернету, інтегрований з зовнішніми системами через REST API.
Внутрішній контур (sensitive registry): фізично ізольована мережа, повний реєстр з усіма чутливими даними, доступ — лише для допущених посадових осіб регулятора.

4.2. Однонаправлений шлюз (data diode)

Передача даних із зовнішнього контуру у внутрішній — через однонаправлений шлюз, що фізично не дозволяє зворотний потік. Це класична архітектура для систем з підвищеними вимогами до confidentiality (за NIST термінологією — high impact baseline).

4.3. Збір даних від операторів

Оператори об’єктів КІІ заповнюють форми у зовнішньому контурі. Залежно від типу даних (загальнодоступні vs чутливі) — або залишаються у зовнішньому контурі, або після підпису і верифікації передаються у внутрішній. Підпис — за ДСТУ 4145 з кваліфікованими сертифікатами.

4.4. Аналітичний шар внутрішнього контуру

У внутрішньому контурі — повний реєстр, інструменти аналітики, генератор звітів, інтеграція з системами реагування на інциденти (SOC, CERT-UA). Експорт назовні — лише через ту саму data diode у зворотному напрямку, з ручним контролем.

4.5. Stateless-архітектура серверного шару

Сервер застосувань у внутрішньому контурі — без клієнтського стану. Перезавантаження не вимагає синхронізації сесій. Авторизація — на кожен запит, з обчисленням прав на основі ролі та категорії даних.

§ 05 — Mapping відповідності

Стандарт / норматив	Положення	Реалізація
ЗУ № 1882-IX	Перелік об’єктів КІІ	Реалізовано
КМУ № 712 (2025)	Авторизація систем безпеки	Реалізовано
НД ТЗІ 2.5-004-99	Профіль захисту АС-3	Реалізовано
NIST CSF Protect	Access Control, Data Security	Реалізовано
NIS2 Article 21.2(j)	Inter-system communication security	Реалізовано
NIST 800-207 Tenet 5	Continuous monitoring	Частково
NIST 800-207 Tenet 7	Dynamic policy	Roadmap

[ ПРАКТИЧНА РЕАЛІЗАЦІЯ ]

Як цю архітектуру реалізовано на UnityBaseDefense

Stateless-архітектура — частина платформи з 2015 року. Air-gapped розгортання можливе завдяки відсутності «домашніх дзвінків» (no telemetry), повної автономності інсталяції та підтримці offline-оновлень. Робота через однонаправлені шлюзи реалізована через файлову інтеграцію (експорт/імпорт JSON або XML) і апарат прикладних транзакцій, що зберігаються в журналі обох контурів.

Технічна архітектура UnityBaseDefense →

§ 06 — Компроміси та обмеження

Складність експлуатації: двоконтурна архітектура потребує дисциплінованого регламенту обміну. Помилка в регламенті обнуляє переваги архітектури.
Затримка оновлень: зміни у внутрішньому контурі — це окрема процедура. Real-time дашбордів для внутрішнього сегменту в архітектурі немає за дизайном.
Висока вартість підтримки: два паралельні envoronments означають дві команди адміністрування, дві ліцензії, дві апаратні платформи. Це закономірна плата за рівень захисту.
Обмежений потенціал ML/AI-аналітики: у ізольованому контурі немає легкого доступу до сучасних cloud-based AI-сервісів. Аналітика — або on-prem, або через ручні експорти.