Legacy ERP часто залишається «серцем» підприємства: через неї проходять фінанси, закупівлі, виробництво, логістика й управлінська звітність. Водночас саме такі системи нерідко не підтримують сучасну багатофакторну автентифікацію, SAML/OIDC, контекстні політики доступу або достатньо гранульований контроль привілеїв. Повне переписування коду чи заміна ERP може бути занадто ризиковою для безперервності бізнесу, тому CISO потрібен проміжний, але керований шлях зниження ризику.
Контекст загроз робить цю задачу практичною, а не теоретичною. ENISA Threat Landscape 2025 визначає фішинг як провідний вектор початкового доступу. У тому ж звітному періоді 53.7% організацій, що зазнали впливу кібератак, належали до essential entities у сфері дії NIS2. Для промисловості, критичної інфраструктури та великих enterprise-організацій це означає: якщо обліковий запис користувача буде скомпрометовано, ERP не має залишатися відкритою ціллю для прямого доступу та lateral movement.
Підхід Zero Trust у такому сценарії не означає, що legacy ERP раптом стає «Zero Trust-системою». Коректніше говорити про захисний контур навколо неї: identity-aware proxy перед веб-доступом, Privileged Access Management для адміністративних і сервісних облікових записів, а також мікросегментацію мережі, яка дозволяє тільки необхідні потоки між ERP, базою даних, інтеграційними шлюзами та адміністративними робочими станціями.
Чому legacy ERP є зручною ціллю для lateral movement
Типова проблема legacy ERP полягає не в одній вразливості, а в комбінації архітектурних обмежень. Система може бути стабільною з погляду бізнес-функцій, але не мати механізмів, які сьогодні вважаються базовими для контролю доступу.
- Застаріла автентифікація. Частина ERP-систем покладається на локальні логіни й паролі та не підтримує сучасні сценарії MFA або федерації ідентичностей без додаткового шару.
- Надлишкові привілеї. Якщо ролі та права формувалися роками без регулярного перегляду, користувачі й технічні акаунти можуть мати ширший доступ, ніж потрібно для їхніх поточних задач.
- Прямий мережевий доступ. У пласких або слабко сегментованих мережах компрометована робоча станція може бачити сервери ERP, бази даних або адміністративні інтерфейси напряму.
- Сервісні облікові записи. Інтеграції між ERP, базою даних і суміжними системами часто працюють через довгоживучі технічні акаунти, які складно швидко змінювати без порушення процесів.
Cisco Cybersecurity Readiness Index 2025, побудований на double-blind survey 8 000 cybersecurity business leaders у 30 markets, оцінює готовність організацій за п’ятьма стовпами: Identity Intelligence, Machine Trustworthiness, Network Resilience, Cloud Reinforcement і AI Fortification. Для legacy ERP особливо практичними є перші три: хто підключається, з якого середовища, яким каналом і з якими привілеями.
Identity-Aware Proxy: MFA перед входом у ERP
Identity-Aware Proxy розміщується перед веб-орієнтованою ERP і приймає запит користувача до того, як той потрапить на сторінку логіну самої системи. У базовому сценарії IAP перенаправляє користувача до корпоративного Identity Provider, де застосовується MFA та політики доступу. Лише після успішної перевірки проксі передає запит до ERP.
Це корисно саме тоді, коли ERP не можна швидко навчити сучасним протоколам автентифікації. Код застосунку не змінюється, але точка входу в нього переноситься під контроль сучасного identity-шару. Для користувачів це може виглядати як додатковий крок входу, а для команди безпеки — як можливість централізовано застосовувати політики MFA та відключати доступ без втручання в ERP.
Важливе обмеження: IAP добре працює для HTTP/HTTPS-доступу, але сам по собі не захищає базу даних ERP, товсті клієнти, службові протоколи чи прямі інтеграції. Тому його не можна розглядати як єдиний контроль. Його задача — прибрати неавторизований веб-доступ і зробити автентифікацію керованою ззовні.
PAM: контроль адміністраторів і сервісних акаунтів
Другий шар — Privileged Access Management. Якщо IAP відповідає на питання «хто може потрапити до інтерфейсу ERP», то PAM відповідає на питання «хто і як керує серверами, базами даних та технічними обліковими записами».
Для legacy ERP PAM зазвичай має три практичні задачі:
- Сховище привілейованих облікових даних. Адміністратори не повинні працювати зі спільними статичними паролями до серверів ERP або СУБД.
- Ротація сервісних акаунтів. PAM-сховище може використовуватися для ротації облікових даних сервісних акаунтів, що підключаються до бази даних ERP, знижуючи ризик витоку довгоживучих або зашитих у конфігурації паролів.
- Контроль сесій. Адміністративний доступ до серверів ERP доцільно проводити через PAM-шлюз із журналюванням і, залежно від політики організації, записом сесій.
Цей шар особливо важливий для сценаріїв, де ERP інтегрована з багатьма внутрішніми системами. Якщо сервісний акаунт має надмірні права або його пароль давно не змінювався, компрометація однієї інтеграції може відкрити доступ до критичних даних. PAM не усуває потреби в перегляді прав у самій ERP, але дає контроль над найбільш ризиковими привілеями поза її кодом.
Мікросегментація: ERP має бачити лише те, що потрібно
Третій шар — мікросегментація. Її мета — зробити так, щоб навіть після компрометації робочої станції або внутрішнього сервера зловмисник не міг вільно рухатися до ERP та її бази даних.
Практичний мінімум для ERP-контуру виглядає так:
- сервер бази даних ERP приймає запити тільки від авторизованих серверів застосунків ERP;
- сервери застосунків ERP приймають веб-запити тільки від Identity-Aware Proxy та визначених інтеграційних шлюзів;
- адміністративні протоколи на кшталт SSH або RDP доступні тільки з PAM-серверів або окремих керованих адміністративних робочих станцій;
- інтеграції з іншими системами описані як конкретні дозволені потоки, а не як широкий доступ між мережевими сегментами.
Найбільший ризик під час мікросегментації — випадково зламати легітимні бізнес-процеси. Тому перед запровадженням правил потрібно мапувати фактичні потоки: які системи підключаються до ERP, які порти й протоколи використовуються, які інтеграції працюють за розкладом, а які — у реальному часі. Без цього мікросегментація перетворюється на серію аварійних винятків, що швидко руйнують початкову модель безпеки.
API та machine-to-machine доступ без переписування ядра
Окрема зона ризику — інтеграції між legacy ERP та іншими внутрішніми системами. Якщо ERP має застарілий API або обмінюється даними через службові канали, варто винести перевірку доступу в інтеграційний шлюз. Такий шлюз може перевіряти токени, сертифікати або інші ознаки довіри до запиту, а вже потім передавати його до legacy-системи.
Як концептуальна аналогія, FCC у матеріалах щодо STIR/SHAKEN описує поєднання технічного процесу authentication/verification із certificate governance для підтримки довіри. Для enterprise-інтеграцій це не є прямою інструкцією до ERP, але добре ілюструє принцип: довіра має спиратися не на мережеве розташування, а на перевірювану ідентичність, керування сертифікатами та контроль політик.
Break-glass: як не зупинити бізнес, якщо identity-шар відмовить
Додатковий захисний контур не повинен ставати єдиною точкою відмови. Якщо IdP, IAP або PAM недоступні, підприємство має мати заздалегідь описану break-glass процедуру. Її суть — не «відкрити все», а надати обмежений, контрольований і аудований аварійний доступ.
Практична break-glass модель для ERP має включати:
- чітко визначених власників рішення про активацію аварійного доступу;
- резервний шлях, наприклад захищене фізичне консольне підключення або ізольований сервісний сегмент;
- окремі облікові записи або ключі, які не використовуються в повсякденній роботі;
- обов’язкове журналювання факту активації, часу, користувача та виконаних дій;
- процедуру повернення до штатного режиму після відновлення identity-шару.
Break-glass потрібно тестувати так само, як резервне копіювання або план аварійного відновлення. Неперевірена процедура часто виявляється або непрацездатною, або надто широкою з погляду доступу.
Методологія впровадження без зупинки ERP
Щоб не порушити бізнес-процеси, захисний контур варто розгортати поетапно. Для управління ризиком корисна логіка Govern, Map, Measure, Manage, яку NIST AI RMF 1.0 застосовує до управління ризиками ШІ; у випадку legacy ERP її можна використати як загальну дисципліну керованого впровадження.
- Govern. Визначити власників ERP-ризику: CISO, CIO, бізнес-власників процесів, адміністраторів ERP, команду мережі та IAM. Зафіксувати, хто затверджує політики доступу й винятки.
- Map. Описати користувачів, ролі, інтеграції, сервісні акаунти, мережеві потоки, адміністративні маршрути та залежності від суміжних систем.
- Measure. Перевірити IAP, PAM і правила сегментації в тестовому або пілотному контурі. Вимірювати не лише технічну працездатність, а й вплив на бізнес-процеси.
- Manage. Поступово переводити групи користувачів і інтеграції на нову модель доступу, починаючи з менш критичних сценаріїв. Усі винятки мають мати власника, строк перегляду та обґрунтування.
Матриця захисних інструментів для legacy ERP
| Інструмент | Де застосовується | Що обмежує | Ключове обмеження |
|---|---|---|---|
| Identity-Aware Proxy | Перед веб-інтерфейсом ERP | Доступ без MFA або без перевірки identity-політик | Не покриває прямий доступ до бази даних, товсті клієнти та non-web протоколи |
| Privileged Access Management | Адміністративні сесії, сервери, СУБД, сервісні акаунти | Неконтрольоване використання привілейованих паролів і довгоживучих технічних акаунтів | Потребує інтеграції з каталогами, процесами підтримки та break-glass процедурою |
| Мікросегментація | Мережеві потоки між ERP, базою даних, шлюзами та адміністративними вузлами | Lateral movement і прямі підключення з неавторизованих сегментів | Потребує точного мапування потоків, інакше можна порушити легітимні інтеграції |
| Інтеграційний шлюз | API та machine-to-machine взаємодія | Неперевірені запити до застарілих інтерфейсів ERP | Не замінює виправлення вразливостей у самій ERP та контроль прав усередині системи |
Де доречна роль інтеграційної команди
У проєктах такого типу основна складність зазвичай не в інсталяції окремого інструмента, а в стику безпеки, мереж, IAM, баз даних і бізнес-процесів. Потрібно не переписати ERP, а правильно «обгорнути» її: описати потоки, винести автентифікацію на зовнішній шар, закрити прямі мережеві маршрути, запровадити PAM і залишити контрольований аварійний доступ.
У межах Intecracy Group такі задачі можуть виконуватися як архітектурні та інтеграційні проєкти; Softengi доречно залучати як команду кастомної розробки та системної інтеграції. Якщо підприємство паралельно створює нові портали, кабінети або інтеграційний шар навколо legacy ERP, платформною основою може бути UnityBase — спільна розробка компаній Intecracy Group, де InBase є ключовим, але не єдиним розробником. У цьому контексті релевантні не маркетингові обіцянки, а конкретні механізми платформи: generated REST API, RBAC/RLS, audit trail, а для комерційних редакцій — зокрема OpenID Connect/OAuth2 та додаткові можливості контролю доступу залежно від редакції.
Головний висновок: IAP, PAM і мікросегментація не скасовують патчинг ERP, hardening ОС і СУБД або планову модернізацію. Але вони дозволяють зменшити поверхню атаки навколо системи, яку не можна швидко замінити, і зробити доступ до неї перевірюваним, обмеженим та аудованим уже зараз.
Поширені питання
Чи стає сама legacy ERP відповідною Zero Trust після впровадження proxy та мікросегментації?
Ні. Зовнішній контур не змінює внутрішню архітектуру ERP і не робить її автоматично Zero Trust-сумісною. Він переносить частину контролів назовні: перевірку ідентичності, обмеження мережевих маршрутів, контроль привілейованих сесій і аудит доступу.
Як налаштувати break-glass доступ до ERP у разі відмови IdP або proxy?
Потрібно заздалегідь описати резервний шлях доступу, наприклад через захищену фізичну консоль або ізольований сервісний сегмент. Активація має бути обмеженою за ролями, журналюватися та завершуватися поверненням до штатної моделі після відновлення identity-шару.
Як захистити інтеграції між legacy ERP та внутрішніми системами без переписування коду?
Практичний підхід — винести контроль у інтеграційний шлюз: описати дозволені потоки, перевіряти ідентичність системи або сервісного акаунта, обмежити мережеві маршрути через мікросегментацію та керувати обліковими даними через PAM.