Бизнесу нельзя использовать данные клиентов 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 инстансах сервиса обезличивания. Поскольку решение масштабируемое, эти значения не являются пределом – мы остановили выбор на этих параметрах как на максимально удобных для нас. Ознакомиться с демо инструмента можно по ссылке. Дополнительное чтение в нашем блоге: Как системное мышление приводит на работу в ИТ из очень разных мест Что принципиально поменялось в ИБ Про интроскопы