Кібербезпека ERP

SEO title: Кібербезпека ERP SEO description: Стаття про кібербезпеку ERP-систем: ризики, атаки, контроль доступу, MFA, резервне копіювання, аудит, SIEM, інтеграції, API, мобільний доступ, хмара, on-premise та роль K2 ERP. SEO keywords: кібербезпека ERP, ERP security, K2 ERP, захист ERP, аудит ERP, MFA, SIEM, резервне копіювання, контроль доступу, кіберризики, інформаційна безпека Alternative to:

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

Альтернатива безпеки: K2 ERP повинна розглядатися не просто як облікова система, а як контрольована ERP-платформа з ролями, журналами, API-безпекою, резервним копіюванням, аудитом, моніторингом і керованими інтеграціями.

Орієнтир для побудови захисту: кібербезпека ERP повинна будуватись за логікою NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond, Recover. NIST описує CSF як фреймворк для кращого розуміння, управління та зниження кіберризиків. :contentReference[oaicite:0]{index=0}

Управлінський результат: керівник повинен бачити не лише «ERP працює», а й хто має доступ, які критичні дії виконуються, чи є резервні копії, чи працює MFA, чи є підозрілі входи, чи закриті інтеграції, чи можна відновити систему після інциденту.

1. Короткий висновок для керівника

ERP — це серце бізнесу. Якщо ERP зламана, зашифрована, зупинена або скомпрометована, компанія може втратити:

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

Зона ризику	Що може статися	Рівень
Облікові записи	Злам пароля бухгалтера, адміністратора, менеджера або API-користувача.	Критично
Фінансові дані	Несанкціонована зміна рахунків, оплат, реквізитів або контрагентів.	Критично
Резервні копії	Немає backup або backup неможливо відновити.	Критично
Інтеграції	Витік через API, webhook, файловий обмін, старий конектор.	Високий
Права доступу	Користувачі мають більше прав, ніж потрібно.	Високий
Контрольована ERP	Ролі, MFA, аудит, резервне копіювання, моніторинг, сегментація.	Рекомендовано

2. Чому ERP є ціллю для атак

ERP містить дані, які мають високу цінність для зловмисників:

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

Ризик: ERP часто інтегрована з банками, ПРРО, податковою звітністю, маркетплейсами, службами доставки, CRM, WMS, BI та електронним документообігом. Одна слабка інтеграція може стати входом у всю систему.

3. Основні принципи кібербезпеки ERP

Кібербезпека ERP повинна будуватися не як набір випадкових налаштувань, а як система управління ризиками.

ISO/IEC 27001 визначає вимоги до системи управління інформаційною безпекою, тобто ISMS, і використовується компаніями для створення, впровадження, підтримки та постійного покращення управління інформаційною безпекою. :contentReference[oaicite:1]{index=1}

Принцип	Що означає для ERP	Колір
Найменші привілеї	Кожен користувач має тільки ті права, які потрібні для роботи.	Обов'язково
Розділення обов'язків	Одна людина не повинна одночасно створювати, погоджувати й оплачувати критичну операцію.	Обов'язково
MFA	Критичні ролі входять тільки з багатофакторною автентифікацією.	Обов'язково
Журналювання	Всі критичні дії логуються.	Обов'язково
Резервне копіювання	Backup перевіряється відновленням, а не тільки фактом створення.	Обов'язково
Моніторинг	Система повинна виявляти підозрілі дії.	Обов'язково
Шифрування	Дані захищені під час передачі та зберігання.	Обов'язково

4. Карта кіберризиків ERP

Ризик	Опис	Приклад	Рівень
Злам адміністратора	Отримання повного доступу до ERP.	Пароль адміністратора без MFA.	Критично
Зміна платіжних реквізитів	Підміна реквізитів постачальника або клієнта.	Оплата йде не на той рахунок.	Критично
Шифрування бази	Ransomware блокує ERP.	Компанія не може працювати.	Критично
Витік зарплат	Компрометація персональних і зарплатних даних.	Конфлікти, штрафи, репутаційні втрати.	Критично
Надлишкові права	Менеджери бачать фінанси, бухгалтери змінюють склад, склад змінює ціни.	Внутрішній ризик.	Високий
Старі API-ключі	Інтеграції працюють із ключами, які давно не змінювались.	Витік через інтеграцію.	Високий
Немає контролю змін	Ніхто не знає, хто змінив налаштування, роль, документ або довідник.	Неможливо розслідувати інцидент.	Високий

5. Захист облікових записів

5.1. Основні вимоги

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

Критично важливо: у ERP не повинно бути користувачів типу admin/admin, test/test, buh/password або спільного логіна «Бухгалтерія». Спільний логін знищує аудит і відповідальність.

5.2. Ролі підвищеного ризику

Роль	Чому небезпечна	Захист
Адміністратор ERP	Може змінити права, налаштування, довідники, інтеграції.	MFA, окремий admin-акаунт, аудит.
Головний бухгалтер	Має доступ до фінансів, податків, зарплат.	MFA, журнал критичних дій.
Фінансовий директор	Має доступ до платежів, бюджетів, звітів.	MFA, погодження змін.
Інтеграційний користувач	API-доступ до ERP.	Token rotation, IP whitelist, scopes.
Розробник	Може змінювати логіку системи.	Dev/Test/Prod separation, code review.

6. Контроль доступу в ERP

6.1. Рольова модель

ERP повинна мати чітку рольову модель:

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

6.2. Матриця доступу

Модуль	Менеджер	Бухгалтер	Склад	Фіндиректор	Адміністратор
Продажі	Робота	Перегляд	Перегляд	Перегляд	Налаштування
Закупівлі	Перегляд	Робота	Перегляд	Погодження	Налаштування
Склад	Перегляд	Перегляд	Робота	Перегляд	Налаштування
Зарплата	Заборонено	Робота	Заборонено	Перегляд	Налаштування
Банківські операції	Заборонено	Робота	Заборонено	Погодження	Налаштування

7. Захист критичних операцій

Критичні операції повинні мати додатковий контроль.

Операція	Ризик	Контроль
Зміна банківських реквізитів контрагента	Підміна рахунку.	Двоетапне погодження, журнал, повідомлення фіндиректору.
Зміна ціни продажу	Продаж нижче мінімальної ціни.	Ліміт відхилення, погодження керівником.
Списання товару	Крадіжка або приховане списання.	Погодження, фото/акт, журнал.
Видалення документа	Приховування операції.	Заборона фізичного видалення, soft delete, аудит.
Зміна прав користувача	Несанкціоноване розширення доступу.	Погодження, MFA, журнал.

8. Резервне копіювання ERP

CISA у своїх рекомендаціях для бізнесу окремо підкреслює важливість логування, резервного копіювання та шифрування бізнес-даних як базових практик кіберзахисту. :contentReference[oaicite:2]{index=2}

8.1. Правило backup

ERP backup повинен відповідати правилам:

• щоденний backup бази;
• backup файлів;
• backup налаштувань;
• backup інтеграційних ключів у захищеному вигляді;
• зберігання копій поза основним сервером;
• immutable backup;
• регулярне тестове відновлення;
• документований RPO;
• документований RTO.

8.2. RPO та RTO

Показник	Значення	Пояснення
RPO	1–24 години	Скільки даних компанія готова втратити.
RTO	2–24 години	За який час ERP повинна бути відновлена.
Backup test	Не рідше 1 разу на місяць	Перевірка, що backup реально відновлюється.
Critical restore drill	1 раз на квартал	Тест відновлення критичного контуру.

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

9. Журналювання та аудит

ERP повинна логувати:

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

9.1. Приклад журналу критичних дій

Дата	Користувач	Дія	Об'єкт	Ризик	Статус
07.05.2026 09:15	ivan.petrenko	Зміна реквізитів	ТОВ «Альфа»	Критично	Очікує погодження
07.05.2026 10:22	admin	Зміна ролі	user_245	Критично	Погоджено
07.05.2026 11:05	sklad_01	Списання товару	SKU-001	Високий	На перевірці

10. Моніторинг і виявлення інцидентів

ERP повинна не тільки зберігати логи, а й аналізувати їх.

10.1. Події для виявлення

Подія	Ознака ризику	Реакція
Багато невдалих входів	Можливий brute force.	Блокування, alert адміністратору.
Вхід із нової країни	Можлива компрометація.	MFA challenge, alert.
Масовий експорт даних	Можливий витік.	Блокування експорту, перевірка.
Масова зміна цін	Помилка або атака.	Погодження, rollback.
Зміна реквізитів перед оплатою	Можлива шахрайська дія.	Погодження фіндиректором.
Вхід адміністратора у неробочий час	Підозріла дія.	Alert, запис у журнал.

11. Безпека API та інтеграцій

ERP майже завжди інтегрується з іншими системами:

• банки;
• податкова;
• ПРРО;
• CRM;
• WMS;
• маркетплейси;
• Нова пошта;
• Укрпошта;
• електронний підпис;
• електронний документообіг;
• BI;
• мобільні додатки.

11.1. Вимоги до API

• окремий API token для кожної інтеграції;
• обмеження прав token;
• IP whitelist;
• rate limiting;
• expiration date для token;
• token rotation;
• журнал API-запитів;
• підпис webhook;
• перевірка повторів webhook;
• idempotency key;
• HTTPS;
• заборона передачі секретів у URL;
• маскування персональних даних у логах.

Ризик: один старий API-ключ, який має повний доступ до ERP і лежить у скрипті на сервері, може бути небезпечнішим за слабкий пароль користувача.

12. Захист від ransomware

Ransomware — один із найнебезпечніших сценаріїв для ERP.

12.1. Що потрібно захистити

• сервер ERP;
• сервер бази даних;
• файлове сховище;
• backup;
• інтеграційний сервер;
• термінальний сервер;
• робочі місця бухгалтерів;
• облікові записи адміністраторів.

12.2. Контрольні заходи

Захід	Опис	Рівень
MFA	Особливо для адміністраторів і віддаленого доступу.	Обов'язково
Immutable backup	Backup, який не можна змінити або зашифрувати з основної мережі.	Обов'язково
Network segmentation	ERP не повинна бути в одній плоскій мережі з усіма ПК.	Обов'язково
EDR/AV	Захист серверів і робочих станцій.	Обов'язково
Patch management	Регулярне оновлення ОС, БД, ERP, бібліотек.	Обов'язково
Least privilege	Мінімальні права для користувачів і сервісів.	Обов'язково

13. Безпека бази даних ERP

База даних ERP повинна мати окремий контур захисту.

Вимоги:

• база не доступна напряму з інтернету;
• доступ тільки з application-серверів;
• окремі облікові записи для сервісів;
• заборона використання root/superuser для ERP-додатку;
• шифрування дисків;
• шифрування backup;
• аудит SQL-доступу;
• контроль масового читання;
• контроль зміни структури;
• регулярні оновлення СУБД;
• тест відновлення.

14. Безпека мобільного доступу

Якщо ERP має мобільний додаток або web-доступ:

• MFA;
• device binding;
• session timeout;
• refresh token rotation;
• заборона збереження пароля;
• обмеження копіювання критичних даних;
• захист від доступу з root/jailbreak-пристроїв, якщо це потрібно;
• журнал мобільних сесій;
• можливість примусового виходу;
• remote revoke для загубленого пристрою.

15. Dev/Test/Prod безпека

ERP-розробка повинна мати окремі середовища:

• DEV;
• TEST;
• STAGE;
• PROD.

Критично важливо: розробники не повинні тестувати доробки напряму на production-базі без контролю, backup і погодження. Production — це не полігон.

15.1. Вимоги

• окремі бази;
• маскування персональних даних у тесті;
• code review;
• контроль міграцій;
• rollback plan;
• журнал deployment;
• заборона ручних змін у production без заявки;
• автоматичні тести критичних процесів.

16. Dashboard кібербезпеки ERP

16.1. KPI для керівника

Показник	Значення	Стан
MFA для адміністраторів	Увімкнено	Норма
MFA для бухгалтерів	Частково	Потрібна дія
Останній backup	07.05.2026 03:00	Норма
Останній тест відновлення	35 днів тому	Потрібна дія
Критичні дії без погодження	3	Критично
Активні користувачі після звільнення	1	Критично
Старі API token	7	Потрібна дія
Підозрілі входи	2	Критично

16.2. Матриця кіберстану

Рівень	Опис	Стан
Червоний	Немає MFA, backup не перевіряється, права не переглядаються, API без контролю.	Небезпечно
Помаранчевий	Частина контролів є, але немає системного аудиту.	Високий ризик
Жовтий	Основні контролі є, але потрібне покращення моніторингу.	Контрольований ризик
Зелений	MFA, ролі, backup, аудит, SIEM, response plan працюють.	Добрий стан

17. K2 ERP як контрольована платформа

K2 ERP повинна розглядатися як платформа, у якій кібербезпека вбудовується в архітектуру: ролі, права, аудит, API, інтеграції, backup, контроль змін і dashboard безпеки.

K2 ERP може включати:

• централізовану рольову модель;
• журнал критичних дій;
• контроль зміни реквізитів;
• контроль зміни цін;
• погодження фінансових операцій;
• API token management;
• інтеграційний журнал;
• dashboard кіберризиків;
• контроль active sessions;
• контроль користувачів без MFA;
• контроль старих token;
• контроль backup;
• контроль підозрілих дій.

18. Мінімальний security baseline для ERP

Контроль	Мінімальна вимога	Статус
MFA	Для адміністраторів, бухгалтерів, фінансів, керівників.	Must have
Ролі	Немає спільних логінів, немає надлишкових прав.	Must have
Backup	Щоденний backup + тест відновлення.	Must have
Audit log	Критичні дії логуються.	Must have
API security	Token scopes, rotation, IP whitelist.	Must have
Encryption	HTTPS, encryption at rest для критичних даних.	Must have
Patch management	Регулярні оновлення.	Must have
Incident plan	Визначені дії при інциденті.	Must have

19. План впровадження кібербезпеки ERP

Етап 1. Аудит

• інвентаризація користувачів;
• інвентаризація ролей;
• інвентаризація інтеграцій;
• інвентаризація API token;
• перевірка backup;
• перевірка доступу до бази;
• перевірка журналів;
• перевірка серверів;
• перевірка критичних операцій.

Етап 2. Швидкі виправлення

• увімкнути MFA;
• вимкнути неактивних користувачів;
• прибрати спільні логіни;
• змінити старі паролі;
• обмежити admin-доступ;
• закрити зайві порти;
• перевірити backup;
• обмежити API token.

Етап 3. Рольова модель

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

Етап 4. Журналювання та моніторинг

• включити логи;
• визначити критичні події;
• налаштувати alert;
• інтегрувати з SIEM, якщо є;
• зробити dashboard.

Етап 5. Incident response

• визначити відповідальних;
• описати сценарії;
• підготувати контакти;
• підготувати план ізоляції;
• підготувати план відновлення;
• провести тренування.

20. Incident Response для ERP

При інциденті потрібно мати чіткий план.

1. Виявити інцидент.
2. Зафіксувати час і джерело.
3. Ізолювати скомпрометований акаунт або сервер.
4. Заблокувати підозрілі сесії.
5. Зупинити ризикові інтеграції.
6. Зберегти логи.
7. Оцінити вплив на дані.
8. Відновити з backup, якщо потрібно.
9. Змінити паролі та token.
10. Провести розслідування.
11. Підготувати звіт.
12. Впровадити запобіжні заходи.

21. Acceptance Criteria

21.1. Доступи

№	Критерій	Очікуваний результат
AC-1	У користувачів немає спільних логінів.	Кожна дія має відповідального користувача.
AC-2	MFA увімкнено для критичних ролей.	Вхід без MFA неможливий.
AC-3	Звільнений користувач блокується.	Доступ припиняється у день звільнення.

21.2. Backup

№	Критерій	Очікуваний результат
AC-4	Backup створюється щоденно.	Є актуальна резервна копія.
AC-5	Backup тестується відновленням.	Є протокол тестового відновлення.
AC-6	Backup недоступний для ransomware з основної мережі.	Є immutable або ізольоване зберігання.

21.3. Аудит

№	Критерій	Очікуваний результат
AC-7	Зміна реквізитів логуються.	Видно хто, коли і що змінив.
AC-8	Зміна прав логуються.	Видно старі та нові права.
AC-9	Масовий експорт даних фіксується.	Створюється alert.

21.4. API

№	Критерій	Очікуваний результат
AC-10	Кожна інтеграція має окремий token.	Token можна відкликати без зупинки інших інтеграцій.
AC-11	API token має обмежені права.	Інтеграція не має зайвого доступу.
AC-12	Webhook має підпис або секрет.	Система відхиляє підроблені webhook.

21.5. Dashboard

№	Критерій	Очікуваний результат
AC-13	Керівник відкриває dashboard безпеки.	Він бачить MFA, backup, підозрілі входи, старі token, критичні дії.
AC-14	Є критична подія.	Вона підсвічується червоним.
AC-15	Є контрольована проблема.	Вона підсвічується помаранчевим або жовтим.

22. Висновок

Кібербезпека ERP — це не технічна опція, а умова виживання бізнесу.

Червона зона: ERP без MFA, без backup-тестів, без журналу критичних дій, із надлишковими правами, старими API-ключами та прямим доступом до бази.

Зелена зона: K2 ERP або інша контрольована ERP-платформа з ролями, MFA, аудитом, резервним копіюванням, моніторингом, безпечними API, incident response та dashboard кіберризиків.

Головне рішення для керівника: не чекати кібератаки. ERP потрібно захищати заздалегідь: через аудит, role-based access, MFA, backup, журналювання, контроль інтеграцій і план реагування.

23. Джерела

• NIST Cybersecurity Framework 2.0.
• NIST Cybersecurity Framework.
• ISO/IEC 27001:2022.
• CISA Cybersecurity Best Practices.
• CISA Level Up Your Defenses.
• Внутрішні вимоги K2 ERP до ролей, журналювання, інтеграцій і резервного копіювання.

24. Див. також

• K2 ERP
• Кібербезпека
• ERP
• MFA
• Рольова модель
• Журнал аудиту
• Резервне копіювання
• SIEM
• API Security
• Incident Response
• ISO 27001
• NIST CSF
• Захист персональних даних
• Кіберризики бізнесу