Бизнесу нельзя использовать данные клиентов as is для тестов. Отдел разработки не может просто взять персональные данные (ПДн) и проверить на них новую фичу, обучить Machine Learning-модель. Этот момент регулируют законы и отраслевые стандарты. Чтобы с данными можно было работать, их необходимо обезличить. В крупных компаниях сотни таблиц переплетены идентификаторами, формулами, процедурами. И здесь речь идет уже о формировании обезличенных интеграционных полигонов (комплексов БД). Максим Никитин, тимлид группы разработки, поделится опытом команды разработки платформы производства ПО «Сфера».
Что нужно обезличивать
Одна из причин неудачных запусков новых функций программного обеспечения (ПО) — отсутствие возможности провести тестирование в условиях, близких к реальным. Этому может мешать разница в качестве и количестве данных между тестовым и производственным стендами. Установить все возможные трудности на небольшом наборе записей проблематично. С ростом сложности системы количество возможных кейсов и ситуаций, когда что-то может пойти не так, растет по экспоненте. Чтобы улучшить ситуацию, нужно предоставить специалистам по тестированию среду с таким же объемом и разнообразием информации — то есть сделать копию базы в продакшн-среде и удалить из неё персональные данные.
Сделать это можно с помощью обезличивания. Главное — понять, какую информацию считать персональными данными. Согласно 152-ФЗ, персональные данные — это любая информация, которая относится к физическому лицу (или юридическому), в том числе его ФИО, дата и место рождения, семейное положение, образование, профессия и другая информация.
Сама по себе формулировка достаточно общая, и на её основе нельзя составить точный список атрибутов ПДн. Под категорию «другая информация» можно подвести практически что угодно. Да, есть очевидные идентификаторы — например, номер паспорта, ИНН, СНИЛС — но бывают и менее очевидные случаи.
Можно ли однозначно определить пользователя по месту его работы? Группу людей можно, но конкретное физическое лицо — нет. Но если к этой информации добавить дату рождения, профессию, семейное положение и количество детей? Каждый дополнительный атрибут сужает круг лиц, и в какой-то момент их станет достаточно для идентификации. Тогда комбинация атрибутов станет персональными данными.
Так, атрибуты ПДн можно разбить на две категории:
Прямой идентификатор — атрибут, позволяющий однозначно определить пользователя.
Косвенный идентификатор — атрибут, позволяющий определить пользователя только в сочетании с другими атрибутами.
Кроме ПДн есть и другая информация, которую необходимо обезличивать. Например, пароль учетной записи системы, ключи шифрования или список планируемых сделок компании. В таком контексте имеет смысл добавить третью категорию атрибутов — ценная информация. Они не относятся к физическому или юридическому лицу (прямо или косвенно), но их разглашение может нанести ущерб бизнесу.
Наш подход к поиску ПД
Начиная обработку данных, первым делом необходимо понять, а нужно ли вообще обезличивать данные? Этот шаг можно пропустить, если свод не содержит ПДн и коммерческие секреты, а потенциальная утечка не критична для заказчика (да, такое тоже возможно). В этом случае мы просто делаем копию имеющейся БД.
Если без обезличивания не обойтись, то нужно приступать к обработке данных. Первым делом необходимо найти чувствительные к утечкам записи, то есть провести профилирование. Очевидно, если база небольшая, то поиск персональных данных сводится к select’ам по каждой таблице. Но такой подход не работает на масштабе десятков тысяч таблиц. В этом случае используют регулярные выражения — применяют специальные паттерны для определения типа записей. Например, если поле называется CLIENT_NAME, значения содержат три слова с заглавной буквы, то с высокой долей вероятности — это ФИО.
Такой подход в целом работает, но не без проблем, одна из которых — скорость. Прогонять все значения каждой колонки через набор регулярных выражений довольно накладно по времени и ресурсам. Другая сложность заключается в низкой точности, поэтому результаты приходится перепроверять в ручном режиме. Примерно половина срабатываний регулярных выражений оказывается ложной. Первую проблему мы решили тем, что стали формировать выборку из непустых значений каждой колонки — по тысяче значений. Чтобы повысить точность классификации, обратились к алгоритму машинного обучения.
Для начала мы определили атрибутный состав данных, который будем классифицировать и обезличивать. Чтобы собрать размеченный датасет для обучения, мы написали сервис функционального профилирования данных, основанный на регулярных выражениях и простых алгоритмах классификации данных. Далее запустили его на срезах данных банковских информационных систем и получили первое приближение репрезентативной выборки. Затем последовал этап ручной валидации данных и нахождения ошибок классификации. В итоге мы получили качественный размеченный датасет для обучения.
Следующий этап — это проектирование метрик, описывающих отдельные характеристики объекта. Сложность состояла в эмпирическом подборе однозначно определяющих и исключающих параметров. Мы учитывали их пересечение и влияние на выделение конкретного подмножества атрибутов.
Поэкспериментировав с разными алгоритмами машинного обучения (МО) для задач классификации, в итоге мы остановились на Random Forest. На одну итерацию обучения уходили примерно сутки. Самым энергозатратным процессом было создание векторов данных для модели. Но в итоге точность и полнота выросли более чем на 40% по сравнению с функциональным профилированием и теперь превышают 90%. Переход на МО позволил минимизировать ручные проверки данных сотрудниками ИБ и сэкономить тысячи часов рабочего времени.
Как эти данные обезличить
Независимо от того для какой цели обезличиваются данные, они должны обладать одним свойством — из них должно быть невозможно восстановить исходные данные. Если речь идет о нагрузочном тестировании, то других требований к данным нет. В этом случае можно ограничиться такими алгоритмами, как замена на константу, удаление значения, размытие дат, замена по справочнику, хеширование. В конце концов данные можно просто сгенерировать, опираясь на список полей БД.
Для проведения функциональных тестов к качеству данных предъявляют больше требований. Например, номер ИНН должен остаться набором цифр той же размерности с валидным контрольным числом, а ФИО не должно превратиться в бессвязный набор символов. Также важно, чтобы после обезличивания сохранились внутренние и интеграционные связи между системами. Для этого алгоритмы должны обладать свойством «повторяемости», то есть одинаковые исходные значения должны превращаться в одинаковые обезличенные значения. Условно, «Ивановы» во всех таблицах должны стать «Петровыми».
Чтобы получить качественные данные на выходе, мы применяем алгоритм FPE — шифрование с сохранением формата — с понижением размерности алфавита и постобработкой. Берем используемый алфавит и вычисляем хеш-суммы всех его символов. Для этого используем AES-hash с неким ключом. Полученные хеш-суммы используем для сортировки символов и получения таблицы подстановки.
Однако есть проблема — зная ключ и алгоритм хеширования, можно полностью восстановить зашифрованные данные. Эту проблему мы решаем удалением из «целевого» алфавита части символов. Тогда шифрование становится шифрованием с потерей данных — то есть необратимым.
Другая проблема заключается в том, что схема FPE позволяет получить обезличенные и валидируемые данные, однако делает не читаемыми записи на выходе. Новые слова могут содержать по пять-шесть согласных букв подряд. Чтобы исправить ситуацию, мы добавили beautify-функцию, которая делает слова более приятными для слуха. Она заменяет идущие подряд гласные (согласные) буквы, для отдельных категорий данных сохраняет окончания, префиксы и так далее.
Чем обезличивать
Чем больше компания, тем большее количество информационных систем в ней используется. Тем более привлекательно выглядит идея выделить функцию поставки тестовых данных в отдельный сервис с универсальным инструментом обезличивания промышленных данных. Это позволит сотрудникам безопасности и тестирования найти точки контакта в подходах к работе с персональными и критическими данными.
Первым делом мы написали update-скрипты для каждой базы. Вариант рабочий только в том случае, если обезличивать планируется одну или несколько небольших баз. На масштабе поддержка таких скриптов становится накладной. Но главный их недостаток в производительности — операция update на таблицах со множеством записей выполняется слишком медленно. В итоге мы решили использовать ETL-процесс, который считывает данные с базы в продакшн, на лету модифицирует значения полей с критичной информацией и записывает результат в базу-приёмник.
По итогу мы разработали библиотеку универсальных наборов правил для обезличивания ПДн, инструменты формирования репрезентативной выборки и ее профилирования и автоматизированный ETL-инструмент, выполняющий обезличивание данных. Сегодня эти инструменты являются частью нашей платформы производства ПО «Сфера». Решения горизонтально масштабируются и не требуют разработки дополнительных скриптов или процессов. На сегодняшний день мы уже обезличили таким способом более 600 баз данных, средняя скорость обработки данных при этом составляет 2,5 - 3 ТБ в сутки при 50 инстансах сервиса обезличивания. Поскольку решение масштабируемое, эти значения не являются пределом – мы остановили выбор на этих параметрах как на максимально удобных для нас. Ознакомиться с демо инструмента можно по ссылке.
Дополнительное чтение в нашем блоге: