Zpráva IBM o nákladech na únik dat za rok 2025 uvádí průměrné náklady na únik dat na 4.44 milionu dolarů. Porušení týkající se osobních údajů s sebou nese nejvyšší regulační sankce podle GDPR a HIPAA, ne proto, že by náprava úniků osobních údajů byla z technického hlediska dražší, ale proto, že s nimi regulační orgány zacházejí odlišně. Pokuty podle GDPR mohou dosáhnout čtyř procent globálních ročních příjmů. Občanskoprávní sankce podle HIPAA dosahují 1.9 milionu dolarů za kategorii porušení ročně. Organizační expozice v důsledku jediného narušení systému, jehož inventarizace PII byla neúplná, protože program zjišťování, který ji měl najít, pokrýval pouze moderní stack a zastavil se na hranici mainframe, není problémem datového inženýrství. Jedná se o regulační a finanční riziko, které je na programu představenstva.
Většina organizací nedokáže na vyžádání vytvořit kompletní inventář PII. Standardní nástroje pro vyhledávání PII, Varonis, IBM Guardium, BigID, Microsoft Purview a Strac, vynikají ve skenování strukturovaných databází, cloudových úložišť, platforem SaaS a sdílených souborů. Připojují se k tomu, k čemu se mohou připojit. Co se nemohou připojit, nemohou skenovat. Soubory VSAM v systému z/OS nemají konektory JDBC. Programy v jazyce COBOL, které uchovávají zákaznická data v úložišti WORKING-STORAGE během dávkového zpracování, nezpřístupňují data prostřednictvím API. Definice datových sad JCL se neregistrují v datovém katalogu. Vrstva mainframe, která zpracovává 95 procent transakcí bankomatů a zpracovává odhadem 3 biliony dolarů v denním obchodu, je největší, nejvíce zatíženou PII a nejvíce systematicky nedostatečně skenovanou vrstvou v podnikových datových prostorách. Nemůžete ochránit to, co nemůžete najít, a většina organizací to celé nenašla.
Osobní údaje, které váš katalog nedokáže oslovit
SMART TS XL sleduje PII od zdroje VSAM přes programy v COBOLu až po každou následnou datovou sadu, která ji dědí.
ZJISTĚTE VÍCE…Proč je starší vrstva nejtěžší částí vyhledávání osobních údajů
Standardní výzva k vyhledávání PII, tedy jmen, adres, čísel sociálního zabezpečení a údajů o platebních kartách roztroušených ve stovkách databází a sdílených souborů, je sice obtížná, ale s moderními nástroji zvládnutelná. Přístupy porovnávání vzorů, které jsou základem většiny nástrojů pro vyhledávání PII, fungují dobře i se strukturovanými daty s přístupnými konektory: prohledávají sloupce, používají vzory regulárních výrazů, označují pole, která odpovídají podpisům PII, klasifikují a inventarizují.
Starší vrstva zavádí čtyři vlastnosti, které narušují přístup porovnávání vzorů:
Zkrácené názvy polí bez sémantického signálu. Názvy polí v COBOLu jsou v moderních dialektech omezeny na 30 znaků a ve starším kódu se běžně psaly v 8místné zkrácené formě: CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DTSkener pro porovnávání vzorů, který identifikuje social_security_number or customer_name protože ukazatele PII v oblasti nemají žádný základ pro klasifikaci SSN-NO or CUST-NM bez pochopení konvencí pojmenování COBOLu. Konvence zkratek je sama o sobě problémem s metadaty, pole obsahuje PII, ale jeho název to skeneru navrženému pro moderní konvence pojmenování jasně nesignalizuje.
PII zabudované do kompozitních struktur. Záznamy v COBOLu často balí více datových prvků do jednoho pole nebo používají REDEFINES k překrytí různých interpretací stejných bajtů. Pole záznamu zákazníka CUST-FULL-DATA definováno jako PIC X(100) může obsahovat jméno, adresu a telefonní číslo zřetězené do jednoho řetězce s dílčími poli na pevné pozici, což je struktura, která se jeví jako jedno neprůhledné textové pole pro jakýkoli skener, který čte pouze definici pole, aniž by chápal logiku programu, která jej naplňuje a čte.
Osobní údaje přenášené přes WORKING-STORAGE. Dávkové programy v COBOLu často čtou osobní údaje ze souborů VSAM, zpracovávají je v proměnných WORKING-STORAGE a zapisují výstupy do datových sad. Osobní údaje existují v WORKING-STORAGE během provádění, v paměti, nikoli v perzistentním úložišti dat, a poté zmizí po ukončení programu. Skenování dat, které prohledává perzistentní úložiště, najde zdroj VSAM a výstupní datovou sadu, ale nikoli meziprodukt zpracování, kde jsou data sestavována, transformována a potenciálně zaznamenávána.
Osobní údaje překračující hranici IT/OT prostřednictvím rozhraní plochých souborů. Zákaznická data extrahovaná ze souborů VSAM sálových počítačů často přecházejí do navazujících systémů prostřednictvím rozhraní plochých souborů, extraktů CSV, souborů záznamů s pevnou délkou, souborů s pozičním formátem, které neobsahují metadata sloupců. Plochý soubor obsahuje osobní údaje na specifických bajtových pozicích, ale následný skener, který soubor přijímá, nemá schéma pro mapování pozic na významy polí, pokud není také analyzována položka COBOL FD, která definuje rozvržení záznamu.
Výzva k inventáři PII v rozděleném panství
Podnik s mainframe systémy starších verzí i moderními cloudovými platformami čelí výzvě v oblasti inventáře PII, která zahrnuje dva zásadně odlišné přístupy k objevování. Moderní vrstva je přístupná standardním nástrojům. Starší vrstva vyžaduje jinou metodu. Požadavek na shodu, právo na výmaz dle GDPR, minimální nezbytný standard dle HIPAA, rozsah údajů o držitelích karet dle PCI-DSS a inventář spotřebitelských dat dle CCPA se vztahují na obě vrstvy stejnou měrou. Žádost o přístup k údajům subjektu údajů dle GDPR vyžaduje inventář všech PII uchovávaných o konkrétní osobě ve všech systémech, nejen v těch, které se připojují k datovému katalogu.
Inventář PII pro rozdělené pozůstalosti má tři složky, které musí fungovat společně:
Moderní datové inventáře , cloudové databáze, platformy SaaS, datové sklady, protokoly API a sdílené soubory jsou adresovatelné standardními nástroji pro vyhledávání PII. Nástroje v této kategorii vyhledávají vzory PII, klasifikují je podle předpisů a integrují se s platformami pro katalogizaci dat za účelem vytváření strukturovaných inventářů. IBM Guardium pokrývá strukturované databáze a mainframe databáze (DB2) s klasifikací řízenou politikami. Microsoft Purview pokrývá cloudové služby Microsoftu. BigID a Varonis pokrývají širší ekosystémy včetně nestrukturovaných dat.
Inventář starších dat , soubory VSAM, schémata DB2 sálových počítačů, pracovní úložiště programů v COBOLu a definice datových sad JCL vyžadují analýzu zdrojového kódu, aby se zjistilo, kde jsou definovány, uloženy a zpracovávány osobní údaje (PII). Tato analýza čte programy v COBOLu, aby pochopila, jaká data zpracovávají, nejen do jakých datových úložišť zapisují.
Inventarizace přeshraničních toků dat , tedy cesty, kterými se PII přesouvá ze starších systémů na moderní platformy, často prostřednictvím rozhraní plochých souborů, které neobsahují žádné schéma, vyžaduje trasování datové linie od zdroje COBOL přes toky úloh JCL až po koncové body, kde data dosahují připojitelných systémů. Plochý soubor, který každou noc opouští mainframe, není označen PII, dokud není schéma definující jeho rozvržení záznamů propojeno s definicemi sloupců cílové datové sady.
Organizace, které vytvářejí kompletní seznamy osobních údajů (PII), jsou ty, které řeší všechny tři složky. Organizace, které neuspějí v auditech GDPR nebo HIPAA, se často zabývají první složkou a předpokládají, že ostatní jsou pokryty.
Vzory PII specifické pro COBOL a jak je najít
Vzor 1: Přímé osobní údaje v záznamech FD a sešitech
Nejpřímější vzor PII v COBOLu: pole v položce FD nebo členu COPY, jehož název, typ nebo kontext jasně indikují PII. I při použití zkrácených konvencí pojmenování jsou určité vzory konzistentně přítomny:
cobol
01 CUSTOMER-RECORD.
05 CUST-ID PIC 9(10).
05 CUST-LAST-NM PIC X(30). *> Last name -- PII
05 CUST-FIRST-NM PIC X(20). *> First name -- PII
05 CUST-DOB PIC 9(8). *> Date of birth -- PII
05 CUST-SSN PIC 9(9). *> Social Security -- PII (HIGH SENSITIVITY)
05 CUST-ADDR-1 PIC X(40). *> Address line 1 -- PII
05 CUST-ADDR-2 PIC X(40). *> Address line 2 -- PII
05 CUST-CITY PIC X(25). *> City -- PII
05 CUST-STATE PIC X(2).
05 CUST-ZIP PIC 9(5). *> ZIP code -- potentially PII
05 CUST-PHONE PIC 9(10). *> Phone number -- PII
05 CUST-EMAIL PIC X(60). *> Email -- PII
Statická analýza identifikuje kandidátská pole PII pomocí kombinace porovnávání vzorů jmen (pole obsahující NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) a typovou analýzu (pole PIC X vhodné délky pro osobní údaje, pole PIC 9 vhodné délky pro rodné číslo nebo telefonní čísla). Výstupem je kandidátský inventář polí PII, který vyžaduje lidské ověření v nejednoznačných případech.
Vzor 2: Osobní údaje ve strukturách REDEFINES
Příkaz REDEFINES vytváří více interpretací stejného fyzického úložiště. Pole, které je v základní definici definováno jako úložiště generických dat, může v jedné ze svých variant REDEFINES obsahovat osobní údaje:
cobol
05 ACCT-DETAIL PIC X(120).
05 ACCT-PERSONAL REDEFINES ACCT-DETAIL.
10 ACCT-HOLDER-NM PIC X(40). *> PII in REDEFINES variant
10 ACCT-HOLDER-DOB PIC 9(8). *> PII in REDEFINES variant
10 ACCT-TAX-ID PIC 9(11). *> PII (EIN or SSN) in REDEFINES
10 FILLER PIC X(57).
05 ACCT-BUSINESS REDEFINES ACCT-DETAIL.
10 ACCT-BUS-NAME PIC X(60). *> Business name -- not personal PII
10 ACCT-REG-NO PIC X(20).
10 FILLER PIC X(40).
Rozsah osobních údajů ACCT-DETAIL nelze určit pouze z definice základního pole. Vyžaduje analýzu struktury REDEFINES, aby se určilo, která varianta obsahuje osobní údaje a které programy přistupují k osobní variantě oproti obchodní variantě. Skener, který profiluje pouze sloupec ACCT_DETAIL v cílové databázi nemá způsob, jak identifikovat obsah PII z definice sloupce, PII se nachází ve zdrojové struktuře COBOLu.
Vzor 3: PII sestavené v PRACOVNÍM ÚLOŽIŠTĚ
Programy, které sestavují PII z více zdrojů v WORKING-STORAGE před zápisem do výstupu, mohou vytvořit expozici PII, která se neobjevuje v žádné definici trvalého souboru:
cobol
WORKING-STORAGE SECTION.
01 WS-REPORT-LINE.
05 WS-CUST-NAME PIC X(50).
05 FILLER PIC X(2) VALUE SPACES.
05 WS-CUST-SSN PIC X(11). *> Formatted SSN: XXX-XX-XXXX
05 FILLER PIC X(2) VALUE SPACES.
05 WS-CUST-BALANCE PIC ZZZ,ZZZ,ZZZ.99.
PROCEDURE DIVISION.
MOVE CUST-LAST-NM TO WS-CUST-NAME
STRING CUST-SSN(1:3) '-' CUST-SSN(4:2) '-' CUST-SSN(6:4)
DELIMITED SIZE INTO WS-CUST-SSN
WRITE REPORT-RECORD FROM WS-REPORT-LINE.
Tento program vytvoří formátované číslo sociálního zabezpečení (SSN) v souboru WORKING-STORAGE a zapíše ho do souboru sestavy. Osobní údaje (PII) existují na dvou místech: ve zdrojovém souboru VSAM (který je zahrnut v klasifikaci PII souboru) a ve výstupním souboru sestavy, který nemusí být klasifikován jako soubor s PII, pokud není analyzován program v COBOLu, který jej zapisuje. WRITE REPORT-RECORD FROM WS-REPORT-LINE Příkaz je událost datové linie, která propojuje číslo sociálního zabezpečení zákazníka se souborem sestavy a je viditelná pouze v DIVIZI PROCEDURE.
Vzor 4: Osobní údaje v definicích datových sad JCL
JCL definuje datové sady, které programy čtou a zapisují. Příkaz JCL DD, který odkazuje na datovou sadu obsahující PII, je součástí datového toku PII, i když sama o sobě žádná data neobsahuje:
JCL
//CUSTPROC JOB (ACCT-001),'CUSTOMER PROCESSING'
//STEP01 EXEC PGM=CUSTUPDT
//CUSTMSTR DD DSN=PROD.CUSTOMER.MASTER.FILE,DISP=SHR
//CUSTOUT DD DSN=BATCH.CUSTOMER.EXTRACT.FILE,
// DISP=(NEW,CATLG),
// SPACE=(CYL,(10,5))
//CUSTLOG DD SYSOUT=*Soubor dat PROD.CUSTOMER.MASTER.FILE je v inventáři PII, protože program COBOL CUSTUPDT čte z něj a obsahuje záznamy o zákaznících. Datová sada BATCH.CUSTOMER.EXTRACT.FILE vyžaduje klasifikaci PII, protože CUSTUPDT zapisuje do něj zákaznická data. JCL je záznam datové linie, který propojuje zdrojovou datovou sadu s výstupní datovou sadou prostřednictvím programu, což je spojení viditelné pouze analýzou JCL spolu s programem, který JCL volá.
Mapování předpisů: Co každý rámec vyžaduje a kam se hodí starší data
Různé předpisy kladou různé požadavky na rozsah zjišťování osobních údajů:
GDPR (osobní údaje EU a EHP) vyžaduje, aby organizace vedly záznamy o činnostech zpracování (RoPA), které dokumentují veškeré zpracování osobních údajů obyvatel EU, kde jsou uloženy, za jakým účelem, na základě jakého právního základu a s jakou dobou uchovávání. Záznamy o činnostech zpracování v souladu s GDPR pro organizaci zpracovávající data zákazníků z EU na mainframe serveru vyžadují, aby se v záznamech o činnostech zpracování objevily soubory VSAM mainframe serveru, programy COBOL a pracovní postupy JCL, které s těmito daty nakládají. Právo na výmaz vyžaduje možnost identifikovat a smazat veškerá data o konkrétní osobě, což vyžaduje znalost všech míst, kde se data dané osoby objevují, včetně datových sad mainframe serverů, které jsou ve výrobě již třicet let.
Zákon HIPAA (US Protected Health Information - chráněné zdravotní informace USA) vyžaduje, aby dotčené subjekty a obchodní partneři chránili chráněné zdravotní informace (PHI), ať už existují kdekoli. Organizace, která zpracovává zdravotní informace na sálovém systému COBOL, záznamy o pacientech, údaje o pojistných událostech a záznamy o autorizaci, musí tento systém zahrnout do svého posouzení rizik HIPAA a rozsahu oznámení o narušení bezpečnosti. Aktualizace bezpečnostních pravidel HIPAA z roku 2025 zvýšily pozornost vymáhání informací týkajících se bezpečnostních kontrol starších systémů, čímž se inventář PHI pro starší systémy stal prioritou vyšší než v předchozích cyklech vymáhání.
Standard PCI-DSS v4.0 (data o držitelích karet) vyžaduje definované prostředí pro data o držitelích karet (CDE), které zahrnuje všechny systémy ukládající, zpracovávající nebo přenášející data o držitelích karet. Organizace, která zpracovává transakce platebními kartami prostřednictvím programu v jazyce COBOL běžícího na sálovém počítači, což popisuje architekturu zpracování transakcí většiny velkých bank a maloobchodníků, má v rámci svého CDE systém sálového počítače. Požadavek standardu PCI-DSS na skenování systémů v rozsahu působnosti pro nalezení dat o držitelích karet se vztahuje na komponenty CDE sálového počítače.
Zákon DORA (EU Digital Operational Resilience Act) pro finanční služby vyžaduje řízení rizik v oblasti IKT, které zahrnuje všechny systémy zapojené do kritických funkcí, se zvláštním zaměřením na rizika třetích stran a starších systémů. Systémy COBOL sálových počítačů finanční instituce, které zpracovávají transakce a uchovávají zákaznická data, spadají do rámce rizik DORA pro IKT, včetně požadavku na udržování aktuálního inventáře všech aktiv IKT podporujících kritické funkce.
Společným rysem je, že regulační požadavky na inventuru PII nemají výjimku pro „vyloučení starších systémů“. Data, která je nejhůře k nalezení, jsou také data, na která se regulační orgány budou ptát, když se něco pokazí.
Pracovní postup objevování-maskování-řízení
Zjišťování osobních údajů je prvním krokem v třístupňovém pracovním postupu pro dodržování předpisů:
Zjišťování identifikuje, kde se napříč všemi datovými úložišti, staršími i moderními, nacházejí osobní údaje. Výstupem je strukturovaný inventář: každé datové úložiště, každá datová sada, každé pole klasifikované jako obsahující specifické kategorie osobních údajů, s regulačními rámci, které se na každý nález vztahují.
Maskování chrání osobní údaje (PII) v neprodukčním prostředí, ve vývoji, testování a analytice, kde nejsou vyžadována úplná produkční data, ale struktura a objem dat ano. GDPR nařizuje, aby byly PII v neprodukčním prostředí chráněny pomocí technik, jako je anonymizace a pseudonymizace. Program pro vyhledávání, který identifikuje PII v souborech VSAM mainframe, umožňuje maskování, které nahrazuje skutečná zákaznická data syntetickými ekvivalenty v testovacích prostředích, ale pouze pokud byla pole PII správně identifikována v položkách COBOL FD a sešitech, které definují rozvržení záznamů.
Řízení a správa udržuje inventář PII v průběhu času a sleduje, kdy jsou přidány nové systémy obsahující PII, kdy jsou stávající PII data migrována nebo vyřazena z provozu a kdy regulační požadavky mění rozsah toho, co musí být inventarizováno. U starších systémů vyžaduje řízení a správa nejen pravidelné opakované skenování datových úložišť, ale také monitorování změn kódu, které vytvářejí nové expozice PII, program v COBOLu upravený tak, aby do výstupního souboru zapsal nové pole, úlohu JCL upravenou tak, aby zahrnovala novou datovou sadu, a změnu v sešitě, která přidá pole PII do existujícího rozvržení záznamu.
Z průzkumu State of Enterprise Data Compliance z roku 2026 vyplývá, že pouze 2 procenta organizací považují svá prostředí umělé inteligence za plně kompatibilní s předpisy, což platí i pro starší prostředí: dodržování předpisů oslabuje na hranici mezi tím, co standardní nástroje pokrývají, a tím, co ne. U většiny organizací tato hranice probíhá přesně podél obvodu staršího systému.
Jak SMART TS XL Podporuje vyhledávání osobních údajů (PII) ve starších prostředích
SMART TS XLRole `s v oblasti vyhledávání PII` spočívá ve vrstvě analýzy zdrojového kódu, což je krok předtím, než standardní nástroje pro vyhledávání PII mohou pracovat ve starších prostředích, a krok, který vytváří metadata, která tyto nástroje potřebují ke správné klasifikaci starších úložišť dat.
Funkce statické analýzy kódu analyzuje každou položku COBOL FD, člen COPY, klauzuli SELECT a PROCEDURE DIVISION, aby identifikovala kandidátská pole PII prostřednictvím analýzy vzorů názvů, analýzy typů a analýzy kontextu. Výstupem je inventář kandidátů PII na úrovni polí, každé pole, jehož název, typ, délka nebo kontext použití naznačuje, že obsahuje osobní údaje, uspořádané podle programu, datové sady a pole, s technickými metadaty COBOL (typ, délka, přesnost), která vyžadují nástroje pro následné maskování a klasifikaci.
Mapování závislostí aplikací vytváří mapu toku dat PII: každý program, který čte ze souboru VSAM obsahujícího PII, každý program, který zapisuje do následné datové sady, která dědí PII ze zdroje, a každý krok úlohy JCL, který vytváří nebo spotřebovává datové sady nesoucí PII. Tato mapa původu je inventářem toků dat napříč hranicemi, záznamem o tom, jak se PII pohybuje od svého původu na sálovém počítači přes transformační programy a toky úloh JCL, které je nakonec doručí do moderních systémů.
Funkce rozšíření JCL sleduje kompletní provozní kontext každé datové sady obsahující PII: které úlohy JCL na ni odkazují, v jakém pořadí, s jakými dispozičními kódy a které následné datové sady z ní úloha vytváří. U žádostí o právo na výmaz dle GDPR tato provozní mapa identifikuje každé místo, kam mohla být data konkrétního zákazníka zapsána v důsledku zpracování jeho zdrojového záznamu, včetně mezilehlých pracovních souborů, datových sad pro třídění a souborů sestav vytvořených během dávkového zpracování.
Funkce podnikového vyhledávání umožňuje dotazování v inventáři PII pro podporu žádostí o přístup k údajům a regulačních auditů: umožňuje najít každý program, který přistupuje k určitému poli, každou datovou sadu obsahující záznamy s konkrétní klíčovou hodnotou, každou úlohu JCL, která zpracovává konkrétní datovou sadu. Tato vyhledávací funkce transformuje inventář PII ze statického dokumentu do živého rozhraní pro dotazování, nástroje, který odpovídá na otázku „kde jsou data této osoby“ během hodin, nikoli týdnů.
Pro organizace provádějící starší modernizace programy, SMART TS XLAnalýza zjišťování PII je předpokladem pro dodržování předpisů: rozsah dodržování předpisů PCI-DSS, HIPAA a GDPR se rozšiřuje na citlivá data, jakmile opustí své původní prostředí. PII, které putují s migrovanými daty, musí být před migrací inventarizovány, během migrace chráněny a po migraci znovu ověřeny. Nemigrujete jen kód. Migrujete riziko.
Perimetr shody zahrnuje vše, co obsahuje osobní údaje
Regulační rámce upravující ochranu osobních údajů, GDPR, HIPAA, PCI-DSS, CCPA a DORA, byly napsány s univerzální působností. Vztahují se na osobní údaje kdekoli existují, bez ohledu na stáří systému, který je uchovává, bez ohledu na to, zda má tento systém moderní konektor, a bez ohledu na to, zda má datový katalog organizace k nim přístup.
Mezera ve vyhledávání PII informací ve starších prostředích není technickým omezením, které by regulační orgány přijímaly jako výmluvu. Jde o mezeru v dodržování předpisů, kterou donucovací opatření považují za neschopnost implementovat vhodná ochranná opatření, což je stejný standard, jaký platí pro moderní systémy, aplikovaný na systémy, které pro správný audit vyžadují odlišné metody vyhledávání informací.
Překlenutí této mezery vyžaduje uznání, že vrstva mainframe v podnikovém datovém komplexu uchovává značné množství osobních údajů (PII), že standardní nástroje pro vyhledávání k nim nemohou dosáhnout prostřednictvím standardních metod připojení a že analýza zdrojového kódu programů v COBOLu a toků úloh JCL, které tato data spravují, je přístup, který vytváří kompletní inventář. Kompletní vyhledávání napříč starší i moderní vrstvou není technickým cílem. Je to základní linie, podle které se hodnotí programy dodržování předpisů.
