pg_anon: как обезличить базу 1С без промежуточной копии

pg_anon обезличивает базу 1С на PostgreSQL прямо в потоке дампа: персональные данные — ИНН, ФИО, телефоны, зарплаты — заменяются по словарю правил ещё до записи файла на диск, поэтому незашифрованная копия базы нигде не появляется. Тестовый контур получает рабочую структуру данных без реальных сведений о клиентах и сотрудниках, а компания не рискует штрафом по 152-ФЗ за утечку из тестовой среды.

Почему возникает риск при копировании базы 1С для тестового контура

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

152-ФЗ не делает исключения для тестовых сред: обработка персональных данных в тестовом контуре без обезличивания — такое же нарушение, как и в боевой базе (текст закона). При жалобе клиента или проверке компания получает штраф по ст. 13.11 КоАП, а если утечка всплывёт у контрагента, с которым подписано соглашение о защите данных, — это уже разговор о разрыве договора, а не только о деньгах. Обычная реакция — обезличить вручную. Но ручные UPDATE-скрипты по полусотне таблиц с учётом связей 1С занимают дни, а копия базы всё это время лежит на диске в открытом виде — проблема не решается, а откладывается на срок обработки.

Как обезличить базу 1С через pg_anon без промежуточной копии

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

Правила задаются словарём вида «таблица.поле → функция»: хеш с фиксированным начальным значением для ИНН и телефонов, фейковые ФИО из справочника-подстановки, сдвиг дат рождения на случайный интервал, обнуление или округление окладов с сохранением статистики по фонду оплаты труда. Сложность в том, что таблицы 1С на PostgreSQL называются техническими именами вроде _Reference123 или _Document456 — словарь пишется не по описанию метаданных конфигурации, а по факту хранения: список реквизитов с персональными данными выгружается из конфигуратора, а затем сопоставляется с техническими именами через отчёт о структуре хранения базы. Если в результате доработки 1С в конфигурации появился кастомный справочник с паспортными данными сотрудников, его нужно внести в словарь отдельно — pg_anon не знает о полях, которых нет в правилах.

Какие поля 1С почти всегда содержат персональные данные

Прежде чем писать словарь, стоит свериться с типовым набором реквизитов, которые попадают под 152-ФЗ в любой конфигурации на базе БСП:

• ✓ФИО и дата рождения в справочниках «Физические лица» и «Контрагенты»
• ✓паспортные данные и СНИЛС в карточках сотрудников
• ✓ИНН и КПП контрагентов-физлиц и ИП
• ✓телефоны и email в подсистеме контактной информации
• ✓банковские реквизиты и номера карт в справочнике «Банковские счета»
• ✓оклады и начисления в регистрах сведений расчёта зарплаты

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

На базе среднего размера (~50 ГБ) разница между подходами выглядит так — цифры ориентировочные, зависят от железа и количества таблиц с ПДн:

Что делать, если анонимизация pg_anon падает или ошибка повторяется на большой базе

Прогон стабильно доходит до 80% и обрывается — знакомая картина для баз, где раньше pg_anon не запускали ни разу. Четыре причины закрывают почти все повторяющиеся сбои.

Первая — обрыв по памяти на больших таблицах: каталоги полнотекстового поиска (_FTQ) и таблицы с bytea-полями под сканы УПД и вложения не предназначены для построчного маскирования. Решение — исключить их из потока и переносить отдельно как есть (эти поля обычно не содержат персональных данных сами по себе), а также поднять work_mem и maintenance_work_mem под сессию pg_anon.

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

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

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

Как предотвратить повторные проблемы с обезличиванием тестовых баз 1С

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

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

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

Сколько стоит настройка обезличивания базы 1С и что входит в услугу

Обезличивание тестового контура — обычно часть более широкого проекта внедрения 1С или перехода на новую конфигурацию, где тестовая база нужна не разово, а постоянно — под каждую доработку и каждое обновление. Работа строится в четыре шага: анализ структуры хранения и составление списка реквизитов с ПДн, разработка и тестирование словаря правил, настройка регулярного пайплайна pg_anon с логированием прогонов, документация процесса для сверки после будущих обновлений. Если нужен отдельный сервер под тестовый контур — стоимость аренды сервера под 1С начинается от 3300 руб/мес. Сопровождение процесса — донастройка правил после обновлений, разбор упавших прогонов, расширение словаря под новые справочники — тарифицируется как обычные работы сисадмина и специалиста сопровождения 1С, от 3800 руб/час.

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

Что такое pg_anon и чем он лучше обычного дампа с ручной обработкой?

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

Работает ли pg_anon, если 1С развёрнута на MS SQL, а не на PostgreSQL?

Нет, pg_anon рассчитан именно на PostgreSQL и работает с его внутренним форматом хранения. Для баз 1С на MS SQL нужен другой инструмент или собственные скрипты маскирования — потоковое обезличивание без промежуточной копии в таком виде для MS SQL напрямую не применить.

Как часто нужно обновлять словарь правил маскирования для базы 1С?

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

Сколько времени занимает обезличивание базы 1С объёмом 100 ГБ и больше?

Зависит от количества таблиц с персональными данными, мощности сервера и числа параллельных потоков pg_anon. Ориентировочно база 50 ГБ в режиме потоковой синхронизации обрабатывается за 1-2 часа, крупная база на 100+ ГБ — кратно дольше, точный расчёт делается по факту структуры конкретной конфигурации.

Можно ли доверить настройку словаря и пайплайна pg_anon подрядчику?

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