Захист інформації в АС та ІКС: що означають ці вимоги і кого стосуються

АС, ІТС, ІКС, ІзОД, КСЗІ — абревіатури, від яких хочеться закрити вкладку. Розберемо їх людською мовою: що вони означають, які об'єкти охороняють і кого стосуються обов'язкові вимоги. Окремо — про зміни 2025–2026 років: більшість матеріалів у мережі досі переказує модель, яка для нових проєктів уже не працює. Якщо потрібне базове визначення й перелік загроз — почніть звідти.

Захист інформації в АС, ІТС та ІКС: три абревіатури — одна суть

Три скорочення з різних періодів законодавства описують майже те саме.

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

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

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

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

Класи АС: чому у старому технічному завданні пишуть «клас 2»

У документах, написаних за нормативними документами ТЗІ, трапляється поділ на три класи — він і досі допомагає швидко оцінити масштаб:

• клас 1 — одномашинний однокористувацький комплекс: окремий комп'ютер, з яким одночасно працює лише одна людина;
• клас 2 — локалізований багатомашинний багатокористувацький комплекс: локальна мережа, де користувачі мають різні повноваження;
• клас 3 — розподілений комплекс: дані передаються через незахищене середовище. Типовий приклад — мережа з філіями, віддаленим доступом і зовнішніми каналами.

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

Об'єкти захисту в інформаційних системах

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

Інженерний периметр ширший. Аби дістатися до цінного, зловмисникові не обов'язково штурмувати базу — достатньо будь-якої ланки довкола неї:

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

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

Захист інформації в автоматизованих системах: що вимагає закон

Обов'язкові вимоги адресовано не всім. Чотири питання, аби зрозуміти, чи стосуються вони вас:

1. Ваша установа — орган влади, державне підприємство чи орган місцевого самоврядування?
2. Ви обробляєте державні інформаційні ресурси?
3. Ви маєте справу з відомостями з обмеженим доступом, охорону яких вимагає закон?
4. Ваше підприємство віднесено до об'єктів критичної інформаційної інфраструктури?

Хоча б одне «так» — вимоги діють. Жодного «так» — обов'язкової процедури немає (але й тут є нюанси, про них нижче).

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

Ще один обов'язок помічають рідко: про спроби та факти несанкціонованих дій щодо державних ресурсів або відомостей з обмеженим доступом власник повідомляє Держспецзв'язку. Мовчати й «розібратися самотужки» — теж порушення.

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

ІзОД: слово, довкола якого крутяться всі вимоги

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

Чинна модель: авторизація з безпеки замість атестата

Найважливіша частина, через яку більшість матеріалів у мережі застаріла.

Як було. Власник будував КСЗІ, проходив державну експертизу й отримував атестат, пізніше — документ про відповідність. Модель статична: перевірили одного разу — живіть далі.

Як стало. Закон № 4336-IX від 27.03.2025 запровадив ризик-орієнтований підхід, а постанова Кабінету Міністрів № 712 від 18.06.2025 затвердила два порядки — авторизації з безпеки та розроблення профілів безпеки. Ланцюжок тепер такий:

1. Базовий профіль безпеки — мінімальний набір заходів; затверджує Адміністрація Держспецзв'язку.
2. Галузевий профіль — доповнення від галузевого уповноваженого органу, за потреби.
3. Цільовий профіль — розробляє власник, спираючись на аналіз ризиків і призначення свого середовища.
4. Оцінювання реалізації цільового профілю.
5. Авторизаційний лист і включення до переліку авторизованих систем з безпеки.

Хто що робить у новій моделі:

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

Що з цього випливає практично:

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

Що таке КСЗІ й з чого вона складалася — у статті КСЗІ простими словами; послідовність робіт — у матеріалі як створюється КСЗІ.

Чому модель змінили

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

Скільки середовищ у вас насправді

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

Що всередині цільового профілю

Цільовий профіль — це не декларація на дві сторінки, а робочий документ. Зазвичай він містить:

• перелік заходів, узятих із базового (і галузевого) профілю;
• доповнення під власні ризики: те, чого немає в базовому наборі, але вимагає ваша специфіка;
• обґрунтування щодо заходів, які ви не застосовуєте, — з поясненням, чим ризик закрито натомість;
• прив'язку кожного заходу до відповідального й строку впровадження;
• порядок перегляду: за яких подій документ оновлюють.

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

Що робити власнику вже зараз

Мінімальний маршрут, який працює й у державному, і в приватному секторі:

1. Скласти перелік середовищ і визначити, де саме обробляються чутливі дані.
2. Віднести кожне середовище до категорії: є ІзОД чи державні ресурси — чи ні.
3. Провести аналіз ризиків: загрози, ймовірність, наслідки, власник ризику.
4. Розробити цільовий профіль на основі базового.
5. Впровадити заходи й зафіксувати сліди виконання: журнали, накази, звіти.
6. Пройти оцінювання, отримати авторизаційний лист і потрапити до переліку.

Хто такий оцінювач і на що він дивиться

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

Три сигнали, що підрядник відстав від нормативки

• обіцяє атестат відповідності для нового середовища;
• посилається на постанову № 627 про декларування — вона втратила чинність;
• жодного разу не згадує профілів безпеки й аналізу ризиків, зате детально описує перелік «сертифікованих засобів».

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

Захист інформації в інформаційно-телекомунікаційних системах: чому термін ще живий

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

• читайте його як «ІКС» — предмет один;
• перевірте, на яку редакцію нормативних актів посилається замовник: посилання на скасовані пункти трапляються часто;
• уточніть очікуваний результат робіт. Якщо документ обіцяє атестат, а середовище нове, замовник описує вчорашній день — узгодьте це до підписання.

А якщо ми звичайний бізнес

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

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

Логіка при цьому та сама, що й у державному секторі: перелік цінного → аналіз ризиків → заходи → перевірка. Міжнародний варіант цієї логіки — ISO 27001: його визнають партнери й замовники, а ліцензій він не потребує.

Що плутають найчастіше: середовище і приміщення

Реформа торкнулася систем, а не приміщень. Це різні контури:

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

Що реформа не скасувала

• ліцензування послуг ТЗІ — чинне;
• нормативні документи ТЗІ (НД ТЗІ) — чинні, зокрема класифікація й вимоги до комплексів;
• категоріювання приміщень та їхня атестація — окремий контур, його не торкалися;
• криптографія — власні правила та ліцензовані засоби;
• порядок доступу до відомостей з обмеженим доступом — без змін.

Як це виглядає на практиці

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

Типові помилки замовників

• Копіювати чужий комплект документів. Цільовий профіль спирається на ваші ризики й ваш масштаб; чужий шаблон перетворюється на папір, який не витримує оцінювання.
• Починати з купівлі засобів. Спершу перелік цінного й аналіз ризиків, потім рішення — інакше бюджет піде на те, чого ніхто не просив.
• Забути про підрядників. Доступ зовнішнього адміністратора до вашого середовища — така сама поверхня, як і власні працівники.
• Вважати документ вічним. Підхід ризик-орієнтований: змінилося середовище — переглядають профіль.
• Тримати роботи всередині ІТ. Аналіз ризиків без бізнесу перетворюється на технічний опис: хто, крім керівника напряму, скаже, у скільки обійдеться доба простою реєстру?