При организации работы в программе 1С:Управление производственным предприятием часто возникает конфликт требований: бухгалтеру или кадровику требуются полные персональные данные (включая паспортные данные, адрес и банковские счета), а линейному персоналу (мастерам смен, диспетчерам, начальникам участков) достаточно видеть лишь ФИО работника для формирования нарядов, заявок на ремонт и распределения задач. Требования Федерального закона № 152-ФЗ «О персональных данных» обязывают оператора минимизировать доступ к защищаемой информации. Рассмотрим, как решить эту проблему технически и организационно.
Проанализируем структуру хранения кадровых сведений в типовых конфигурациях на платформе «1С:Предприятие 8». Распространенной ошибкой является предположение, что паспортные данные хранятся непосредственно в карточке сотрудника. На самом деле данные разделены между несколькими объектами конфигурации:
Такое разделение позволяет настроить права на уровне ролей так, чтобы мастер мог выбирать сотрудника в документ без доступа к конфиденциальным сведениям физического лица.
Механизм прав платформы «1С:Предприятие» не позволяет ограничивать права на чтение отдельных реквизитов одного объекта без использования RLS (ограничения доступа на уровне записей). Однако в данном случае данные уже разнесены по разным таблицам базы данных. Разберем по шагам, как выстроить безопасную модель доступа:
ПаспортныеДанныеФизЛиц ошибочно включено в общую роль Пользователь. Если это так, снимем флажок «Чтение» для этого регистра в базовой роли.СотрудникиОрганизаций. Право на чтение регистра ПаспортныеДанныеФизЛиц и справочника ФизическиеЛица у данной роли должно отсутствовать.ПаспортныеДанныеФизЛиц оставляем только в кадровых и расчетных ролях (например, Кадровик, Бухгалтер).СправочникСсылка.СотрудникиОрганизаций, а не СправочникСсылка.ФизическиеЛица. При открытии формы выбора мастер видит список сотрудников с полями: наименование (ФИО), табельный номер и подразделение.Иногда разработчики пытаются решить задачу простым скрытием полей или закладок формы через программный код в событии ПриОткрытии:
// Небезопасный способ ограничения доступа!
Если Не РольДоступна("Кадровик") Тогда
ЭлементыФормы.ПанельДанных.Страницы.Паспорт.Видимость = Ложь;
КонецЕсли;
Обратим внимание: изменение свойства Видимость = Ложь у элементов интерфейса является лишь визуальным ограничением. Если у пользователя есть право «Чтение» на объект метаданных, он сможет прочитать паспортные данные через универсальные отчеты, групповую обработку справочников и документов или внешние печатные формы. Настоящая защита обеспечивается исключительно на уровне прав ролей конфигуратора.
Если мастеру при формировании печатной формы или отчета требуется вывести инициалы или служебные сведения, связанные с физлицом, но прав на чтение у него нет, платформа сгенерирует ошибку нарушения прав доступа. Чтобы избежать этого, такие алгоритмы выносят в общие модули с установленным флажком Привилегированный:
// В привилегированном общем модуле
Функция ПолучитьФИОСотрудникаДляПечати(СотрудникСсылка) Экспорт
УстановитьПривилегированныйРежим(Истина);
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ФизЛицо.Наименование КАК ФИО
|ИЗ
| Справочник.СотрудникиОрганизаций КАК Сотрудники
|ГДЕ
| Сотрудники.Ссылка = &Сотрудник";
Запрос.УстановитьПараметр("Сотрудник", СотрудникСсылка);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
Возврат Выборка.ФИО;
КонецЕсли;
Возврат "";
КонецФункции
Привилегированный режим позволяет безопасно получить строго определенные поля в коде без предоставления пользователю прямого интерактивного доступа ко всей таблице персональных данных.
Разберем правовой аспект взаимодействия с персональными данными:
Таким образом, для надежного закрытия персональных данных необходимо исключить доступ к регистру ПаспортныеДанныеФизЛиц из базовых ролей, настроить работу мастера только через справочник СотрудникиОрганизаций и закрепить разграничение обязанностей локальными нормативными актами организации.