Когда для разработки нужны данные о людях, возникает выбор: взять их из рабочей системы, изменить существующие записи или создать новые. Синтетические данные и анонимизация — два разных ответа на этот вопрос, и между ними есть ещё два подхода, которые часто путают с ними. Разница принципиальная: один набор относится к реальным людям, другой — нет, и от этого зависят и риски, и пригодность данных для конкретной проверки.
Четыре подхода и чем они отличаются
| Подход | Что делают | Связь с человеком | Для чего годится |
|---|---|---|---|
| Синтетические данные | Создают записи с нуля по правилам страны | Отсутствует | Любые тесты, в том числе публичные наборы |
| Анонимизация | Удаляют возможность связать запись с человеком | Утрачена | Аналитика и статистика |
| Псевдонимизация | Заменяют прямые признаки, сохраняя ключ | Сохраняется через ключ | Проверки, где нужна близость к реальности |
| Маскирование | Скрывают часть значения при отображении | Сохраняется в хранилище | Показ данных, журналы, снимки экрана |
Ключевой столбец — третий. Пока запись можно связать с конкретным человеком хотя бы через ключ или справочник, она остаётся персональными данными и подчиняется тем же требованиям, что и исходная. Только первый вариант снимает вопрос полностью, потому что синтетическая запись с самого начала никого не описывает.
Почему удаление имени — ещё не анонимизация?
Потому что имя — лишь один из признаков, по которым человека узнают. Запись без имени, но с точной датой рождения, редкой профессией, небольшим городом и названием организации часто указывает на одного человека точнее, чем фамилия. Достаточно сопоставить её с любым открытым списком, чтобы вернуть имя обратно.
Именно поэтому проверка анонимности не сводится к перечню удалённых полей. Смотреть нужно на то, сколько людей может соответствовать оставшемуся набору. Если запись выделяет одного человека из миллиона, она не анонимна, как бы она ни называлась в документации проекта.
Отдельный случай — почти-уникальные значения. Полная дата рождения встречается у очень многих, но полная дата вместе с почтовым индексом — уже у заметно меньшего числа людей. Каждое дополнительное поле сужает круг, и это сужение происходит быстрее, чем кажется интуитивно. Сочетание даты рождения, индекса и пола различает людей точнее, чем каждое из этих полей по отдельности, хотя порознь они встречаются у миллионов.
Может ли набор полей выдать человека?
Да, и чаще всего это происходит не злым умыслом, а соединением двух наборов. Записи, которые по отдельности ничего не раскрывают, при сопоставлении по общему полю превращаются в подробный портрет. Поле, по которому соединяются наборы, может быть самым безобидным: год рождения, регион, место работы.
Отсюда практический вывод для тестовых данных: чем меньше полей и чем они грубее, тем меньше риск. Набор, в котором рядом с датой рождения стоит точный адрес, город и место работы, — это уже почти карточка конкретного человека, даже если он собран из синтетических значений. Хорошая новость в том, что для большинства проверок такая точность не нужна вовсе.
Чем синтетический набор отличается от копии рабочего?
Копия рабочего набора — самый быстрый способ получить данные, похожие на настоящие, и самый рискованный. Она содержит записи конкретных людей, поэтому к ней применяются все требования защиты: ограничение доступа, срок хранения, учёт передач. Кроме того, копия быстро расходится с действительностью: в рабочей системе записи меняются каждый день, а вчерашняя выгрузка остаётся прежней, и проверки на ней со временем теряют смысл.
Синтетический набор устроен наоборот. Он создаётся под нужный случай и потому содержит ровно те сочетания, которые вы хотите проверить: длинное имя, дату на самом пороге, редкий формат адреса. Распространять его можно свободно, а расхождение с рабочей системой для него не недостаток, потому что он и не должен её повторять. Следить стоит только за разнообразием: набор из однотипных записей проверяет заметно меньше, чем кажется по числу тестов.
Какой подход выбрать для тестов?
Для проверки логики приложения синтетические данные почти всегда подходят лучше. Они описывают нужный случай — граничную дату, длинное имя, редкий формат адреса, — и при этом их можно свободно хранить, копировать и передавать. Никаких ограничений на распространение у них нет, потому что за ними не стоит никто.
Псевдонимизированный набор выбирают, когда важно, чтобы распределение значений напоминало рабочее: например, чтобы проверить производительность поиска на реальном разнообразии написаний. Такой набор полезнее, но требует тех же мер защиты, что и исходные данные, и потому редко бывает удобен для повседневной разработки.
Маскирование — это вообще не способ подготовки данных, а способ их показа. Оно уместно в журналах, отчётах и на снимках экрана, но не превращает рабочий набор в тестовый. Анонимизация как отдельный подход применяется там, где данные нужны для анализа, а не для проверки конкретных сценариев. Подробнее про требования к таким наборам рассказано в статье про GDPR и тестовые данные.
Синтетические данные в генераторе
В генераторе данных личности записи создаются по правилам выбранной страны: имя, дата рождения, номер документа, адрес и контакты собираются вместе и остаются согласованными между собой. Ни одна из записей не получена из чьих-либо сведений и не связана с человеком. Один и тот же ключ личности возвращает ту же самую запись, поэтому набор можно закрепить и воспроизводить в разных тестах.
Всё, что генерирует сервис, — это вымышленные значения для тестирования; совпадения с реальными людьми случайны, а сами данные не годятся для того, чтобы кого-то выдать за человека или пройти проверку личности.
Что важно разработчику: воспроизводимость и распределение
Первое — воспроизводимость. Набор, который меняется от запуска к запуску, мешает отладке, поэтому записи стоит фиксировать ключом или сохранять в репозитории. Как устроены такие наборы, разобрано в статье про фикстуры с тестовыми данными.
Второе — распределение. Синтетические значения не обязаны повторять реальные пропорции, но и не должны быть слишком однообразными: если все имена короткие, а все адреса простые, тесты не увидят вёрстку и проверки, которые ломаются на длинных и редких записях. Полезно сознательно добавлять небольшое число нетипичных образцов.
Третье — доказуемость. Хорошо, когда можно показать, что в наборе нет реальных данных: он создан генератором, ключи записаны рядом с тестами, исходных выгрузок нет. Это простой и убедительный аргумент, который не требует разбирать каждую запись отдельно.
Четвёртое — не смешивайте подходы. Набор, в котором синтетические записи перемешаны с псевдонимизированными, наследует все ограничения второго, а выгоду даёт редко. Если такие данные нужны для отдельной проверки, лучше держать их отдельно и не переносить в общий набор.
Пятое — храните связь между назначением набора и его происхождением. Если через полгода никто не сможет сказать, откуда взялся файл с записями, набор придётся считать потенциально содержащим реальные данные и обращаться с ним соответственно. Короткая пометка о происхождении — самая дешёвая мера из всех перечисленных, и самая первая, которую забывают.
Что делать дальше
Пройдитесь по своим наборам и отнесите каждый к одной из четырёх категорий. Для наборов второго и третьего типа проверьте, есть ли они в тестовой среде вообще и нужны ли они там. Для новых проверок собирайте синтетические записи с нужными граничными случаями и фиксируйте их ключом — начать можно в генераторе, выбрав страну и посмотрев, какие поля приходят вместе с ней.