Порядок створення КСЗІ не є довільним: його визначає нормативний документ системи технічного захисту інформації, і він однаковий незалежно від того, будується захист із нуля чи додається до вже робочої системи. Розберемо шість кроків методично — що на кожному відбувається, які папери з'являються та куди все це веде сьогодні. Що таке комплексний захист загалом — у статті КСЗІ простими словами.
Спершу клас: створення КСЗІ в АС різного рівня — різні всесвіти
Ще до початку робіт систему класифікують. Класична схема виділяє три ієрархічні класи автоматизованих систем:
- клас 1 — одномашинний однокористувацький комплекс: найпростіший випадок, який у житті трапляється рідко;
- клас 2 — локалізований багатомашинний багатокористувацький комплекс, тобто звичайна локальна мережа;
- клас 3 — розподілений багатомашинний багатокористувацький комплекс, зокрема з доступом до мереж загального користування.
Від класу залежить набір обов'язкових функціональних послуг безпеки, а отже — обсяг та складність робіт. Створення КСЗІ класу 1 і створення КСЗІ класу 3 відрізняються радикально: у першому випадку йдеться про одну машину, у другому — про розподілене середовище з виходом назовні (див. КСЗІ в ІКС).
Класифікація — не формальність і не самоціль. Вона просто відповідає на питання, скільки обов'язкових функцій безпеки доведеться реалізувати. Для однієї машини їх кілька. Для розподіленого середовища з виходом назовні — десятки, і кожну треба довести.
Практичний наслідок: перша битва проєкту точиться навколо межі. Що менше вузлів ви чесно можете вивести за контур, то дешевший результат. Але саме чесно — «забути» про філію дешевше рівно до першої перевірки.
Етапи створення КСЗІ: шість кроків
Далі — методична логіка. Вона стійка: змінюються нормативні документи, змінюються назви підсумкових паперів, а послідовність лишається.
Крок перший. Формування вимог
Найважливіший і найбільш недооцінений. Тут закладається все інше.
Що відбувається:
- обґрунтування необхідності робіт — на підставі законодавства, а не бажання;
- створення служби захисту інформації (СЗІ) — хто взагалі веде проєкт;
- обстеження середовищ функціонування: обчислювального, інформаційного, фізичного та середовища користувачів;
- категоріювання об'єкта, якщо йдеться про регульоване приміщення;
- побудова моделі загроз — що саме нам загрожує;
- побудова моделі порушника — хто здатен нашкодити, з якими можливостями та мотивами;
- формування завдання на роботи.
Строк цього кроку зазвичай недооцінюють удвічі: обстеження гальмує не апаратура, а люди, яким треба знайти час і згадати, що де лежить.
Ключова думка. Якщо модель загроз складено формально, уся подальша конструкція оберігатиме не від того, від чого треба. Це найдешевший спосіб змарнувати бюджет — і найпоширеніший.
Крок другий. Політика безпеки
На основі моделей визначають, як саме захищати: правила доступу, розмежування прав, порядок роботи з відомостями, реагування на події. Результат оформлюють політикою (планом) захисту.
Тут корисно пам'ятати про людей. Політика, яку неможливо виконати, не виконується — її обходять. Тож правила варто звіряти з тими, хто щодня ними користуватиметься.
Показник якості простий: якщо співробітник переказує правила своїми словами — політику написано добре. Якщо він лише знає, де вона лежить, — переписуйте.
Крок третій. Технічне завдання
ТЗ — центральний документ проєкту. Саме з ним потім звірятимуть результат, і саме він погоджується з органами Держспецзв'язку.
Найчастіша причина переробок — ТЗ, написане «під обладнання»: замість властивостей, які має мати захист, туди переносять специфікацію бажаного пристрою. Детально про цей крок і про ролі учасників — у статті побудова КСЗІ: наказ і ТЗ.
Крок четвертий. Проєкт
Проєктні рішення: які заходи та засоби ТЗІ реалізують вимоги ТЗ, як вони поєднуються між собою. Залежно від складності проєкт виконують у кілька стадій — ескізну, технічну, робочу.
Тут же добирають вироби з підтвердженою відповідністю (див. сертифіковані засоби захисту). Саме тут, а не місяцем раніше.
Крок п'ятий. Введення у дію та оцінювання захищеності
Найдовший відрізок, що складається з кількох стадій:
- підготовка до введення у дію: експлуатаційна документація, інструкції, формуляр;
- навчання персоналу — люди мають знати, як працювати із захистом, а не обходити його;
- комплектування, монтаж, пусконалагоджувальні роботи;
- попередні випробування — програма й методика, протокол, акт;
- дослідна експлуатація у реальних умовах, із виявленням та усуненням проблем;
- оцінювання захищеності — і саме тут за останній рік усе змінилося;
- наказ про дозвіл на обробку та введення у постійну роботу.
Про дослідну експлуатацію окремо. Це не формальність перед підписанням акта, а єдиний шанс побачити захист у бою: як він поводиться під піковим навантаженням, скільки хибних спрацювань дає щодня, чи не ламає він робочі процеси настільки, що люди почнуть шукати обхідні шляхи. Період, коротший за один робочий цикл установи, майже завжди марний.
Крок шостий. Супроводження
Створенням нічого не закінчується. Захист треба підтримувати: оновлювати, контролювати, реагувати на зміни середовища та загроз. Суттєва модернізація зазвичай означає повторне оцінювання.
Найчастіша помилка тут — вважати підсумковий документ індульгенцією. Він засвідчує стан на конкретну дату. Через рік система вже інша.
Окремий випадок: система вже працює
Класична схема описує побудову з нуля. Реальність частіше інша: середовище давно живе, люди звикли, зупиняти його ніхто не дасть.
Логіка кроків від цього не змінюється, але додаються три складнощі.
- Інвентаризація замість проєктування. Спершу треба чесно описати те, що вже є: вузли, застосунки, потоки, доступи. Зазвичай виявляється, що половини цього немає в жодній схемі.
- Розрив між тим, що є, і тим, що потрібно. Його оформлюють переліком розбіжностей із черговістю усунення. Це і стає планом робіт.
- Ризик простою. Кожна зміна у робочому середовищі — потенційна зупинка. Тому впровадження ведуть хвилями, з вікнами й відкатом.
Парадокс у тому, що захист на вже робочій системі часто виходить чеснішим: модель загроз пишуть за фактичними процесами, а не за уявленнями про них.
Куди ведуть кроки сьогодні
Головне, чого немає у більшості матеріалів мережі.
Раніше п'ятий крок закінчувався так: державна експертиза → експертний висновок → Атестат відповідності → наказ про постійну експлуатацію.
Тепер для нових середовищ фініш інший: цільовий профіль безпеки → оцінювання його реалізації → авторизаційний лист → включення до переліку авторизованих систем. Модель запроваджено постановою Кабінету Міністрів № 712 від 18.06.2025, перехідний період завершився 18 червня 2026 року.
Що це означає практично:
- кроки з першого по четвертий і шостий не змінилися — обстеження, моделі, правила, проєкт і супроводження потрібні так само;
- змінився зміст п'ятого: замість «доведи відповідність власному ТЗ» — «покажи, як реалізовано кожен пункт профілю»;
- раніше видані документи діють до кінця свого строку.
Держспецзв'язку окремо оприлюднила перелік нормативних документів для побудови захисту з використанням базових і цільових профілів — тобто методичну базу оновлено, а не скасовано.
Кроки можна поєднувати — і це прямо передбачено
Малознаний факт, який економить місяці. Нормативний документ дозволяє виключати окремі етапи робіт або поєднувати кілька — залежно від масштабу й характеру системи.
Умова одна: рішення має бути обґрунтоване й зафіксоване у технічному завданні. Не «ми вирішили пропустити», а «за таких-то характеристик середовища ці стадії поєднано з такої-то причини».
Для невеликої однокористувацької системи це може згорнути проєкт удвічі. Для розподіленого середовища — навряд чи: там кожна стадія має власний сенс.
Де проєкти найчастіше зупиняються
- На переліку відомостей. Установа щиро вважає, що обробляє «звичайні робочі файли», а виявляється службова інформація. Обсяг робіт змінюється, кошторис — теж. Тому інвентаризацію варто робити до підписання договору, а не після.
- На технічному завданні. Погодження вимагає точності, а перша редакція зазвичай описує бажане обладнання.
- На дослідній експлуатації. Засоби конфліктують із застосунками, і виявляється це не на стенді.
- На персоналі. Правила затверджено, але їх ніхто не читав, і оцінювач це бачить за п'ять хвилин розмови.
- На підряднику. Виконавець без потрібної ліцензії — і всі попередні місяці марні.
Які папери має отримати замовник
Результат — не пристрій на стіні, а папка. У ній щонайменше має бути:
- перелік відомостей, які підлягають захисту;
- акт обстеження середовищ функціонування;
- модель загроз і модель порушника;
- політика (план) захисту;
- технічне завдання з погодженням;
- проєктні рішення й перелік застосованих виробів із документами відповідності;
- програма й методика випробувань, протоколи, акти;
- експлуатаційна документація та інструкції для персоналу;
- підсумковий документ оцінювання.
Якщо підрядник обіцяє «зробити все й віддати один папірець» — насторожтеся: перевіряти будуть саме проміжні документи.
І ще: кожен документ має жити далі. Акт обстеження застаріває після першої ж перебудови мережі, модель загроз — після появи нового сервісу. Папку варто вести як робочий інструмент, а не як архів під перевірку.
Коротко про головне
Послідовність кроків стійкіша за нормативні документи, які її описують. Спершу розібратися, що і від кого оберігати. Потім вирішити як. Потім побудувати. Потім довести. І далі підтримувати. Змінюється лише те, кому і яким документом ви це доводите.
Логіка процесу однією фразою
Спершу зрозуміти, що і від кого оберігати (обстеження, моделі), потім вирішити, як (політика, ТЗ), потім побудувати (проєкт, впровадження), потім довести, що працює (випробування, дослідна експлуатація, оцінювання), і далі підтримувати.
Це, до речі, та сама логіка, що й у міжнародному ISO 27001 — просто викладена українськими нормативними словами.