Персональные данные в базе 1С: карта мест перед тем, как копия уедет наружу
Иван Недомолков · Опубликовано:
Копию рабочей базы 1С рано или поздно отдают наружу: подрядчику на доработку, тестировщику, на тестовый сервер, куда ходит пол-отдела. Вопрос “что в ней надо спрятать” обычно решают за пять минут: справочник физических лиц, сотрудники, может быть контрагенты. На этом список заканчивается.
Он заканчивается рано. Когда наш анонимизатор базы строил карту персональных данных на одной рабочей базе, он насчитал 164 объекта, в которых лежат ФИО, номера, адреса или телефоны. Карта строилась в режиме чтения, и журнал регистрации это подтверждает: за время построения ни одного изменения данных, только читающие транзакции. Ниже разбираем, из чего складываются эти полторы сотни и как составить такую карту для своей базы.
Где лежат персональные данные: карта по местам
Удобнее идти по видам хранения: объектов метаданных сотни, а видов хранения меньше десятка, и у каждого свой способ защиты.
| Где | Что там обычно | Что с этим делать |
|---|---|---|
| Справочники физлиц, сотрудников, контрагентов | ФИО, ИИН, адреса, телефоны, почта | подменять правдоподобными значениями той же длины и формата |
| Банковские счета и реквизиты | номера счетов, ИИН и БИН получателей | подменять с сохранением длины и контрольной суммы |
| Реквизиты документов | ФИО и номера, попавшие в документ при заполнении | искать по содержимому: по имени такие реквизиты не опознать |
| Группы справочников | название папки, которое по виду не отличить от имени | отличать группу от элемента на уровне объекта, иначе папка получит вымышленное ФИО |
| Версии объектов, история данных | старые значения тех же реквизитов в двоичном виде | подменять не берёмся, только удаляем без возврата |
| Присоединённые файлы, безопасное хранилище | содержимое файлов, секреты | то же: удалить, если копия уходит наружу |
| Журнал регистрации | имена пользователей и их действия | чистится только вручную администратором, встроенный язык до него не дотягивается |
Две строки таблицы стоит прочитать дважды.
С двоичными данными выбор один: удалить. Версии объектов и история данных хранятся в двоичном виде, и подменять ФИО внутри них так же надёжно, как в обычном реквизите, мы не берёмся. Удаляя их, помните, что назад в копию эти данные уже не вернутся.
Журнал регистрации живёт отдельно от данных: в клиент-серверном варианте это файлы в каталоге кластера серверов 1С. В бэкап СУБД и в выгрузку .dt он не попадает. Если копию отдают бэкапом, журнал остаётся дома. Если отдают каталог сервера целиком, с ним уезжают имена и действия всех живых пользователей.
Почему поиск по имени реквизита промахивается
Первое, что приходит в голову: пройти по метаданным и собрать реквизиты, в имени которых есть “ИИН”, “ФИО”, “Адрес”, “Телефон”. Мы начинали так же, и на двух базах подряд этого хватило. Первый промах случился на свежей копии рабочей Бухгалтерии для Казахстана, а дальше нашлись и обратные.
Имя молчит, а внутри персональные данные. Номер физлица в этой базе хранился в реквизите ИдентификационныйКодЛичности. Ни одного искомого слова в имени нет, и живые двенадцатизначные ИИН остались бы в копии, которую отчёт объявил бы чистой.
Имя обещает, а внутри другое. Реквизит НаименованиеПолное у контрагента-юрлица по смыслу похож на имя человека, а внутри название организации. Формы собственности тоже надо знать все: ТОО и АО распознать несложно, а ОсОО или сокращение “ГК” легко пропустить, и тогда организация получает вымышленное ФИО.
Формат обманывает. Справочник товарных кодов на 8 047 328 записей попал в разбор из-за десятизначных кодов, похожих на номер налогоплательщика, и в оценке времени давал 37 % от 101 часа работы. Двенадцать цифр тоже не гарантия: это и ИИН, и БИН, и штрихкод UPC-A, которого в торговой базе сотни тысяч.
Подробный разбор этих дыр с кодом проверки контрольной суммы есть в статье об обезличивании данных 1С. Здесь важен вывод: имя реквизита годится для первого отбора, а решение принимается по содержимому.
Как составить карту для своей базы
Порядок, который работает на любой конфигурации:
- Соберите все строковые реквизиты справочников, документов и их табличных частей. Список будет длинным, это нормально.
- Из каждого возьмите выборку значений, сотни строк хватает. Смотрите на форму: цифры определённой длины, слова с заглавной буквы через пробел, символ
@, адресные сокращения. - Номера проверяйте контрольной суммой, но с поправкой на жизнь. В живых базах ИИН с опечаткой встречается, и он всё равно остаётся ИИН. Для двенадцатизначных номеров проверку разумно ослабить, а штрихкоды исключать по конкретному объекту метаданных.
- Отделите организации от людей по списку форм собственности, в котором есть все страны ваших контрагентов.
- Запускайте разбор под полными правами. Под ограничением доступа на уровне записей скрипт увидит часть строк и честно отчитается об успехе по этой части.
Как проверить копию перед отправкой
Отчёт инструмента перечисляет то, что он заменил. Того, что он не распознал, в отчёте нет по определению. Поэтому последняя проверка ручная: откройте копию и пройдите глазами по справочникам и паре документов с каждого участка учёта.
Вторая проверка числовая. Суммы, количества и даты при обезличивании не трогаются, иначе копия перестаёт быть похожей на рабочую базу. Значит оборотно-сальдовая ведомость до и после обязана совпасть до копейки. Не совпала - значит задето то, что трогать было нельзя.
И третья, про то, чего обезличивание не закрывает. Настоящие суммы остаются, а по сочетанию косвенных признаков (должность, дата приёма, размер начисления) человека иногда можно узнать и без фамилии. Если копия уходит за периметр надолго, это повод договориться с подрядчиком ещё и о сроке, после которого копия удаляется.
Когда нужна обратимость
Для тестового сервера внутри компании достаточно заменить данные один раз. С подрядчиком сложнее: его доработку потом принимают на настоящих цифрах, и бухгалтерии нужно сверить расчёт с тем, что было. Тут нужна замена с файлом соответствий, по которому данные возвращаются обратно.
Полный круг “заменить, вернуть, сверить” мы прогоняли дважды, и на копии рабочей Бухгалтерии для Казахстана он замкнулся без потерь: 211 440 замен, все вернулись, 125 контрольных значений из 125 совпали посимвольно. Файл соответствий при этом сам становится персональными данными и хранится отдельно от копии, никогда не в том же архиве.
Копию для теста удобно поднимать из ночного бэкапа рабочей базы: как это устроено и почему тест отстаёт, разобрано в статье про тестовую базу, которая отстала от рабочей. Обезличивание встаёт в ту же цепочку следующим шагом, перед тем как копию кто-то откроет.
