Реєстр об'єктів критичної інформаційної інфраструктури — система, що ведеться галузевим або центральним регулятором. Містить: перелік об'єктів КІІ за секторами (енергетика, телеком, банки, транспорт, охорона здоров'я), категорії важливості, оператори, технічні характеристики, історія інцидентів, відповідність вимогам безпеки.
§ 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 місяців. Бюджет — індивідуально, від десятків мільйонів грн.