Как обезличить базу 1С: практическое руководство

Обезличивание (деперсонализация) базы 1С требуется, когда копию рабочей информационной базы нужно передать внедренцу, разработчику, службе поддержки или использовать как тестовый стенд. В базе хранятся персональные данные сотрудников и контрагентов: ФИО, паспортные данные, ИНН, СНИЛС, телефоны, адреса, банковские реквизиты. Передача такой копии третьим лицам без обезличивания — нарушение законодательства о персональных данных и риск утечки коммерческой информации.

Суть обезличивания — заменить реальные значения на сгенерированные «шумовые» данные так, чтобы структура базы, связи между объектами и аналитика сохранились, а восстановить исходные значения было невозможно. При этом документы должны оставаться проведёнными, отчёты — сходиться, а тестовые сценарии — работать.

Ниже разобраны доступные способы: штатные механизмы типовых конфигураций, готовые обработки, самостоятельная разработка и деперсонализация на уровне СУБД. Для каждого варианта указаны ограничения и порядок проверки результата.

Какие данные подлежат обезличиванию

Перед началом работы составьте перечень полей, которые нужно заменить. Минимальный набор для большинства конфигураций: наименования физических лиц и контрагентов-физлиц, ФИО в регистрах сведений «ФИО физических лиц», документы удостоверения личности (серия, номер, кем выдан), ИНН, СНИЛС, адреса регистрации и проживания, телефоны и адреса электронной почты, банковские счета и реквизиты карт.

Отдельная категория — контактная информация контрагентов-юридических лиц. Формально реквизиты организации персональными данными не являются, но телефоны менеджеров, email и имена контактных лиц — являются. Кроме того, заказчик часто просит скрыть и сам список контрагентов, чтобы не раскрывать круг клиентов и поставщиков.

Не забывайте про «скрытые» места хранения: табличные части документов, комментарии, присоединённые файлы (сканы паспортов, договоров), историю изменений, версии объектов, регистры сведений с произвольными строковыми полями. Именно через них чаще всего происходит утечка после «обезличивания».

Подготовка: работаем только с копией

Главное правило: обезличивание выполняется на копии базы, никогда — на рабочей. Для файловой базы достаточно скопировать каталог с файлом 1Cv8.1CD или выгрузить базу в файл .dt через конфигуратор (режим «Загрузка/выгрузка информационной базы»). Для клиент-серверной базы снимите резервную копию средствами СУБД или выгрузку .dt и разверните её под отдельным именем.

Проверьте, что копия открывается и работает: войдите в базу, проведите тестовый документ, сформируйте пару отчётов. Только после этого приступайте к замене данных. Если что-то пойдёт не так, вы всегда сможете заново развернуть копию из исходного файла.

Отключите в копии регламентные задания, обмены с другими системами, отправку почты и синхронизацию с сайтом. Иначе тестовая база может начать рассылать письма реальным клиентам или выгружать обезличенные данные в рабочие системы — это одна из самых неприятных ошибок на практике.

Штатное скрытие данных в типовых конфигурациях

В типовых решениях на базе Библиотеки стандартных подсистем (1С:ЗУП, 1С:Бухгалтерия, 1С:ERP, 1С:Управление торговлей актуальных версий) есть встроенный механизм «Скрытие конфиденциальной информации». Обычно он находится в разделе «Администрирование» → «Обслуживание» или в настройках защиты персональных данных, в зависимости от конфигурации и её версии.

Обработка позволяет выбрать, какие данные скрывать: физических лиц, контрагентов, контактную информацию, документы удостоверения личности. Механизм заменяет значения в справочниках, регистрах сведений и документах, сохраняя целостность ссылок. Файлы вложений при этом обычно не обрабатываются — их нужно чистить отдельно.

1. 1
   Разверните копию базы и отключите обмены и регламентные задания
2. 2
   Откройте Администрирование → Обслуживание → Скрытие конфиденциальной информации
3. 3
   Отметьте группы данных для скрытия: физлица, контрагенты, контактная информация
4. 4
   Запустите обработку и дождитесь завершения
5. 5
   Удалите или очистите присоединённые файлы с персональными данными
6. 6
   Проверьте результат поиском реальных ФИО и ИНН по всей базе

Ограничение штатного механизма: он работает только с объектами, предусмотренными библиотекой. Если конфигурация сильно доработана и персональные данные хранятся в самописных регистрах или справочниках, штатная обработка их не затронет.

Внешние обработки и собственная разработка

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

Собственная обработка даёт максимальный контроль. Типовой алгоритм: перебрать справочники «Физические лица», «Контрагенты», «Пользователи», заменить наименования и реквизиты; пройтись по регистрам сведений с ФИО, документами удостоверения личности, контактной информацией; при необходимости обработать табличные части документов. Для генерации значений используют функции случайных чисел и заранее подготовленные списки вымышленных фамилий и имён.

Генератор = Новый ГенераторСлучайныхЧисел;
Выборка = Справочники.ФизическиеЛица.Выбрать();
Пока Выборка.Следующий() Цикл
    Объект = Выборка.ПолучитьОбъект();
    Объект.Наименование = "Сотрудник " + Формат(Генератор.СлучайноеЧисло(1000, 99999), "ЧГ=");
    Объект.ИНН = "";
    Объект.СтраховойНомерПФР = "";
    Объект.Записать();
КонецЦикла;

Важные нюансы самостоятельной реализации: заменяйте значения детерминированно, где это нужно для логики (один человек — одно новое имя во всех объектах), сохраняйте формат полей (ИНН из 10 или 12 цифр, СНИЛС в маске), иначе проверочные процедуры конфигурации будут выдавать ошибки. Для больших баз выполняйте запись порциями с транзакциями, чтобы не получить тайм-ауты и блокировки.

Обезличивание на уровне СУБД

Для клиент-серверных баз на MS SQL или PostgreSQL иногда применяют прямые UPDATE-запросы к таблицам. Способ быстрый на больших объёмах, но рискованный: структура хранения 1С не документирована для прямой модификации, имена таблиц и полей генерируются платформой, а изменение данных в обход платформы может нарушить служебные механизмы (полнотекстовый поиск, итоги регистров, версионирование).

Использовать SQL-замену оправданно только для точечных задач — например, массово очистить текстовое поле в конкретной таблице — и только при полном понимании структуры хранения. После прямых изменений в СУБД обязательно выполните тестирование и исправление информационной базы и проверьте пересчёт итогов.

Проверка результата и типичные ошибки

После обезличивания выполните контрольную проверку. Возьмите 5–10 реальных ФИО, ИНН и телефонов из исходной базы и выполните поиск по всей базе (в конфигураторе — «Поиск ссылок в объектах» и глобальный поиск по данным, в режиме предприятия — полнотекстовый поиск). Ни одно реальное значение не должно находиться.

Затем проверьте работоспособность: проведите документы, сформируйте регламентированные отчёты, сверку с контрагентом, отчёт по зарплате. Итоги и связи должны сохраниться — обезличивание меняет значения, а не структуру и не суммы (если только заказчик не просил исказить и финансовые показатели).

Юридические и организационные ограничения

Обезличенные данные перестают быть персональными только при необратимости замены. Если где-то хранится таблица соответствия «старое значение — новое значение», данные считаются псевдонимизированными, и требования законодательства о персональных данных к ним сохраняются. Таблицу соответствий либо не создавайте, либо уничтожайте после проверки.

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

Частые вопросы