Безпечна інтеграція в майбутнє


Безпечна інтеграція в майбутнє

Від вимоги до доказу: як перевірити готовність ERP до запуску

Майстер-клас: секрети випікання найсмачніших млинців!

07.10.2026

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

Відповідність, кіберзахищеність і коректність даних — не тотожні поняття

Вони пов’язані, але їх не варто змішувати.
Відповідність показує, наскільки виконані визначені вимоги в обраному периметрі. Кіберзахищеність залежить також від того, наскільки ці вимоги відповідають актуальним загрозам і як захисні механізми працюють на практиці. Коректність бізнес-даних в ERP потребує ще й правильних первинних даних, довідників, алгоритмів розрахунку та перевірених інтеграцій.
Наприклад, компанія може мати затверджену політику доступу, але фактичні права користувачів їй не відповідатимуть. Або система може бути добре захищеною, але розраховувати показник за неправильно налаштованою методикою.
Отже, відсоток відповідності не є підтвердженням правильності всіх даних у системі. Він лише демонструє, наскільки виконано конкретні вимоги та контролі, які організація включила до оцінки.

Контроль є. Але що саме він перевіряє?

Розглянемо типову ситуацію. Одна з вимог передбачає журналювання доступу до всіх критичних систем у визначеному периметрі. Інженер підтверджує: логи збираються, механізм працює. Далі постає питання: скільки систем він охоплює?
Припустімо, логи надходять із приблизно 200 Windows-систем. Після звірки з іншими джерелами з’ясовується, що критичних систем у периметрі 320. Отже, контроль охоплює 200 із 320 систем, тобто 62,5%.
Це не свідчить про компрометацію решти 120 систем. Це означає інше: виконання визначеної вимоги для них не підтверджене.
Причини можуть бути різними:● джерело не підключили;● актив не внесли до периметра;● відсутнє потрібне налаштування;● для системи діє погоджений виняток.
Сам механізм збору логів при цьому може працювати без помилок. Проблема виникає тоді, коли справність механізму помилково сприймають як повне покриття.
Тому під час перевірки важливо знати не лише, скільки активів пройшли контроль, а й скільки мали його пройти.

Починати потрібно з вимоги, а не з наявного інструмента

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

Чому без інвентаризації складно підтвердити повноту перевірки?

Щоб перевірити вимогу, потрібно чітко розуміти, які активи входять до її периметра.
Саме тут виникає одна з типових проблем. Адміністратори, служба інформаційної безпеки та інфраструктурна команда можуть використовувати різні джерела обліку.
В одній системі сервер є, в іншій його немає. Для активу може бути не визначений власник. Дані про операційну систему, антивірус або оновлення можуть надходити з різних консолей.
ITS Inventory збирає та зіставляє інформацію про активи з підключених джерел. Один ноутбук, наприклад, можна одночасно побачити через дані антивірусної системи, каталогу користувачів і засобів оновлення ОС.
CMDB, консолі антивірусів, системи патч-менеджменту та інші наявні джерела при цьому не замінюються. Їхні дані використовуються для формування спільної картини.
Зіставлення дає змогу виявляти розбіжності в обліку, активи без визначеного власника або системи, які присутні в одному джерелі й відсутні в іншому. Саме тому в прикладі з 200 із 320 систем спочатку необхідно визначити повний перелік активів, а вже потім оцінювати результат контролю.

Як ITS Compliance працює з вимогами та доказами

В ITS Compliance відправною точкою є вимога та визначений для неї периметр.
Далі налаштовуються спосіб перевірки, джерело інформації та критерій виконання. Показник відповідності обчислюється на основі доступних даних про технічні налаштування активів, документи, виконані задачі та затвердження відповідальних.
Такий підхід зменшує обсяг ручного зведення інформації. Оцінка оновлюється разом із новими даними.
Водночас автоматичний розрахунок не гарантує абсолютної правильності результату. Він залежить від якості вхідних даних, актуальності джерел, повноти периметра та коректності налаштованих правил.
Якщо джерело давно не оновлювалося, його останній результат не можна вважати поточним станом системи. Якщо актив не потрапив до периметра, контроль може його взагалі не перевірити.
Отже, автоматизація не усуває потреби контролювати якість самих даних.

4 типи контролів

Технічні контролі зіставляють фактичні дані про активи з налаштованими правилами. Наприклад, перевіряють, чи активний антивірус на робочих станціях, для яких він є обов’язковим. Межі такої перевірки залежать від доступних даних та інтеграцій.
Документальні контролі пов’язують вимогу з артефактом: файлом, скриншотом або посиланням. Система може контролювати строки чинності, оновлення та погодження. Водночас наявність чинного документа сама по собі не підтверджує виконання описаної процедури.
Ручні контролі застосовуються там, де потрібне рішення або підтвердження людини. Наприклад, коли результат потребує експертної оцінки або особистого підтвердження виконання певної дії. Не всі подібні перевірки доцільно автоматизувати.
Структурні контролі пов’язують загальну вимогу з виконанням вкладеного набору вимог. Наприклад, політику інформаційної безпеки можна деталізувати до процедур, регламентів і конкретних перевірок. Це дає змогу простежити шлях від загального правила до доказів його виконання.

Що відбувається після виявлення відхилення?

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

Перевірювані умови готовності до запуску ERP

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

Після запуску стан системи продовжує змінюватися

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

Аудит без авралу починається до запиту аудитора

Класична підготовка до аудиту часто починається тоді, коли надходить запит на докази.
Команди збирають інформацію по підрозділах, звіряють таблиці, шукають погоджені політики та з’ясовують, чому дані про кількість активів у різних джерелах не узгоджуються. Кваліфіковані фахівці витрачають час не на перевірку суті контролів, а на відновлення картини станом на потрібну дату.
Якщо вимоги, контролі, докази та задачі пов’язані заздалегідь, підготовка звітності стає простішою. Легше зрозуміти походження даних, побачити зміни та знайти потрібні підтвердження.
Водночас автоматичне формування звіту не завершує підготовку до аудиту. Потрібно перевірити повноту доказів, розглянути винятки, усунути суттєві прогалини та відповісти на питання аудитора. Автоматизація скорочує ручну роботу, але не скасовує професійну оцінку.

Скільки роботи потребує така модель?

Масштаб залежить від кількості вимог, джерел даних, інтеграцій і рівня автоматизації.
Як орієнтир із практики впроваджень можна навести проєкт із 5 стандартами, понад 600 вимогами та понад 2500 контролями. У цьому прикладі близько 80% контролів — документальні, а 20% — технічні.
Налаштування такого обсягу потребує 4–6 місяців. Для одного стандарту обсяг робіт може становити близько 1000 людино-годин. Ці цифри не варто переносити на будь-який проєкт без урахування його периметра.
Перед оцінкою строків потрібно визначити:● які вимоги опрацьовуються першочергово;● які системи входять до перевірки;● які джерела вже доступні;● що доведеться перевіряти вручну.
Також необхідно врахувати участь бізнес-власників, ERP-команди, підрозділів ІТ та інформаційної безпеки, внутрішнього аудиту. Значна частина роботи — це погодження правил, винятків і результатів.

Про що потрібно знати керівнику для ухвалення обгрунтованого рішення?

Керівнику не треба самостійно перевіряти кожне технічне налаштування. Але він має бачити цілісну картину.
Що саме перевірили? Який периметр охопили? Наскільки актуальні дані? Де залишилися прогалини? Хто за них відповідає? Які ризики прийняті, а які ще потрібно усунути?
Для ERP це переводить розмову про готовність із загальних тверджень у перевірювані факти:● Резервні копії створюються — але чи перевірено відновлення й зафіксовано результат? ● Доступи налаштовані — але чи зіставлено фактичні права з ролями, чи розглянуто конфлікти та визначено відповідальних за винятки?● Контроль працює — але чи відомо, які активи він перевіряє, а які поки що залишаються поза його межами?
Так комплаєнс стає частиною управління ERP — до запуску та під час подальшої експлуатації. Він не гарантує абсолютної безпеки чи правильності усіх бізнес-даних. Але дає перевірювані підстави для рішення про наступний крок.
Саме для цього ми створили ITS Compliance — програмний продукт IT Specialist для автоматизованої оцінки відповідності вимогам стандартів кібербезпеки та внутрішніх політик. Система розгортається on-premise, у периметрі замовника. У тандемі з ITS Inventory вона використовує інвентаризаційні дані як основу для технічних перевірок. Конкретний периметр, джерела даних і правила контролю визначаються під час впровадження — із урахуванням потреб і пріоритетів бізнесу.

Illustration


Зателефонувати

Офіс+38 (044) 390 81 90

Департамент продажів+38 (096) 390 81 90

Написати

moc.tsilaicepsti-ym%40olleh

Приїхати на каву

Бізнес-центр Sigma,бульвар Вацлава Гавела, 6, корпус 3, Україна, Київ, 03124

Illustration


Зателефонувати

Офіс+38 (044) 390 81 90

Департамент продажів+38 (096) 390 81 90

Написати

moc.tsilaicepsti-ym%40olleh

Приїхати на каву

Бізнес-центр Sigma,бульвар Вацлава Гавела, 6, корпус 3, Україна, Київ, 03124