§ Регуляторика на практиці

КМУ № 712 (2025): ризик-орієнтована методологія авторизації

Перехід від нормативного до ризик-орієнтованого підходу: що це означає для нових проектів.

ЧАС: 12 хв читання СКЛАДНІСТЬ: Розширена ОНОВЛЕНО: 2026-05-14

Постанова КМУ № 712 (2025) — найбільша зміна підходу до сертифікації інформаційних систем в Україні з часів НД ТЗІ 2.5-004-99 (1999). Замість фіксованого переліку вимог за класом АС вводиться ризик-орієнтована методологія: захист визначається не «що написано в нормативі для АС-2», а «які реальні ризики у вашій конкретній системі і які заходи їх адресують».

Що змінилось

Старий підхід (НД ТЗІ-орієнтований):

  1. Визначити клас АС (1, 2 або 3).
  2. Взяти стандартний функціональний профіль захищеності для цього класу.
  3. Реалізувати всі функції з профілю.
  4. Експертиза перевіряє відповідність профілю.

Новий підхід (КМУ 712):

  1. Виконати аналіз ризиків конкретної системи.
  2. Сформувати цільовий профіль захисту — набір заходів, що адресують виявлені ризики.
  3. Реалізувати заходи цільового профілю.
  4. Експертиза перевіряє адекватність ризик-аналізу та реалізації.

Принципи ризик-орієнтованого підходу

Базується на міжнародних стандартах: ISO/IEC 27005 (risk management), NIST 800-30 (risk assessment), NIST 800-37 (Risk Management Framework).

Ключові ідеї:

  • Захист — функція від ризиків. Немає «правильного захисту» взагалі — є захист, адекватний конкретним загрозам конкретної системи.
  • Заходи обираються прагматично. Замість того, щоб впроваджувати всі можливі заходи (дорого, складно), впроваджуються тільки ті, що дають істотне зниження ризику.
  • Постійний цикл. Ризик-аналіз — не одноразова робота, а регулярний процес (мінімум раз на рік або при істотних змінах).
  • Розподілена відповідальність. Замовник несе більше відповідальності за обґрунтування рішень, експерт — за оцінку якості обґрунтування.

Визначення цільового профілю захисту

Цільовий профіль — це формальний документ, що описує:

  • Активи системи (що захищаємо).
  • Загрози (від чого).
  • Уразливості (через які канали).
  • Імпакт (наслідки реалізації загрози).
  • Ймовірність (з якою може статися).
  • Залишковий ризик (impact × ймовірність).
  • Заходи (як зменшуємо ризик).
  • Резервний ризик після заходів (як виглядає після впровадження).

Замовник формулює свій цільовий профіль і захищає його перед експертом. Експерт перевіряє якість обґрунтування, а не сліпу відповідність нормативу.

Методологія оцінки ризиків

Стандартні кроки:

Крок 1. Каталог активів

Не «система загалом», а конкретні активи: БД персональних даних, фінансові записи, документообіг, журнали аудиту, ключі шифрування. Для кожного — оцінка цінності за трьома вимірами: confidentiality, integrity, availability (CIA-triad).

Крок 2. Каталог загроз

Систематичний перелік: зовнішні атакуючі, внутрішні зловмисники, ненавмисні дії персоналу, технічні відмови, природні події, регуляторні зміни. Для кожної загрози — оцінка «технічної можливості» реалізації у вашій конкретній системі.

Крок 3. Уразливості

Через які канали загрози можуть реалізуватись: незахищені інтерфейси, помилки конфігурації, слабка автентифікація, відсутність моніторингу, недостатнє навчання персоналу.

Крок 4. Імпакт і ймовірність

Impact — оцінюється як «низький / середній / високий / критичний» з прив’язкою до конкретних наслідків (фінансові, репутаційні, регуляторні, людські).

Ймовірність — на основі історичних даних, threat intelligence, експертної оцінки.

Крок 5. Матриця ризиків

Ймовірність / Імпакт Низький Середній Високий Критичний
Дуже ймовірно Середній Високий Дуже високий Критичний
Ймовірно Низький Середній Високий Дуже високий
Можливо Низький Низький Середній Високий
Малоймовірно Дуже низький Низький Низький Середній

Крок 6. Treatment plan

Для кожного ризику — рішення: уникнути (avoid), знизити (mitigate), передати (transfer — наприклад, страхування), прийняти (accept). Mitigate — це і є заходи захисту.

Mapping ризиків на функції безпеки

Кожен ризик, що mitigate’ується, прив’язується до конкретного заходу. Приклади:

  • Ризик: компрометація облікового запису через phishing → захід: MFA для всіх адмін-облікових + регулярний phishing-тренінг персоналу.
  • Ризик: інсайдер експортує великий обсяг даних → захід: DLP-механізми + моніторинг експорту + аудит з alert’ами.
  • Ризик: ransomware шифрує БД → захід: бекап з air-gapped копією + EDR на серверах + segmentation мережі.

Таблиця ризиків → заходів — основа цільового профілю. На експертизі замовник захищає логіку: «ось ризик, ось захід, ось чому захід адекватний».

Відмінності від попереднього підходу

Аспект НД ТЗІ підхід КМУ 712 підхід
Профіль захисту Стандартний за класом АС Цільовий, обґрунтований замовником
Роль замовника Реалізувати норматив Обґрунтувати свій підхід
Роль експерта Перевірити відповідність нормативу Оцінити адекватність обґрунтування
Гнучкість Низька Висока
Складність ТЗ Стандартизована Потребує сильної аналітики
Можливості для оптимізації Низькі (треба все з профілю) Високі (тільки потрібне)

Переваги і виклики

Переваги:

  • Захист «під конкретну систему», не «під шаблон».
  • Можливість не впроваджувати дорогі заходи, які не дають істотного ефекту.
  • Сумісність з міжнародними фреймворками (ISO 27001, NIST RMF, COBIT).
  • Простіше для систем, що не вписуються у стандартні класи АС.

Виклики:

  • Замовник повинен мати компетенцію у risk management. Багато українських організацій не мали досвіду.
  • Експертиза стає більш суб’єктивною — два експерти можуть по-різному оцінити одне обґрунтування.
  • Документація стає об’ємнішою (треба обґрунтовувати кожне рішення).
  • Перехідний період: системи, сертифіковані за старим підходом, продовжують існувати; нові — за новим.

Як готувати ризик-аналіз для тендера

Для участі у тендерах за новим підходом замовник готує:

  • Каталог активів з оцінкою CIA.
  • Каталог загроз і уразливостей.
  • Матрицю ризиків.
  • Цільовий профіль захисту з обґрунтуванням.
  • Treatment plan з конкретними заходами і термінами.
  • План моніторингу і регулярного перегляду.

Обсяг документації — 60-200 сторінок залежно від складності системи. Підготовка — 2-4 місяці для нової системи.

[ ПРАКТИЧНА РЕАЛІЗАЦІЯ ]
Гнучкість UBD під ризик-орієнтований підхід

UBD дозволяє декларувати цільовий профіль захисту під конкретні ризики проекту: вмикати/вимикати функції безпеки залежно від moделі загроз, конфігурувати глибину аудиту, налаштовувати криптографічні алгоритми. Замовник у ТЗ обґрунтовує конкретний набір заходів, а UBD надає документований інструмент для їх реалізації з посиланням на експертний висновок Г-3.

UnityBaseDefense — технічна довідка →

Мітки