Gdzieś w dużym banku zespół inżynierów niedawno zakończył tłumaczenie dwóch milionów linii kodu COBOL na Javę — migracja trwała czternaście miesięcy, przeszła wszystkie zestawy testów i została uruchomiona zgodnie z harmonogramem, jednak w ciągu pierwszego tygodnia zespół bezpieczeństwa odkrył, że numery kart kredytowych, numery ubezpieczenia społecznego i salda kont przepływają bez ochrony przez punkty końcowe API, potok Kafka i analityczne jezioro danych, które oryginalna architektura mainframe nigdy nie ujawniała.
Modernizacja się powiodła, ale ochrona danych już nie — i ten scenariusz powtarza się znacznie częściej, niż większość przedsiębiorstw chciałaby przyznać.
Wydatki na modernizację mainframe przyspieszają, jednak rozmowy nadal skupiają się przede wszystkim na tłumaczeniu kodu, infrastrukturze chmurowej i redukcji kosztów, podczas gdy bezpieczeństwo danych — jedyny czynnik decydujący o tym, czy projekt modernizacji tworzy ryzyko, czy je eliminuje — rzadko otrzymuje należytą uwagę, dopóki coś się nie posypie.
Problem Perymetru Tworzony przez Modernizację
Starsze mainframe'y nigdy nie były projektowane z myślą o bezpieczeństwie w nowoczesnym sensie — były projektowane tak, by być nieosiągalne. Środowiska IBM z/OS polegały na fizycznej izolacji, kontrolach dostępu RACF i samej nieprzejrzystości swojej architektury w celu ochrony wrażliwych danych, a przez dziesięciolecia dane pozostawały wewnątrz perymetru, ponieważ nie miały dokąd indziej trafić.
Modernizacja fundamentalnie zmienia to równanie, ponieważ w momencie, gdy organizacja przenosi aplikację COBOL do chmury lub replikuje tabele DB2 do hurtowni danych, wrażliwe dane zaczynają przekraczać granice zaufania, które wcześniej nigdy nie istniały, a każdy nowy punkt integracji — czy to wywołanie API, potok danych, czy też platforma analityczna — staje się powierzchnią ataku, do ochrony której oryginalny model bezpieczeństwa nigdy nie był budowany.
Wyzwanie potęguje wiek tych systemów — kod COBOL jest ściśle powiązany z logiką biznesową, której nikt w pełni nie dokumentuje, programiści, którzy go napisali, przechodzą na emeryturę, a praktycznie każde przedsiębiorstwo korzystające z mainframe'a stosuje tę samą politykę: nie instalować agentów, nie modyfikować kodu produkcyjnego, nie ryzykować zakłócenia obciążeń przetwarzających krytyczne transakcje.
Dlaczego Samo Tłumaczenie Kodu Nie Wystarczy
Narzędzia do tłumaczenia kodu wspomagane przez AI przyspieszyły proces migracji — to, co kiedyś zajmowało lata, można teraz zrealizować w ciągu miesięcy — jednak tłumaczenie COBOL na Javę lub Python nie przenosi mechanizmów kontroli bezpieczeństwa, które chroniły dane, gdy znajdowały się wewnątrz mainframe'a. W typowym wdrożeniu z/OS szyfrowanie jest obsługiwane na poziomie sprzętowym przez dedykowane procesory kryptograficzne, kontrola dostępu jest egzekwowana przez RACF lub ACF2, a dane nigdy nie opuszczają systemu bez przejścia przez ściśle kontrolowane procesy wsadowe.
Gdy jednak te same dane przenoszą się do środowiska natywnie chmurowego, model ochrony zmienia się całkowicie: dane są teraz rozproszone między wieloma usługami, regionami i dostawcami, a zakres zgodności z PCI DSS, HIPAA i RODO rozszerza się na każdy system, który dotyka wrażliwych danych po opuszczeniu przez nie z/OS. Bez strategii ochrony danych opracowanej przed rozpoczęciem migracji organizacje odkryją, że nie tyle unowocześniły swoje bezpieczeństwo, co przeniosły swoje ryzyko.
Ochrona Danych bez Ingerencji w Mainframe
Najbardziej praktyczne podejścia do zabezpieczania danych podczas modernizacji i po jej zakończeniu działają na warstwie sieciowej, a nie na warstwie aplikacji — i to rozróżnienie ma znaczenie, ponieważ modyfikowanie starszych aplikacji COBOL jest rzadko wykonalne, a instalowanie agentów na produkcyjnych mainframe'ach wiąże się z niedopuszczalnym ryzykiem operacyjnym. Bezkontaktowe rozwiązania ochrony danych przechwytują dane przepływające między mainframe'em a systemami podrzędnymi — tokenizując, maskując lub szyfrując wrażliwe pola w czasie rzeczywistym bez zmian w kodzie mainframe'a, schematach baz danych czy istniejących przepływach pracy — a najlepsze rozwiązania do modernizacji i aktualizacji mainframe integrują teraz tego rodzaju wbudowane zabezpieczenia jako podstawowy element, a nie jako myśl późniejszą.
Tokenizacja w szczególności stała się preferowaną metodą dla przedsiębiorstw działających w środowiskach mainframe. Tokeny zachowujące format utrzymują strukturę danych, której oczekują starsze kontrole walidacji — takie jak weryfikacja Luhna dla numerów kart kredytowych — eliminując jednocześnie matematyczny związek między tokenem a oryginalną wartością, co oznacza, że tokeny mogą przepływać przez potoki chmurowe, platformy analityczne i integracje z podmiotami trzecimi bez ujawniania wrażliwych danych ani zakłócania systemów podrzędnych zależnych od spójnych formatów.
Co Przedsiębiorstwa Powinny Ocenić Przed Migracją
Organizacje planujące programy modernizacji mainframe powinny ocenić swoją pozycję w zakresie bezpieczeństwa danych przed przeniesieniem pierwszego obciążenia — w szczególności: gdzie wrażliwe dane są przechowywane w bazach danych mainframe i zasobach danych aplikacji, które ścieżki migracji narażą te dane na nowe środowiska oraz jak ochrona będzie utrzymana po dotarciu danych do chmury. Przedsiębiorstwa, które właściwie przeprowadzają modernizację, traktują bezpieczeństwo danych jako ograniczenie projektowe od pierwszego dnia, a nie jako pole wyboru zgodności stosowane z mocą wsteczną, podczas gdy te, którym się to nie udaje, mają tendencję do odkrywania — często zbyt późno — że zbudowały szybszą, tańszą i zarazem bardziej podatną na ataki wersję tego, co już miały.
