Разработчику нужна свежая база 1С, но отдавать ему ФИО, телефоны, ИНН и зарплаты нельзя. Обычная цепочка через полный дамп и отдельную обработку создаёт ещё одну копию с исходными данными.
В сценарии UKVED база около 50 ГБ прошла потоковую обработку через pg_anon за 1–2 часа. Полный дамп с отдельным ETL занял 2–4 часа, ручные UPDATE — 3–5 часов. Это результаты конкретного сценария UKVED, а не замеры нашей лаборатории. Для другой базы они не обещают такое же время.
Задача pg_anon — отдать рабочую копию для разработки или проверки обновления. Структура, связи и число строк сохраняются, а чувствительные значения меняются при выгрузке. Но результат зависит от словаря: пропущенное поле останется без маскирования.
Что означает «без промежуточной копии»
pg_anon читает исходную PostgreSQL порциями и применяет правила к каждой порции. Незамаскированные строки остаются в памяти процесса только на время обработки. На диск утилита пишет уже изменённые данные.
Это не означает работу без дампа. Режим dump создаёт файлы, которые затем принимает restore. Исходная база остаётся на месте.
Есть ещё одно ограничение. Команда init создаёт в исходной базе схему anon_funcs с функциями маскирования. Это изменение схемы, хотя прикладные данные команда не переписывает. Такое поведение описано в документации проекта TantorLabs на GitHub.
До init снимите обычную восстанавливаемую копию PostgreSQL. Если команда завершится штатно, копия не понадобится. Если ошибётся оператор или пропадёт диск, у вас останется точка возврата.
Формат копии выбирайте по своему регламенту. Разницу между логическим дампом, физической копией и WAL описывает порядок резервирования кластера PostgreSQL.
Сначала проверьте версии PostgreSQL и утилит
pg_anon работает с PostgreSQL и совместимыми СУБД. Для 1С на MS SQL Server этот инструмент не подходит: потребуются другие средства маскирования или собственные скрипты.
README проекта TantorLabs задаёт четыре базовых требования.
| Что проверить | Требование pg_anon | Что сделать при несовпадении |
|---|---|---|
| Версия PostgreSQL | 9.6 или новее | Обновить сервер либо выбрать другой инструмент |
| Версия Python | 3.11 или новее | Установить отдельное окружение Python |
pg_dump и pg_restore | Та же основная версия, что у исходного сервера | Взять клиентские утилиты из подходящего дистрибутива PostgreSQL |
| Целевой PostgreSQL | Та же основная версия или новее | Подготовить совместимый целевой сервер |
| Тип СУБД | PostgreSQL или совместимая СУБД | Для MS SQL Server подобрать другой способ маскирования |
Если одно условие не выполнено, сначала исправьте окружение. Проверять совместимость опытным запуском на продуктивной базе не нужно.
Для базы на MS SQL Server сначала сохраните рабочую точку возврата. Подходящие полные, разностные и журнальные копии описаны в порядке резервирования 1С на SQL Server. Эта инструкция не обезличивает данные, а защищает их перед отдельной обработкой.
Потоковая выгрузка не исправляет неполный словарь
Рабочая цепочка состоит из шести операций:
initсоздаёт служебные функции маскирования.create-dictищет чувствительные поля по мета-словарю.view-fieldsпоказывает найденные поля и назначенные правила.view-dataвыводит пробные изменённые строки без записи в целевую базу.dumpвыгружает структуру и маскированные данные.restoreразворачивает результат на отдельном сервере или в отдельной базе.
Команды, параметры и порядок подготовки описаны в инструкции по pg_anon 1.11.0. Здесь главный вопрос другой: что должно попасть в словарь до запуска dump.
pg_anon видит таблицы PostgreSQL, а не знакомые администратору объекты 1С. Вместо справочника «Физические лица» он работает с именами вроде _Reference123. Документы выглядят как _Document456.
Список чувствительных реквизитов сначала получают из конфигуратора. Затем каждый реквизит сопоставляют с физическим полем через отчёт о структуре хранения базы.
Если поля нет в словаре, pg_anon пропустит его без ошибки. Успешное завершение команды доказывает только то, что выгрузка закончилась. Оно не доказывает, что из копии исчезли персональные данные.
Проверьте минимум такие области:
- ФИО и даты рождения в справочниках физических лиц и контрагентов;
- паспортные данные и СНИЛС в карточках сотрудников;
- телефоны и электронную почту в контактной информации;
- ИНН и КПП физических лиц и ИП;
- банковские счета и номера карт;
- оклады и начисления в регистрах зарплаты.
Составные реквизиты требуют отдельного внимания. Часть из них хранится внутри бинарного XML, поэтому поиск по названиям колонок их не обнаружит.
Тип поля задаёт границы маскирования
Нельзя назначить одну функцию всем колонкам подходящего размера. В базе 1С тип данных связан с прикладной логикой.
Поля bytea часто содержат ссылки. Маскирование таких значений нарушает ссылочную целостность. Поля boolean хранят два состояния, и случайная подмена меняет поведение программы.
С датами действует похожее ограничение. Поле «Период» регистра связано с датами документов и движениями. Массовый сдвиг дат даст расхождение между документом и его регистрами.
Astra Linux Wiki описывает мета-словарь, проверенный на типовой ERP производственной организации. В нём чувствительным типом выбран mvarchar, а служебные таблицы исключены. Такой файл годится как начальная заготовка, но не как готовый словарь для любой конфигурации.
Выбирайте правило по назначению данных
Одинаковая замена для ФИО, телефона и оклада создаёт две проблемы. Часть значений теряет пригодность для проверки, а связанные поля получают разные результаты.
| Данные | Подходящее правило | Что проверить после восстановления |
|---|---|---|
| ФИО | Подстановка значений из подготовленного справочника | Формы и отчёты открываются, исходные ФИО не находятся |
| ИНН | Детерминированное преобразование с одной функцией и солью | Один исходный ИНН получил одинаковую замену во всех таблицах |
| Телефоны | Детерминированное правило с сохранением допустимого формата | Поиск и проверки формата не падают |
| Дата рождения | Контролируемый сдвиг даты | Возрастные условия и связанные даты не потеряли смысл |
| Оклад и начисления | Обнуление либо округление | Отчёты строятся, исходные суммы не сохранились |
| Пустые значения | CASE: пустое оставить пустым, остальное изменить | Пустые поля не превратились в вымышленные данные |
Универсального словаря для базы 1С нет. Даже две базы одной конфигурации могут различаться расширениями и добавленными реквизитами.
Для одинакового ИНН в нескольких местах нужна одна детерминированная функция. Одинаковое исходное значение тогда получает одинаковую замену, и связи сохраняются.
Соль для такого преобразования нельзя публиковать вместе со словарём. В статье TantorLabs на Хабре указано, что хеш с открытой солью можно подобрать. Рабочий секрет храните отдельно от репозитория с общими правилами.
Пустые строки тоже требуют явного решения. Функции pg_anon пропускают NULL, но пустая строка — другое значение. Оберните правило в CASE, если отсутствие данных имеет прикладной смысл.
Почему ориентир для 50 ГБ нельзя переносить на 500 ГБ
В опубликованном UKVED сценарии результаты для базы около 50 ГБ выглядят так:
| Способ | Время в сценарии UKVED | Что происходит с исходными данными |
|---|---|---|
Ручные UPDATE по таблицам | 3–5 часов плюс подготовка скриптов | Создаётся и изменяется отдельная копия |
| Полный дамп и отдельный ETL | 2–4 часа | До обработки хранится полный незамаскированный дамп |
| pg_anon в потоковом режиме | 1–2 часа | Значения меняются во время чтения и записи |
В этом сценарии pg_anon сократил цепочку и убрал незамаскированный промежуточный дамп. Считать такой результат нормативом для всех баз нельзя.
Во время выгрузки сервер читает исходные таблицы, считает маски и пишет результат. Параметр --processes задаёт число параллельных процессов. Итог зависит от процессора, дисков, словаря, размера таблиц и конкурирующей нагрузки.
В публикации UKVED нет характеристик оборудования и значения --processes. Поэтому расчёт «50 ГБ за два часа, значит 500 ГБ за двадцать» не имеет основания. На крупной базе изменится не только объём, но и доля тяжёлых функций, крупных таблиц и индексов.
Для планирования окна проведите первый прогон на восстановленной технической копии. Запишите объём базы, число процессов, версию словаря, время dump и время restore.
Следующий запуск можно оценивать по этому замеру, если ресурсы и словарь не изменились. После добавления новых правил замер повторяют: вычисление хешей и подстановок меняет нагрузку.
Как проверить копию перед передачей разработчику
Проверка через view-data ловит ошибки словаря до долгой выгрузки. Она показывает пробные значения, но не подтверждает работу всей базы.
После dump разверните результат через restore в отдельном контуре. Не подключайте разработчиков к копии, пока не завершили приёмку.
Проверьте результат в таком порядке:
- Откройте базу через клиент 1С.
- Выполните вход под тестовой учётной записью.
- Откройте справочники физических лиц, контрагентов и сотрудников.
- Проверьте ссылки из документов на справочники.
- Откройте документы и движения по регистрам.
- Постройте отчёты, затрагивающие зарплату и взаиморасчёты.
- Найдите в PostgreSQL контрольные ФИО, ИНН, телефоны и номера счетов.
- Повторите поиск по выгруженному списку чувствительных реквизитов.
Контрольные значения подготовьте до маскирования. Возьмите несколько записей из каждой области, но не переносите этот список вместе с копией разработчику.
Если вход работает, а поиск находит исходный телефон, копия не прошла проверку. Если персональные значения исчезли, но документы потеряли ссылки, копия тоже не готова.
Дамп без ошибок ещё не означает обезличивание
TantorLabs называет результат pg_anon псевдонимизированной копией. Утилита подменяет значения, но возможность связать данные с человеком зависит от словаря и выбранных функций.
Открытая соль, пропущенный реквизит или сохранённый квази-идентификатор могут оставить путь к восстановлению личности. Сама утилита не подтверждает соответствие требованиям 152-ФЗ.
Копию выпускают после двух проверок. Техническая проверка подтверждает работу связей и документов в 1С. Ответственный за защиту данных проверяет, достаточно ли выбранных правил для конкретного контура.
Рабочее правило короткое: копия готова не после сообщения об успешном dump. Она готова, когда поиск не находит исходных идентификаторов, а 1С сохраняет связи, документы и движения.