Обезличенные данные для тестового стенда: как с ними работать и что учесть?

Ужесточение законодательства в области персональных данных заставляет компании как можно более осторожно подходить к их использованию – даже если речь идет о внутреннем контуре компании. В то же время целый ряд IT-систем требуют тестирования на данных, которые максимально похожи на настоящие. Решением может стать использование обезличивание (маскирование) клиентских записей.

Какой подход к обезличиванию выбрать и какие моменты нужно учесть при подготовке тестового стенда, рассказывает Валентина Васильева, лид тестирования в IT-компании HFLabs.

Зачем обезличивать данные для тестов?

Когда тестируемая система работает с данными клиентов, то и тестировать ее нужно на аналогичных данных. Синтетические массивы тут не подойдут: сложно учесть все детали, которые встречаются в реальных персональных сведениях. Правило тут простое: чем ближе тестовые данные к реальным, тем качественнее тесты.

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

Как именно маскировать?

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

Возьмем, к примеру, наиболее подходящий для целей тестирования метод, в котором меняется состав и семантика данных. Достигается это несколькими способами.

Первый подход – заменить часть символов в ФИО и документах на «звездочки». При работе с таким массивом сразу очевидно, что данные обезличены – это плюс. Минус – меняется тип данных. Если в дате выдачи документа часть цифр превращается в «звездочки», то меняется и тип данных – с даты на строку. Из-за несовпадения типов БД такое изменение может не принять. Второй момент – популярные имена, города и отчества, даже со «звездочками», несложно расшифровать. И, наконец, такая замена убивает смысл данных: они теряют семантику, валидность, социально-демографические характеристики. Например, 89*******12 – это номер паспорта или номер телефона?

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

Третий подход – маскирование с сохранением формата данных и аналитических характеристик. В этом случае исходные данные заменяются на очень похожие. Например, при замене ФИО учитывается его популярность. Это значит, что Петр Петрович Иванов может быть заменен на Сергея Сергеевича Петрова, но никак не на Артемия Валерьяновича Великосветского. Дата рождения меняется на близкую, чтобы социально-демографические группы были сохранены. В адресе меняются улицы и номера домов, а страна, город и район остаются реальными. Номер паспорта меняется синхронно с датой рождения, чтобы данные прошли форматно-логический контроль.

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

Что важно для тестировщиков?

На что обратить внимание, если персональные данные обезличиваются для использования на тестовом стенде?

Качество и смысл данных – краеугольный камень. Тестировщикам, аналитикам и бизнесу нужно обсудить, какие характеристики данных должны быть сохранены при обезличивании и в каких сценариях эти данные будут использоваться. Например, чтобы не упустить адреса массовой регистрации, все одинаковые адресные записи в базе после маскирования должны остаться одинаковыми.

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

При консистентном обезличивании стоит подумать, а как работать с новыми данными в этих средах? Здесь есть два подхода. Первый – полностью маскировать заново все связанные системы (разные стенды и типы СУБД, файлы, текст). Второй – маскировать инкрементально, то есть «дообезличивать» изменения в уже обработанную ранее базу.

Форматы данных и процессы внутри

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

• Формат и маска. Допустим, в одной БД номера СНИЛС хранятся с дефисами. После обезличивания могут остаться только цифры, а дефисы пропадут. Для бизнеса это неважно, а вот для другой системы, которая интегрируется с этой БД, такое изменение может быть критичным. Отсутствие дефисов может стать причиной падения интеграций.
• Валидность объектов БД. В БД могут быть настроены разные процедуры и функции, которые завязаны на персональные данные. При обезличивании важно проверить, нет ли таких процессов в вашей БД и не повлечет ли изменение данных каких-либо проблем.
• Ссылочная целостность. Если в двух табличках меняются одни и те же данные, то изменения в них должны быть синхронными и совершаться по одной и той же логике.
• Спецсимволы. Интеграции могут быть чувствительными к определенным спецсимволам. Например, воспринять конкретные символы как экранирование или начало новой строки. Поэтому лучше спецсимволы не менять.
• Исключения. Обсудите, стоит ли добавить какой-то тип данных в исключения и не обезличивать их. Например, это могут быть технические учетки, маскирование которых приведет к невозможности аутентификации для интеграционного тестирования.

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

Рекомендации по работе с обезличенными данными

В завершение, короткие рекомендации для тех, кто работает с обезличенными данными – в тестировании и не только:

• следите за изменениями требований Роскомнадзора к обезличиванию данных;
• взаимодействуйте со службой ИБ: узнайте, что она считает чувствительными данными, которые стоит обезличить;
• обсудите со всеми заинтересованными сторонами – аналитиками, тестировщиками, маркетологами, что им важно сохранить в обезличенных данных.
• проработайте сценарии тестирования и определите, как вы будете соблюдать баланс между безопасностью данных и их качеством. Оценить безопасность обезличивания можно с помощью независимых инструментов – например, риск-модели, разработанной в Ассоциации больших данных;
• на постоянной основе мониторьте изменения бизнес-сценариев и модели данных;
• решите, как будете в долгую работать с обезличенными данными и что будете делать, когда процессмаскирования нужно будет повторить.