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

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

4. | style="background:#c8e6c9;" | Must have |- | Patch management | Регулярні оновлення версій. Об'єкт ! Дія

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

! |- | Зміна прав користувача | style="background:#ef9a9a;" | Несанкціоноване розширення доступу. | Погодження фіндиректором. | компанія-користувач не здатна працювати. | style="background:#c8e6c9;" | Обов'язково |- | Шифрування | інформаційні дані захищені під час передачі та зберігання. Спільний логін знищує аудит і відповідальність. | style="background:#ffcc80;" | Високий |- | style="background:#ffcc80;" | Права доступу | Користувачі мають більше прав, ніж потрібно. ! Значення ! |}

! |}

! Зберегти логи. |- | RTO | 2–24 години | За який час ERP повинна бути відновлена. | Вхід без MFA неможливий. Контроль

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

|- | Адміністратор ERP | здатна змінити права, конфігурація, довідники, інтеграції. Колір ! №

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

:contentReference [oaicite:2]{index=2}	style="background:#c8e6c9;" | Двоетапне погодження, журнал, повідомлення фіндиректору. | style="background:#ffcc80;" | Високий
Контрольована ERP	-	AC-15	style="background:#ef9a9a;" | Критично
Надлишкові права	-	AC-4	style="background:#c8e6c9;" | Заборона фізичного видалення, soft delete, аудит. Критерій
Облікові записи	-	AC-14	виступає як критична подія. 9. Ризик ERP повинна не тільки зберігати логи, а й аналізувати їх. Зафіксувати час і джерело. Стан 9. Журналювання та аудит	Менеджер 12. Принцип 12.1. Що потрібно захистити 22. Висновок style="background:#c8e6c9;" | Обов'язково Моніторинг style="background:#c8e6c9;" | Погодження, MFA, журнал. | Неможливо розслідувати інцидент. | style="background:#c8e6c9;" | MFA, погодження змін. ! | style="background:#c8e6c9;" | Погодження, фото/акт, журнал.=== 21.1. Доступи === сервер ERP; сервер бази даних; файлове сховище; backup; інтеграційний сервер; термінальний сервер; робочі місця бухгалтерів; облікові записи адміністраторів. | style="background:#c8e6c9;" | Must have Encryption HTTPS, encryption at rest для критичних даних. № == 12. Захист від ransomware == SEO-опис 13. Безпека бази даних ERP NIST Cybersecurity Framework 2.0. | Створюється alert. ! | style="background:#c8e6c9;" | Token rotation, IP whitelist, scopes. | style="background:#ffcc80;" | Високий Мінімальна вимога 15. Dev/Test/Prod безпека Зелена зона: K2 ERP або інша контрольована ERP-платформа з ролями, MFA, аудитом, резервним копіюванням, моніторингом, безпечними API, incident response та dashboard кіберризиків. * описати ролі; описати матрицю доступу; розділити обов'язки; ввести погодження; ввести періодичний перегляд прав. Роль Оплата йде не на той рахунок. |- Масова зміна цін Помилка або атака. Рівень DEV; TEST; STAGE; PROD. | Вона підсвічується помаранчевим або жовтим. Пояснення K2 ERP Кібербезпека ERP MFA Рольова модель Журнал аудиту Резервне копіювання SIEM API Security Incident Response ISO 27001 NIST CSF Захист персональних даних Кіберризики бізнесу Головне рішення для бізнесу для керівника: не чекати кібератаки. Адміністратор Значення платформа відхиляє підроблені webhook.=== 8.1. Правило backup === - Зміна реквізитів перед оплатою Витік через інтеграцію.== Див. 24. так само == Кібербезпека ERP — це не технічна опція, а умова виживання бізнесу. |- AC-12 Webhook має підпис або секрет. Що здатна статися - AC-5 Backup тестується відновленням. * окремі бази; маскування персональних даних у тесті; code review; контроль міграцій; rollback plan; журнал deployment; заборона ручних змін у production без заявки; автоматичні тести критичних процесів. Показник 7. |- провідний бухгалтер Має доступ до фінансів, податків, зарплат. Рівень 11.1. Вимоги до API 4. Карта кіберризиків ERP ! Чому небезпечна Бухгалтер } ERP майже завжди інтегрується з іншими системами: 17. K2 ERP як контрольована платформа бухгалтер; провідний бухгалтер; фінансовий директор; менеджер продажів; керівник продажів; закупівельник; складський облік; керівник складу; виробництво; HR; керівник; адміністратор; інтеграційний користувач системи; аудитор. користувач системи 21.2. Backup 21.3. Аудит AC-7 виступає як актуальна резервна копія. |- Масовий експорт даних - Інтеграційний користувач системи style="background:#c8e6c9;" | Обов'язково Розділення обов'язків style="background:#ef9a9a;" | Критично Зміна платіжних реквізитів Добрий стан 8. ! Альтернатива безпеки: K2 ERP повинна розглядатися не без зусиль як облікова платформа, а як контрольована ERP-платформа з ролями, журналами, API-безпекою, резервним копіюванням, аудитом, моніторингом і керованими інтеграціями. Показник Ransomware — один із найнебезпечніших сценаріїв для ERP. Змінити паролі та token. * CISA Level Up Your Defenses. | style="background:#c8e6c9;" | Обов'язково 10.1. Події для виявлення Критичні операції повинні мати додатковий контроль. ERP потрібно захищати заздалегідь: через аудит, role-based access, MFA, backup, журналювання, контроль інтеграцій і план реагування. ! № 10. Моніторинг і виявлення інцидентів При інциденті потрібно мати чіткий план. ! Для ERP важливий не факт створення копії, а гарантоване відновлення бізнесу. складський облік CISA у своїх рекомендаціях для бізнесу окремо підкреслює важливість логування, резервного копіювання та шифрування бізнес-даних як базових практик кіберзахисту. | Небезпечно
Помаранчевий	Частина контролів виступає як, але немає системного аудиту. Статус	Очікуваний результат ERP повинна логувати: 6. Заблокувати підозрілі сесії. | Кожна дія має відповідального користувача. | style="background:#c8e6c9;" | Must have
Incident plan	Визначені дії при інциденті. :contentReference [oaicite:0]{index=0}
AC-13	-	AC-2	MFA увімкнено для критичних ролей. Критерій 7. Захист критичних операцій	style="background:#c8e6c9;" | Обов'язково
Least privilege	style="background:#c8e6c9;" | Must have
Audit log	style="background:#c8e6c9;" | Must have
Backup	-	MFA	Alert, запис у журнал. |-	Списання товару	Крадіжка або приховане списання. | style="background:#c8e6c9;" | Рекомендовано

21. Acceptance Criteria

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

- AC-3 Звільнений користувач системи блокується. Впровадити запобіжні заходи. Відновити з backup, якщо потрібно.

8.2. RPO та RTO

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

Найменші привілеї } === 5.2. Ролі підвищеного ризику === Фіндиректор

style="background:#c8e6c9;" | Must have

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

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

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

style="background:#c8e6c9;" | Must have
Ролі	Немає спільних логінів, немає надлишкових прав.	-	07.05.2026 09:15	ivan.petrenko	Зміна реквізитів	ТОВ «Альфа»	Критично	Очікує погодження
07.05.2026 10:22	admin	Зміна ролі	user_245	Критично	Погоджено
07.05.2026 11:05	sklad_01	Списання товару	SKU-001	Високий	На перевірці

Етап 1. Аудит

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

23. Джерела

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

15.1. Вимоги

! | style="background:#ef9a9a;" | Критично |- | style="background:#ef9a9a;" | Шифрування бази | Ransomware блокує ERP. | виступає як протокол тестового відновлення. | style="background:#c8e6c9;" | Обов'язково |- | MFA | Критичні ролі входять тільки з багатофакторною автентифікацією. |- | AC-8 | Зміна прав логуються. Статус 11. Захід ! Очікуваний результат

21.4. API

! | інтеграційні функції ERP не має зайвого доступу. ERP backup повинен відповідати правилам:

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

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

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

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

K2 ERP здатна включати: 5. компонент

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

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

продажі та реалізація Робота Перегляд Перегляд Перегляд конфігурація закупівельна діяльність Перегляд Робота Перегляд Погодження конфігурація складський облік Перегляд Перегляд Робота Перегляд конфігурація Зарплата Заборонено Робота Заборонено Перегляд конфігурація Банківські операції Заборонено Робота Заборонено Погодження конфігурація ! | style="background:#c8e6c9;" | Обов'язково |- | Журналювання | Всі критичні дії логуються. Захист Управлінський результат: керівник повинен бачити не лише «ERP функціонує», а й хто має доступ, які критичні дії виконуються, чи виступає як резервні копії, чи функціонує MFA, чи виступає як підозрілі входи, чи закриті інтеграції, чи можна відновити систему після інциденту. | style="background:#c8e6c9;" | Dev/Test/Prod separation, code review. | Погодження, rollback. | style="background:#c8e6c9;" | MFA, журнал критичних дій. |- | Зміна ціни продажу | style="background:#ffcc80;" | Продаж нижче мінімальної ціни. {| class="wikitable" |- | Багато невдалих входів | Можливий brute force. Ізолювати скомпрометований акаунт або сервер. | style="background:#ef9a9a;" | Критично |- | style="background:#ef9a9a;" | Витік зарплат | Компрометація персональних і зарплатних даних.=== Етап 2. Швидкі виправлення === * MFA; * device binding; * session timeout; * refresh token rotation; * заборона збереження пароля; * обмеження копіювання критичних даних; * захист від доступу з root/jailbreak-пристроїв, якщо це потрібно; * журнал мобільних сесій; * можливість примусового виходу; * remote revoke для загубленого пристрою. | Вона підсвічується червоним. | Видно хто, коли і що змінив. | style="background:#c8e6c9;" | Обов'язково |- | EDR/AV | Захист серверів і робочих станцій. Приклад

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

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

Backup test	Не рідше 1 разу на місяць	Перевірка, що backup реально відновлюється.=== 16.1. KPI для керівника === ERP-розробка повинна мати окремі середовища:	Контроль ERP повинна мати чітку рольову модель:
MFA	Для адміністраторів, бухгалтерів, фінансів, керівників. * Внутрішні вимоги K2 ERP до ролей, журналювання, інтеграцій і резервного копіювання. Реакція	} 5.1. Основні вимоги SEO title: Кібербезпека ERP SEO keywords: кібербезпека ERP, ERP security, K2 ERP, захист ERP, аудит ERP, MFA, SIEM, резервне копіювання, контроль доступу, кіберризики, інформаційна безпека </noinclude> {{SEO Шаблон для службового SEO-опису сторінки. }} входи користувачів; невдалі спроби входу; зміну пароля; зміну ролей; створення користувача; блокування користувача; зміну довідників; зміну банківських реквізитів; зміну цін; зміну залишків; проведення документів; скасування документів; видалення документів; запуск інтеграцій; API-запити; експорт даних; масові операції. |- AC-1 У користувачів немає спільних логінів. Якщо ERP зламана, зашифрована, зупинена або скомпрометована, компанія-користувач здатна втратити: Пароль адміністратора без MFA. | MFA challenge, alert. |} 6.2. Матриця доступу Етап 4. Журналювання та моніторинг Орієнтир для побудови захисту: кібербезпека ERP повинна будуватись за логікою NIST CSF 2.0: Govern. ! |- Critical restore drill 1 раз на квартал - Фінансовий директор style="background:#c8e6c9;" | Обов'язково Immutable backup Блокування, alert адміністратору. |- AC-11 style="background:#c8e6c9;" | MFA, окремий admin-акаунт, аудит. Одна слабка інтеграційні функції ERP здатна стати входом у всю систему. | style="background:#ef9a9a;" | Критично Інтеграції Витік через API, webhook, файловий обмін, старий конектор. № Злам адміністратора - Видалення документа Приховування операції. | style="background:#c8e6c9;" | Ліміт відхилення, погодження керівником. Рівень визначити відповідальних; описати сценарії; підготувати контакти; підготувати план ізоляції; підготувати план відновлення; провести тренування. Що означає для ERP Етап 5. Incident response Високий ризик Жовтий - AC-6 Backup недоступний для ransomware з основної мережі. Критерій Зона ризику окремий API token для кожної інтеграції; обмеження прав token; IP whitelist; rate limiting; expiration date для token; token rotation; журнал API-запитів; підпис webhook; перевірка повторів webhook; idempotency key; HTTPS; заборона передачі секретів у URL; маскування персональних даних у логах. У ній зберігаються фінансовий блок, зарплати, податки, договори, ціни, залишки, виробничі інформаційні дані, клієнти, постачальники, управлінська формування звітів і комерційна таємниця. | Внутрішній ризик. |- AC-9 Масовий експорт даних фіксується.=== 6.1. Рольова модель === включити логи; визначити критичні події; налаштувати alert; інтегрувати з SIEM, якщо виступає як; зробити dashboard. Очікуваний результат увімкнути MFA; вимкнути неактивних користувачів; прибрати спільні логіни; змінити старі паролі; обмежити admin-доступ; закрити зайві порти; перевірити backup; обмежити API token. ERP містить інформаційні дані, які мають високу цінність для зловмисників: 16.2. Матриця кіберстану Етап 3. Рольова модель Блокування експорту, перевірка. |- Червоний style="background:#c8e6c9;" | Обов'язково Резервне копіювання Backup перевіряється відновленням, а не тільки фактом створення. Ознака ризику виступає як immutable або ізольоване зберігання. Ризик централізовану рольову модель; журнал критичних дій; контроль зміни реквізитів; контроль зміни цін; погодження фінансових операцій; API token management; інтеграційний журнал; dashboard кіберризиків; контроль active sessions; контроль користувачів без MFA; контроль старих token; контроль backup; контроль підозрілих дій. Ризик доступ до замовлень; доступ до складу; можливість відвантаження; можливість виставлення рахунків; контроль оплат; бухгалтерський обліковий облік; податкову формування звітів; зарплатний бізнес-процес; управлінську аналітику; довіру клієнтів; гроші; репутацію. Очікуваний результат база не доступна напряму з інтернету; доступ тільки з application-серверів; окремі облікові записи для сервісів; заборона використання root/superuser для ERP-додатку; шифрування дисків; шифрування backup; аудит SQL-доступу; контроль масового читання; контроль зміни структури; регулярні оновлення версій СУБД; тест відновлення. Критерій MFA для адміністраторів; MFA для бухгалтерів; MFA для фінансових ролей; MFA для користувачів із доступом до банківських операцій; складна політика паролів; заборона спільних логінів; автоматичне блокування після невдалих спроб; контроль входів із нових пристроїв; контроль входів із незвичних країн або IP; регулярний перегляд активних користувачів; швидке відключення звільнених працівників. |- Зміна банківських реквізитів контрагента Підміна рахунку. {| class="wikitable" SEO-опис - Вхід із нової країни style="background:#c8e6c9;" | Must have API security - Розробник - AC-10 style="background:#c8e6c9;" | Обов'язково 2. Провести розслідування. | style="background:#ef9a9a;" | Критично
Резервні копії	Контрольований ризик
Зелений	MFA, ролі, backup, аудит, SIEM, response plan працюють. ISO/IEC 27001 визначає вимоги до системи керування інформаційною безпекою, тобто ISMS, і застосовують, коли потрібно компаніями для створення, впровадження, підтримки та постійного покращення керування інформаційною безпекою.	style="background:#ef9a9a;" | Критично
Фінансові інформаційні дані	Несанкціонована зміна рахунків, оплат, реквізитів або контрагентів.== 11. Безпека API та інтеграцій == ERP — це серце бізнесу. | style="background:#ffcc80;" | Високий
Немає контролю змін	Ніхто не знає, хто змінив конфігурація, роль, документ або довідник. операційна дія	} 3. ! | Конфлікти, штрафи, репутаційні втрати. | style="background:#c8e6c9;" | Обов'язково Patch management Регулярне оновлення версій ОС, БД, ERP, бібліотек. :contentReference [oaicite:1]{index=1} Видно старі та нові права. |} 19. План впровадження кібербезпеки ERP - Вхід адміністратора у неробочий час style="background:#ffcc80;" | Високий Старі API-ключі } Вимоги: банки; податкова; ПРРО; CRM; WMS; маркетплейси; Нова пошта; Укрпошта; електронний підпис; електронний електронний документообіг; BI; мобільні додатки. Підготувати звіт. Окремо варто відзначити Identify, Protect, Detect, Respond, Recover. Очікуваний результат style="background:#c8e6c9;" | Обов'язково Network segmentation ERP не повинна бути в одній плоскій мережі з усіма ПК. № 20. Incident Response для ERP щоденний backup бази; backup файлів; backup налаштувань; backup інтеграційних ключів у захищеному вигляді; зберігання копій поза основним сервером; immutable backup; регулярне тестове відновлення; документований RPO; документований RTO. | Він бачить MFA, backup, підозрілі входи, старі token, критичні дії. {| class="wikitable" RPO 1–24 години Доступ припиняється у день звільнення. Рівень 21.5. Dashboard