В типовых конфигурациях 1С, таких как Управление торговлей (УТ 11), Бухгалтерия предприятия (БП 3.0) или Зарплата и управление персоналом (ЗУП 3.1), часто возникает специфическая задача по защите персональных данных (ПДн). С одной стороны, рядовым сотрудникам (например, кладовщикам или менеджерам по продажам) необходимо выбирать физических лиц в документы для оформления выдачи спецодежды, доверенностей или учета доставок. С другой стороны, согласно требованиям безопасности и ФЗ-152, эти же сотрудники не должны иметь доступа к паспортным данным, адресам регистрации и телефонам этих лиц.
Проблема заключается в том, что стандартная роль ЧтениеФизическихЛиц или аналогичные права на чтение справочника обычно позволяют пользователю открыть карточку элемента (форму объекта) и увидеть все реквизиты. Разберем по шагам, как решить эту задачу, минимизируя вмешательство в типовую конфигурацию и обеспечивая надежную защиту данных.
Проанализируем самый быстрый способ реализации — запрет открытия основной формы элемента для пользователей, не обладающих специальной ролью. Чтобы не снимать конфигурацию с поддержки, мы будем использовать механизм расширений.
Рассмотрим алгоритм действий:
ПросмотрПерсональныхДанныхФизЛиц.ФизическиеЛица.ПриСозданииНаСервере.Посмотрим на пример кода, который необходимо разместить в расширении:
&НаСервере
&После("ПриСозданииНаСервере")
Процедура Защ_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверяем наличие специальной роли у текущего пользователя
Если Не РольДоступна("ПросмотрПерсональныхДанныхФизЛиц") Тогда
// Если роли нет, выводим сообщение и блокируем открытие формы
ОбщегоНазначенияКлиентСервер.СообщитьПользователю("У вас недостаточно прав для просмотра детальной информации физического лица.");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Этот метод эффективен против обычных пользователей, которые пытаются "кликнуть" на человека в списке. Однако, как верно заметили участники обсуждения, он не защищает от получения данных через универсальные отчеты или консоль запросов.
Выясним более элегантный способ, который позволяет не просто запретить доступ, а показать пользователю "безопасную" версию карточки. Для этого мы можем создать в расширении свою форму (например, ФормаПросмотраОграниченная), где будут выведены только ФИО и, допустим, табельный номер.
Для подмены формы воспользуемся обработчиком ОбработкаПолученияФормы в модуле менеджера справочника ФизическиеЛица. Это позволит системе автоматически решать, какую форму показать в зависимости от прав доступа.
Процедура ОбработкаПолученияФормы(ВидФормы, Параметры, ВыбраннаяФорма, СтандартнаяОбработка)
// Нас интересует только форма объекта
Если ВидФормы = "ФормаОбъекта" Тогда
// Если у пользователя нет полных прав на просмотр ПДн
Если Не РольДоступна("ПросмотрПерсональныхДанныхФизЛиц") Тогда
// Подменяем стандартную форму на нашу "легкую" форму из расширения
ВыбраннаяФорма = "Справочник.ФизическиеЛица.Форма.ФормаПросмотраОграниченная";
СтандартнаяОбработка = Ложь;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Преимущество этого метода: пользователь не получает раздражающую ошибку "Отказ", а видит данные, которые ему разрешены. Это сохраняет комфорт работы, но закрывает доступ к чувствительной информации.
Проанализируем наиболее фундаментальный подход. Платформа 1С:Предприятие 8.3 позволяет настраивать RLS (Record Level Security) не только на записи целиком, но и на конкретные реквизиты (поля). Это "золотой стандарт" безопасности, так как ограничение работает на уровне СУБД.
Рассмотрим, как настроить это в роли:
ФизическиеЛица.Чтение.ДатаРождения, ИНН, КодИМНС и т.д.).ГДЕ Ложь (или другое условие, ограничивающее доступ).Важный нюанс: при использовании RLS по полям, если пользователь без прав попытается построить отчет по защищенным полям, он увидит в них пустые значения или NULL, вместо ошибки доступа. Это полностью решает проблему "типовых отчетов", упомянутую в дискуссии.
Разберем ситуацию в конфигурациях на базе БСП (ЗУП, УТ 11). В разделе Администрирование -> Настройки пользователей и прав существует возможность включить "Ограничение доступа на уровне записей".
Для справочника физических лиц можно включить доступ по Группам доступа физических лиц:
Однако, если кладовщику все же нужно выбирать именно сотрудников, этот метод может быть избыточным, так как он полностью скроет записи из списка. Поэтому комбинация Метода 2 (подмена формы) и Метода 3 (RLS по полям) является наиболее сбалансированной.
Подводя итог, можно сказать, что выбор метода зависит от критичности требований безопасности в вашей организации:
ПриСозданииНаСервере через расширение.RLS на уровне отдельных полей справочника.Не забывайте также про встроенные возможности логирования. В типовых решениях можно включить "Регистрацию событий доступа к персональным данным" (в журнале регистрации), что позволит постфактум проверить, кто и когда просматривал карточки физических лиц, даже если у них был на это доступ.