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