Меню

GDPR и тестовые данные: персональные данные в разработке

GDPR и тестовые данные связаны напрямую: имя, номер документа, дата рождения и адрес остаются персональными данными где угодно, включая тестовую среду. Разбираем, что это значит на практике.

Опубликовано

  • GDPR
  • персональные данные
  • тестовые данные

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

Что считается персональными данными

Список шире, чем кажется на первый взгляд. В него попадает не только то, что прямо называет человека:

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

Отдельно стоит отметить, что персональными данные делает не формат, а возможность связать значение с человеком. Даже обезличенная строка, если она позволяет отличить одного человека от другого и узнать о нём что-то новое, может рассматриваться как относящаяся к нему. Именно поэтому копия рабочей базы, выгруженная «просто для тестов», — плохая идея, даже если в ней нет полных имён.

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

Почему тестовая среда не отменяет требования?

Тестовая среда — это то же хранилище, с теми же рисками утечки и теми же последствиями для человека. Часто она защищена слабее: доступ к ней шире, копии раздаются разработчикам, резервные копии лежат дольше, а данные из неё свободно попадают в переписку и снимки экрана. В результате сведения оказываются доступны большему числу людей, чем в рабочей системе.

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

Чем псевдонимизация отличается от анонимизации?

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

Анонимизация означает, что связь утрачена безвозвратно и восстановить её нельзя ни при каких усилиях. Разница не в количестве удалённых полей, а в обратимости: если у вас есть ключ, справочник или достаточно подробная запись, чтобы вернуться к человеку, это псевдонимизация, как бы она ни называлась в документации.

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

Минимизация и сроки хранения

Два принципа, которые на удивление часто нарушают именно в тестовых наборах.

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

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

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

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

Как получить данные без реальных людей

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

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

Что важно разработчику: среды, журналы, снимки экрана

Первое — изоляция. Тестовая и рабочая среды не должны делить хранилище, а перенос данных между ними не должен быть обычной операцией «на всякий случай». Если перенос всё же нужен, он заслуживает отдельного решения, а не привычки.

Второе — журналы и снимки экрана. Данные попадают в журналы приложений, в отчёты об ошибках, во вложения к задачам и в текст сообщений. Набор, который вы считаете тестовым, может оказаться в публичном обсуждении вместе с записями отладки. Проверьте, что попадает в журнал, и не печатайте значения полей целиком, если для отладки достаточно их наличия и длины.

Третье — маскирование не равно анонимизации. Замена букв на звёздочки уменьшает заметность, но не устраняет связь, если рядом остались регион, дата рождения и другие подробности. И четвёртое: не заводите собственное правило вместо оценки. Формулировки требований различаются от случая к случаю, а решение о том, какие данные допустимы в конкретном наборе, обычно требует участия человека, отвечающего за их защиту. Как такие наборы устроены технически, разобрано в статье про фикстуры с тестовыми данными.

Что делать дальше

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

Читать дальше

Статьи: Генератор данных личности и тестовых данных онлайн