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