Консультація
Про нас Кейси Блог Контакти Службові сторінки
Стандарти / НСТ

КСЗІ в інформаційно-комунікаційних системах: особливості побудови

01.08.2027

КСЗІ в ІКС: чому розподілене середовище складніше, що змінюється технічно, роль дослідної експлуатації та які два маршрути підтвердження діють сьогодні.

Побудова КСЗІ в інформаційно-комунікаційній системі: розподілені вузли, шифровані канали зв'язку, сегментований периметр і контроль підключень до зовнішніх мереж

Вибудувати захист усередині однієї «коробки» — одна задача. Побудувати його там, де вузли розкидані по містах, канали виходять за периметр, а користувачів сотні, — задача принципово інша. Розберемо технічні особливості. Базове пояснення — у статті КСЗІ простими словами.

ІКС, ІТС і чому у документах різні слова

Спершу термінологія, бо вона плутає навіть фахівців.

Донедавна профільний закон називався «Про захист інформації в інформаційно-телекомунікаційних системах». Звідси й досі живий пошуковий запит КСЗІ в телекомунікаційних системах. Після реформи електронних комунікацій (зміни за Законом № 1089-IX від 16.12.2020) термінологію оновили: тепер ідеться про інформаційно-комунікаційні системи.

Визначення просте: ІКС — сукупність інформаційних та електронних комунікаційних складників, які під час обробки відомостей діють як єдине ціле.

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

КСЗІ, ІКС і природа складності

Чому розподілене середовище важче за локальне? Ось причини, і кожна з них додає роботи.

  • Розподіленість. Вузли стоять у різних приміщеннях, будівлях, містах, а часом і у чужих дата-центрах.
  • Канали зв'язку. Відомості виходять за межі контрольованої зони, отже, їх теоретично можна перехопити.
  • Зовнішні підключення. Вихід у мережі загального користування різко розширює поверхню атаки.
  • Багато користувачів і ролей. Розмежувати права серед п'ятьох легко, серед п'ятисот — уже проєкт.
  • Взаємодія із суміжниками. Обмін даними з іншими середовищами створює додаткові точки ризику.
  • Підрядники. Адміністратор на аутсорсі має доступ, але вашому наказу не підпорядковується.

Зв'язка КСЗІ — ІКС саме тому й потребує окремого підходу: тут оберігають не приміщення, а маршрут відомостей від вузла до вузла.

Класифікація: від структури залежить обсяг вимог

Перше, що роблять на старті, — визначають, з чим узагалі мають справу. Обсяг обов'язкових заходів залежить від кількох ознак.

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

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

Що складніша структура, то ширший обов'язковий набір заходів. Тому перша битва проєкту зазвичай точиться навколо межі: чи справді ця ділянка мережі частина контуру, чи її можна відрізати. Іноді правильна архітектура економить більше, ніж будь-яка знижка на обладнання.

Що це змінює технічно

1. Канали зв'язку. Якщо відомості виходять за контрольовану зону, потрібне шифрування. У регульованій галузі це вже криптографія — з власними правилами й власними засобами, що мають позитивний експертний висновок. Побутовий VPN тут не зарахують.

2. Розмежування доступу. Потрібен набір механізмів, що працює у багатокористувацькому середовищі: ідентифікація, автентифікація, розмежування прав, реєстрація подій. Ключове слово — ролі. Коли кожному адміністратору видали «повний доступ, бо так зручніше», проєкт уже провалено.

3. Периметр і сегментація. Міжмережеві екрани, поділ на сегменти, контроль підключень назовні. Плаский контур, де все бачить усе, оцінювач не пропустить.

4. Антивірусний контроль і перевірка цілісності програмного середовища на всіх вузлах, а не тільки на серверах. Забутий термінал у філії — типова знахідка перевірки.

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

6. Резервування й відновлення. Розподілений контур падає частинами, і питання «скільки ми відновлюємося» має мати відповідь на папері, а не у голові адміністратора.

7. Робочі місця й віддалений доступ. Найслабша ланка розподіленого контуру — не сервер, а ноутбук, який їздить додому. Шифрування диска, контроль знімних носіїв, заборона локального збереження, правила віддаленого підключення — усе це має бути описане, а не мовчазно припущене.

Модель порушника: кого треба вписати

У локальному контурі коло підозрюваних вузьке. Щойно середовище розповзається — воно розширюється, і половину дійових осіб забувають.

  • Зовнішній нападник. Класика, про яку пам'ятають завжди.
  • Внутрішній користувач. Має легальний доступ і зловживає ним — навмисне або через недбалість.
  • Адміністратор. Найнебезпечніша роль: він може і діяти, і замести сліди. Саме тому журнали мають лежати там, куди він не дотягнеться.
  • Підрядник. Формально сторонній, фактично всередині. Вписувати його треба з тими правами, які він реально має.
  • Постачальник послуги. Не зловмисник, але точка ризику: його збій або компрометація стає вашою.

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

Хмара: окрема історія

Найчастіше проєкт спотикається саме тут, бо хмара створює ілюзію, що відповідальність теж орендована. Вона не орендована.

Провайдер відповідає за свою інфраструктуру. Ви — за налаштування, доступи, ключі, журнали й за те, що саме туди поклали. Межу треба знати напам'ять і мати її письмово.

Зона Провайдер Ви
Обладнання, живлення, фізична охорона
Гіпервізор, базова мережа
ОС віртуальної машини й застосунки
Налаштування доступів і ролей
Ключі шифрування
Журнали й реагування на інциденти частково
Класифікація того, що ви туди поклали

Останній рядок найважливіший, і саме його ігнорують: провайдер ніколи не знатиме, що ваш «архів звітів» містить відомості з обмеженим доступом.

Три питання, які варто поставити провайдерові до підписання:

  1. Де фізично лежать дані й де їхні копії? Відповідь «десь у Європі» — не відповідь. Потрібен перелік майданчиків.
  2. Хто має адміністративний доступ з боку провайдера і як це журналюється?
  3. Що станеться з даними при розірванні договору? Терміни видалення, підтвердження, доля резервних копій.

Усні запевнення тут нічого не варті. Усе перелічене має бути пунктами договору.

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

Три сценарії, які ламають розподілений контур

Це не гіпотези, а типові знахідки.

Філія без зв'язку. Канал упав, філія перейшла на мобільний інтернет «тимчасово». Тимчасове живе роками, шифрування там ніхто не налаштував, а у документації цього маршруту взагалі немає.

Підрядник із ключами. Компанія, яка колись налаштовувала обладнання, досі має службовий обліковий запис. Договір скінчився, доступ лишився. Оцінювач знаходить його за п'ять хвилин.

Тіньовий сервіс. Хтось підняв файлообмінник або чат, «щоб було зручніше». Він поза схемою, поза журналами й поза моделлю загроз. Зате всередині контуру.

Спільна риса всіх трьох — розрив між тим, що написано, і тим, що працює.

Як це виявляти. Раз на квартал звіряйте три речі: список активних облікових записів із фактичним переліком співробітників і підрядників; схему мережі з тим, що реально відповідає на запити; журнали з тим, що мало б до них потрапити. Три звірки, півдня роботи. Знахідки бувають неприємні, але вони дешевші за зауваження оцінювача.

Географія вузлів: обмеження, про яке забувають

Окреме правило, що стосується саме розподілених контурів і хмари. Жоден елемент не може бути розташований:

  • на тимчасово окупованих територіях України;
  • у державах, визнаних Верховною Радою державами-агресорами;
  • у державах, щодо яких застосовано санкції;
  • у державах, які входять до митних союзів із переліченими вище.

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

Дослідна експлуатація КСЗІ: етап, який недооцінюють

Дослідна експлуатація КСЗІ — період, коли рішення вже працюють із реальними процесами, але середовище ще не введено у постійну роботу.

Навіщо вона потрібна:

  • перевірити поведінку рішень у реальних умовах, а не на стенді;
  • виявити конфлікти між засобами й робочими застосунками;
  • відпрацювати дії персоналу та адміністраторів;
  • зібрати зауваження й доопрацювати конфігурацію.

Що варто зафіксувати саме на цьому етапі:

  1. Скільки хибних спрацювань дає кожен засіб і скільки часу забирає їх розбір.
  2. Чи витримує шифрований канал пікове навантаження.
  3. Що відбувається під час збою: контур закривається чи відкривається.
  4. Чи справді журнали пишуться на всіх вузлах і чи збігається час.
  5. Чи знає черговий персонал, що робити, коли спрацювала сигналізація.

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

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

Завершується етап актом, після якого середовище готують до оцінювання. Пропустити або «прискорити» його — типова помилка, що згодом обертається зауваженнями.

Атестат відповідності комплексної системи захисту інформації: що він давав

Класична схема виглядала так: державна експертиза перевіряла, чи відповідає результат технічному завданню й нормативним документам, видавала експертний висновок, а на його підставі — Атестат відповідності.

Практично документ означав три речі:

  • середовище дозволено вводити у постійну роботу;
  • у ньому можна законно обробляти відомості, які закон вимагає оберігати;
  • установа виконала нормативний обов'язок.

Без нього обробка таких відомостей була порушенням.

Що змінилося: два маршрути для ІКС сьогодні

Головне, чого немає у більшості матеріалів мережі. Класичний ланцюг більше не є єдиним фінішем для нових середовищ.

Маршрут перший — авторизація з безпеки. Запроваджена постановою Кабінету Міністрів № 712 від 18.06.2025: базовий профіль → галузевий → цільовий → оцінювання реалізації → авторизаційний лист → включення до переліку авторизованих. Перехідний період від старої моделі завершився 18 червня 2026 року.

Маршрут другий — сертифікат відповідності стандарту інформаційної безпеки, виданий органом з оцінки. Він доступний за одночасного дотримання кількох умов, серед яких:

  • підтверджена відповідність СУІБ національним стандартам;
  • застосування засобів криптографічного захисту з позитивним експертним висновком;
  • дотримання географічних обмежень, описаних вище;
  • виконання особливих вимог Уряду залежно від категорії відомостей.

Раніше видані документи діють до кінця свого строку. Але якщо підрядник обіцяє «атестат» як мету нового проєкту — він продає вчорашній результат.

Що спитати у підрядника про розподілене середовище

  • Де ви проводите межу контуру і чим це обґрунтовано?
  • Як ви захищаєте канали між майданчиками і які засоби застосуєте?
  • Як буде влаштоване журналювання й синхронізація часу?
  • Скільки триватиме дослідна експлуатація і хто у ній бере участь?
  • Ви ведете нас до авторизаційного листа чи до сертифіката за стандартом? Чому саме туди?

П'ять помилок у розподілених середовищах

  • Оберігати центр і забувати про філії. Найслабший вузол визначає рівень усього контуру.
  • Довіряти каналу, бо «він внутрішній». Орендований канал між містами проходить чужим обладнанням.
  • Не документувати зміни. Схема застаріває за місяць, а оцінювач звіряє папір із реальністю.
  • Пропускати дослідну експлуатацію. Стенд бреше: у житті засоби конфліктують із застосунками.
  • Ігнорувати підрядників. Адміністратор на аутсорсі має бути у моделі порушника, а не поза нею.
  • Купувати обладнання до карти контуру. Поки межа не намальована, будь-яка закупівля — ставка навмання.

Коротко про головне

Розподілене середовище відрізняється від локального не кількістю обладнання, а кількістю меж. Кожна межа — канал, підключення, підрядник, майданчик — потребує окремого рішення й окремого доказу. Тому головна робота тут не монтажна, а картографічна: спершу чесно намалювати, що куди йде, і аж потім купувати.

Потрібна консультація з кібербезпекою?

Discovery-дзвінок — 30 хвилин, безкоштовно. Обговоримо вашу задачу і запропонуємо рішення.

Консультація