Персональные данные в 1С: что это значит для бизнеса, который их обрабатывает
Персональные данные в 1С есть у любой компании, где учет сотрудников или клиентов ведется через продукты фирмы 1С. Это не абстрактный риск где-то в облаке, а конкретные таблицы с ФИО, телефонами, паспортными данными, СНИЛС, адресами доставки и историей покупок, которые открываются двойным кликом на рабочем столе бухгалтера или менеджера. Формально 1С здесь ни при чем: программа такой же инструмент, как Excel или бумажная папка с делами. Оператором персональных данных остается компания, которая ее использует, и отвечает за нарушения именно она, а не разработчик конфигурации.
Типовые конфигурации 1С проектировались для удобства учета, а не для защиты данных. Права по умолчанию широкие, журнал действий часто выключен ради скорости работы базы, выгрузка в Excel доступна из любого справочника в два клика. Из-за этого появляется разрыв между тем, что компания написала в политике обработки персональных данных, и тем, что реально происходит внутри базы.
Особенно быстро этот разрыв копится в компаниях, где рядом работают сразу две базы: ЗУП для сотрудников и УТ или Розница для клиентов, а между ними настроен обмен данными. Каждая база по отдельности может быть настроена аккуратно, но сам обмен нередко копирует персональные данные шире, чем это нужно получателю - например, синхронизация подтягивает полную карточку контрагента вместе с паспортными данными туда, где для доставки заказа достаточно было бы имени и телефона.
Разрыв обнаруживается двумя способами. Либо на проверке, когда инспектор спрашивает, кто из сотрудников имеет доступ к персональным данным клиентов и на каком основании, а внятного ответа нет. Либо после утечки, когда выясняется, что база выгружалась на личный ноутбук менеджера якобы для работы из дома полгода назад, и с тех пор никто не знает, где она хранится. Закон возлагает на оператора обязанность принимать организационные и технические меры для защиты персональных данных, а нарушение этой обязанности наказывается по статье 13.11 КоАП РФ. При утечке к этому добавляется обязанность уведомить Роскомнадзор и пострадавших в короткий срок - подробный порядок действий по часам разобран в статье о плане реагирования на утечку персональных данных.
Дальше по порядку: где именно в 1С чаще всего теряют контроль над данными, что с этим делать и как проверить свои базы, если аудита еще не было ни разу.
Права доступа в 1С: где чаще всего теряют контроль над данными
Самая частая ошибка - пользователи заведены с ролью, близкой к Полным правам, потому что так было проще на старте внедрения, и с тех пор никто их не пересматривал. В 1С:Зарплате и управлении персоналом это означает, что менеджер по продажам с обычным логином в базе технически может открыть карточку сотрудника с окладом и паспортными данными. В 1С:Управлении торговлей или 1С:Рознице - что оператор склада видит полную клиентскую базу с телефонами и адресами, хотя для работы ему нужен только состав заказа.
Правильная настройка строится на ролях и профилях групп доступа, которые есть в любой современной конфигурации на платформе 1С:Предприятие 8.3. Дополнительно стоит использовать разграничение прав на уровне записей (RLS) - оно позволяет ограничить не просто доступ к справочнику целиком, а конкретный набор строк в нем: например, менеджер видит только своих клиентов, а не всю базу разом.
Персональные данные сотрудников в ЗУП без лишних глаз
В базе учета зарплаты хранится самый чувствительный набор персональных данных сотрудников: паспортные данные, СНИЛС, ИНН, банковские реквизиты для перечисления зарплаты, иногда сведения о больничных и инвалидности - а это уже специальная категория персональных данных с более строгими требованиями к обработке. Доступ к этим сведениям нужен кадровику и бухгалтеру по расчету зарплаты, и не нужен линейным руководителям, которым для работы достаточно дат отпусков и дисциплинарных отметок.
Типичная находка на аудите: роль Кадровик в свое время скопировали с роли Администратор, чтобы не разбираться с правами при внедрении, и с тех пор ее не сузили. Кто именно должен иметь доступ, на каком основании и кто отвечает за пересмотр прав хотя бы раз в квартал - это стоит закрепить в отдельном документе, а не держать в голове у системного администратора. О том, какие локальные акты для этого нужны компании, подробно разобрано в статье про локальные акты оператора персональных данных.
Персональные данные клиентов в УТ и Рознице: другой набор рисков
Клиентская база в 1С:Управлении торговлей и 1С:Рознице отличается от кадровой тем, что доступ к ней есть у гораздо большего числа сотрудников: не только у бухгалтерии, а у всего отдела продаж, склада, иногда у call-центра на аутсорсе. Риск здесь не столько в отдельных чувствительных полях, сколько в масштабе - уходит не одна карточка, а вся база контактов целиком, если у нее нет ограничения по ответственному менеджеру.
Отдельно стоит проверить учетные записи временных сотрудников и подрядчиков: удаленного бухгалтера, оператора call-центра на подряде, стажера. Такие логины часто заводят с широкими правами один раз в начале сотрудничества и забывают отключить после его окончания, а база тем временем продолжает считать этого человека действующим пользователем с полным доступом к контактам клиентов.
Журналирование в 1С: как узнать, кто и что делал с персональными данными
В 1С есть встроенный журнал регистрации, который фиксирует, кто заходил в базу, какие документы и справочники открывал, что менял. По умолчанию он часто выключен или настроен на минимум записей, потому что подробное журналирование немного замедляет работу базы, и администраторы отключают его, не думая о последствиях для защиты персональных данных.
Журнал регистрации по каждому событию хранит дату, время, пользователя, объект и тип действия - создание, изменение, удаление, а для отдельных справочников можно включить и фиксацию просмотра. Настройка находится в разделе администрирования базы, и по умолчанию 1С не диктует, сколько хранить записи - это решает администратор, и нередко ставит короткий срок, чтобы не раздувать базу лишними данными. Для персональных данных ориентироваться стоит не на удобство хранения, а на срок, за который может прийти запрос от субъекта данных или от Роскомнадзора: разумный минимум - не меньше года.
Без журнала невозможно ответить на два вопроса, которые задают в первую очередь при разборе инцидента: кто из сотрудников обращался к карточке конкретного клиента и когда именно данные могли покинуть систему. Отсутствие журнала не освобождает от ответственности, а только затрудняет расследование и увеличивает риск, что сроки уведомления Роскомнадзора будут нарушены просто потому, что компания не успела разобраться, что произошло.
Практическая настройка: включить журнал хотя бы для справочников Физические лица, Контрагенты и для кадровых документов, установить срок хранения записей журнала не меньше срока, на который заявлена обработка персональных данных в политике, и раз в несколько месяцев выборочно проверять записи, а не полагаться на то, что журнал сам все сохранит и никогда не понадобится.
Выгрузки в Excel и на рабочий стол: скрытый канал утечки персональных данных
Типовая ситуация: менеджеру по продажам нужен список контактов для обзвона, бухгалтеру - список сотрудников для зарплатного проекта в банке, маркетологу - база клиентов для рассылки. В 1С это делается стандартной командой вывода списка в любом справочнике, без дополнительных вопросов и без записи о том, кто и зачем выгрузил данные.
Дальше файл живет собственной жизнью: лежит на рабочем столе неделями, пересылается коллеге через мессенджер, попадает в личное облачное хранилище того, кто его создал. Ни один из этих шагов не проходит через контроль оператора, хотя формально это все та же обработка персональных данных, только за пределами защищенной системы. Похожая проблема возникает при подключении сторонних сервисов к сайту: разбор типичных ошибок при интеграции есть в статье про интеграцию CRM с сайтом - данные утекают из системы учета именно в те моменты, когда никто не думает об этом как об обработке персональных данных.
Похожий риск создают печатные формы. Кадровик распечатывает список сотрудников с окладами для сверки, менеджер выводит на печать список клиентов перед планеркой - и лист остается в лотке общего принтера или в переговорной. Формально это тоже разглашение персональных данных, просто не в электронном виде. Решение здесь не техническое: печать отчетов с чувствительными данными - только на персональный принтер или с уничтожением листа сразу после использования, а не на общий сетевой аппарат в коридоре.
Что стоит сделать: снять право Вывести список и Печать для ролей, которым выгрузка не нужна по работе; там, где выгрузка необходима регулярно, закрепить порядок в локальном акте и требовать удаления файла сразу после использования, а не хранения его на рабочем столе на будущее.
Облачная 1С и локализация баз с персональными данными
Часть компаний перешла на 1С:Fresh или похожие облачные сервисы, где база физически стоит не на офисном сервере, а у стороннего провайдера. Здесь появляется вопрос, который для локальной установки не возникает: где именно расположены серверы, на которых обрабатываются персональные данные российских граждан.
По закону запись и хранение персональных данных россиян, в том числе собранных через интернет, должны вестись на серверах, расположенных на территории России - это отдельная норма о локализации баз данных внутри закона о персональных данных. Для облачной 1С это означает, что нужно прямо спросить провайдера, где физически стоят серверы, а не полагаться на то, что раз сервис называется российским, то и данные точно в России. Похожая проверка нужна при переезде сайта с зарубежного хостинга - что именно проверяют в таком случае, описано в статье о локализации баз данных в РФ.
Проверить размещение серверов можно без глубокого технического аудита: попросить у провайдера письмо или отдельный пункт в договоре о месте размещения оборудования, а не устное заверение менеджера по продажам. Для 1С:Fresh как официального сервиса самой фирмы 1С это, как правило, не проблема - инфраструктура работает на территории России. А вот у сторонних партнеров, предлагающих хостинг 1С в облаке, условия стоит уточнять отдельно: часть таких сервисов исторически строилась на зарубежных мощностях, и переход на российские серверы мог пройти не полностью.
Второй момент - договор с провайдером облачной 1С. Раз данные обрабатывает не сама компания, а внешний сервис, это поручение на обработку персональных данных в чистом виде, и с провайдером должен быть заключен договор с условиями об обработке персональных данных, а не просто акт об оказании ИТ-услуг без упоминания персональных данных вообще.
Резервные копии 1С: где их хранить нельзя
Регламентное задание архивирования в 1С по умолчанию складывает файлы копий в папку на том же сервере или в общую сетевую папку. Для восстановления после сбоя это работает, но с точки зрения защиты персональных данных копия - это полный слепок базы со всеми ФИО, паспортами и телефонами, только без интерфейса разграничения прав поверх нее: у кого есть доступ к папке с файлом копии, у того есть доступ ко всем данным сразу, в обход ролей, настроенных в самой 1С.
Частая находка на аудите: копии синхронизируются в личный облачный диск сотрудника, который в свое время настраивал резервное копирование, чтобы не потерять данные при поломке сервера. Формально это уже передача персональных данных за пределы информационной системы компании, никем не согласованная и никак не защищенная. Разбор похожих случаев и правил хранения копий есть в статье о хранении резервных копий персональных данных.
Стоит проверять не только место хранения копий, но и то, что происходит с ними при удалении данных по запросу субъекта. Если клиент требует удалить свои персональные данные, а компания стирает их только из рабочей базы, оставляя нетронутыми резервные копии за прошлые месяцы, формально обработка данных продолжается. Разумный подход - закрепить в локальном акте, что копии с истекшим сроком хранения не восстанавливают выборочно ради одного клиента, а сам срок хранения копий держать настолько коротким, насколько это позволяет план восстановления после сбоя.
Что стоит сделать: хранить копии на ресурсе с более узким кругом доступа, чем у рабочей базы; шифровать архивы, если это позволяет способ резервного копирования; установить срок хранения копий и удалять устаревшие, а не копить их годами. Это же требование распространяется и на саму рабочую базу: персональные данные нельзя хранить дольше, чем это нужно для целей обработки, заявленных в политике компании.
Защита персональных данных в 1С: чек-лист по ЗУП, Управлению торговлей и Рознице
Свести проблемы по типовым конфигурациям в одну таблицу удобнее, чем держать их в голове по отдельности:
| Конфигурация | Какие персональные данные хранит | Типичное нарушение | Что проверить в первую очередь |
|---|---|---|---|
| 1С:Зарплата и управление персоналом | ФИО, паспорт, СНИЛС, ИНН, банковские реквизиты, иногда сведения о здоровье | Доступ к карточке сотрудника есть у линейных руководителей и офис-менеджера | Роли кадровика и расчетчика настроены отдельно от прав линейных руководителей, доступ к сведениям о здоровье ограничен отдельно |
| 1С:Управление торговлей / 1С:Розница | ФИО, телефон, email, адрес доставки, история покупок | Любой сотрудник видит полную базу контрагентов без ограничения по ответственному менеджеру | Включено разграничение по ответственному менеджеру, право вывода списка снято у ролей, которым оно не нужно |
| CRM-модуль и интеграция с сайтом | Заявки, телефон, email, история обращений | Заявки с сайта попадают в 1С без проверки, что согласие на обработку было получено при отправке формы | В форме на сайте есть чекбокс согласия, а в 1С не сохраняются заявки без него |
| Облачная 1С (1С:Fresh и аналоги) | Все перечисленное выше, но на стороннем сервере | Не проверено, где физически расположены серверы провайдера | Есть договор поручения с провайдером и подтверждение размещения серверов на территории России |
| Резервные копии баз | Полный слепок всех данных выше без разграничения прав | Копии лежат в общей сетевой папке или личном облаке сотрудника | Доступ к папке с копиями уже, чем к рабочей базе, копии шифруются и не хранятся бессрочно |
Закономерность видна сразу: чем больше конфигураций обмениваются данными между собой, тем быстрее исходные настройки ролей теряют смысл, потому что данные копируются туда, где права доступа заново никто не проверял.
Если аудит прав доступа в 1С не проводился ни разу, порядок действий такой:
- Выгрузить список всех пользователей базы и сверить его с текущим штатом - логины уволенных сотрудников и бывших подрядчиков встречаются почти в каждой второй проверке.
- Для каждой роли выписать, к каким справочникам и документам с персональными данными она дает доступ, и сравнить с тем, что человеку действительно нужно по должности.
- Включить журнал регистрации для справочников с физическими лицами и контрагентами, а также для кадровых документов, если он выключен.
- Снять права на вывод списка и печать там, где выгрузка не нужна для работы.
- Проверить, где физически хранятся резервные копии, кто имеет к ним доступ и шифруются ли они.
- Если используется облачная 1С, запросить у провайдера письменное подтверждение размещения серверов в России и заключить договор поручения на обработку персональных данных, если его еще нет.
- Назначить ответственного, который не реже раза в квартал заново сверяет права доступа со списком сотрудников, а не полагается на настройки, сделанные один раз при внедрении.
- Зафиксировать результаты проверки документом - актом или служебной запиской, чтобы на проверке было что показать, а не пересказывать по памяти.
Что делать с персональными данными в 1С: план на ближайший месяц
1С не проектировали как систему защиты персональных данных - это инструмент учета, и то, как в ней настроены права, журналирование и резервное копирование, целиком остается на совести компании, а не разработчика конфигурации. Большая часть перечисленных проблем закрывается не покупкой нового программного обеспечения, а пересмотром ролей и нескольких регламентных заданий: на это уходит несколько дней работы администратора базы, если заранее понятно, что именно проверять: большая часть находок видна сразу, стоит только смотреть по ролям и группам доступа, а не перебирать пользователей поодиночке.
С документами сложнее, чем с настройками программы: разграничение доступа нужно закрепить письменно, порядок действий при инциденте должен существовать до того, как инцидент случится, а облачный провайдер требует отдельного договора, а не устной договоренности. Здесь и полезен взгляд со стороны - когда аудит сайта и внутренних систем компании на соответствие требованиям закона о персональных данных проводит тот, кто регулярно этим занимается и знает, на какие пункты в первую очередь смотрит проверяющий. В такой пакет обычно входят политика обработки персональных данных, положение о разграничении прав доступа, регламент действий при утечке и, если нужно, договор поручения с облачным провайдером - без этого набора техническая настройка ролей и журнала остается только половиной работы.
152fzpro.ru занимается именно такими задачами: аудитом сайтов и внутренних процессов обработки персональных данных, подготовкой необходимых документов и точечными техническими доработками там, где они действительно нужны - без переделки того, что уже работает правильно.
