В современном мире объемы данных растут экспоненциально: компании ежедневно генерируют и обрабатывают огромные массивы информации — от реляционных баз данных и текстовых документов до изображений, аудио и видео. С этим ростом усложняется и защита информации, особенно в отношении чувствительных сведений: персональных данных сотрудников и клиентов, финансовой информации, корпоративных документов и других конфиденциальных материалов.
Традиционные методы обнаружения и классификации информации, основанные на формальной экспертизе и регулярных выражениях, демонстрируют ограниченную эффективность: они неплохо работают для стандартных форматов, таких как 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-системы отделов, связанных с бухгалтерией, документооборотом, юристами. Каждая из таких баз данных может иметь десятки или сотни таблиц.
При работе с табличными данными мы выделили три ключевые категории колонок:
Структурированные колонки (примитивы): содержат данные с четкой структурой (например, email, ФИО, номер телефона или их комбинация).
Полуструктурированные и неструктурированные колонки: свободный текст без жесткой структуры (отчеты, комментарии, JSON-логи, HTML/XML и прочее).
Идентификаторы: первичные и внешние ключи, уникальные ID.
Вот пример содержимого одной из таких колонок, которое мы обнаружили, несмотря на предположение о том, что в таблицах хранятся данные с четкой структурой:
{
"request": {
"order_id": 987654321,
"customer": {
"customer_id": 474280,
"name": "Иван Иванов",
"email": "[email protected]",
"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 (информация об ИТ-ресурсах) — информация, связанная с информационными системами, их конфигурациями, учетными записями и доступом к ним.
Чтобы определить ключевые области применения машинного обучения, мы составили список сущностей ПДн и подготовили отложенный набор размеченных данных, который содержит тексты на русском и английском языках. На этом наборе оценивали возможности регулярных выражений в выявлении чувствительной информации.
№ | Сущности | Описание | Примеры |
1 | PERSON | Любая информация, позволяющая прямо или косвенно идентифицировать конкретного человека по имени или ФИО | Иван Иванов |
2 | DATE | Любые даты в различных форматах (день/месяц/год, месяц/день/год и т. п.), включающие календарные даты, даты рождения, даты транзакций и пр. | 12.05.2021 2021-05-12 |
3 | PHONE_NUMBER | Номера телефонов в национальном или международном форматах, включая коды стран и городов, с добавочным номером или без | +7 (495) 123-45-67 8 800 555-35-35 |
4 | Электронные адреса в стандартном формате имени пользователя и домена (user@domain) | ||
5 | ORGANIZATION | Названия компаний, учреждений и организаций (государственных или коммерческих) | АО «Позитив Текнолоджиз» |
6 | IBAN | Международный номер банковского счета | DE89370400440532013000 |
7 | LICENSE_PLATE | Регистрационные номера транспортных средств | А123ВС 77 B202XT 98 |
Нам важно следить за тем, сколько действительно чувствительных данных мы обнаруживаем, — это показатель полноты (Recall). Однако важно не только находить как можно больше чувствительных данных, но и избегать ошибок, когда система ошибочно помечает безопасные данные как чувствительные (ложные срабатывания), что относится к показателю точности (Precision).
Это важно, поскольку увеличение доли ложных срабатываний приводит к росту числа рисков и инцидентов. Это может как перегрузить систему, так и создать лишнюю когнитивную нагрузку на ее пользователей.
Таким образом, нужно обеспечивать высокую полноту, при этом минимизируя количество ложных срабатываний, чтобы повысить общую ценность продукта и обеспечить максимальную автоматизацию. Для этого существует метрика F1, которая взвешивает Precision и Recall.
При расчете метрик мы используем подход макроусреднения (macro). Это позволяет равномерно учитывать вклад каждого класса в общий результат и избежать смещения в сторону доминирующего класса.
Чтобы оценить, насколько точно регулярные правила справляются с обнаружением и классификацией персональных данных, мы использовали результаты сканирования трех решений (коммерческих и open-source): все они используют для поиска и классификации данных регулярные выражения и формальную экспертизу.
Стоит также отметить, что классификация подразделяется на два вида:
По содержимому.
По наименованиям колонок (метаданным).
Это важно, поскольку разные вендоры используют один из методов или гибридный подход, что отмечено на всех графиках.
И в дополнение к информации о датасете: он состоит из более чем 3000 колонок (более 300 тыс. ячеек в совокупности) таблиц БД, в которых учтены все особенности представления данных, описанные выше.
Где:
PII — тип персональной информации (сущности из таблицы 1)
TP — True Positive = верно распознанные сущности
FN — False Negative = пропущенные сущности
FP — False Positive = ошибочно найденные сущности
Macro Precision | Macro Recall | Macro F1 | |
Вендор 1 | 0,4827 | 0,4416 | 0,4110 |
Вендор 2 | 0,9947 | 0,1504 | 0,2470 |
Вендор 3 | 0,5660 | 0,3632 | 0,4042 |
Исходя из полученных результатов, можно сделать следующие выводы:
Вендорские решения и их регулярные выражения успешно справляются только с сущностями: EMAIL и IBAN. Для остальных типов — результаты оказываются менее удовлетворительными.
Это связано как минимум c:
ограниченной применимостью шаблонов — регулярные выражения не могут охватить все возможные вариации данных, особенно если речь идет о свободно записываемых сущностях (например, ФИО, названиях организаций и пр.).
высоким риском ложных срабатываний — случайные числовые последовательности могут быть ошибочно интерпретированы как номера телефонов (как у Вендора 1).
нестабильностью в обработке редких или нестандартных форматов — нестандартные представления данных могут не соответствовать предопределенным шаблонам, что ведет к их пропуску в процессе классификации.
Несмотря на эти нюансы, регулярные выражения должны оставаться сильной и важной частью системы и использоваться как дополнительный инструмент для повышения точности классификации.
В экспериментах с моделями машинного обучения мы решили исключить те классы, которые уже успешно обрабатываются регулярными выражениями, и сосредоточились на следующих: PERSON, PHONE_NUMBER, ORGANIZATION, DATE, LICENSE_PLATE.
Мы рассмотрели несколько методов, применимых к поиску и классификации чувствительных данных.
Для успешного обнаружения чувствительной информации в табличных данных важно не только корректно интерпретировать отдельные значения полей, но и учитывать контекст соседних ячеек (Рис. 2 — ML CASSED). Один из таких подходов описан в статье CASSED: Context-based Approach for Structured Sensitive Data Detection. В ней рассматриваются проблемы обнаружения чувствительных сведений в БД и предлагается метод, позволяющий классифицировать данные на уровне целых столбцов.
Ключевая идея CASSED заключается в формировании контекста колонки: берутся метаданные и сами значения ячеек, а затем они объединяются в один вход для модели BERT. Это дает возможность одновременно анализировать несколько ячеек этой колонки и присваивать ей одну или несколько сущностей. Таким образом достигается более точная классификация, поскольку учитываются не только отдельные значения, но и их взаимосвязи и общая структура данных.
Распознавание именованных сущностей — классическая задача в области естественного языка. Ее суть заключается в том, чтобы искать и классифицировать отдельные фрагменты любых текстов, что позволяет применить идею как к структурированным, так и к неструктурированным данным.
Мы решили сравнить два описанных подхода на отложенном наборе данных, который также использовался для сравнения формальных решений.
ML/Metrics | Macro Precision | Macro Recall | Macro F1 |
CASSED | 0,7461 | 0,7569 | 0,7499 |
NER | 0,9017 | 0,9625 | 0,9293 |
Можно сразу отметить, что NER отрабатывает лучше CASSED, несмотря на то что второй проектировался специально под кейсы чувствительных данных в БД.
Мы также разобрали в деталях, как подходы работают в контексте неструктурированных столбцов, поскольку это тот тип колонок, который не встречался в обучающих выборках, и результаты моделей на этих колонках могут говорить об обобщающей способности. В наборе данных были примеры json’ов (мы показали один из них в самом начале). По сущностям были представлены действительно единичные кейсы на уровне ячеек, и, что самое важное, — NER-модель смогла проявить себя и сделать уникальные детекты, в то время как CASSED не обнаружил ни одного класса в тестовой подвыборке такого формата.
Формальные методы полезны, когда мы говорим о сущностях, которые имеют четкие паттерны и низкую вариативность. В случаях, когда персональная информация представлена в произвольном текстовом виде (ФИО, даты, названия организаций), регулярные выражения и четкий поиск подстрок ограничены своей жесткостью: любое отклонение от заранее заданного формата (например, пробелы в номере карты или необычное написание даты) приводит к пропуску данных.
ML-классификация столбцов CASSED, в свою очередь, применима к структурированным данным и не учитывает отдельные разнородные записи внутри одной таблицы, однако является более производительным решением с точки зрения скорости обработки табличных данных. Кроме того, одним из негативных факторов, который мы не затронули в этой статье, являются слабые показатели для русского языка. С учетом специфики рынка продукта такое решение не подходит для внедрения.
ML-подход на основе NER же универсален: он позволяет распознавать сущности в любых текстах, включая таблицы и неструктурированные данные, хорошо работает как на русском, так и на английском языках. Также этот подход по сравнению с CASSED тfребует меньше данных для дообучения модели. Кроме того, мы можем получать границы подстроки с чувствительной информацией, что позволит нам в дальнейшем развить функциональность продукта, добавив анонимизацию.
Решение на основе NER будет доступно пользователям после выхода версии PT Data Security, предназначенной для первых пилотных внедрений. Следите за новостями.