В современном мире объемы данных растут экспоненциально: компании ежедневно генерируют и обрабатывают огромные массивы информации — от реляционных баз данных и текстовых документов до изображений, аудио и видео. С этим ростом усложняется и защита информации, особенно в отношении чувствительных сведений: персональных данных сотрудников и клиентов, финансовой информации, корпоративных документов и других конфиденциальных материалов.

Традиционные методы обнаружения и классификации информации, основанные на формальной экспертизе и регулярных выражениях, демонстрируют ограниченную эффективность: они неплохо работают для стандартных форматов, таких как email-адреса и банковские карты, но могут не покрывать с должной полнотой обнаружение в реальных сценариях.

На помощь приходит машинное обучение, позволяющее автоматизировать процесс классификации, учитывать контекст и работать с разными источниками информации.

Меня зовут Вадим Безбородов. Мы c Максимом Митрофановым в департаменте Data science & ML в Positive Technologies занимаемся исследованием и внедрением машинного обучения в продукты компании. В этой статье расскажем о наших исследованиях и внедрении ML-модуля поиска и классификации чувствительных данных в PT Data Security.

Бизнес-потребность: усилить экспертизу продукта 

PT Data Security – наш новый продукт, MVP мы представили осенью 2024, и с тех пор команда активно развивает решение, насыщая его экспертизой и новыми функциями. Словом, сейчас идет подготовка к выпуску версии для первых пилотных внедрений.

Продукт предназначен для инвентаризации и классификации информации, анализа рисков и мониторинга обращений к данным, лежащим в БД, в файловых, объектных и других хранилищах клиента, для соответствия законодательным и индустриальным требованиям по их защите. В рамках MVP продукт использовал регулярные выражения и формальную логику, чтобы находить и определять чувствительные/конфиденциальные/персональные данные.

Основное ограничение формальных методов заключается в том, что качество обнаружения классов зависит от культуры хранения данных клиентом, например:

• Встречаются неинформативные названия колонок: col1, value, field123, которые затрудняют классификацию.

• Попадаются смешанные данные: одна ячейка таблицы может содержать несколько типов.

• Множество шумов и пропусков.

• Так называемая эволюция хранимых данных: формат данных может меняться со временем, например, ФИО, которые были записаны латиницей, теперь записаны кириллицей.

• Содержание сокращенных записей или комбинирование нескольких форматов.

• Опечатки.

Поэтому возникла гипотеза о том, что использование ML для обнаружения и классификации поможет решить эти проблемы, позволив не только увеличить число сущностей (классов данных), но и уменьшить количество ложных срабатываний на уже имеющихся.

Оценка начального состояния данных

Специфика данных клиентов

Прежде всего мы сосредоточились на текстовых данных как на наиболее распространенном формате представления информации. Документы (договоры, отчеты, письма), переписка (электронная почта, чаты), записи в базах данных, логи систем, инструкции, описания процессов и пути в файловых хранилищах — все это текст.

Таким образом, мы выделили два основных формата:

• Структурированные данные — информация, организованная в виде таблиц.

• Неструктурированные данные — произвольные тексты (документы, переписка, логи, отчеты и др.), в которых чувствительная информация может находиться в свободной форме без четкой структуры.

Прежде чем приступить к разработке решения, мы изучили, как именно хранятся и используются данные в реальности. В этом нам помогла программа «Ранние ПТашки», благодаря которой мы глубже изучили организацию баз и систем хранения данных в компаниях разных отраслей.

Ранние ПТашки — программа раннего тестирования PT Data Security 

Так, анализ текстовых данных в файловых хранилищах показал, что структурированные данные — это не всегда реляционные БД. В некоторых случаях это полуструктурированные файлы формата XLSX или CSV, что важно учитывать при дальнейшей проработке вопроса классификации.

Кроме того, в инфраструктуре могут находиться и базы данных, развернутые для разных целей: одни обслуживают самописные приложения заказчиков, другие — CRM-системы отделов, связанных с бухгалтерией, документооборотом, юристами. Каждая из таких баз данных может иметь десятки или сотни таблиц.

Особенности структурированных данных

При работе с табличными данными мы выделили три ключевые категории колонок:

1. Структурированные колонки (примитивы): содержат данные с четкой структурой (например, email, ФИО, номер телефона или их комбинация).

2. Полуструктурированные и неструктурированные колонки: свободный текст без жесткой структуры (отчеты, комментарии, JSON-логи, HTML/XML и прочее).

3. Идентификаторы: первичные и внешние ключи, уникальные ID.

Вот пример содержимого одной из таких колонок, которое мы обнаружили, несмотря на предположение о том, что в таблицах хранятся данные с четкой структурой:

{

    "request": {

        "order_id": 987654321,

        "customer": {

            "customer_id": 474280,

            "name": "Иван Иванов",

            "email": "example@example.com",

            "address": {

                "street": "ул. Ленина, д. 9999",

                "city": "Санкт-Петербург",

                "postal_code": "199999",

            },

        },

        "order_details": [

            {

                "product_id": 4567,

                "product_name": "Ноутбук",

                "quantity": 1,

                "price_per_unit": 55000,

                "total_price": 55000,

            },

            {

                "product_id": 7890,

                "product_name": "Мышь беспроводная",

                "quantity": 2,

                "price_per_unit": 1500,

                "total_price": 3000,

            },

        ],

        "order_total": 58000,

        "payment_status": "Paid",

        "shipping_status": "Dispatched",

        "order_date": "2025-03-07",

    },

    "time_request": "2025-03-07T13:55:43+03:00",

    "response": {

        "result": True,

        "code": 200,

        "message": "Order successfully processed.",

        "token": "abcdef1234567890",

    },

    "time_response": "2025-03-07T13:56:03+03:00",

}

Особенности неструктурированных данных

Неструктурированные данные представляют дополнительную сложность, поскольку чувствительная информация в них: 

• Разбросана по всему документу — данные могут встречаться в разных частях текста без явной структуры.

• Может быть неоднозначной — одно и то же слово может иметь разные значения в зависимости от контекста (например, «Владимир» может означать как имя, так и город).

• Требует понимания естественного языка — для точного обнаружения необходимо анализировать контекст, а не просто искать совпадения по шаблонам.

Наше исследование позволило определить, какие классы чувствительной информации следует искать, какие особенности учитывать и с какими вызовами нам придется столкнуться.

Кроме того, команда экспертизы ИБ продукта PT Data Security сформулировала онтологию текстовых данных, в рамках которой продукт на текущем этапе должен покрывать два класса: ПДн и IT Info. Для каждого из классов были сформулированы сущности/примитивы, которые должны покрываться регулярными выражениями и машинным обучением. На первой итерации ML-проекта мы сфокусировались на ПДн.

• Персональные данные (ПДн) — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу.

• IT Info (информация об ИТ-ресурсах) — информация, связанная с информационными системами, их конфигурациями, учетными записями и доступом к ним.

Ограничения формальных решений

Чтобы определить ключевые области применения машинного обучения, мы составили список сущностей ПДн и подготовили отложенный набор размеченных данных, который содержит тексты на русском и английском языках. На этом наборе оценивали возможности регулярных выражений в выявлении чувствительной информации.

Метрики оценки качества

Нам важно следить за тем, сколько действительно чувствительных данных мы обнаруживаем, — это показатель полноты (Recall). Однако важно не только находить как можно больше чувствительных данных, но и избегать ошибок, когда система ошибочно помечает безопасные данные как чувствительные (ложные срабатывания), что относится к показателю точности (Precision).

Это важно, поскольку увеличение доли ложных срабатываний приводит к росту числа рисков и инцидентов. Это может как перегрузить систему, так и создать лишнюю когнитивную нагрузку на ее пользователей.

Таким образом, нужно обеспечивать высокую полноту, при этом минимизируя количество ложных срабатываний, чтобы повысить общую ценность продукта и обеспечить максимальную автоматизацию. Для этого существует метрика F1, которая взвешивает Precision и Recall.

При расчете метрик мы используем подход макроусреднения (macro). Это позволяет равномерно учитывать вклад каждого класса в общий результат и избежать смещения в сторону доминирующего класса. 

Результаты сканирования

Чтобы оценить, насколько точно регулярные правила справляются с обнаружением и классификацией персональных данных, мы использовали результаты сканирования трех решений (коммерческих и open-source): все они используют для поиска и классификации данных регулярные выражения и формальную экспертизу.

Стоит также отметить, что классификация подразделяется на два вида:

1. По содержимому.

2. По наименованиям колонок (метаданным).

Это важно, поскольку разные вендоры используют один из методов или гибридный подход, что отмечено на всех графиках.

И в дополнение к информации о датасете: он состоит из более чем 3000 колонок (более 300 тыс. ячеек в совокупности) таблиц БД, в которых учтены все особенности представления данных, описанные выше.

Где:

• PII — тип персональной информации (сущности из таблицы 1)

• TP — True Positive = верно распознанные сущности

• FN — False Negative = пропущенные сущности

• FP — False Positive = ошибочно найденные сущности

Исходя из полученных результатов, можно сделать следующие выводы:

Вендорские решения и их регулярные выражения успешно справляются только с сущностями: EMAIL и IBAN. Для остальных типов — результаты оказываются менее удовлетворительными.

Это связано как минимум c:

• ограниченной применимостью шаблонов — регулярные выражения не могут охватить все возможные вариации данных, особенно если речь идет о свободно записываемых сущностях (например, ФИО, названиях организаций и пр.).

• высоким риском ложных срабатываний — случайные числовые последовательности могут быть ошибочно интерпретированы как номера телефонов (как у Вендора 1).

• нестабильностью в обработке редких или нестандартных форматов — нестандартные представления данных могут не соответствовать предопределенным шаблонам, что ведет к их пропуску в процессе классификации.

Несмотря на эти нюансы, регулярные выражения должны оставаться сильной и важной частью системы и использоваться как дополнительный инструмент для повышения точности классификации.

Применение машинного обучения для классификации данных

В экспериментах с моделями машинного обучения мы решили исключить те классы, которые уже успешно обрабатываются регулярными выражениями, и сосредоточились на следующих: PERSON, PHONE_NUMBER, ORGANIZATION, DATE, LICENSE_PLATE.

Подходы

Мы рассмотрели несколько методов, применимых к поиску и классификации чувствительных данных.

CASSED: Context-based Approach for Structured Sensitive Data Detection

Для успешного обнаружения чувствительной информации в табличных данных важно не только корректно интерпретировать отдельные значения полей, но и учитывать контекст соседних ячеек (Рис. 2 — ML CASSED). Один из таких подходов описан в статье CASSED: Context-based Approach for Structured Sensitive Data Detection. В ней рассматриваются проблемы обнаружения чувствительных сведений в БД и предлагается метод, позволяющий классифицировать данные на уровне целых столбцов.

Ключевая идея CASSED заключается в формировании контекста колонки: берутся метаданные и сами значения ячеек, а затем они объединяются в один вход для модели BERT. Это дает возможность одновременно анализировать несколько ячеек этой колонки и присваивать ей одну или несколько сущностей. Таким образом достигается более точная классификация, поскольку учитываются не только отдельные значения, но и их взаимосвязи и общая структура данных.

Named Entity Recognition (NER)

Распознавание именованных сущностей — классическая задача в области естественного языка. Ее суть заключается в том, чтобы искать и классифицировать отдельные фрагменты любых текстов, что позволяет применить идею как к структурированным, так и к неструктурированным данным.

Сравнение ML-моделей

Мы решили сравнить два описанных подхода на отложенном наборе данных, который также использовался для сравнения формальных решений.

Можно сразу отметить, что NER отрабатывает лучше CASSED, несмотря на то что второй проектировался специально под кейсы чувствительных данных в БД. 

Мы также разобрали в деталях, как подходы работают в контексте неструктурированных столбцов, поскольку это тот тип колонок, который не встречался в обучающих выборках, и результаты моделей на этих колонках могут говорить об обобщающей способности. В наборе данных были примеры json’ов (мы показали один из них в самом начале). По сущностям были представлены действительно единичные кейсы на уровне ячеек, и, что самое важное, — NER-модель смогла проявить себя и сделать уникальные детекты, в то время как CASSED не обнаружил ни одного класса в тестовой подвыборке такого формата.

Результаты

Формальные методы полезны, когда мы говорим о сущностях, которые имеют четкие паттерны и низкую вариативность. В случаях, когда персональная информация представлена в произвольном текстовом виде (ФИО, даты, названия организаций), регулярные выражения и четкий поиск подстрок ограничены своей жесткостью: любое отклонение от заранее заданного формата (например, пробелы в номере карты или необычное написание даты) приводит к пропуску данных. 

ML-классификация столбцов CASSED, в свою очередь, применима к структурированным данным и не учитывает отдельные разнородные записи внутри одной таблицы, однако является более производительным решением с точки зрения скорости обработки табличных данных. Кроме того, одним из негативных факторов, который мы не затронули в этой статье, являются слабые показатели для русского языка. С учетом специфики рынка продукта такое решение не подходит для внедрения. 

ML-подход на основе NER же универсален: он позволяет распознавать сущности в любых текстах, включая таблицы и неструктурированные данные, хорошо работает как на русском, так и на английском языках. Также этот подход по сравнению с CASSED тfребует меньше данных для дообучения модели. Кроме того, мы можем получать границы подстроки с чувствительной информацией, что позволит нам в дальнейшем развить функциональность продукта, добавив анонимизацию.

Решение на основе NER будет доступно пользователям после выхода версии PT Data Security, предназначенной для первых пилотных внедрений. Следите за новостями.