1C:SRE-Suite: автоматизируем маскирование данных через pg_anon в CI/CD без промежуточных копий

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

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

В третьей части нашего цикла мы рассмотрим, как полностью автоматизировать процесс маскирования многогигабайтных и терабайтных баз данных 1С на СУБД PostgreSQL с помощью бесплатного инструмента pg_anon в рамках автоматического пайплайна, полностью избегая создания небезопасных промежуточных копий на диске. Исходный код проекта доступен на GitHub: NickScherbakov/1c-sre-suite.

Важно: пайплайн работает с изолированной staging-копией СУБД (stage_anonymized_1c), которая создаётся и уничтожается в рамках самого процесса и никогда не публикуется как продуктивная база. Все операции над содержимым информационной базы 1С - включая пост-обработку (сброс паролей, снятие регистрации изменений планов обмена) - выполняются исключительно через объектную модель платформы 1С:Предприятие (headless-запуск обработки, см. раздел ниже), без единого прямого SQL-обращения к таблицам ИБ.

Проблема традиционного подхода к маскированию

Обычный процесс подготовки тестовой базы традиционно состоит из трех последовательных этапов:

1. Выгрузка полного резервного копирования (дампа) продуктивной базы на диск временного сервера.
2. Восстановление этого дампа в промежуточную техническую СУБД.
3. Запуск скриптов очистки и маскирования данных.

Этот классический подход несет в себе три критических инженерных недостатка:

• Угроза безопасности: на протяжении нескольких часов на диске промежуточного сервера в открытом виде хранится точный слепок боевой базы со всеми персональными данными, окладами сотрудников и финансовыми операциями. Любой несанкционированный доступ приведет к полной компрометации защищаемого периметра.
• Дефицит дискового пространства: для терабайтной базы данных 1С:ERP требуется как минимум два, а чаще три терабайта свободного места на staging-сервере.
• Низкая скорость работы: операции записи промежуточного дампа на накопитель и его обратного вычитывания критически замедляют весь цикл подготовки стендов.

Концепция маскирования в потоке (On-The-Fly)

Для решения этих проблем в рамках открытого проекта 1C:SRE-Suite разработан модуль маскирования, который задействует стандартный механизм Unix-пайпов (pipes) для непрерывной потоковой передачи данных между продуктивной и временной базами. Это полностью исключает стадию записи незащищенного дампа на диск.

Ниже приведена схема прохождения данных в нашем автоматизированном скрипте anonymize-pipeline.sh:

1pg_dump -h $DB_HOST -Fc production_1c \
2  | pg_restore -h $DB_HOST -d stage_anonymized_1c

Поток байтов резервной копии продуктивного контура передается по защищенной сети и сразу разворачивается в изолированную временную базу данных, размещенную в СУБД на быстром RAM-диске или скоростном NVMe-накопителе. Дисковая подсистема хоста вообще не задействуется для промежуточных файлов.

Разбор декларативных правил pg-anon-1c.yml

Специфика маскирования баз данных платформы 1С заключается в динамической генерации имен таблиц и полей на уровне СУБД. Вместо понятных названий таблиц физических лиц или регистров адресов мы сталкиваемся с именами вида _Reference112 и _InfoRg1120, а также полями _Fld1004 или _Fld1122.

Конфигурационный файл pg-anon-1c.yml решает эту проблему путем описания точечных правил маскирования для этих специфических таблиц:

 1# pg_anon configuration template for 1C:Enterprise on PostgreSQL
 2# Данный файл описывает правила маскирования персональных данных (PII) в СУБД для сред разработки (Dev/Test)
 3
 4dictionary:
 5  # Словарь для генерации реалистичных замен
 6  first_names: ["Иван", "Петр", "Сергей", "Алексей", "Дмитрий", "Елена", "Мария", "Ольга", "Анна"]
 7  last_names: ["Иванов", "Петров", "Сидоров", "Смирнов", "Кузнецов", "Попова", "Васильева"]
 8
 9rules:
10  # Пример маскирования таблицы физических лиц (например, _Reference112)
11  - table: "_Reference112"
12    columns:
13      # Поле Наименование (обычно содержит ФИО)
14      - name: "_Description"
15        provider: "faker"
16        mask: "last_names + ' ' + first_names"
17      # Поле ИНН (например, _Fld1004)
18      - name: "_Fld1004"
19        provider: "random_digits"
20        length: 12
21      # Поле СНИЛС (например, _Fld1005)
22      - name: "_Fld1005"
23        provider: "hash"
24        salt: "sre_salt_123"
25
26  # Пример маскирования контактной информации (таблица _InfoRg1120)
27  - table: "_InfoRg1120"
28    columns:
29      # Поле Представление (телефон, адрес)
30      - name: "_Fld1122"
31        provider: "faker"
32        mask: "'+7 (999) ' + random_digits(7)"

Использование встроенного провайдера faker позволяет формировать связные, реалистичные и грамматически корректные ФИО, адреса и телефоны. Использование провайдера hash с секретной солью гарантирует, что ИНН и СНИЛС заменяются на уникальные псевдослучайные значения. Это критически важно для сохранения целостности индексов СУБД и уникальности бизнес-ключей в 1С.

Автоматизация конвейера: anonymize-pipeline.sh

Наш скрипт-оркестратор anonymize-pipeline.sh выполняет полный цикл подготовки базы данных под ключ за шесть детерминированных технологических шагов:

1. Создание изолированной базы маскирования: скрипт разворачивает временную СУБД stage_anonymized_1c на сервере маскирования.
2. Потоковое копирование структуры и данных: данные переносятся напрямую из боевой базы через конвейер СУБД pg_dump | pg_restore без дисковых операций.
3. Применение маскирования pg_anon: запускается утилита pg_anon с использованием нашего декларативного файла правил pg-anon-1c.yml.
4. Пост-обработка средствами платформы 1С: на этом шаге сбрасываются пароли пользователей информационной базы и снимается регистрация изменений планов обмена (чтобы staging-копия не начала рассылать тестовые данные в смежные системы). Выполняется headless-запуском 1cv8 ENTERPRISE ... /Execute внешней обработки post-anonymize-1c.epf (исходник — scripts/post-anonymize-1c.bsl), через объектную модель платформы (ИнформационнаяБаза.ПользователиИнформационнойБазы, ПланыОбмена.УдалитьРегистрациюИзменений()) — без единого прямого SQL-обращения к таблицам СУБД.
5. Экспорт готового дамп-файла: очищенная база выгружается в сжатый файл anonymized_dev.dump.
6. Полная деструкция временных ресурсов: база stage_anonymized_1c полностью удаляется из СУБД, гарантируя чистоту окружения.

 1#!/usr/bin/env bash
 2# Скрипт автоматического маскирования базы данных 1С на PostgreSQL с помощью pg_anon
 3# Реализует концепцию: Безопасный пайплайн без промежуточной копии на диске
 4
 5set -euo pipefail
 6
 7# Переменные по умолчанию
 8DB_HOST="${DB_HOST:-localhost}"
 9DB_PORT="${DB_PORT:-5432}"
10DB_USER="${DB_USER:-postgres}"
11DB_PASS="${DB_PASS:-}"
12PROD_DB="production_1c"
13ANON_STAGE_DB="stage_anonymized_1c"
14RULES_FILE="config/pg-anon-1c.yml"
15OUTPUT_DUMP="/workspace/out/anonymized_dev.dump"
16
17# Путь к 1cv8 и к обработке для платформенной пост-обработки (см. post-anonymize-1c.bsl)
18PATH_1C="${PATH_1C:-/opt/1cv8/x86_64/current/1cv8}"
19POST_ANONYMIZE_EPF="${POST_ANONYMIZE_EPF:-scripts/post-anonymize-1c.epf}"
20IB_USER="${IB_USER:-Администратор}"
21IB_PASS="${IB_PASS:-}"
22
23echo "[*] Старт процесса обезличивания базы данных..."
24
25# Шаг 1. Создание изолированной базы данных для маскирования
26echo "[*] Создание staging СУБД: $ANON_STAGE_DB..."
27PGPASSWORD="$DB_PASS" dropdb -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" --if-exists "$ANON_STAGE_DB"
28PGPASSWORD="$DB_PASS" createdb -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -O "$DB_USER" "$ANON_STAGE_DB"
29
30# Шаг 2. Копирование структуры и данных напрямую через конвейер (без сохранения промежуточного дампа на диск)
31echo "[*] Перенос данных из $PROD_DB в $ANON_STAGE_DB в потоке..."
32PGPASSWORD="$DB_PASS" pg_dump -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -Fc "$PROD_DB" \
33  | PGPASSWORD="$DB_PASS" pg_restore -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$ANON_STAGE_DB"
34
35# Шаг 3. Применение правил обезличивания pg_anon
36echo "[*] Запуск маскирования pg_anon..."
37if [ -f "$RULES_FILE" ]; then
38  pg_anon -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$ANON_STAGE_DB" -c "$RULES_FILE"
39else
40  echo "[-] Ошибка: Файл правил $RULES_FILE не найден!"
41  exit 1
42fi
43
44# Шаг 4. Пост-обработка для среды разработки: сброс паролей пользователей ИБ
45# и снятие регистрации изменений планов обмена. Выполняется средствами самой
46# платформы 1С:Предприятие (headless-запуск post-anonymize-1c.epf), а не прямыми
47# SQL-командами к таблицам СУБД - см. scripts/post-anonymize-1c.bsl (исходник
48# обработки) и правила публикации Infostart.ru о прямом доступе к СУБД 1С.
49echo "[*] Выполнение пост-обработки средствами платформы 1С..."
50"$PATH_1C" ENTERPRISE \
51  /S"${DB_HOST}/${ANON_STAGE_DB}" \
52  /N"$IB_USER" /P"$IB_PASS" \
53  /Execute "$POST_ANONYMIZE_EPF" \
54  /DisableStartupDialogs /DisableStartupMessages
55
56# Шаг 5. Экспорт готового обезличенного дампа для разработчиков
57echo "[*] Создание чистого дампа для разработчиков..."
58PGPASSWORD="$DB_PASS" pg_dump -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -Fc -d "$ANON_STAGE_DB" -f "$OUTPUT_DUMP"
59
60# Шаг 6. Удаление временной базы маскирования
61echo "[*] Удаление staging СУБД $ANON_STAGE_DB..."
62PGPASSWORD="$DB_PASS" dropdb -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" "$ANON_STAGE_DB"
63
64echo "[+] Обезличивание успешно завершено! Дамп сохранен в $OUTPUT_DUMP"
65exit 0

Интеграция в сквозной CI/CD-пайплайн

Включение процесса маскирования в общий цикл доставки изменений выполняется добавлением отдельного джоба в наш ранее описанный файл конфигурации. Подробное руководство по контейнеризации и безопасному пробросу лицензий доступно в нашей статье по интеграции CI/CD 1С:Предприятие в Docker. Поскольку процесс маскирования крупной базы данных требует времени, этот шаг рекомендуется настраивать на регламентный ночной запуск по расписанию (cron):

 1  anonymize-db:
 2    name: Nightly Database Anonymization
 3    runs-on: ubuntu-latest
 4    if: github.event_name == 'schedule'
 5    steps:
 6      - name: Checkout repository
 7        uses: actions/checkout@v4
 8
 9      - name: Run Anonymization Script
10        env:
11          DB_HOST: ${{ secrets.PROD_DB_HOST }}
12          DB_PASS: ${{ secrets.PROD_DB_PASSWORD }}
13        run: |\
14          chmod +x scripts/anonymize-pipeline.sh
15          ./scripts/anonymize-pipeline.sh

В результате выполнения этого джоба в защищенном S3-хранилище или на выделенном внутреннем файловом сервере каждую ночь будет обновляться готовый, проверенный и на 100% безопасный файл anonymized_dev.dump. Разработчики смогут скачивать его одной командой и разворачивать на своих локальных машинах, не нарушая регламентов безопасности и коммерческой тайны.

Перспективы развития модуля маскирования

Наш декларативный подход позволяет гибко масштабировать правила маскирования под любую прикладную конфигурацию. В репозитории проекта NickScherbakov/1c-sre-suite мы планируем развивать этот модуль по следующим направлениям:

Мы приглашаем SRE-инженеров, администраторов баз данных и разработчиков принять активное участие в тестировании и контрибьюте в проект! Делитесь опытом, пишите предложения в разделе Issue и присылайте ваши Pull Request'ы в репозиторий NickScherbakov/1c-sre-suite.