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