Где-то внутри крупного банка команда инженеров недавно завершила перевод двух миллионов строк 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 редко осуществима, а установка агентов на производственные мейнфреймы создаёт неприемлемые операционные риски. Безагентные решения для защиты данных перехватывают данные по мере их передачи между мейнфреймом и нижестоящими системами — токенизируя, маскируя или шифруя конфиденциальные поля в режиме реального времени без изменений в коде мейнфрейма, схемах баз данных или существующих рабочих процессах, — и лучшие решения для модернизации и обновления мейнфреймов теперь интегрируют подобную встроенную безопасность как ключевой компонент, а не как запоздалое дополнение.
Токенизация, в частности, стала предпочтительным методом для предприятий, работающих в средах мейнфреймов. Токены с сохранением формата поддерживают структуру данных, которую ожидают унаследованные проверки валидации, — например, алгоритм Луна для номеров кредитных карт, — одновременно устраняя математическую связь между токеном и исходным значением, что означает: токены могут проходить через облачные конвейеры, аналитические платформы и сторонние интеграции, не раскрывая конфиденциальные данные и не нарушая работу нижестоящих систем, зависящих от согласованных форматов.
Что предприятиям следует оценить перед миграцией
Организациям, планирующим программы модернизации мейнфреймов, следует оценить состояние безопасности данных до перемещения первой рабочей нагрузки — в частности, где находятся конфиденциальные данные в базах данных мейнфреймов и хранилищах данных приложений, какие пути миграции открывают эти данные новым средам и как защита будет обеспечиваться после того, как данные достигнут облака. Предприятия, успешно проводящие модернизацию, с первого дня рассматривают безопасность данных как конструктивное ограничение, а не как галочку соответствия, применяемую задним числом, тогда как те, кто допускает ошибки, нередко обнаруживают — зачастую слишком поздно, — что создали более быструю, дешёвую и при этом значительно более уязвимую версию того, что у них уже было.
