Обезличивание персональных данных в тестовых средах: как сохранить пользу, а не путь к человеку

В тестовую среду приехала «почти безопасная» выгрузка

В пятницу команда передала подрядчику копию CRM для проверки нового обмена. В выгрузке уже нет ФИО, телефонов и паспортов. На первый взгляд всё правильно: прямые идентификаторы убраны, разработка не ждёт, интеграция проверяется на данных, похожих на реальные.

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

Именно поэтому в законе нет определения «скрыли имя». Статья 3 Закона № 152‑ФЗ называет обезличиванием действия, после которых без использования дополнительной информации нельзя определить принадлежность персональных данных конкретному субъекту. Здесь важны оба слова: «дополнительная информация» и «конкретному субъекту».

Для руководителя ИБ это не спор о терминах. Это вопрос о маршруте данных. Какие сведения попадут в тесты? Какие свойства должны сохраниться? У кого есть доступ к ключам, исходным системам, выгрузке и журналам? Как команда подтвердит, что выбранный метод достаточен именно для этого сценария? Пока на эти вопросы нет ответа, «обезличенная копия» — скорее название папки, чем проверяемый результат.

Что считается обезличиванием, а что — только удобной маской

Тестовые данные часто называют анонимными, обезличенными, замаскированными, синтетическими или токенизированными как взаимозаменяемые вещи. На практике это разные операции и разные остаточные риски.

Маскирование обычно заменяет видимое значение: например, показывает +7 999 ***‑**‑12 вместо телефона или скрывает часть номера документа. Это может быть правильным контролем на экране. Но оно не отвечает на вопрос, какие ещё признаки остались в записи, можно ли выгрузить исходное значение или сопоставить его по связанным таблицам.

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

Преобразованная копия меняет поля, состав, связи или порядок записей. В актуальном приказе Роскомнадзора № 140 закреплены требования и методы обезличивания для охватываемых им случаев. Для редакционного вывода важнее не перечислить названия методов, а увидеть его управленческую логику: оператор должен определить процедуру, применяемые методы и оценку их достаточности. Это несовместимо с ритуалом «запустили скрипт и забыли».

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

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

Международное техническое руководство NIST SP 800‑188 полезно здесь не как иностранная правовая норма, а как инженерное напоминание: удаление очевидных идентификаторов не завершает анализ. Нужно определить цель использования, рассмотреть пути раскрытия и проверять риск связи с человеком. Российскую правовую границу задаёт 152‑ФЗ; методическая часть помогает не подменить её одним фильтром в SQL.

Сначала определить, что тест на самом деле должен проверить

Слово «тестирование» слишком общее. Один и тот же набор данных может быть избыточным для smoke‑проверки и недостаточным для расчёта комиссии. Поэтому первая рабочая встреча должна начинаться не с вопроса «какие поля замаскируем», а с вопроса «какое наблюдаемое свойство должен подтвердить тест».

Обычно полезность тестовой копии складывается из нескольких свойств.

×

Рисунок 1. Метод выбирают после цели теста и списка свойств, которые должны сохраниться. Это авторская инфографика НТА по статье 3 Закона № 152‑ФЗ и приказу РКН № 140; она не является юридической консультацией.

Полезная формулировка для паспорта теста звучит конкретно: «проверить, что при частичной отмене заказа пересчитывается резерв и не возникает повторное списание». В ней есть сущности, переход, исключение и ожидаемый результат. Формулировка «нужна копия CRM, чтобы всё проверить» ничего не говорит о необходимых свойствах и почти всегда приводит к максимальной выгрузке «на всякий случай».

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

Прямые и квазиидентификаторы: путь к человеку редко лежит в одной колонке

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

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

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

×

Рисунок 2. Скрытое имя не исключает связь с субъектом: оцениваются и прямые, и квазиидентификаторы, и доступ к дополнительной информации. Авторская инфографика НТА по 152‑ФЗ, приказу РКН № 140 и приказу ФСТЭК № 21.

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

Матрица выбора: не один метод, а связка «цель — свойства — доступ»

Ниже не универсальный юридический шаблон, а рабочая карта для совместного решения ИБ, владельца системы, QA и владельца процесса. Её задача — заставить команду назвать компромисс до выгрузки.

Замена, изменение состава, разбиение связей или перемешивание — не кнопки с гарантированным результатом. Они полезны, когда понятно, какое свойство должно пережить преобразование. Например, для интеграции нужны стабильные связи между таблицами; для отчёта — распределения и границы; для нагрузки — объём и частота. Для визуальной проверки интерфейса обычно достаточно специально составленных сценариев.

Технический стандарт ISO/IEC 20889 описывает терминологию и методы деидентификации. Для руководителя ИБ переносимая польза этого подхода в том, что метод нельзя оценивать в вакууме. Один и тот же способ может быть хорош для статистического отчёта и плох для отладки сквозного процесса, потому что во втором случае разрушены связи. Или наоборот: устойчивый токен помогает интеграции, но сохраняет слишком удобную связь с исходником, если ключ доступен без барьера.

Почему токен — не готовый ответ

В проектах особенно часто возникает соблазн оставить постоянный заменитель: «у нас же не ФИО, а технический ID». Такой ID может быть необходим — иначе невозможно проверить, что клиент в одной системе соответствует клиенту в другой. Проблема начинается не с самого токена, а с его жизненного цикла.

Проверьте пять вопросов.

1. Как и где создаётся соответствие между исходным значением и токеном?
2. Может ли один пользователь, сервис или подрядчик одновременно прочитать тестовую копию и соответствие?
3. Попадает ли соответствие в резервные копии, логи, тикеты, файлы миграции или экспорт BI?
4. Нужна ли обратимость конкретному тесту или команда сохранила её «на всякий случай»?
5. Кто удалит ключ, копию и сопутствующие артефакты после завершения работ?

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

Такой подход согласуется с общей логикой приказа ФСТЭК России № 21: защита ПДн не сводится к одному преобразованию, а строится из организационных и технических мер, включая доступ и регистрацию действий. Приказ не даёт готовой архитектуры тестового контура, зато не позволяет считать технологическую операцию единственным уровнем контроля.

Синтетические данные: меньше связи, но не меньше ответственности за качество теста

Синтетика полезна там, где тесту не нужны реальные значения. Например, можно сгенерировать десять тысяч заказов с правдоподобными статусами, возвратами, регионами, корзинами и временными интервалами. Но «правдоподобно» не означает «случайные красивые числа».

У синтетического набора есть минимум четыре проверки полезности.

• Структурная. Схемы, типы, справочники и ссылки между сущностями валидны.
• Правил. Данные содержат допустимые и недопустимые комбинации, на которых должны сработать бизнес-правила.
• Распределений. Если отчёт или лимит зависит от диапазонов и частот, они заданы осмысленно, а не равномерным шумом.
• Исключений. В наборе есть дубли, отмены, частичные возвраты, задержки и ошибки формата, которые реально проверяют обработчики.

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

Паспорт тестовой выгрузки: минимальный артефакт, который можно проверить

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

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

Контрольный маршрут: от выгрузки до удаления

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

1. Разрешить цель. Владелец теста описывает проверяемое свойство и подтверждает, что без набора нельзя обойтись синтетикой или защищённым доступом.
2. Собрать минимальный состав. Команда исключает поля и вложения, не связанные с целью, до запуска выгрузки.
3. Преобразовать в контролируемом контуре. Исходный набор, правила и дополнительная информация не разъезжаются в личные папки и разовые скрипты без владельца.
4. Проверить связи. ИБ и технический владелец пробуют восстановить субъект по данным, которые реально доступны ролям тестового контура, а не по идеальной модели на бумаге.
5. Передать по ролям. Получатель видит только подготовленный набор и только на срок задачи; доступ, экспорт и повторная выдача учитываются.
6. Удалить и подтвердить. По окончании теста закрывают набор, таблицы соответствия, резервные копии, временные бакеты и вспомогательные артефакты настолько, насколько это применимо к архитектуре.

Приказ № 140 прямо делает важными процедуру и оценку достаточности; остальная часть маршрута — инженерная рекомендация, связанная с управлением доступом и жизненным циклом. Она не обещает «полное соответствие» сама по себе. Но она превращает разовую выгрузку в наблюдаемый процесс, в котором можно обнаружить лишнюю связь до того, как она станет инцидентом.

Для широкой картины доступа внутри систем пригоден разбор «DLP или контроль доступа к данным»: DLP контролирует передачу по каналам, а право на раскрытие внутри системы возникает раньше. В тестовой среде нужны оба вопроса: кто может увидеть подготовленный набор и можно ли вынести его дальше. Общий контекст последствий утечек собран в материале НТА об утечках персональных данных; здесь мы сознательно не повторяем статистику и штрафы.

Как проверить метод до того, как копия уйдёт в работу

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

Сначала проверить состав. Возьмите итоговую схему, а не список полей из постановки задачи. В реальных цепочках данные появляются в служебных атрибутах, JSON‑полях, вложениях, заголовках файлов, URL, очередях, логах ошибок и выгрузках аналитики. Если тесту нужен только статус заказа и дата события, файл с обращением в поддержку не должен попасть в копию потому, что его «проще выгрузить вместе с заказом».

Затем проверить сценарии сопоставления. Это не попытка взлома всей компании. Команда перечисляет источники, которыми располагает реальная роль получателя: боевой интерфейс, общая папка, резервная копия, мониторинг, журнал обмена, справочник, почтовый ящик или тикет. После этого она пробует ответить на вопрос: можно ли по этим доступным данным однозначно либо практически убедительно связать тестовую запись с человеком? Если да, уменьшают состав, меняют преобразование, отделяют дополнительную информацию или отказываются от выгрузки.

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

Проверить эксплуатационный след. Кто создал набор? Кто его получил? Куда он был передан? Где физически или логически хранится? Какой срок и владелец удаления назначены? Приказ РКН № 140 связывает деятельность по обезличиванию с локальными актами и оценкой достаточности. В ежедневной работе эта норма становится устойчивой только тогда, когда ответ на эти вопросы не ищут в переписке трёхмесячной давности.

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

Роли: кто принимает решение и кто не должен получать лишнее

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

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

• владелец процесса или продукта описывает решение, которое должен подтвердить тест, и принимает потерю несущественных деталей;
• технический владелец данных знает происхождение таблиц, скрытые поля, резервные копии и зависимости;
• QA или разработка формулируют свойства, редкие сценарии и критерии приёмки подготовленного набора;
• ИБ оценивает реальные пути доступа, роли, журналирование и срок жизни;
• юрист или privacy-функция проверяет применимость правового режима и локальных актов там, где это требуется.

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

Ошибки, которые выглядят как экономия времени

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

Вторая — хранить ключ соответствия рядом с токенами «чтобы быстро разбираться с дефектом». Это делает токенизацию удобной, но одновременно устраняет её главный организационный барьер. Если обратимость необходима, она должна быть явной привилегией и наблюдаемым действием, а не обычной функцией SQL‑пользователя.

Третья — удалять набор из одной базы и забывать о резервных копиях, временных корзинах, архиве CI, объектах S3‑совместимого хранилища, ноутбуках и тикетах. Полное техническое удаление в разных системах может идти по разным правилам, поэтому в паспорте важны не только команда delete, но и владелец, сроки и подтверждение согласно архитектуре.

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

Как выбрать первый пилот

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

У пилота должны быть две независимые метрики приемки. Первая — тестовая: набор позволяет пройти объявленные сценарии и обнаружить заранее выбранный класс дефектов. Вторая — контрольная: команда может описать источники дополнительной информации, доказать разделение ролей и закрыть созданные артефакты в срок. Если первая метрика зелёная, а вторая не проверялась, пилот доказал полезность, но не безопасность. Если вторая зелёная, а тест потерял нужные свойства, он доказал стерильность, но не ценность.

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

Где заканчивается техника и начинается решение организации

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

Поэтому плохая практика звучит так: «мы поставили продукт для маскирования, значит все тесты безопасны». Хорошая — так: «для этого сценария нам нужны именно такие свойства, мы выбрали такой метод, проверили такие пути к субъекту, ограничили такой доступ и знаем, когда удалим артефакты».

Если задача начинается со старой выгрузки, полезно не переносить её в новый инструмент автоматически. Сначала составьте карту того, что уже существует: dev-базы, QA-дампы, резервные копии, объектные хранилища, тикеты, логи интеграций, ноутбуки подрядчиков. Иногда главный риск находится не в свежей выгрузке, а в старом файле, который никто не считает частью тестового контура.

Для проверки публичных форм и cookies есть отдельный чек-лист 152‑ФЗ для сайта. Он отвечает на другое намерение: сбор и обработка данных посетителей сайта. В этой статье предмет уже после сбора — подготовка рабочих наборов для разработки, тестирования и сопровождения.

Тест понедельником

В понедельник утром попросите владельца ИБ, системного аналитика и руководителя тестирования вместе пройти один обычный маршрут: от запроса на копию до удаления после релиза.

Пусть каждый без подсказок ответит на пять вопросов:

1. Какой конкретный сценарий этот набор должен проверить?
2. Какие связи или распределения обязательны, а какие поля попали «на всякий случай»?
3. Где хранится дополнительная информация, способная связать запись с человеком?
4. Кто может одновременно получить тестовую копию и эту информацию, включая резервные копии и логи?
5. Кто подтвердит удаление набора и связанных артефактов после работы?

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

Если нужно разобрать одну фактическую цепочку подготовки тестовых данных — от источника до удаления — команда НТА поможет оформить критерии, контрольные точки и практический пилот. Решение DataSafe может стать частью такого контура, когда требуется управлять раскрытием значений, обезличиванием и журналированием внутри корпоративных систем; оно не заменяет юридическую оценку, DLP, IAM или процессные правила.

Важное уведомление

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