Как внедрить процесс обезличивания в пайплайн CI/CD: разбираемся на практике

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

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

Чтобы реальные данные всё-таки не попали в руки сторонних подрядчиков и вообще за контур организации, обезличивание нужно сделать обязательным и повторяемым процессом. Василий Жидков, директор по продукту ДатаСан, рассказывает специально для читателей Кибер Медиа, как правильно встроить его в пайплайн CI/CD — по шагам и с примерами.

Почему обезличивание должно быть частью CI/CD

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

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

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

Есть и менее очевидная причина — скорость разработки. Когда обезличивание не автоматизировано, подготовка тестовых данных превращается в отдельный проект: нужно попросить доступы, дождаться выгрузки, прогнать скрипты, проверить результат. Если процесс уже встроен в CI/CD, инженер может поднять среду или прогнать тесты в любой момент.

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

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

Кейс: как меняется жизнь команды после изменения пайплайна

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

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

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

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

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

Что сделали? В репозитории появился конфигурационный файл с правилами обработки данных: 

• какие поля маскируются;
• какие значения заменяются синтетическими;
• какие таблицы очищаются полностью. 

В пайплайне GitLab между этапами получения дампа продуктовой среды и развертывания тестовой среды появился отдельный stage anonymize_data.

Какие преимущества получили

Процесс превратился в последовательность автоматических шагов: получить актуальную копию, применить правила обезличивания, развернуть базу в тестовой среде и проверить результат. Весь цикл стал занимать около 40–50 минут.

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

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

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

В результате то, что изначально рассматривалось как мера комплаенса, превратилось в инструмент ускорения разработки и упрощения процессов. 

Внедряем обезличивание в пайплайн по шагам

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

Найти точки, где живут персональные данные

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

Первый шаг — пройти всю цепочку «от продуктовой среды до теста» и ответить на несколько простых вопросов:

1. Откуда тест сейчас берет данные? Это может быть прямая копия продуктовой среды, выгрузка через ETL-процесс, витрина из DWH, наборы из аналитического контура, или даже «выгрузили CSV и залили руками».
2. Попадают ли туда реальные идентификаторы людей и транзакционные следы? Иногда команда уверена, что работает «с агрегатами», а в витрине внезапно лежат email или номер телефона, потому что так удобнее объединять таблицы. 
3. Как часто и каким способом тестовая база обновляется? Раз в неделю вручную — это один риск-профиль. Ночью по расписанию автоматически — другой. Когда обновление автоматизировано, персональные данные могут попадать в тест регулярно и незаметно, и тогда обезличивание должно стоять на этом же автоматическом пути, а не «делаться иногда».
4. Где делаются бэкапы, и кто к ним имеет доступ? Бэкап — это почти всегда «вторая база данных» по ценности для атакующего, только с гораздо более слабой защитой. Бэкапы могут лежать в S3/MinIO, на файловых шарах, в артефактах CI, в старых папках «tmp», на машинах администраторов. Часто обнаруживается неожиданное: продуктивная база давно закрыта, а вот ее копии разошлись по нескольким местам, и доступ к ним есть у всех.
5. Какие задачи CI/CD запускаются поверх этих данных? Это не только автотесты, но и миграции схемы, генерация отчетов, индексация, прогон нагрузочных сценариев, выгрузки логов, сбор артефактов, создание копий для воспроизведения дефектов. Любой шаг пайплайна, который читает данные или сохраняет результаты наружу, потенциально может «утянуть» персональные поля в логи, отчеты или артефакты.

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

Детально описать сценарии обезличивания

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

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

Поэтому сценарии обычно описывают на уровне конкретных типов данных.

ФИО клиентов: 

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

Идентификаторы документов, налоговые номера, банковские карты:

• подбирать значения, корректные по формату; 
• если номер карты должен содержать корректную контрольную сумму, она должна быть рассчитана правильно; 
• сохранять маски ввода и визуальное форматирование.

Адреса:

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

Телефоны и электронная почта — отдельная категория, потому что они участвуют во внешних коммуникациях:

• важно исключить случайные отправки реальным людям: используем служебные диапазоны номеров, которые не привязаны к клиентам и не подключены к SMS-шлюзам;
• почтовые адреса переводят на технические домены вроде user+id@test.example.internal, которые физически не могут доставить письмо наружу.

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

Для реализации часто используют готовые библиотеки и инструменты: например, решения вроде db-anonymizer или генераторы синтетических данных на базе Faker. Они позволяют задавать правила на уровне типов данных и таблиц и хорошо подходят для встраивания в CI/CD.

Поставить обезличивание до попадания данных в тест

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

Если реальные данные хотя бы на короткое время попадают в тестовый контур, они начинают распространяться дальше по инфраструктуре. База попадает в резервные копии, снимки виртуальных машин и контейнеров, артефакты CI/CD, временные выгрузки для отладки. Даже если через несколько минут данные будут обезличены, оригиналы могут остаться в нескольких местах.

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

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

Надежный вариант строится вокруг промежуточного этапа подготовки данных. 

1. Создается копия продуктовой базы: например, резервная или снимок.
2. Эта копия попадает в изолированную зону, доступ к которой есть только у сервисных аккаунтов пайплайна.
3. Автоматически запускается процедура обезличивания. 
4. Только после завершения обработки подготовленная база передается в тестовую среду.

С точки зрения пайплайна это обычно выглядит примерно так:

backup_prod → anonymize_data → deploy_test

Этап anonymize_data становится обязательным шагом подготовки данных. Пока он не завершен успешно, тестовая среда не обновляется.

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

Встроить шаг в CI/CD как job/stage

Закрепляем обезличивание технически в правильном месте, чтобы процесс нельзя было обойти случайно или «временно». Самый рабочий способ — сделать обезличивание отдельной job, которая обязана завершиться успешно, прежде чем тестовая среда обновится.

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

В GitLab CI это выглядит примерно так: сначала делаем бэкап, затем прогоняем обезличивание, затем восстанавливаем базу в тесте. Обезличенная копия становится единственным артефактом, который допускается дальше по пайплайну.

stages:

  - backup_prod

  - anonymize_data

  - deploy_test

backup_prod:

  stage: backup_prod

  script:

            - ./scripts/backup_prod.sh

  artifacts:

            paths:

           - backups/prod_dump.sql

anonymize_data:

  stage: anonymize_data

  needs: [backup_prod]

  script:

            - anonymizer --input backups/prod_dump.sql \

                      --output backups/test_dump_anon.sql \

                      --config anonymizer_rules.yml

  artifacts:

            paths:

           - backups/test_dump_anon.sql

deploy_test:

  stage: deploy_test

  needs: [anonymize_data]

  script:

            - ./scripts/restore_to_test.sh backups/test_dump_anon.sql

Важно, что зависимость задается жестко: deploy_test физически не может стартовать, пока не завершился anonymize_data. Можно сделать еще строже: после anonymize_data удалять исходную копию или вообще не сохранять ее как артефакт, чтобы он не «гулял» по инфраструктуре.

Похожая логика переносится в любую систему CI/CD. В Jenkins это будет отдельный stage в pipeline, в GitHubActions — отдельный job с needs, в TeamCity — dependency между шагами. Суть не меняется: обезличивание становится обязательным промежуточным звеном.

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

Добавить регулярную проверку качества

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

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

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

2. Анализ того, что сам инструмент обезличивания рассказывает о своей работе. Хорошие процессы всегда оставляют следы: сколько строк и полей обработано, какие таблицы прошли по правилам, где правила не применились. Этот лог — по сути ваш «отчет качества». Например, в схему добавили поле contact_email, а правила про него забыли — инструмент либо не тронет поле, либо отметит его как неизвестный тип. Если вы регулярно смотрите такие отчеты, проблема ловится на первом же обновлении, а не на аудите через полгода.

3. Дисциплина обновления правил. Схема базы почти никогда не стоит на месте: появляются новые таблицы, поля меняют типы, меняются источники данных. Хорошая практика — пересматривать правила обезличивания всякий раз, когда меняется структура БД, и иметь быстрый способ обнаружить, что в обезличенной копии появилось «что-то лишнее». Это может быть и простая проверка наличия паттернов (например, email или телефонов) в критичных таблицах, и более формальные проверки на уровне метрик отчета инструмента.

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

Типичные ошибки

Когда команды начинают внедрять обезличивание в CI/CD, проблемы обычно из-за организационных и процессных мелочей. Почти в каждой компании встречаются одни и те же сценарии.

1. Обезличивание не там, где нужно. Самая распространенная ошибка. Формально процесс существует: есть скрипты, есть job в пайплайне, данные действительно проходят обработку. Но боевую базу копируют в тест, делают резервные копии или передают копии подрядчикам, а уже потом запускают маскировку — смысл обезличивания теряется, потому что персональные данные уже успели выйти за пределы защищенного контура. 
2. Обезличивание ломает тестовую среду. Это происходит, когда правила пишутся слишком грубо: значения заменяются случайными строками, исчезает уникальность ключей, нарушаются связи между таблицами или меняются распределения данных. Распознать можно по автотестам, которые падают без видимой причины — или отчетам, которые показывают странную статистику. Если долго игнорировать, команда начнет воспринимать обезличивание как препятствие для работы — и тогда появятся обходные пути, временные копии и реальные копии «чисто для проверки».
3. Разовая акция вместо процесса. Команда один раз прогоняет скрипты обезличивания, показывает результат на внутренней проверке и считает задачу закрытой. Но если процесс не встроен в CI/CD, очень быстро всё возвращается к прежнему состоянию: через месяц база обновляется старым способом, скрипты лежат без изменений, а никто уже точно не помнит, какие данные на тесте на самом деле используются. Без автоматизации процесс почти всегда деградирует.
4. Отсутствие метрик качества. Не измеряется доля обработанных полей, количество неизвестных столбцов или ошибки применения правил. Кажется, что всё под контролем — но доказать это невозможно.

Мини-чек-лист: что делать пошагово

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

• Понять, где именно живут данные. Зафиксировать все источники и маршруты движения данных.
• Описать сами данные. Составить перечень таблиц и полей, где хранится чувствительная информация: имена пользователей, контакты, документы, финансовые идентификаторы, адреса. 
• Определить правила обезличивания. Для каждого типа данных определить не только то, как значения будут заменяться, но и какие свойства должны сохраниться. 
• Выбрать инструмент. Это может быть готовое решение, open source-библиотека или собственный набор скриптов — важна возможность запускать его автоматически и повторяемо. 
• Поставить обезличивание до развертывания тестовой базы. Тестовая среда должна получать только уже обработанные данные. Если реальные данные хотя бы временно попадают в тестовый контур, контроль над ними быстро теряется.
• Закрепить обезличивание в CI/CD как обязательный этап пайплайна. Обновление тестовой базы должно зависеть от успешного выполнения этого шага.
• Делать процесс наблюдаемым. Настроить отчеты и метрики: сколько таблиц и полей обработано, где правила не применились, как часто возникают ошибки в пайплайне. 

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