pg_anon: как быстро обезличить базу 1С без создания промежуточной копии
При разработке и тестировании решений на 1С часто требуется копия рабочей базы. Она должна сохранять структуру, связи, справочники, документы и другие особенности продуктивной системы, иначе тестирование потеряет смысл. Самый простой путь - передать разработчикам копию рабочей базы целиком. Однако вместе с техническими данными в таком случае наружу могут попасть персональные сведения, коммерческая тайна и внутренняя информация об инфраструктуре.
Для компании это означает сразу несколько рисков. Передача персональных данных сотрудников, клиентов и контрагентов без надлежащих оснований может привести к претензиям со стороны регуляторов и штрафам по требованиям 152-ФЗ. Подрядчик получает доступ к ценам, условиям договоров, скидкам, клиентской базе и другой чувствительной информации. Соглашение о неразглашении снижает риски, но не отменяет сам факт передачи данных за пределы защищённого контура.
Есть и менее очевидная проблема: разработчики обычно не проходят те же процедуры допуска и контроля, что сотрудники, работающие с продуктивными системами. При этом копия базы может содержать логины, ФИО пользователей, адреса серверов, параметры подключения и сведения о доступе к внешним сервисам.
Оптимальный подход - передавать не копию с реальными сведениями, а функционально полноценную обезличенную базу. В ней реальные значения заменяются правдоподобными вымышленными данными, а структура и логика работы системы остаются неизменными.
Какие сведения нужно маскировать
В зависимости от конфигурации 1С к чувствительным данным могут относиться:
- ФИО, ИНН, паспортные данные, СНИЛС;
- адреса регистрации и проживания;
- телефоны и адреса электронной почты;
- банковские счета и номера карт;
- сведения о клиентах, поставщиках и контактных лицах;
- цены, скидки, условия договоров и коммерческие предложения;
- логины пользователей;
- IP-адреса, DNS-имена и MAC-адреса;
- пароли, ключи и параметры доступа к внешним системам;
- внутренние идентификаторы и иные поля, по которым можно восстановить принадлежность данных конкретному человеку или организации.
Анонимизация, или маскирование, - это преобразование исходных значений в правдоподобные, но не настоящие. Сенситивным полем называют столбец, в котором хранится персональная, коммерческая или технически конфиденциальная информация.
Почему стандартных средств 1С бывает недостаточно
В 1С предусмотрена обработка "Скрытие конфиденциальной информации". Она позволяет заменить часть персональных данных, но при работе со сложными базами быстро проявляются ограничения:
- набор обрабатываемых полей ограничен заранее заданным перечнем;
- дополнительные чувствительные реквизиты приходится искать и добавлять вручную;
- ссылочные значения могут обрабатываться только объектами;
- перед маскированием нужно создать отдельную копию базы;
- процесс выполняется внутри самой информационной базы и может заметно нагружать систему.
Более удобная схема - сформировать обезличенный дамп непосредственно при выгрузке данных. Исходная база при этом только читается, а незамаскированная копия на диске или в отдельном окружении не появляется.
Что такое pg_anon
pg_anon - бесплатная утилита для анонимизации баз PostgreSQL. Она не привязана к конкретной прикладной системе и может применяться к произвольным схемам и таблицам. Поэтому инструмент подходит и для баз 1С, работающих на PostgreSQL.
Главное преимущество заключается в разделении этапов:
1. рабочая база анализируется без изменения данных;
2. формируются правила для чувствительных полей;
3. выполняется выгрузка структуры и данных;
4. в результирующий дамп попадают уже обезличенные значения;
5. исходная база не превращается во временную "грязную" копию.
Такой подход особенно удобен, если база большая, а регулярное создание промежуточных копий занимает много времени и дискового пространства.
Общая схема работы
Работу с pg_anon удобно разделить на несколько этапов.
Сначала устанавливается утилита и подготавливается отдельное окружение, из которого она сможет подключаться к PostgreSQL. Затем выполняется инициализация: создаются необходимые служебные объекты и конфигурация.
После этого проводится разведка. На данном этапе инструмент анализирует структуру базы, таблицы, столбцы, типы данных и связи между объектами. Результаты помогают определить, какие поля действительно требуют обработки.
Следующий шаг - создание мета-словаря. В нём описываются правила маскирования: какие поля включать в обработку, какие исключать, какие функции использовать и какие значения считать чувствительными.
Завершается процесс формированием обезличенного дампа и проверкой результата на тестовом стенде.
Типы данных и правила обработки
В PostgreSQL встречаются разные типы, поэтому для каждого из них требуется подходящая стратегия.
Значения `bytea` могут содержать бинарные данные, файлы, изображения или сериализованные структуры. Их нельзя безопасно обрабатывать как обычный текст: сначала нужно понять назначение поля и выбрать замену, сохраняющую допустимый формат.
Тип `numeric` используется для сумм, количественных показателей, номеров и идентификаторов. Важно отличать финансовые значения от технических чисел. Для одних полей потребуется случайная величина в заданном диапазоне, для других - сохранение длины и формата.
Текстовые поля, включая `mvarchar`, обычно маскируются заменой строк с сохранением требуемой длины, набора символов или общей структуры. Для ФИО можно генерировать новые имена, для телефонов - номера в том же формате, а для электронной почты - синтетические адреса.
Для `timestamp without time zone` применяется генерация новых дат и времени. Иногда достаточно сдвинуть исходное значение на случайный интервал, а иногда необходимо полностью заменить временную шкалу, чтобы нельзя было восстановить реальную хронологию событий.
Булевы поля обычно не содержат персональной информации, но в отдельных прикладных сценариях даже их обработка может быть необходима. Например, значение флага способно раскрыть статус клиента, наличие задолженности или участие в специальной программе.
Особое внимание нужно уделять ссылочным полям. Простая замена идентификатора может нарушить связи между таблицами. Поэтому значения должны обрабатываться согласованно: одинаковая исходная ссылка должна превращаться в одинаковую новую ссылку во всех зависимых объектах.
Формирование мета-словаря
Мета-словарь определяет правила обработки данных. В нём можно указать:
- конкретные таблицы и столбцы;
- шаблоны имён полей;
- условия включения и исключения;
- регулярные выражения;
- фиксированные константы;
- пользовательские функции;
- сенситивные типы данных;
- правила для отдельных схем или групп объектов.
Условия включения позволяют автоматически находить поля, соответствующие признакам чувствительных данных. Например, в обработку можно включить столбцы, в названии которых встречаются фрагменты `phone`, `email`, `address`, `passport` или их аналоги, если это соответствует соглашениям конкретной базы.
Условия исключения необходимы для защиты от ложных срабатываний. Поле с названием, похожим на персональные данные, может использоваться для технического идентификатора и не нуждаться в маскировании.
Регулярные выражения помогают описывать сложные правила: формат телефона, банковского счёта, адреса электронной почты, номера документа или IP-адреса. Это позволяет сохранять внешний вид данных, не оставляя в них реальные значения.
Константы подходят для случаев, когда исходное значение не должно сохраняться даже в изменённом виде. Например, все пароли можно заменить единой безопасной строкой, а внутренние адреса серверов - на нейтральные значения тестового контура.
Разведка и уточнение правил
Перед массовой обработкой полезно выполнить разведку и внимательно изучить её результаты. Автоматический анализ не заменяет эксперта: одинаково названные поля в разных конфигурациях могут иметь совершенно разное назначение.
На этом этапе следует проверить:
- где действительно хранятся персональные данные;
- какие таблицы содержат копии одних и тех же сведений;
- какие поля участвуют в связях;
- не осталось ли чувствительных значений в комментариях и дополнительных реквизитах;
- какие реквизиты используются внешними интеграциями;
- не нарушится ли работа прикладных механизмов после замены.
После анализа правила уточняются. Часть полей добавляется в обработку вручную, для других задаются исключения. В результате формируется не универсальный, а адаптированный под конкретную конфигурацию профиль анонимизации.
Маскирование и проверка результата
После настройки выполняется выгрузка. Важно проверить не только отсутствие очевидных ФИО и телефонов, но и косвенные признаки раскрытия данных: уникальные названия организаций, реальные домены, номера договоров, банковские реквизиты, адреса инфраструктуры и сочетания значений, по которым можно идентифицировать клиента.
Обезличенную базу необходимо восстановить в отдельном тестовом окружении и проверить:
- запуск 1С и подключение пользователей;
- открытие основных разделов;
- проведение документов;
- работу отчётов и обработок;
- выполнение фоновых заданий;
- обмены с внешними системами;
- корректность ссылок и регистров;
- отсутствие ошибок из-за нарушения форматов.
Не следует считать процедуру завершённой только после успешного формирования дампа. Важен функциональный тест восстановленной базы: маскирование не должно превращать её в набор формально корректных, но непригодных для разработки данных.
Расширенные возможности
Для сложных проектов полезно разделять белые и чёрные списки. Белый список задаёт объекты, которые разрешено обрабатывать, а чёрный исключает таблицы и поля из автоматического анализа. Это снижает вероятность случайной обработки системных или служебных данных.
Можно отдельно формировать дамп структуры и дамп данных. Такой режим удобен, если структура уже развёрнута на тестовом стенде или данные требуется обновлять регулярно без повторного создания схемы.
При необходимости создаются собственные функции маскирования. Они позволяют учитывать бизнес-правила: сохранять контрольную цифру, длину реквизита, маску номера, взаимосвязь между несколькими полями или согласованность значений в разных таблицах.
Например, для контрагента можно заменить название, ИНН, телефон и электронную почту так, чтобы все новые значения относились к одной синтетической организации. Для сотрудника аналогично можно согласованно изменить ФИО, логин, email и связанные кадровые реквизиты.
Практические рекомендации
Перед первым запуском стоит составить карту данных: перечислить таблицы, ответственных владельцев информации и категории риска. Это помогает не полагаться исключительно на названия столбцов и заранее определить зоны, которые требуют ручной проверки.
Правила маскирования желательно хранить отдельно от самой базы и версионировать. Тогда изменения можно отслеживать, возвращаться к рабочей конфигурации и воспроизводить одинаковый результат для разных выгрузок.
Для регулярных операций полезно автоматизировать запуск pg_anon по расписанию. При этом доступ к продуктивной базе должен быть минимальным: отдельная учётная запись, права только на чтение и журналирование подключений.
Наконец, обезличивание не отменяет требования к защите самого тестового контура. Даже синтетическая база может содержать служебные настройки, структуру бизнес-процессов или фрагменты данных, не попавшие под правила. Поэтому доступ к результату также следует ограничивать, а перед передачей внешнему подрядчику проводить контрольную проверку.
Заключение
pg_anon позволяет выстроить более безопасный и технологичный процесс подготовки баз 1С для разработки. Рабочая база не изменяется, промежуточная копия с реальными сведениями не создаётся, а обезличивание выполняется на этапе формирования дампа.
Инструмент особенно полезен там, где требуются регулярные обновления тестовых сред, большие объёмы данных и строгий контроль над персональной и коммерческой информацией. Однако максимальный результат достигается только при сочетании автоматической разведки, грамотно составленного мета-словаря, ручной проверки чувствительных полей и обязательного функционального тестирования восстановленной базы.