Тестовая база 1С светит ИНН клиентов: маскируем через pg_anon в CI/CD

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

Почему тестовая база 1С в CI/CD хранит реальные персональные данные ⚠️

В компании, которая внедряет 1С:Управление торговлей для оптового дистрибьютора в Москве, ночной джоб в GitLab CI каждую ночь снимает бэкап продовой базы PostgreSQL размером около 80 ГБ и разворачивает его в тестовом контуре. Утром три тестировщика на аутсорсе и подрядчик, который дорабатывает печатные формы, заходят в свежую копию и гоняют регресс перед релизом. Тесты зелёные, релиз выходит вовремя.

Но за неделю до планового аудита по 152-ФЗ служба безопасности поднимает список серверов, доступных подрядчикам по VPN, и находит в тестовой базе те же ИНН, телефоны и сканы паспортов клиентов, что и в проде — просто на сутки моложе. Обработка персональных данных этими людьми формально не согласована ни с одним клиентом: тестовый контур не входит в перечень систем, где заявлена обработка ПДн. В акте аудита это фиксируется как факт неконтролируемой обработки ПДн, а не как рекомендация на будущее. Поэтому регресс, который вчера прошёл без единого красного теста, сегодня превращается в основание для предписания.

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

Как исправить это через маскирование pg_anon без промежуточных копий 🛠️

Классическая схема выглядит так: восстановить дамп прод-базы в тестовом контуре, а затем прогнать поверх набор UPDATE-скриптов, которые подменяют ФИО, ИНН и телефоны на случайные значения. Проблема не в самих скриптах, а в паузе между этими двумя шагами. На базе в 80 ГБ восстановление занимает от получаса, маскирующий скрипт — ещё столько же, и всё это время реальные данные лежат в тестовой базе доступными по обычному подключению. Если скрипт упадёт на середине или его забудут запустить после ручного восстановления «на скорую руку», тестовая база так и останется с настоящими данными — при этом в логах пайплайна будет зелёная галочка «restore: success».

pg_anon убирает саму паузу. Вместо последовательности «восстановить → потом замаскировать» он читает строки из источника и сразу применяет правила анонимизации — хэширование, подстановку по шаблону, обнуление — в процессе потоковой передачи в целевую базу. Строка с настоящим ИНН просто не сохраняется на диске тестового сервера ни на секунду: она уже заменена к моменту записи.

Как pg_anon маскирует данные в потоке, не создавая лишний дамп

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

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

Как встроить маскирование в пайплайн CI/CD для 1С

На практике стадию «restore» в пайплайне заменяют на «restore + mask», и получается такая последовательность:

• ✓источником для pg_anon служит реплика прод-базы, а не мастер, чтобы копирование не создавало нагрузку на боевых пользователей;
• ✓целевая база сразу получает результат маскирования — отдельного шага восстановления «как есть» не существует;
• ✓после разворачивания тестовая база проходит стандартную постобработку 1С: отключение регламентных заданий, чтобы она не разослала реальным клиентам письма или СМС из тестового контура;
• ✓пайплайн падает, а не проходит с предупреждением, если словарь не покрывает новое поле — об этом ниже.

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

Что делать, если ошибка повторяется — маскирование падает или пропускает поля 🔁

Три сценария повторяются чаще остальных. Первый — дрейф схемы: после обновления конфигурации в ERP появляется новый регистр с мобильным телефоном клиента из CRM-подсистемы, а словарь маскирования о нём не знает. Пайплайн отрабатывает без единой ошибки, но телефон в тестовой базе остаётся настоящим, потому что для pg_anon это просто ещё одно текстовое поле, а не персональные данные. Пока это не найдут вручную, тестовая база выглядит обезличенной по отчёту пайплайна, хотя по факту таковой не является.

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

Третий — блокировки. Если источником по ошибке подключили не реплику, а боевую мастер-базу, маскирование ненадолго блокирует таблицы, с которыми в этот момент работают активные пользователи 1С. Сессии подвисают, в поддержку летят тикеты «база встала», хотя формально никто её не трогал руками. Проверка проста: источник для pg_anon должен быть read-only реплика, и точка.

Как предотвратить повторное попадание незамаскированных данных в тестовый контур 🛡️

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

После маскирования полезно гонять по тестовой базе набор регулярных выражений на типовые форматы ИНН, паспорта и телефона и требовать нулевое количество совпадений, прежде чем помечать базу готовой для тестировщиков. Так пайплайн не полагается на код возврата «0» от самого pg_anon, а проверяет результат независимо.

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

Сколько стоит настроить конвейер маскирования 1С и кто этим занимается 💰

Настройка такого пайплайна — задача на стыке администрирования PostgreSQL, работы с CI/CD и знания конкретной конфигурации 1С, поэтому обычно её ведут вместе сисадмин и разработчик 1С. Старт обычно начинается с аудита текущей схемы резервного копирования и списка таблиц с персональными данными, а дальше пайплайн работает без постоянного участия команды — разработчик подключается только когда меняется конфигурация. У нас эта работа идёт по ставке сопровождения 1С и системного администрирования — от 3800 руб/час; итоговый бюджет зависит от размера базы, количества таблиц с персональными данными и того, есть ли в компании готовый CI/CD или его нужно разворачивать с нуля.

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

❓ Частые вопросы

Чем pg_anon отличается от обычного скрипта UPDATE, который подменяет ФИО и телефоны после восстановления базы?

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

Можно ли маскировать базу 1С, если она размещена в облаке или на арендованном сервере?

Да, pg_anon работает с любым PostgreSQL, к которому есть сетевой доступ и права на чтение, независимо от того, стоит ли СУБД на собственном железе или на арендованном сервере. Важно только подключать маскирование к реплике, а не к боевой мастер-базе, чтобы не создавать лишнюю нагрузку на продовых пользователей.

Что произойдёт с прикреплёнными файлами — сканами паспортов, договорами, — если их нельзя замаскировать текстовым словарём?

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

Нужно ли останавливать 1С или отключать пользователей на время маскирования базы?

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

Сколько стоит настроить такой конвейер маскирования для типовой базы 1С?

Стоимость зависит от размера базы, количества таблиц с персональными данными и того, есть ли в компании уже настроенный CI/CD. Работа сисадмина и разработчика 1С над таким пайплайном оценивается по ставке сопровождения — от 3800 руб/час, итоговый бюджет считается после аудита текущей инфраструктуры.