Поговорим про псевдонимизацию?

Есть довольно типичная ситуация в проектах на 1С. На рабочей базе возникает ошибка или нужно доработать нетиповой сценарий. Разработчику желательно получить именно копию базы: на демо-базе ошибка может не воспроизводиться. И тут появляется неприятный вопрос: что еще мы передаем вместе с этой копией?

ФИО сотрудников и клиентов, телефоны, адреса, ИНН, банковские реквизиты, начисления зарплаты, комментарии пользователей — все это легко оказывается на сервере подрядчика или компании-франчайзи. А потом копия может путешествовать между разработчиками, виртуальными машинами и резервными серверами значительно дольше, чем существует сама задача.

Можно удалить чувствительные данные полностью. Но тогда мы получим уже другую базу, на которой часть исходных сценариев проверить невозможно. Мы попробовали другой подход: обратимую псевдонимизацию базы 1С. То есть перед передачей копии заменять реальные персональные данные правдоподобными синтетическими значениями, сохраняя структуру и связи внутри базы, а после работы подрядчика — при необходимости возвращать исходные значения обратно.

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

Почему просто заменить ФИО на «Иванов Иван Иванович» недостаточно?

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

• в справочнике физических лиц;

• у сотрудника;

• в кадровых документах;

• в документах начисления;

• в контактной информации;

• в регистрах;

• в комментариях и дополнительных реквизитах.

Если в каждом месте генерировать случайное значение независимо, мы разрушим связи в данных. Условный Иванов Иван Иванович превратится в одном объекте в Петрова Анна, в другом — в Сидорова Ольга, а в третьем — еще во что-нибудь. Поэтому основное правило у нас другое:

Одному исходному значению во всей базе соответствует один псевдоним.

За счет этого группировки, повторяемость значений и логика документов не должны разваливаться. При этом суммы, количества, даты и номера документов не изменяются.

Например:

Иванов Иван Иванович -> Соколов Максим Олегович
+7 999 123-45-67     -> +7 916 482-31-05
ivanov@example.ru    -> sokolov@example.ru

Если исходный телефон встретился в базе двадцать раз, все двадцать вхождений должны получить одно и то же синтетическое значение.

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

Почему решение не привязано к конкретной конфигурации

Вторая проблема мира 1С это разнообразие конфигураций. Можно написать отдельные правила для Бухгалтерии, ЗУП или ERP. Но почти в каждом крупном проекте появляются расширения, дополнительные справочники, собственные регистры и реквизиты с названиями вроде:

Контакт
МобильныйТелефон
ТелефонДляСвязи
ФИОКлиента
Получатель
ОтветственныйПредставитель
Комментарий

Поэтому привязка только к известным объектам типовой конфигурации быстро перестает работать. В нашем случае обработка идет через метаданные 1С и содержимое информационной базы, без прямого обращения к СУБД. Она ищет потенциальные персональные данные по именам реквизитов и самим значениям. Среди распознаваемых типов — ФИО, ИНН, адреса, телефоны, email, банковские реквизиты и свободный текст; технические коды и UUID от такого анализа отсеиваются. Это позволяет работать в том числе с самописными объектами, а не только с заранее известным набором справочников и документов.При этом мы специально не формулируем это как «автоматика найдет вообще все». К этому ограничению еще вернемся.

Процесс можно разбить на пять этапов.

1. Найти потенциальные персональные данные

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

2. Построить правила замены

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

original value -> pseudonym

Оригинальное значение в рамках одной обработки всегда получает одинаковую замену.

3. Изменить копию базы

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

4. Сохранить таблицу соответствий отдельно

Чтобы потом можно было выполнить обратный ход, соответствия между исходными значениями и псевдонимами нужно где-то сохранить. Но хранить их внутри той же базы бессмысленно: если подрядчик получает и копию, и таблицу соответствий, вся схема теряет смысл. Поэтому соответствия записываются в отдельный защищенный датасет, который остается у владельца базы. В реализации для него используются AES-256 и SHA-256. Фактически этот датасет нужно рассматривать как ключ к деанонимизации базы.

Передавать его подрядчику вместе с копией нельзя.

Пароль датасета также не хранится. Если его потерять, выполнить автоматический обратный ход уже не получится.

5. При необходимости вернуть исходные значения

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

После обычного необратимого затирания остаются два варианта:

1. поверить, что исправление сработает на рабочей базе;

2. снова воспроизводить проблему на исходной базе.

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

А как проверить, что обратный ход действительно работает?

Обратимость плохое место для тестирования в стиле «на глаз вроде нормально». Поэтому мы прогоняли полный цикл:

исходная база
     |
     v
псевдонимизация
     |
     v
измененная база
     |
     v
восстановление
     |
     v
сравнение с исходными значениями

Проверки выполнялись на нескольких информационных базах:

Для контрольных значений до обработки сохранялась привязка к UUID, а после восстановления выполнялось посимвольное сравнение.

В трех тестах совпадение контрольных наборов составило соответственно:

• 132/132;

• 54/54;

• 125/125.

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

106 031 объект
215 642 замены
0 ошибок записи

215 642 / 215 642 значений восстановлено
0 ошибок записи
0 спорных мест

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

Где заканчивается автоматика

Здесь начинается часть, которую в продуктовых описаниях обычно хочется сделать мелким шрифтом. Но для такого инструмента она важнее списка преимуществ. Автоматически найти 100% персональных данных нельзя гарантировать. Можно анализировать названия реквизитов, типы значений, содержимое строк и метаданные. Но всегда может существовать что-нибудь вроде:

Комментарий = "Перезвонить Сергею Петровичу после 18:00"

или самописный реквизит:

ДопПоле17

с чувствительным содержимым.

Поэтому результат автоматического обнаружения нужно проверять глазами до передачи базы. Сам инструмент показывает найденные области и предварительный результат именно для этого.

Не все в базе можно безопасно восстановить

Версии объектов, история, присоединенные файлы и различные секреты относятся к так называемым двоичным хвостам. Для них предусмотрено удаление, но не обратимая подмена. Причем такие операции по умолчанию отключены.

Журнал регистрации — отдельная история

Он очищается вручную. Обработка предупреждает об этом и показывает необходимый порядок действий, но сама задача не исчезает.

Псевдонимизация не исключает косвенную идентификацию

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

Модель угроз получается довольно простой

В итоге мы исходим из следующей схемы.

Подрядчик получает:

псевдонимизированную копию 1С

У владельца остаются:

исходная рабочая база
+
датасет соответствий
+
пароль от датасета

При этом датасет соответствий должен защищаться не менее внимательно, чем сама исходная информационная база: внутри него находятся реальные значения. То есть само наличие AES-256 проблему организационной безопасности не решает.

Если положить рядом:

database.dt
mapping.zip
password.txt

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

Что с совместимостью

На момент описанных проверок ограничения такие:

• платформа 1С 8.3.20 и выше;

• проверялись версии 8.3.20 и 8.3.27;

• требуется управляемое приложение;

• обычные формы, в частности УПП, УТ 10, КА 1.1 и БП 2.0, не поддерживаются;

• требуются полные права;

• при включенном RLS обработка не запускается;

• поддерживаются файловые и клиент-серверные базы.

То есть это не универсальный механизм для любой исторической базы 1С.

Почему мы не стали делать прямую обработку на уровне SQL

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

максимальная скорость
        vs
переносимость между конфигурациями

В этом инструменте приоритет отдан второму варианту.

Что в итоге

Изначально задача звучала довольно узко:

Как отправить подрядчику копию базы 1С и не отправить ему реальные персональные данные?

Но довольно быстро выяснилось, что простая генерация случайных ФИО проблему не решает.

Чтобы копия оставалась полезной, нужно одновременно:

• найти чувствительные данные в незнакомой конфигурации;

• сохранить повторяемость значений и связи;

• не разрушить бизнес-показатели;

• показать пользователю результат до передачи;

• отдельно защитить таблицу соответствий;

• уметь продолжать обработку после остановки;

• проверить полноценный обратный цикл;

• честно обозначить данные, которые автоматикой гарантированно обнаружить или восстановить нельзя.

Получается не столько «генератор случайных ФИО», сколько отдельный процесс подготовки диагностической копии базы.

И, пожалуй, главный вывод после реализации: в такой задаче важнее не обещание «мы все найдем автоматически», а возможность увидеть, что именно будет отправлено за пределы контура, до того как это произойдет.

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