Suurte pankade sees lõpetas hiljuti insenerite meeskond kahe miljoni COBOL-koodirea tõlgendamise Java keelde – see üleminek kestis 14 kuud, läbis kõik testikomplektid ja läks täpselt ajakavas ellu, kuid turvameeskond avastas esimese nädala jooksul, et krediitkaardanumbrid, sotsiaalkindlustusnumbrid ja kontosalod voolasid kaitseta API-lõpp-punktide, Kafka-andmevoogude ja analüütika andmepargi kaudu, mida originaalne mainframe-arhitektuur kunagi ei eksportinud.
Moderniseerimine õnnestus, kuid andmete kaitse ei õnnestunud, ja selline stsenaarium esineb palju sagedamini, kui enamik ettevõtteid sooviks tunnistada.
Mainframe’i moderniseerimisele kulutatav summa kasvab kiiresti, kuid arutelu keskendub üleliialt kooditõlgendusele, pilveteenuste infrastruktuurile ja kulude vähendamisele, samas kui andmete turvalisus – ainus tegur, mis otsustab, kas moderniseerimisprojekt loob riski või seda eemaldab – saab harva piisavalt tähelepanu seni, kuni midagi katki läheb.
Moderniseerimisega tekkinud piirjoone probleem
Vanad mainframe’id ei olnud kunagi mõeldud turvalisuseks kaasaegses mõttes; neid oli mõeldud olema ligipääsmatud. IBM z/OS-keskkonnad tuginesid füüsilisele isoleerimisele, RACF-ligipääsukontrollile ja nende arhitektuuri täielikule ebateadlikkusele tundliku andmete kaitseks ning kümnendite vältel jäi andmed piirjoone sisse, sest neil polnud kuhugi muuda minna.
Moderniseerimine muudab seda olukorda põhjalikult, sest hetkel, mil organisatsioon ülepaigutab COBOL-rakenduse pilve või kopeerib DB2-tabelid andmevaraülesse, hakkavad tundlikud andmed ristuma usalduspiiridega, mida varem ei eksisteerinud, ja iga uus integreerimispunkt – olgu see siis API-käsk, andmevoog või allaharus analüüsiv platvorm – muutub rünnakuobjektiks, mille kaitseks originaalne turvamudel pole kunagi loodud.
Probleemi süvendab süsteemide vanus – COBOL-kood on tihedalt seotud ärilogikaga, mida keegi täielikult ei dokumenteerinud, COBOL-i kirjutanud arendajad pensionituvad ja peaaegu igas ettevõttes, mis mainframe’i kasutab, kehtib sama poliitika: ära paigalda agentesid, ära muuda tootmisversioonis olevat koodi ja ära ohusta missioonikriitiliste tehingute töötlemist.
Miks üksnes kooditõlgendus ei piisa
AI-toetatud kooditõlgendusvahendid on kiirendanud migreerimisprotsessi – seda, mille tegemine võttis varem aastaid, saab nüüd teha kuudes – kuid COBOL-i tõlgendamine Java või Python keelde ei tähenda automaatselt ka turvameetmete tõlgendamist, mis kaitstsid andmeid mainframe’is. Tüüpilises z/OS-deployments (deployments) käivitatakse krüpteerimine riistvaratasemel eraldi krüptograafiliste protsessorite abil, ligipääsukontroll rakendatakse RACF-i või ACF2-ga ning andmed ei jõua välja ilma läbi rangelt reguleeritud partii-protsesside läbimata.
Kui aga samad andmed liiguvad pilveteenuste keskkonda, muutub kaitsemudel täiesti: andmed jaotuvad mitme teenuse, piirkonna ja pakkujaga ning vastavusnõuded PCI DSS-i, HIPAA ja GDPR alusel laienevad kõigile süsteemidele, mis puudutavad tundlikke andmeid pärast nende väljumist z/OS-ist. Ilma enne migreerimist koostatud andmekaitsestrategiata leiavad organisatsioonid, et nad ei ole oma turvalisust moderniseerinud, vaid pigem oma riske migreerinud.
Andmete kaitse ilma mainframe’i muutmata
Praktilisemad viisid andmete kaitseks moderniseerimise ajal ja pärast seda toimivad võrgutasemel, mitte rakendustasemel, ja see eristus on oluline, sest vanade COBOL-rakenduste muutmine on harva teostatav ja agentide paigaldamine tootmisversioonis olevatesse mainframe’idesse teeb operatsioonilise riski liialt suureks. Agentideta andmekaitse lahendused püüavad andmeid kinni mainframe’ist ja allaharude süsteemide vahel liikudes – tehes reaalajas tokeniseerimise, maskeerimise või krüpteerimise tundliku väli ja muutes mainframe’i koodi, andmebaasi skeeme või olemasolevaid töövooge – ning parimad mainframe’i uuendus- ja moderniseerimislahendused integreerivad praegu sellise sisemise turvalisuse kui tuumkomponendi, mitte kui tagantjärele lisatud funktsiooni.
Eriti tokeniseerimine on kujunenud ettevõtete jaoks eelistatud meetodiks mainframe’i keskkonnas. Vormi säilitavad tokendid hoiavad säilinud andmestruktuuri, mida ootavad vanad valideerimiskontrollid – näiteks Luhn’i kontroll krediitkaardanumbrite korral – samas kui tokendi ja originaalväärtuse vahel puudub matemaatiline seos, st tokendid võivad voolata pilveteenuste voogudes, analüüsplatvormides ja kolmandate osapoolte integreerimistes ilma tundlike andmete avaldamata või allaharude süsteemide rikkumata, mis sõltuvad pidevatest vormidest.
Mida ettevõtted peaksid hindama enne migreerimist
Mainframe’i moderniseerimisprogramme planeerivad organisatsioonid peaksid hindama oma andmete turvalisuse seisukorda juba enne esimese töökoormuse liigutamist – eriti kus tundlikud andmed asuvad mainframe’i andmebaasides ja rakenduste andmevarudes, millised migreerimisruted ekspositsiooniks neid andmeid uutesse keskkondadesse ja kuidas kaitse säilib pärast andmete jõudmist pilve. Ettevõtted, kes moderniseerimise õigesti teevad, käsitlevad andmete turvalisust projekteerimispiiranguks juba esimesest päevast, mitte tagantjärele rakendatava vastavuskontrollina, samas kui need, kes seda valesti teevad, avastavad sageli liiga hilja, et nad on ehitatud kiirema, odavama ja kokkuvõttes täielikult haavatavama versiooni sedast, mida neil juba oli.
