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

Реєстр об’єктів критичної інформаційної інфраструктури — система, що ведеться галузевим або центральним регулятором. Містить: перелік об’єктів КІІ за секторами (енергетика, телеком, банки, транспорт, охорона здоров’я), категорії важливості, оператори, технічні характеристики, історія інцидентів, відповідність вимогам безпеки.

§ 01 — Тип системи

Спеціалізована реєстраційна система з обмеженим колом користувачів (галузевий регулятор + оператори об’єктів КІІ). Класифікація АС — АС-2 з підвищеними вимогами через категорію інформації. Користувачів — від десятків (галузевий регулятор) до кількох тисяч (множинні оператори в галузі).

Особливість: дані одного об’єкту бачать лише регулятор і оператор цього об’єкту. Між операторами — повна ізоляція. Це формує специфічну модель прав.

§ 02 — Виклики та модель загроз

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

§ 03 — Вимоги нормативів

Закон № 1882-IX «Про критичну інфраструктуру»
КМУ № 943 (2020) — порядок формування переліку об’єктів КІІ
КМУ № 518 (2020) — категорії важливості об’єктів КІІ
КМУ № 712 (2025) — ризик-орієнтована авторизація
НД ТЗІ 2.5-004-99 — АС-2 з підвищеними вимогами
NIS2 Directive (для гармонізації з ЄС)
NIST 800-82 Guide to OT Security (для частини, що стосується технічних характеристик)

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

Multi-tenancy на UBD

Один інстанс UBD обслуговує усю галузь. Розділення між операторами реалізоване не як окремі бази даних, а як окрема модель прав з обов’язковою фільтрацією по тенанту. Кожен запит автоматично проходить через перевірку: який оператор запитує, до даних якого об’єкту, з якою метою.

Це принципово важливо: фізично окремі БД для кожного оператора — погана архітектура для реєстру, бо ускладнює агрегаційну звітність регулятору. Гранулярна модель прав з фільтрацією на рівні запиту вирішує задачу елегантніше.

Реєстраційна частина

Оператори вносять дані про свої об’єкти через захищений АРМ. Інформація: технічні характеристики, локалізація (з рівнем агрегації, що не дозволяє визначити точне місцезнаходження критичних точок), оператори, постачальники, перелік виявлених ризиків, плани заходів безпеки.

Регулятор переглядає, верифікує, веде категоризацію об’єктів за КМУ № 518. Внесення змін у категорію — окрема процедура з підписом керівника регулятора.

Облік ризиків

На UBD реалізується ризик-орієнтований підхід (відповідно до КМУ № 712): оператори декларують виявлені ризики, регулятор аналізує, формується цільовий профіль захисту для кожної категорії об’єктів. Профілі — динамічні, оновлюються з кожним інцидентом у галузі.

Журнал інцидентів

Окрема функціональна частина реєстру. Оператор повідомляє інцидент за встановленою формою. Регулятор отримує сповіщення в межах термінів NIS2 (24-72 години залежно від типу інциденту). Журнал доступний для агрегаційного аналізу — без розкриття подробиць конкретного інциденту іншим операторам.

Інтеграція з європейською системою

Для гармонізації з NIS2 — інтеграція з European CSIRT мережею через стандартизовані канали. Обмін знеособленою інформацією про інциденти, технічні індикатори компрометації, методи атак.

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

Контроль	Норматив	Реалізація на UBD
Профіль захисту АС-2	НД ТЗІ 2.5-004-99	Г-3
Ризик-орієнтована методологія	КМУ № 712 (2025)	Цільові профілі
Категоризація КІІ	КМУ № 518	Прикладна логіка
Управління інцидентами	NIS2 Art. 21.2(d)	Через прикладну логіку
Звітування про інциденти	NIS2 Art. 23 (24-72h)	Автоматизовано
Multi-tenancy ізоляція	—	Модель прав на рівні запиту
Незмінний журнал змін	NIST 800-53 AU	WORM
Інтеграція з European CSIRT	NIS2 Art. 12	Roadmap

§ 06 — Що НЕ робимо у цій архітектурі

Не централізована система моніторингу. Реєстр КІІ — про облік і категоризацію об’єктів, а не про активний моніторинг технологічної мережі операторів. Real-time SIEM для OT — окрема система, що інтегрується з реєстром, але працює окремо.
Не AI-аналіз ризиків автоматично. Регулятор приймає рішення про категоризацію людиною з відповідною кваліфікацією. AI може давати рекомендації, але не приймає рішень про категорію критичної інфраструктури.
Не публічний API для перевірки статусу об’єкту. Інформація про категорію КІІ окремого об’єкту — не публічна. Запити — тільки через автентифіковані канали з підтвердженням повноважень.

§ 07 — Орієнтовний обсяг проекту

Реєстр об’єктів КІІ — типовий регуляторний проект. Терміни залежать від галузі (енергетика складніша за телеком через специфіку OT), кількості об’єктів, ступеня гармонізації з ЄС.

Обстеження галузі, формування ТЗ — 3-6 місяців
Архітектура і КСЗІ — 4-8 місяців
Розробка прикладного рішення — 9-18 місяців
Міграція з існуючих реєстрів (часто паперових або у Excel) — 3-9 місяців
Пілот з обмеженим колом операторів — 3-6 місяців
Повний запуск — поетапно протягом року

Загальний термін від запуску проекту до промислової експлуатації — від 24 до 48 місяців. Бюджет — індивідуально, від десятків мільйонів грн.