Дамп готов, но передавать его разработчику нельзя. Внутри остались ФИО, телефоны, ИНН, адреса и зарплаты сотрудников.
pg_anon 1.11.0 заменяет выбранные значения во время выгрузки PostgreSQL. Структура базы и связи между таблицами сохраняются. Разработчик получает рабочую копию для тестов, но не видит исходные значения.
Есть принципиальная оговорка. Максим Ибрагимов из команды Tantor Labs называет результат pg_anon псевдонимизированным по умолчанию. Если сохранить словарь, соль и доступ к исходной базе, часть соответствий можно восстановить или подтвердить перебором.
Поэтому такую копию нельзя считать свободной от ограничений автоматически. Храните словари отдельно, ограничивайте доступ и проверяйте результат перед передачей.
Кому пригодится версия 1.11.0
pg_anon подходит администратору, который обслуживает базу 1С на PostgreSQL. Инструмент работает с PostgreSQL 9.6 и более новыми версиями, а также совместимыми СУБД.
Для 1С на MS SQL Server этот порядок не годится. Там нужны средства выгрузки и маскирования, рассчитанные на SQL Server. Различия в обслуживании двух платформ собраны в материале о выборе СУБД под эксплуатацию 1С.
Версия 1.11.0 требует Python 3.11 или новее. Базовая установка выглядит так:
pip install "pg_anon==1.11.0"
pg_anon --versionКоманда проверки должна показать установленную версию. Перед рабочим прогоном также проверьте pg_dump и pg_restore: документация Tantor SE-1C требует клиентские утилиты той же основной версии, что и сервер.
В версии 1.11.0 операции стали отдельными командами
Раньше режим передавали через --mode. Старый синтаксис сохранили для совместимости, но новый CLI строится на подкомандах.
Теперь имя операции видно прямо в команде: init, create-dict, dump, restore, view-fields или view-data. Для потокового переноса структуры и данных появились отдельные команды семейства sync-*.
| Изменение в 1.11.0 | Что меняется в работе администратора | Когда пригодится |
|---|---|---|
Подкоманды вместо общего --mode | Операция читается из самой команды, параметры труднее перепутать | Скрипты с несколькими этапами выгрузки |
Отдельная команда pg_anon_api | REST-служба отделена от ручного запуска | Интеграция с внутренней системой подготовки стендов |
| Частичная выгрузка и восстановление | Таблицы можно включать или исключать словарями | Тесту нужен ограниченный фрагмент большой базы |
Опции --clean-db и --drop-db | Целевую базу можно очистить либо пересоздать перед восстановлением | Стенд регулярно собирается заново |
Опция --ignore-privileges | Владельцы объектов и права не переносятся | Роли тестового контура отличаются от боевых |
Параметры для pg_dump и pg_restore | Штатным утилитам PostgreSQL можно передать дополнительные опции | Требуется управлять форматом или поведением восстановления |
Опция --save-dicts | Входные и итоговые словари сохраняются в каталоге запуска | Нужно повторить прогон и сравнить правила |
| Поддержка секций и наследования | Полный цикл восстанавливает секционированные таблицы, внешние ключи и INHERITS | В базе есть сложная схема PostgreSQL |
Главная причина обновления — не номер версии. Новый CLI лучше разделяет подготовку, проверку, выгрузку и восстановление сложных баз.
Служебные файлы pg_anon складывает в подкаталог pg_anon_runs текущего каталога. Другой корень задаёт переменная PG_ANON_HOME. Эти изменения описал Максим Ибрагимов из Tantor Labs в обзоре pg_anon 1.11.0.
Словарь определяет, что попадёт в копию
pg_anon не распознаёт персональные данные сам по смыслу. Если поля нет в правилах, его содержимое попадёт в выгрузку без замены.
Работа начинается с мета-словаря. Это файл Python с признаками, по которым pg_anon ищет чувствительные таблицы и поля.
После сканирования появляются два подготовленных словаря. Первый связывает чувствительное поле с функцией маскирования. Второй запоминает проверенные поля без конфиденциальных данных и ускоряет следующие проходы.
Отдельный табличный словарь ограничивает состав выгрузки. Через него можно включить нужные таблицы или исключить служебные данные.
Для обычной схемы PostgreSQL достаточно сопоставить имя таблицы и столбца. У базы 1С физические имена выглядят как _Reference123 и _Document456, поэтому ручной список быстро теряет связь с конфигурацией.
Документация Tantor SE-1C предусматривает построение сопоставления по метаданным конфигурации 1С. Оно связывает прикладной реквизит с физическим полем PostgreSQL. После обновления конфигурации такое сопоставление нужно пересобрать и проверить.
Найденное поле — лишь половина работы. Следом надо выбрать преобразование, которое скроет исходное значение и не нарушит прикладные связи.
Одинаковые значения должны меняться одинаково
Если один ИНН встречается в нескольких таблицах, случайная замена каждого вхождения разорвёт связь. Отчёт увидит разных контрагентов там, где в производственной базе был один.
Для таких полей нужна детерминированная функция. Одинаковое исходное значение при одинаковых правилах даёт одинаковый результат.
pg_anon поддерживает замену, обфускацию, шифрование и генерацию. В комплекте есть anon_funcs.digest() для текста, anon_funcs.noise() для чисел и anon_funcs.random_inn() для ИНН.
| Данные | Что требуется от копии | Подход | Что проверить |
|---|---|---|---|
| ФИО и телефоны | Скрыть значение, сохранить повторяемость связей | anon_funcs.digest() либо подготовленная функция замены | Одинаковые входные значения дают одинаковый результат |
| ИНН | Убрать исходный идентификатор и сохранить формат реквизита | anon_funcs.random_inn() или согласованное правило словаря | 1С принимает значение, поиск не находит настоящий ИНН |
| Зарплаты и суммы | Изменить число, сохранив подходящий числовой тип | anon_funcs.noise() | Документы открываются, итоговые значения не раскрывают оригинал |
| Справочные строки | Подменить значение правдоподобным аналогом | Функция замены или генерации | Длина и формат не ломают обработку |
| Составные реквизиты | Сохранить внутреннюю структуру объекта 1С | Отдельное правило для объекта целиком | Объект открывается после восстановления |
| Технические поля | Не менять без установленной причины | Внести в словарь нечувствительных данных | Ссылки, GUID и служебная логика не повреждены |
Функцию выбирают не по названию колонки, а по поведению поля в 1С. Проверка через интерфейс платформы здесь так же нужна, как контрольный SQL-запрос.
Фиксированная соль сохраняет соответствие между одинаковыми значениями. Но она же делает преобразование повторяемым. Результат остаётся псевдонимизированным, поэтому соль нельзя передавать вместе с копией.
Особого внимания требуют поля bytea и составные реквизиты. В практическом разборе pg_anon для 1С показано, что составное значение может храниться как бинарный XML.
Точечная замена подстроки внутри такого объекта повреждает его. После восстановления 1С не сможет открыть реквизит. Для бинарных полей сначала установите назначение содержимого, затем проверяйте объект целиком.
Каталоги полнотекстового поиска _FTQ тоже не стоит обрабатывать как обычные прикладные строки. Их включение в словарь требует отдельной проверки на тестовом восстановлении.
Рабочий прогон начинается не с дампа
Первая попытка нужна для проверки правил, а не для передачи базы разработчику. Сначала установите pg_anon, инициализируйте исходную базу и посмотрите пробные строки.
Команда init создаёт в исходной базе схему anon_funcs. В неё загружаются SQL-функции, которыми словарь преобразует значения. Без этой схемы режим view-data не отработает.
Дальше создайте мета-словарь и подготовленные словари. Храните их как конфигурацию процесса, но отделите от готового дампа и тестовой базы. Доступ к правилам должен быть уже, чем доступ к стенду разработчика.
Перед полной выгрузкой запустите view-data для каждой группы чувствительных полей. Этот режим показывает преобразованные строки без создания дампа. На этом этапе видны пропущенные колонки, неверный формат и несогласованные значения.
| Этап | Что делает администратор | Признак готовности |
|---|---|---|
| Проверка среды | Сверяет Python, pg_anon, pg_dump и pg_restore | Версии подходят серверу, команды запускаются |
| Инициализация | Запускает init для исходной базы | Схема anon_funcs создана |
| Поиск полей | Строит словари по метаданным и правилам поиска | Чувствительные поля перечислены явно |
| Пробный просмотр | Проверяет результат через view-data | Исходные значения не видны, формат сохранён |
| Маскированная выгрузка | Запускает dump или подходящую sync-* операцию | В рабочем каталоге появился полный набор файлов |
| Отдельное восстановление | Разворачивает данные в целевую базу | Производственная база не менялась |
| Приёмка через 1С | Открывает объекты и выполняет контрольные запросы | Связи работают, настоящие данные не находятся |
Не переходите к выгрузке, пока пробный просмотр не прошёл по всем категориям данных. pg_anon применяет только записанные правила.
Целевую базу отделяют от производственной
Документация Tantor SE-1C требует заранее создать пустую целевую базу. В версии 1.11.0 восстановление также поддерживает --clean-db и --drop-db.
--clean-db удаляет объекты, которые входят в дамп, а затем загружает их заново. --drop-db пересоздаёт целевую базу целиком. Обе опции требуют точной проверки строки подключения.
Не указывайте производственную базу как цель даже для пробного запуска. Отдельное имя базы защищает не от ошибки в словаре, а от ошибочного восстановления поверх рабочих данных.
До первого прогона подготовьте обычную резервную копию PostgreSQL. Маскированный дамп решает задачу передачи данных, но не заменяет резервирование. Порядок для логических дампов, физических копий и WAL описан в схеме восстановления PostgreSQL для 1С.
Частичную выгрузку тоже проверяйте как самостоятельную базу. pg_anon собирает DDL вспомогательных объектов из затронутых схем, однако прикладная логика 1С может ожидать отсутствующие таблицы.
Если тестовый сценарий требует всей конфигурации, частичный дамп принесёт больше проверки, чем экономии. Используйте его для ограниченного набора данных с понятными зависимостями.
Незамаскированные строки не должны попадать в промежуточный файл
При дампе pg_anon читает строки, применяет правила и записывает преобразованный результат. Незамаскированные значения остаются в памяти процесса на время обработки порции.
Это снижает риск появления ещё одной открытой копии базы на диске. Но защита работает только для полей, которые попали в словарь.
Ручные UPDATE после передачи не исправят главный просчёт. К этому моменту исходные данные уже окажутся у получателя. Если проверка нашла настоящее значение, удалите неудачную копию, поправьте словарь и повторите весь прогон.
Что pg_anon не проверит за администратора
Инструмент не знает прикладной смысл реквизитов 1С. Он выполнит функцию из словаря, даже если выбранное преобразование нарушит формат или связь.
pg_anon также не решает вопрос коммерческой тайны. После маскирования персональных полей в базе могут остаться договоры, цены, условия поставок и внутренняя отчётность.
Отдельно проверьте вложения, двоичные данные, полнотекстовые индексы и редко используемые подсистемы. Пропуск обнаружится только там, где вы выполнили контрольный запрос или открыли объект через 1С.
Обновление конфигурации меняет физическую схему. После него прежний словарь нельзя принимать на веру. Снова постройте сопоставление по метаданным и сравните набор чувствительных полей.
Как принять готовую копию
Копию можно отдавать разработчику после четырёх проверок:
- Контрольный поиск не находит реальные ФИО, телефоны, ИНН и другие выбранные значения.
- Одинаковые исходные значения преобразованы согласованно во всех связанных таблицах.
- Документы, справочники и составные реквизиты открываются через клиент 1С.
- В журнале запуска указана отдельная целевая база, а не производственная.
Провал любого пункта означает новый прогон. Исправьте словарь, снова проверьте данные через view-data, соберите дамп и восстановите его в отдельную базу.
Рабочее правило короткое: тестовая копия готова не после завершения restore, а после поиска исходных значений и проверки через 1С.