← На главную

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

Посмотрим на эту ситуацию подробнее и разберем по шагам, какие архитектурные подходы и программные инструменты помогут нам реализовать безопасное обновление тестовых баз.

Использование изолированной «буферной зоны»

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

1. Подготавливаем отдельный, полностью изолированный сервер СУБД и сервер 1С (буферную зону). Доступ к этому серверу имеет только узкий круг DevOps-инженеров или сервисные аккаунты системы CI/CD.
2. Восстанавливаем резервную копию рабочей базы в эту изолированную среду.
3. В режиме Предприятия запускаем обработку обезличивания данных (например, штатную СкрытиеКонфиденциальнойИнформации.epf или самописную). В этой зоне отключены регламентные задания, чтобы база случайно не отправила письма клиентам или не выполнила обмены с другими рабочими системами.
4. После успешного завершения очистки делаем бэкап уже «чистой» (анонимизированной) базы.
5. Восстанавливаем этот безопасный бэкап на общедоступном тестовом сервере, где работают программисты и тестировщики.

Такой подход полностью исключает человеческий фактор и предотвращает случайный вход разработчиков в необработанную ИБ.

Автоматизация блокировок через утилиты RAS и RAC

Рассмотрим еще один современный подход для автоматизации пакетного запуска и блокировок, если буферный сервер создать невозможно. В современных CI/CD пайплайнах мы можем управлять кластером программно.

Разберем процесс по шагам:

1. Сразу после восстановления базы средствами СУБД, специальный скрипт через консоль администратора RAC обращается к службе RAS и устанавливает блокировку начала сеансов на данную информационную базу.
2. При установке блокировки скрипт задает Код разрешения. Это гарантирует, что ни один обычный пользователь не сможет войти в ИБ.
3. Далее скрипт запускает клиент 1С в пакетном режиме, передавая ключи запуска. Используется ключ /UC для обхода блокировки, а также ключи /Execute для вызова внешней обработки обезличивания и /C для передачи ей параметров.
4. Робот (единственный сеанс в базе) проводит замену реальных наименований, ИНН, телефонов на фиктивные данные.
5. После штатного завершения работы робота, скрипт через RAC снимает блокировку, открывая доступ разработчикам.

Использование монопольных обработчиков БСП

Посмотрим на пример, основанный на механизмах Библиотеки Стандартных Подсистем (БСП). В конфигурации можно предусмотреть предопределенные обработчики, которые срабатывают до старта основного интерфейса.

Как это реализовать внутри 1С:

1. Создаем в базе служебного пользователя, который обладает полными правами.
2. В модуле сеанса или при начале работы системы прописываем проверку: если база запускается под этим специальным пользователем, и система определяет, что это копия (например, по имени сервера), запускается процедура обработки в монопольном режиме.
3. Перед развертыванием бэкапа крайне важно отключить регламентные задания на кластере 1С для новой базы. Либо в самих самописных регламентных заданиях добавить строгую проверку на то, является ли текущая база рабочей (прод-средой).

Обезличивание на уровне СУБД для сверхбольших баз

Выясним причину, по которой иногда приходится отказываться от штатных средств 1С. Если ваша база весит сотни гигабайт или терабайты, стандартная обработка 1С может перебирать и перезаписывать справочники сутками. Заказчики и админы не могут ждать столько времени для получения тестового контура.

В исключительных случаях применяется обезличивание прямыми SQL-запросами. Хотя прямое вмешательство в таблицы СУБД не рекомендуется и может нарушать лицензионное соглашение, для автоматизации подготовки тестов этот способ применяется часто:

1. До выгрузки рабочей базы система автоматически считывает текущую структуру метаданных 1С (определяет соответствие таблиц SQL объектам метаданных, таким как Справочник.Контрагенты или Справочник.ФизическиеЛица).
2. Динамически формируются скрипты, состоящие из массовых операций UPDATE, где реальные строковые значения заменяются на случайно сгенерированные хэши или стандартные значения (например, "Контрагент_1").
3. Скрипт отрабатывает на восстановленной в СУБД копии базы за считанные минуты, еще до того, как база регистрируется в консоли кластера 1С.

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