Десь у великому банку команда інженерів нещодавно завершила переклад двох мільйонів рядків COBOL на Java — міграція тривала чотирнадцять місяців, пройшла всі тестові набори та вийшла в промислову експлуатацію за графіком, однак вже в перший тиждень команда безпеки виявила, що номери кредитних карток, номери соціального страхування та залишки на рахунках незахищено передаються через API-ендпоінти, конвеєр Kafka та аналітичне озеро даних, які оригінальна архітектура мейнфрейму ніколи не розкривала.
Модернізація вдалася, але захист даних — ні, і цей сценарій повторюється набагато частіше, ніж більшість підприємств готові визнати.
Витрати на модернізацію мейнфреймів зростають, але обговорення й надалі зосереджене переважно на трансляції коду, хмарній інфраструктурі та скороченні витрат, тоді як безпека даних — єдиний чинник, що визначає, чи створює проєкт модернізації ризики, чи усуває їх — рідко отримує належну увагу, доки щось не ламається.
Проблема периметра, яку створює модернізація
Застарілі мейнфрейми ніколи не проєктувалися як захищені в сучасному розумінні — вони проєктувалися як недосяжні. Середовища IBM z/OS покладалися на фізичну ізоляцію, засоби контролю доступу RACF та непрозорість своєї архітектури для захисту чутливих даних, і десятиліттями дані залишалися всередині периметра, бо їм просто нікуди було виходити.
Модернізація докорінно змінює це рівняння, адже щойно організація переносить COBOL-застосунок у хмару або реплікує таблиці DB2 до сховища даних, чутливі дані починають перетинати межі довіри, яких раніше не існувало, і кожна нова точка інтеграції — чи то виклик API, конвеєр даних, чи аналітична платформа нижнього рівня — стає поверхнею атаки, для захисту якої оригінальна модель безпеки ніколи не призначалася.
Проблему ускладнює вік цих систем — код COBOL тісно пов'язаний із бізнес-логікою, яку ніхто повністю не документував, розробники, що його писали, виходять на пенсію, і практично кожне підприємство, що використовує мейнфрейм, дотримується однієї політики: не встановлювати агентів, не змінювати виробничий код, не ризикувати порушенням роботи навантажень, що обробляють критично важливі транзакції.
Чому трансляція коду сама по собі недостатня
Інструменти трансляції коду на основі ШІ прискорили процес міграції — те, що колись займало роки, тепер можна виконати за місяці — однак переклад COBOL на Java чи Python не переносить засоби контролю безпеки, які захищали дані, поки вони перебували всередині мейнфрейму. У типовому розгортанні z/OS шифрування виконується на апаратному рівні через спеціалізовані криптографічні процесори, контроль доступу забезпечується через RACF або ACF2, а дані ніколи не виходять назовні, не пройшовши через суворо контрольовані пакетні процеси.
Однак коли ті самі дані переміщуються в хмарне середовище, модель захисту змінюється повністю: дані тепер розподілені між кількома сервісами, регіонами та провайдерами, а область відповідності вимогам PCI DSS, HIPAA та GDPR поширюється на кожну систему, що торкається чутливих даних після їх виходу з z/OS. Без стратегії захисту даних, розробленої до початку міграції, організації виявлять, що вони не стільки модернізували свою безпеку, скільки перенесли свої ризики.
Захист даних без втручання в мейнфрейм
Найбільш практичні підходи до захисту даних під час і після модернізації працюють на мережевому рівні, а не на рівні застосунків, і ця відмінність важлива, оскільки модифікація застарілих COBOL-застосунків рідко є реальною можливістю, а встановлення агентів на виробничих мейнфреймах створює неприйнятний операційний ризик. Безагентні рішення захисту даних перехоплюють дані в процесі їх передачі між мейнфреймом і системами нижнього рівня — токенізуючи, маскуючи або шифруючи чутливі поля в режимі реального часу без змін у коді мейнфрейму, схемах баз даних чи існуючих робочих процесах — і найкращі рішення для оновлення та модернізації мейнфреймів тепер інтегрують такий вбудований захист як основний компонент, а не як запізніле доповнення.
Токенізація зокрема стала переважним методом для підприємств, що працюють у середовищах мейнфреймів. Токени зі збереженням формату підтримують структуру даних, яку очікують застарілі перевірки валідації — наприклад, верифікація за алгоритмом Луна для номерів кредитних карток — водночас усуваючи математичний зв'язок між токеном і вихідним значенням, тобто токени можуть проходити через хмарні конвеєри, аналітичні платформи та інтеграції з третіми сторонами без розкриття чутливих даних або порушення роботи систем нижнього рівня, що залежать від узгодженості форматів.
Що підприємства мають оцінити перед міграцією
Організації, що планують програми модернізації мейнфреймів, повинні оцінити стан безпеки даних до того, як перше навантаження переміщується — зокрема, де зберігаються чутливі дані в базах даних мейнфрейму та сховищах даних застосунків, які шляхи міграції розкриють ці дані новим середовищам і як захист зберігатиметься після того, як дані потраплять у хмару. Підприємства, що правильно здійснюють модернізацію, розглядають безпеку даних як проєктне обмеження з першого дня, а не як позначку про відповідність, що застосовується заднім числом, тоді як ті, хто помиляється, зазвичай виявляють — часто надто пізно — що побудували швидшу, дешевшу та загалом більш вразливу версію того, що вже мали.
