Согласно отчету IBM «Стоимость утечки данных в 2025 году», средняя стоимость утечки составляет 4.44 миллиона долларов. Утечки, связанные с персональными данными, влекут за собой самые крупные штрафы в соответствии с GDPR и HIPAA, не потому что устранение последствий утечек персональных данных обходится дороже с технической точки зрения, а потому что регулирующие органы относятся к ним по-разному. Штрафы по GDPR могут достигать четырех процентов от годового дохода компании. Гражданские штрафы по HIPAA достигают 1.9 миллиона долларов за каждую категорию нарушений в год. Уязвимость организации в результате единичной утечки данных из системы, инвентаризация персональных данных которой была неполной, поскольку программа обнаружения, которая должна была ее обнаружить, охватывала только современный стек и останавливалась на границе мэйнфрейма, — это не проблема проектирования данных. Это регуляторный и финансовый риск, который стоит на повестке дня совета директоров.
Большинство организаций не могут по запросу получить полный перечень персональных данных. Стандартные инструменты обнаружения персональных данных, такие как Varonis, IBM Guardium, BigID, Microsoft Purview, Strac, отлично справляются со сканированием структурированных баз данных, облачных хранилищ, SaaS-платформ и файловых ресурсов. Они подключаются к тому, к чему могут подключиться. К тому, к чему не могут подключиться, они не могут сканировать. Файлы VSAM на z/OS не имеют коннекторов JDBC. Программы COBOL, которые хранят данные клиентов в рабочей памяти во время пакетной обработки, не предоставляют доступ к данным через API. Определения наборов данных JCL не регистрируются в каталоге данных. Уровень мэйнфрейма, который обрабатывает 95 процентов транзакций банкоматов и обрабатывает ежедневные операции на сумму около 3 триллионов долларов, является самым большим, наиболее насыщенным персональными данными и наиболее систематически недосканируемым уровнем в корпоративных системах данных. Вы не можете защитить то, что не можете найти, и большинство организаций не нашли всего этого.
Персональные данные, недоступные вашему каталогу.
SMART TS XL Отслеживает персональные данные от источника VSAM через программы COBOL до каждого последующего набора данных, который их наследует.
УЗНАТЬ БОЛЬШЕ…Почему анализ устаревших данных — самая сложная часть обнаружения персональных данных
Стандартная задача обнаружения персональных данных — поиск имен, адресов, номеров социального страхования и данных платежных карт, разбросанных по сотням баз данных и файловых ресурсов, — сложна, но решаема с помощью современных инструментов. Подходы к сопоставлению шаблонов, лежащие в основе большинства инструментов обнаружения персональных данных, хорошо работают со структурированными данными с доступными коннекторами: сканирование столбцов, применение регулярных выражений, пометка полей, соответствующих сигнатурам персональных данных, классификация и инвентаризация.
Устаревший слой вводит четыре свойства, которые нарушают подход сопоставления с образцом:
Сокращенные названия полей без семантического сигнала. В современных диалектах имена полей COBOL ограничены 30 символами, а в более старых языках программирования они обычно записывались в 8-символьной сокращенной форме. CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DTСканер для сопоставления образов, который идентифицирует social_security_number or customer_name поскольку индикаторы поля PII не имеют оснований для классификации SSN-NO or CUST-NM без понимания соглашений об именовании COBOL. Само соглашение об аббревиатурах является проблемой метаданных: поле содержит персональные данные, но его название не дает четкого представления об этом сканеру, разработанному для современных соглашений об именовании.
PII, встроенный в композитные структуры. В записях COBOL часто используется объединение нескольких элементов данных в одно поле или применение оператора REDEFINE для наложения различных интерпретаций на одни и те же байты. Например, поле в записи клиента. CUST-FULL-DATA определяются либо как PIC X(100) Может содержать имя, адрес и номер телефона, объединенные в одну строку с подполями фиксированного положения, структура, которая для любого сканера, считывающего только определение поля, без понимания логики программы, которая его заполняет и считывает, выглядит как одно непрозрачное текстовое поле.
Персональные данные передаются через рабочую память. Пакетные программы на COBOL часто считывают персональные данные из файлов VSAM, обрабатывают их в переменных рабочей памяти и записывают выходные данные в наборы данных. Персональные данные существуют в рабочей памяти во время выполнения, в памяти, а не в постоянном хранилище данных, и исчезают после завершения программы. Сканирование данных, сканирующее постоянное хранилище, обнаруживает источник VSAM и выходной набор данных, но не промежуточный этап обработки, где данные собираются, преобразуются и, возможно, записываются в журнал.
Персонально идентифицируемая информация (PII) пересекает границу ИТ/ОТ через интерфейсы плоских файлов. Данные клиентов, извлеченные из файлов VSAM мэйнфреймов, часто передаются в нижестоящие системы через интерфейсы плоских файлов, CSV-файлы, файлы записей фиксированной длины, файлы позиционного формата, которые не содержат метаданных столбцов. Плоский файл содержит PII в определенных байтовых позициях, но сканер, получающий файл, не имеет схемы для сопоставления позиций со значениями полей, если не анализируется также запись позиционного файла COBOL, определяющая структуру записи.
Проблема инвентаризации персональных данных в условиях разделенной интеллектуальной собственности.
Предприятие, использующее как устаревшие мэйнфреймовые системы, так и современные облачные платформы, сталкивается с проблемой инвентаризации персональных данных, которая охватывает два принципиально разных подхода к обнаружению. Современный уровень доступен для стандартных инструментов. Для устаревшего уровня требуется другой метод. Требования соответствия, право на удаление данных в соответствии с GDPR, минимально необходимый стандарт HIPAA, область действия данных держателей карт в соответствии с PCI-DSS, инвентаризация данных потребителей в соответствии с CCPA, в равной степени применимы к обоим уровням. Запрос на доступ к данным субъекта в соответствии с GDPR требует инвентаризации всех персональных данных, хранящихся о конкретном лице во всех системах, а не только в тех, которые подключены к каталогу данных.
Инвентаризация персональных данных при раздельном наследстве включает три компонента, которые должны работать согласованно:
Современные системы инвентаризации данных , облачные базы данных, SaaS-платформы, хранилища данных, журналы API и файловые хранилища, доступны для стандартных инструментов обнаружения персональных данных. Инструменты этой категории сканируют на наличие закономерностей в хранении персональных данных, классифицируют их в соответствии с нормативными требованиями и интегрируются с платформами каталогизации данных для создания структурированных инвентаризаций. IBM Guardium охватывает структурированные базы данных и базы данных мэйнфреймов (DB2) с классификацией на основе политик. Microsoft Purview охватывает облачные сервисы Microsoft. BigID и Varonis охватывают более широкие экосистемы, включая неструктурированные данные.
Для анализа устаревших данных , файлов VSAM, схем DB2 мэйнфреймов, рабочей памяти программ COBOL, определений наборов данных JCL, требуется анализ исходного кода, чтобы определить, где определяются, хранятся и обрабатываются персональные данные. Этот анализ включает чтение программ COBOL для понимания того, какие данные они обрабатывают, а не только какие хранилища данных они используют для записи.
Для отслеживания трансграничных потоков данных , путей перемещения персональных данных из устаревших систем на современные платформы, часто через интерфейсы плоских файлов, не содержащие схемы, необходимо прослеживать происхождение данных от источника COBOL через потоки заданий JCL до конечных точек, где данные попадают в подключаемые системы. Плоский файл, ежедневно покидающий мэйнфрейм, не помечается как содержащий персональные данные до тех пор, пока схема, определяющая структуру его записей, не будет связана с определениями столбцов целевого набора данных.
Организации, которые составляют полные перечни персональных данных, — это те, которые учли все три компонента. Организации, которые не проходят аудиты GDPR или проверки HIPAA, часто учитывают только первый компонент и предполагают, что остальные компоненты уже учтены.
Специфические для COBOL шаблоны PII и способы их обнаружения
Схема 1: Прямое указание персональных данных в записях FD и копибуках
Наиболее простой шаблон персонально идентифицируемой информации в COBOL: поле в записи дескриптора файла или члене COPY, имя, тип или контекст которого явно указывают на персонально идентифицируемую информацию. Даже при использовании сокращенных соглашений об именовании, определенные шаблоны присутствуют постоянно:
кобол
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
Статический анализ выявляет потенциальные поля, содержащие персональные данные, посредством сочетания сопоставления шаблонов имен (поля, содержащие NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) и анализ типов (поля PIC X соответствующей длины для персональных данных, поля PIC 9 соответствующей длины для номеров социального страхования или телефонных номеров). В результате получается список потенциальных полей, содержащих персональные данные, который требует проверки человеком в неоднозначных случаях.
Шаблон 2: Персональные идентификационные данные в структурах REDEFFINES
Функция REDEFINES создает несколько интерпретаций одного и того же физического хранилища. Поле, определенное как универсальное хранилище данных в базовом определении, может содержать персональные данные в одном из вариантов REDEFINES:
кобол
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).
Объем персональных данных ACCT-DETAIL Это невозможно определить только на основе базового определения поля. Для определения того, какой вариант содержит персональные данные и какие программы обращаются к личному варианту, а какие — к корпоративному, требуется анализ структуры REDEFINES. Необходим сканер, который анализирует только столбец. ACCT_DETAIL В целевой базе данных нет способа идентифицировать содержимое, содержащее персональные данные, по определению столбца; персональные данные хранятся в исходной структуре COBOL.
Шаблон 3: Персональные данные, собранные в рабочем хранилище.
Программы, которые собирают персональные данные из нескольких источников в рабочей памяти перед записью в выходной файл, могут создавать угрозу для персональных данных, которая не отображается ни в одном из определений постоянных файлов:
кобол
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.
Эта программа создает отформатированный номер социального страхования (SSN) в рабочей памяти и записывает его в файл отчета. Персональные данные (PII) находятся в двух местах: в исходном файле VSAM (который классифицируется как содержащий PII) и в выходном файле отчета, который не может быть классифицирован как содержащий PII, если не будет проанализирована программа COBOL, которая его записывает. WRITE REPORT-RECORD FROM WS-REPORT-LINE Это сообщение представляет собой событие, связывающее номер социального страхования клиента с файлом отчета, и отображается только в разделе «Процедуры».
Шаблон 4: Персональные данные в определениях наборов данных JCL
JCL определяет наборы данных, которые программы читают и записывают. Оператор JCL DD, ссылающийся на набор данных, содержащий персональные данные, является частью потока данных, содержащих персональные данные, даже если сам набор данных не содержит никаких данных:
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=*Набор данных PROD.CUSTOMER.MASTER.FILE включено в реестр персональных данных, поскольку программа COBOL CUSTUPDT Он считывает данные из него, и он содержит записи о клиентах. Набор данных BATCH.CUSTOMER.EXTRACT.FILE требуется классификация персональных данных, потому что CUSTUPDT Записывает в него данные о клиентах. JCL — это запись о происхождении данных, которая связывает исходный набор данных с выходным набором данных через программу; эта связь видна только при анализе JCL вместе с программой, которую вызывает JCL.
Сопоставление нормативных требований: что требует каждая система и каково место устаревших данных.
Различные нормативные акты предъявляют разные требования к объему обнаружения персональных данных:
GDPR (обработка персональных данных граждан ЕС и ЕЭЗ) требует от организаций ведения записей об обработке данных (Records of Processing Activities, RoPA), документирующих всю обработку персональных данных резидентов ЕС, где они хранятся, с какой целью, на каком правовом основании и с каким сроком хранения. Для организации, обрабатывающей данные клиентов из ЕС на мэйнфрейме, соответствующая требованиям GDPR запись RoPA должна содержать файлы VSAM мэйнфрейма, программы COBOL и потоки заданий JCL, обрабатывающие эти данные. Право на удаление данных требует возможности идентифицировать и удалить все данные о конкретном лице, что предполагает знание всех мест, где хранятся данные этого лица, включая наборы данных мэйнфрейма, находящиеся в эксплуатации в течение тридцати лет.
Закон HIPAA (Закон США о защите конфиденциальной медицинской информации) требует от организаций и их деловых партнеров обеспечивать защиту конфиденциальной медицинской информации везде, где она находится. Организация, обрабатывающая медицинскую информацию в мэйнфрейме на базе COBOL, медицинские карты пациентов, данные о страховых выплатах, записи об авторизации, должна включить эту систему в свою оценку рисков HIPAA и в сферу действия уведомления о нарушениях. Обновления Правил безопасности HIPAA 2025 года усилили внимание к мерам безопасности устаревших систем, что сделало инвентаризацию конфиденциальной медицинской информации в устаревших системах более приоритетной задачей, чем в предыдущих циклах правоприменения.
Стандарт PCI-DSS v4.0 (данные держателей карт) требует наличия определенной среды обработки данных держателей карт (CDE), которая охватывает все системы, хранящие, обрабатывающие или передающие данные держателей карт. Организация, обрабатывающая транзакции по платежным картам с помощью программы COBOL, работающей на мэйнфрейме (что описывает архитектуру обработки транзакций большинства крупных банков и розничных продавцов), имеет в своей CDE систему мэйнфрейма. Требование PCI-DSS о сканировании систем, входящих в область действия стандарта, на наличие данных держателей карт распространяется на компоненты CDE мэйнфрейма.
Закон ЕС о цифровой операционной устойчивости (DORA) для финансовых услуг требует управления рисками в сфере ИКТ, охватывающего все системы, задействованные в критически важных функциях, с особым вниманием к рискам, связанным с третьими сторонами и устаревшими системами. Системы COBOL на мэйнфреймах финансовых учреждений, обрабатывающие транзакции и хранящие данные клиентов, подпадают под действие системы управления рисками в сфере ИКТ DORA, включая требование поддерживать актуальный перечень всех ИКТ-активов, поддерживающих критически важные функции.
Общая черта: требования регулирующих органов к инвентаризации персональных данных не предусматривают исключений для «устаревших систем». Данные, которые сложнее всего найти, — это те же данные, которые регулирующие органы будут запрашивать в случае возникновения проблем.
Рабочий процесс обнаружения-маскирования-управления
Выявление персональных данных — это первый шаг в трехэтапном процессе обеспечения соответствия нормативным требованиям:
Программа Discovery выявляет наличие персональных данных во всех хранилищах данных, как устаревших, так и современных. Результатом является структурированный перечень: каждое хранилище данных, каждый набор данных, каждое поле, классифицированное как содержащее определенные категории персональных данных, с указанием нормативных требований, применимых к каждому обнаруженному факту.
Маскирование защищает персональные данные в непроизводственных средах, средах разработки, тестирования и аналитики, где полные производственные данные не требуются, но необходима структура и объем данных. GDPR требует, чтобы персональные данные защищались с помощью таких методов, как анонимизация и псевдонимизация, в непроизводственных средах. Программа обнаружения, которая идентифицирует персональные данные в файлах VSAM мэйнфрейма, позволяет использовать маскирование, заменяющее реальные данные клиентов синтетическими эквивалентами в тестовых средах, но только если поля с персональными данными были правильно идентифицированы в записях COBOL FD и копибуках, определяющих структуру записей.
Управление обеспечивает ведение учета персональных данных с течением времени, отслеживая добавление новых систем, содержащих персональные данные, миграцию или удаление существующих данных, а также изменения в объеме данных, подлежащих учету, в соответствии с нормативными требованиями. Для устаревших систем управление требует не только периодического повторного сканирования хранилищ данных, но и мониторинга изменений кода, которые приводят к новым утечкам персональных данных, модификации программы COBOL для записи нового поля в выходной файл, модификации задания JCL для включения нового набора данных, а также изменения структуры записи, добавляющего поле с персональными данными в существующую структуру записи.
Согласно результатам опроса «Состояние соответствия корпоративных данных требованиям законодательства в 2026 году», только 2% организаций считают свои среды ИИ полностью соответствующими требованиям, что в равной степени относится и к устаревшим средам: соответствие требованиям ослабевает на границе между тем, что охватывают стандартные инструменты, и тем, что они не охватывают. Для большинства организаций эта граница проходит точно по периметру устаревшей системы.
Как SMART TS XL Поддерживает обнаружение персональных данных в устаревших средах.
SMART TS XLРоль инструмента в обнаружении персональных данных заключается в анализе исходного кода, на этапе, предшествующем работе стандартных инструментов обнаружения персональных данных в устаревших средах, и на этапе, который создает метаданные, необходимые этим инструментам для правильной классификации устаревших хранилищ данных.
Функция статического анализа кода анализирует каждую запись дескриптора файла COBOL, член COPY, предложение SELECT и раздел PROCEDURE DIVISION для выявления полей, потенциально содержащих персональные данные, посредством анализа шаблонов имен, анализа типов и анализа контекста. Результатом является перечень полей, потенциально содержащих персональные данные, — каждое поле, чье имя, тип, длина или контекст использования указывают на то, что оно содержит персональные данные, — организованный по программам, наборам данных и полям, с техническими метаданными COBOL (тип, длина, точность), необходимыми для инструментов маскирования и классификации.
Карта зависимостей приложений строит карту потока данных, содержащих персональные данные: каждая программа, считывающая данные из VSAM-файла, содержащего персональные данные, каждая программа, записывающая данные в последующий набор данных, наследующий персональные данные от источника, каждый шаг задания JCL, создающий или обрабатывающий наборы данных, содержащие персональные данные. Эта карта происхождения представляет собой межсистемный инвентарь потоков данных, запись того, как персональные данные перемещаются от своего источника на мэйнфрейме через программы преобразования и потоки заданий JCL, которые в конечном итоге доставляют их в современные системы.
Возможность расширения JCL отслеживает полный операционный контекст каждого набора данных, содержащего персональные данные: какие задания JCL ссылаются на него, в какой последовательности, с какими кодами обработки и какие последующие наборы данных создаются заданием на его основе. Для запросов на удаление данных в соответствии с GDPR эта операционная карта определяет каждое место, где данные конкретного клиента могли быть записаны в результате обработки его исходной записи, включая промежуточные рабочие файлы, наборы данных для сортировки и файлы отчетов, созданные во время пакетной обработки.
Функция корпоративного поиска позволяет запрашивать данные из реестра персональных данных в рамках запросов на доступ к информации от субъектов данных и регуляторных проверок: находить каждую программу, обращающуюся к определенному полю, каждый набор данных, содержащий записи с определенным ключевым значением, каждое задание JCL, обрабатывающее определенный набор данных. Эта функция поиска превращает реестр персональных данных из статического документа в интерфейс оперативного запроса, инструмент, который отвечает на вопрос «где находятся данные этого человека» за часы, а не за недели.
Для организаций, осуществляющих модернизация наследия программы, SMART TS XLАнализ персональных данных, передаваемых в рамках миграции, является обязательным условием соблюдения требований: сфера действия стандартов PCI-DSS, HIPAA и GDPR распространяется на конфиденциальные данные, как только они покидают исходную среду. Персональные данные, передаваемые вместе с мигрированными данными, должны быть инвентаризированы до миграции, защищены во время миграции и повторно проверены после миграции. Вы переносите не просто код. Вы переносите риски.
Периметр соответствия включает в себя все, что содержит персональные данные.
Нормативно-правовые рамки, регулирующие защиту персональных данных (GDPR, HIPAA, PCI-DSS, CCPA, DORA), были разработаны с учетом универсального применения. Они распространяются на персональные данные везде, где они находятся, независимо от возраста системы, в которой они хранятся, независимо от наличия у этой системы современного коннектора и независимо от того, имеет ли каталог данных организации доступ к этим данным.
Проблема обнаружения персональных данных в устаревших системах не является техническим ограничением, которое регулирующие органы принимают в качестве оправдания. Это пробел в соблюдении требований, который в рамках правоприменительных мер рассматривается как несоблюдение надлежащих мер защиты, тот же стандарт, что и для современных систем, но для систем, требующих иных методов обнаружения для корректного проведения аудита.
Для устранения этого пробела необходимо признать, что мэйнфреймный уровень корпоративной информационной инфраструктуры содержит значительные объемы персональных данных, что стандартные инструменты обнаружения не могут получить к ним доступ через свои стандартные методы подключения, и что анализ исходного кода программ COBOL и потоков заданий JCL, управляющих этими данными, является подходом, позволяющим получить полный перечень информации. Полный поиск информации как на устаревшем, так и на современном уровнях — это не техническая цель. Это базовый уровень, по которому оцениваются программы соответствия требованиям.
