Szacuje się, że COBOL nadal obsługuje 95% transakcji w bankomatach, 80% transakcji w punktach sprzedaży oraz podstawową logikę przetwarzania w większości dużych banków, firm ubezpieczeniowych i agencji rządowych na całym świecie. Organizacje korzystające z tego kodu podlegają również najbardziej wymagającym regulacjom technologicznym: RODO, DORA, HIPAA, PCI-DSS, Bazylea III oraz reżimom sektorowym egzekwowanym przez FCA, OCC, APRA i dziesiątki innych organów krajowych. Kiedy organizacje te rozważają przeniesienie obciążeń do chmury, problem nie jest wyłącznie natury technicznej. Ma on charakter prawny, umowny i można go udowodnić zewnętrznemu audytorowi w określonym czasie.
Chmura hybrydowa, polegająca na zachowaniu części obciążeń lokalnych i przeniesieniu innych do infrastruktury chmurowej, nie jest rozwiązaniem kompromisowym dla regulowanych organizacji korzystających z języka COBOL. Często jest to rozwiązanie architektonicznie poprawne. Wymagania dotyczące rezydencji danych wynikające z RODO i jego krajowych odpowiedników mogą prawnie zabraniać niektórym danym opuszczania określonej jurysdykcji. Wymagania dotyczące odporności operacyjnej wynikające z ustawy DORA wymagają wykazania, że krytyczne funkcje finansowe są w stanie przetrwać awarie dostawców usług chmurowych. Wymagania dotyczące integralności obliczeń kapitału regulacyjnego zgodnie z Bazyleą III wymagają, aby określone obliczenia były powtarzalne, audytowalne i zabezpieczone przed manipulacją, co jest łatwiejsze do wykazania, gdy obliczenia są przeprowadzane w infrastrukturze kontrolowanej przez organizację.
Znajdź luki w zgodności przed rozpoczęciem migracji
SMART TS XL ujawnia zakodowane na stałe dane uwierzytelniające, brakujące ślady audytu i regulowane wzorce danych w kodzie źródłowym COBOL.
Więcej informacjiWyzwaniem jest to, że architektura chmury hybrydowej dla regulowanego języka COBOL jest bardziej ograniczona, niż wskazują na to ogólne wytyczne dotyczące chmury hybrydowej. Strategia integracji chmury hybrydowej zapewnia niezbędną równowagę między innowacyjnością a stabilnością podczas migracji z komputerów mainframe do chmury. Ta równowaga jest z zasady prawidłowa. Pomija ona jednak specyficzną architekturę techniczną i zgodności, niezbędną do wyznaczenia granicy między środowiskiem lokalnym a chmurą w miejscu, które spełnia wymogi organów regulacyjnych, zachowuje ciągłość operacyjną i tworzy ścieżkę migracji, a nie trwały podział.
W tym przewodniku omówiono, w jaki sposób poszczególne główne ramy regulacyjne kształtują decyzję o granicach hybrydowych, cztery wzorce architektoniczne, które sprawdzają się w regulowanych środowiskach COBOL, tryby błędów zgodności, które wprowadzają architektury hybrydowe, jeśli nie zostały dla nich zaprojektowane, oraz co audytorzy faktycznie sprawdzają podczas przeglądu hybrydowego środowiska COBOL.
Jak regulacje kształtują granicę hybrydową
Najważniejszą decyzją w architekturze chmury hybrydowej dla organizacji podlegającej regulacjom nie jest wybór dostawcy chmury ani wybór obciążeń do migracji w pierwszej kolejności. Chodzi o to, gdzie wyznaczyć granicę zgodności: które dane i które procesy muszą pozostać lokalne, a które można przenieść do infrastruktury chmurowej bez naruszania przepisów.
Każda główna struktura nakłada inne wymagania na tę granicę:
| Regulacja | Jurysdykcja | Podstawowe ograniczenie hybrydowe | Co musi pozostać na miejscu |
|---|---|---|---|
| RODO / nFADP | UE, Szwajcaria | Miejsce przechowywania danych osobowych rezydentów UE/EOG | Każdy system COBOL przetwarzający dane osobowe UE bez decyzji o adekwatności dla docelowego regionu chmury |
| DORA | Usługi finansowe UE | Odporność operacyjna; zarządzanie ryzykiem stron trzecich dla dostawców ICT | Funkcje krytyczne lub ważne muszą mieć strategie wyjścia; obowiązują limity ryzyka koncentracji |
| HIPAA | Opieka zdrowotna w USA | PHI nie może być przetwarzany przez dostawcę usług w chmurze bez BAA; wymagania dotyczące szyfrowania | ePHI przesyłane i przechowywane na dowolnej ścieżce w chmurze wymagają udokumentowanych kontroli |
| PCI-DSS w wersji 4.0 | Globalne (płatności kartą) | Środowisko danych posiadacza karty musi być odizolowane od sieci | Systemy przetwarzania CHD; zarządzanie kluczami szyfrującymi |
| Bazylea III/IV | Globalny (bankowość) | Obliczenia kapitału regulacyjnego muszą być powtarzalne i możliwe do zweryfikowania | Silniki obliczeniowe, w których audytowalność jest wykazywana poprzez kontrolę infrastruktury |
| FCA / PRA (Wielka Brytania) | Usługi finansowe w Wielkiej Brytanii | Odporność operacyjna; ważne usługi biznesowe muszą spełniać wymagania dotyczące tolerancji na uderzenia | Zależy od możliwości udowodnienia umowy SLA; chmura nie jest wykluczona, ale musi zostać udowodniona |
| OCC (bankowość amerykańska) | Banki narodowe USA | Zarządzanie ryzykiem dostawców; należyta staranność wobec stron trzecich | Brak całkowitego zakazu, ale wymagane jest ryzyko koncentracji i plany wyjścia |
Praktyczne konsekwencje dla obciążeń COBOL-a:
Program wsadowy COBOL przetwarzający dane kont klientów z UE nie może zostać przeniesiony na platformę chmury obliczeniowej poza UE/EOG, chyba że jurysdykcja dostawcy chmury otrzyma decyzję o odpowiednim poziomie ochrony lub zostaną wdrożone odpowiednie zabezpieczenia (standardowe klauzule umowne). Ten sam program przetwarzający wyłącznie wewnętrzne dane operacyjne ma znacznie większą elastyczność.
Przed wyznaczeniem granicy hybrydowej każda regulowana organizacja powinna przeprowadzić klasyfikację danych w swoim portfolio COBOL: które programy mają kontakt z danymi osobowymi, które z danymi posiadaczy kart, które z chronionymi informacjami medycznymi (PHI) i które przetwarzają obliczenia kapitału regulacyjnego. Ta klasyfikacja określa, które programy mogą swobodnie migrować, a które muszą pozostać poza granicą zgodności, niezależnie od preferencji technicznych.
Problem zgodności z COBOL-em, o którym nikt nie wspomina
Programy COBOL wprowadzają ryzyka zgodności specyficzne dla języka i jego epoki, których nie uwzględniają ogólne wytyczne dotyczące zgodności w chmurze. Ryzyka te występują obecnie lokalnie i stają się problemami z widocznością w środowisku hybrydowym, gdzie audytor oczekuje kontroli po obu stronach granicy.
Luki w dzienniku audytu. Programy COBOL zazwyczaj zapisują do plików i baz danych bez natywnego rejestrowania transakcji. Aktualizacja VSAM KSDS w COBOL domyślnie nie generuje niezmiennego zapisu tego, kto, co i kiedy zmienił oraz z jakiej wartości na jaką. W środowisku regulowanym jest to luka zgodności, a przeniesienie programu z tą luką do środowiska hybrydowego, w którym chmura korzysta z nowoczesnego rejestrowania audytu, sprawia, że luka ta jest bardziej widoczna, a nie mniej.
Zakodowane na stałe dane uwierzytelniające i klucze szyfrujące. Starsze aplikacje COBOL często nie posiadają nowoczesnych funkcji, takich jak kontrola dostępu oparta na rolach, monitorowanie w czasie rzeczywistym i protokoły szyfrowania, co naraża je na wyrafinowane cyberzagrożenia. Analiza statyczna programów COBOL rutynowo ujawnia zakodowane na stałe klucze, hasła w pamięci operacyjnej (WORKING-STORAGE) oraz ciągi połączeń osadzone w kodzie źródłowym. W środowisku hybrydowym, które musi spełniać wymogi PCI-DSS dotyczące zarządzania kluczami lub kontroli szyfrowania HIPAA, wzorce te wymagają korekty przed migracją, a nie po niej.
Powtarzalność obliczeń. Upakowana arytmetyka dziesiętna języka COBOL (COMP-3) charakteryzuje się określoną precyzją i zaokrąglaniem. Obliczenie kapitału regulacyjnego, które działa poprawnie w systemie z/OS, może dawać inne wyniki w systemie Linux ze względu na różnice w obsłudze miejsc dziesiętnych przez kompilator. Różnica może wynosić centy za transakcję lub być istotna dla współczynnika kapitałowego. Środowiska hybrydowe, które rozdzielają komponenty obliczeniowe na różne platformy, muszą jawnie weryfikować równoważność liczbową.
Cztery hybrydowe wzorce architektoniczne dla regulowanego języka COBOL
Różne regulowane obciążenia wymagają różnych architektur hybrydowych. Nie ma jednego uniwersalnego wzorca, ale te cztery obejmują zakres sytuacji, z którymi spotyka się większość regulowanych organizacji.
Wzorzec 1: Brama API Compliance-Boundary
Najlepiej dla: organizacji, w których logika biznesowa COBOL musi pozostać lokalna ze względu na przepisy, ale nowoczesne aplikacje, analizy i usługi skierowane do klientów można przenieść do chmury.
Programy COBOL pozostają na komputerze mainframe. Cienka warstwa API, zazwyczaj działająca w infrastrukturze przyległej do chmury lub w sieci prywatnej organizacji, udostępnia funkcjonalność COBOL jako punkty końcowe REST lub gRPC. Aplikacje chmurowe wywołują te punkty końcowe. Program COBOL nigdy się nie przenosi, ale jego interfejs – tak.
Cloud Region (permitted) Compliance Boundary On-Premises (required)
┌─────────────────────┐ │ ┌──────────────────────────┐
│ New cloud-native │ │ │ COBOL programs │
│ applications │──── API ─────┤──────────────│ (regulated processing) │
│ │ call │ │ │
│ Analytics │ │ │ VSAM files (PHI/CHD) │
│ platforms │ │ │ │
│ │ │ │ Audit logs │
└─────────────────────┘ │ └──────────────────────────┘Zaleta zgodności: Dane regulowane nigdy nie przekraczają granicy. Brama API obsługuje uwierzytelnianie, autoryzację i rejestrowanie na granicy, zapewniając dostęp do śladu audytu, którego sam program COBOL może nie wygenerować. Chmura nigdy nie przetwarza danych regulowanych bezpośrednio.
Wymagania operacyjne: Warstwa API musi być zaprojektowana tak, aby obsługiwać synchroniczny model żądanie-odpowiedź języka COBOL. Długotrwałe zadania wsadowe COBOL wymagają asynchronicznych wzorców z mechanizmami wywołań zwrotnych lub sondowania, a nie synchronicznych wywołań API, które ulegają przekroczeniu limitu czasu.
Wzorzec 2: Warstwowanie danych według wrażliwości regulacyjnej
Najlepiej dla: organizacji, które w tym samym środowisku COBOL przechowują zarówno dane regulowane, jak i nieregulowane, gdzie dane regulowane można oddzielić od danych operacyjnych.
Dane transakcyjne, które podlegają wymogom regulacyjnym, dane osobowe, dane posiadaczy kart, PHI, pozostają na miejscu. Zagregowane, zanonimizowane lub operacyjne dane, które nie podlegają ograniczeniom regulacyjnym, są przenoszone do chmury i przetwarzane. Programy COBOL generujące regulowane dane wyjściowe nadal działają na komputerach mainframe. Programy raportujące, które wykorzystują zagregowane dane, działają w chmurze.
Kluczowy wymóg implementacji: Etap agregacji i anonimizacji musi być audytowalny. Proces przekształcania danych regulowanych w dane nieregulowane w celu transmisji w chmurze musi być rejestrowany, testowany i podlegać własnym mechanizmom kontroli. Proces deidentyfikacji, który zawodzi w określonych warunkach wejściowych, może generować dane w chmurze, które przypadkowo ponownie identyfikują osoby, co stanowi naruszenie RODO spowodowane przez architekturę, która została zaprojektowana w celu zapobiegania temu naruszeniu.
Wzorzec 3: Walidacja dwuetapowa
Najlepiej dla: organizacji migrujących obciążenia COBOL, które wykonują regulowane obliczenia, w których równoważność funkcjonalna starych i nowych systemów musi zostać wykazana organowi regulacyjnemu przed przełączeniem.
Oryginalny program COBOL nadal działa na komputerze mainframe, przetwarzając dane w czasie rzeczywistym. Implementacja równoległa, przebudowana na nową platformę lub przeprojektowana, działa jednocześnie w infrastrukturze chmurowej, przetwarzając te same dane wejściowe. Dane wyjściowe są porównywane w czasie rzeczywistym. Rozbieżności są sygnalizowane, badane i rozwiązywane przed certyfikacją implementacji chmurowej jako systemu rekordów.
Wartość zgodności: System Dual-run spełnia wymóg udowodnionej równoważności, który organy regulacyjne nakładają na zmiany w systemach wykonujących obliczenia regulacyjne. Organizacja może przedstawić audytorowi zapis N miesięcy równoległej pracy, proces uzgadniania zastosowany do rozbieżności oraz dowody na to, że nowy system generuje zasadniczo identyczne wyniki we wszystkich testowanych warunkach wejściowych.
Koszty operacyjne: Równoległe działanie dwóch systemów jest kosztowne. Podwójne działanie to mechanizm przejściowy, a nie stała architektura. Harmonogram ukończenia walidacji i przejścia na nowy system powinien być określony w planie projektu i uzgodniony z odpowiednim organem regulacyjnym, jeśli wymagana jest wstępna zgoda (podobnie jak w przypadku zmian funkcji krytycznych w ramach ustawy DORA).
Wzorzec 4: Dusiciel Fig z granicą zgodności
Najlepiej dla: organizacji rozwijających nowe możliwości w chmurze, utrzymujących regulowane obciążenia COBOL lokalnie w perspektywie długoterminowej, ze zdefiniowaną ścieżką migracji dla każdego obciążenia po uzyskaniu certyfikatu.
Nowe funkcje i funkcjonalności skierowane do klienta są od samego początku tworzone jako usługi natywne dla chmury. Regulowane obciążenia COBOL pozostają lokalne, z dostępem za pośrednictwem wzorca bramy API. Z czasem poszczególne programy COBOL uzyskują certyfikację do wdrożenia w chmurze, przechodząc walidację dwuetapową, spełniając wymagane zgody regulacyjne i migrując do chmury. Komputer mainframe stopniowo się kurczy w miarę jak każdy program uzyskuje certyfikat zgodności.
Dlaczego to rozwiązanie sprawdza się w organizacjach regulowanych: Umożliwia szybką modernizację obciążeń nieregulowanych, jednocześnie stosując odpowiednią rygorystyczność w przypadku obciążeń regulowanych. Granica zgodności jest jasno określona, możliwa do zweryfikowania i jednokierunkowa. Organizacja może wykazać organom regulacyjnym, że każde obciążenie w chmurze przeszło zdefiniowany proces certyfikacji, a każde obciążenie w środowisku lokalnym ma plan certyfikacji.
O co tak naprawdę pytają audytorzy w kontekście hybrydowych środowisk COBOL
Zgodność to nie stan, to proces, który można udowodnić. Pytanie nie brzmi, czy Twoja architektura hybrydowa jest zgodna. Pytanie brzmi, czy możesz to udowodnić komuś, kto zajmuje się wyszukiwaniem problemów.
Oto pytania, które zadają audytorzy z głównych organów regulacyjnych w kontekście hybrydowych środowisk COBOL i jakie dowody potwierdzają każde z nich:
„Gdzie te dane znajdują się w stanie spoczynku i w jakich jurysdykcjach?” Wymagane: aktualna mapa danych pokazująca wszystkie magazyny danych, pliki VSAM, tabele DB2, chmurowe obiekty pamięci masowej, wraz z jurysdykcją, klasyfikacją i wdrożonymi mechanizmami kontroli. Programy COBOL, które zapisują dane w zestawach danych, muszą być widoczne na tej mapie z sklasyfikowanymi wynikami.
„Pokaż mi ślad audytu dla tej transakcji”. Wymagane: pełny ślad od początku transakcji, przez każdy system, który miał kontakt z danymi, w tym program COBOL, który je przetworzył. Jeśli program COBOL nie generuje własnych rekordów audytu, otaczająca infrastruktura musi to skompensować – funkcja ta musi być jawnie zaplanowana, a nie zakładana.
„Co stanie się z Twoimi krytycznymi funkcjami, jeśli Twój dostawca usług w chmurze ulegnie awarii?” Wymagania (DORA): udokumentowane scenariusze odporności operacyjnej, przetestowane wskaźniki RPO i RTO dla krytycznych funkcji oraz dowody na to, że systemy lokalne mogą działać niezależnie od zależności w chmurze przez czas określony w polityce odporności organizacji.
„Skąd wiesz, że zmigrowany system generuje takie same wyniki jak oryginalny?” Wymagane: rekord uzgadniania dwóch przebiegów, pokrycie przypadków testowych, a w przypadku obciążeń zależnych od obliczeń analiza równoważności numerycznej.
„Kto może uzyskać dostęp do regulowanych danych w chmurze i jakie zatwierdzenia regulują ten dostęp?” Wymagane: dokumentacja polityki IAM, rejestry zarządzania dostępem z uprawnieniami oraz dowody na to, że kontrola dostępu w chmurze jest co najmniej tak restrykcyjna, jak w środowisku lokalnym.
Ramy decyzyjne do ustalenia granicy hybrydowej
Nie każdy program COBOL należy do tej samej strony granicy hybrydowej. Ta lista kontrolna określa umiejscowienie każdego obciążenia:
Przenieś się do chmury bez ograniczeń regulacyjnych:
- Program nie przetwarza danych osobowych osób w jurysdykcjach RODO/nFADP
- Program nie przetwarza danych posiadacza karty (potwierdzono wykluczenie zakresu PCI-DSS)
- Program nie przetwarza żadnych PHI (potwierdzono wyłączenie zakresu HIPAA)
- Program nie wykonuje obliczeń stanowiących dane wejściowe do wskaźników kapitału regulacyjnego
- Program nie posiada zakodowanych na stałe danych uwierzytelniających ani kluczy szyfrujących w źródle
- Wyniki programu nie podlegają wymogom dotyczącym rezydencji danych w żadnej jurysdykcji
Wymaga projektu zgodności przed migracją do chmury:
- Program generuje lub przetwarza dane osobowe, przeprowadza pełną ocenę wpływu na dane
- Program mieści się w zakresie PCI-DSS, kompletnego SAQ/ROC dla środowiska chmurowego
- Program wykonuje obliczenia kapitału regulacyjnego i pełną analizę równoważności numerycznej
- Programowi brakuje generowania śladu audytu, projektowania kontroli kompensacyjnych przed migracją
- Program zawiera zakodowane na stałe klucze, które należy naprawić przed udostępnieniem w ścieżce sieciowej w chmurze
Musi pozostać na miejscu do momentu uzyskania wstępnej zgody organów regulacyjnych:
- Program jest klasyfikowany jako funkcja krytyczna lub ważna w ramach ustawy DORA
- Program podlega wymogom FCA/PRA dotyczącym odporności operacyjnej jako ważna usługa biznesowa
- Organ regulacyjny wyraźnie wymagał powiadomienia lub wcześniejszej zgody na zmiany w systemie (co jest powszechne w bankowości podstawowej)
W jaki sposób SMART TS XL Obsługuje planowanie architektury hybrydowej dla regulowanego języka COBOL
Decyzje opisane w tym przewodniku, dotyczące tego, gdzie umieścić granicę zgodności, które programy przetwarzają dane regulowane, które zawierają wymagania dotyczące naprawy bezpieczeństwa, które wykonują funkcje obliczeniowe wymagające walidacji równoważności, wymagają dokładnej znajomości struktury każdego programu w portfolio COBOL. Wiedzy tej nie można zakładać na podstawie dokumentacji. W regulowanych środowiskach COBOL, istniejąca dokumentacja była zazwyczaj pisana dla systemu, który od tego czasu był modyfikowany dziesiątki razy bez odpowiednich aktualizacji dokumentacji.
SMART TS XL'S statyczna analiza kodu Ujawnia wzorce bezpieczeństwa i zgodności w kodzie źródłowym COBOL, które określają, po której stronie granicy hybrydowej znajduje się każdy program: zakodowane na stałe dane uwierzytelniające w WORKING-STORAGE, obsługę kluczy szyfrujących, generowanie dziennika audytu (lub jego brak) oraz wzorce obliczeniowe wpływające na kapitał regulacyjny. Odkrycia te wspierają prace projektowe dotyczące zgodności, które muszą poprzedzać ustalenie granicy hybrydowej dla regulowanych obciążeń.
Mapowanie zależności aplikacji pokazuje , które programy współdzielą dane z innymi, a także wzorce dostępu do zbiorów danych między programami, które decydują o tym, czy umieszczenie jednego programu w chmurze spowoduje regulowany przepływ danych przez granicę, którego nie przewidywano. Program COBOL, który pozornie przetwarza wyłącznie dane operacyjne, może odczytywać dane z pliku VSAM, który zawiera również dane osobowe zapisane przez inny program. Mapa zależności uwidacznia te relacje współdzielenia danych przed narysowaniem granicy hybrydowej.
Możliwość analizy wpływu sprawia , że zmiany granic podlegają audytowi: gdy program jest przenoszony z lokalizacji lokalnej do chmury, analiza wpływu wymienia wszystkie inne programy, na które ma wpływ to przeniesienie, wywołujących, odbiorców zbiorów danych, strumienie zadań JCL , dostarczając zakres zmiany jako dowód dla organu regulacyjnego i podstawę dla programu testowania równoważności.
Funkcja wyszukiwania w przedsiębiorstwie umożliwia wyszukiwanie w inwentarzu zgodności w całym programie hybrydowym: znajdź każdy program przetwarzający określony typ danych, każdy program uzyskujący dostęp do określonego klastra VSAM, każdy plik źródłowy COBOL zawierający określony wzorzec, obejmujący miliony wierszy, w ciągu kilku sekund. Dla organizacji podlegającej regulacjom, która chce wykazać audytorowi, że wszystkie programy w zakresie zostały zidentyfikowane i ocenione, ten wyszukiwalny inwentarz stanowi dowód zastępujący ręczne poświadczanie.
Organ regulacyjny nie interesuje się harmonogramem migracji
Chmura hybrydowa nie jest stanem tymczasowym dla regulowanych organizacji korzystających z języka COBOL. Dla wielu z nich jest to stały model operacyjny, nie ze względu na ograniczenia techniczne, ale dlatego, że ramy regulacyjne regulujące ich dane i funkcje wymagają nieograniczonej kontroli lokalnej nad określonymi obciążeniami. Właściwe pytanie nie brzmi: „jak odejść od komputerów mainframe”, ale: „które obciążenia mogą zostać przeniesione do chmury, w ramach jakiej architektury zgodności i z jakim dowodem na to, że granica jest właściwie kontrolowana”.
Konfiguracje hybrydowe dają organizacjom elastyczność w zakresie zachowania starszych komponentów lokalnie, umożliwiając jednocześnie integrację z chmurą. W branżach regulowanych ta elastyczność nie jest opcjonalna, lecz obowiązkowa dla określonych kategorii obciążeń. Organizacje, które odnoszą sukcesy z hybrydową architekturą COBOL, to te, które wyraźnie projektują granicę zgodności, od samego początku zapewniają jej audytowalność i traktują tworzenie dowodów regulacyjnych jako wymóg architektoniczny, a nie jako dodatek do dokumentacji.
