Как ограничить доступ пользователей к отчетам по подразделениям в 1С?

Ограничение доступа к данным в отчетах — частая задача при разработке систем на платформе 1С. Когда возникает необходимость сделать так, чтобы пользователь «Мастер» видел данные только своего подразделения, а «Работник» — только свои, важно выбрать правильный архитектурный подход. Давайте разберем, какие варианты существуют и в чем заключаются их особенности.

Вариант 1: Использование механизма RLS (Row Level Security)

Самым надежным способом обеспечения безопасности данных является использование механизма ограничения доступа на уровне записей (RLS). Это штатный функционал платформы 1С, который позволяет задавать условия доступа непосредственно к таблицам базы данных (регистрам, справочникам, документам).

Преимущества RLS:

1. Глобальная защита: Как только вы настроите права, данные будут защищены во всех отчетах, консолях запросов и даже при попытке открытия объекта напрямую. Вам не придется дорабатывать каждый отдельный отчет.
2. Надежность: Это защита на уровне СУБД или ядра платформы, которую невозможно обойти через настройки внешних отчетов или пользовательские настройки СКД.

Как это работает:

В конфигураторе в роли настраиваются ограничения доступа. Вы указываете шаблон, например, по полю Подразделение. Если у пользователя нет права доступа к конкретному подразделению, платформа автоматически исключит соответствующие записи из выборки любого запроса. Важно помнить, что RLS требует корректной настройки прав для каждого регистра, к которому обращаются отчеты.

Вариант 2: Программное наложение отборов в отчетах на СКД

Если задача заключается не в жестком обеспечении безопасности, а в удобстве интерфейса для рядового пользователя, можно воспользоваться программным наложением отборов. Чаще всего отчеты в современных конфигурациях строятся на базе Системы Компоновки Данных (СКД).

Разберем, как наложить отбор программно через процедуру ПриКомпоновкеРезультата в модуле объекта отчета:

Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
    // Отменяем стандартную обработку, чтобы вручную добавить отбор
    СтандартнаяОбработка = Ложь;
    
    // Получаем настройки компоновщика
    Настройки = КомпоновщикНастроек.ПолучитьНастройки();
    
    // Создаем или находим нужный отбор
    ПараметрПодразделение = Настройки.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
    ПараметрПодразделение.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Подразделение");
    ПараметрПодразделение.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
    ПараметрПодразделение.ПравоеЗначение = ПараметрыСеанса.ТекущееПодразделениеПользователя;
    ПараметрПодразделение.Использование = Истина;
    
    // Формируем отчет
    КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
    Макет = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, Настройки);
    ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
    ПроцессорКомпоновки.Инициализировать(Макет);
    
    ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
    ПроцессорВывода.УстановитьДокумент(ДокументРезультат);
    ПроцессорВывода.Вывести(ПроцессорКомпоновки);
КонецПроцедуры

Важное предостережение:

Этот метод является защитой от «честного пользователя». Продвинутый пользователь с доступом к изменению настроек отчета или использованию внешних отчетов может легко обойти данный фильтр. Используйте этот способ только если данные не являются конфиденциальными и требуется лишь упростить повседневную работу сотрудников.

Почему не стоит разделять доступ через подсистемы?

Часто возникает соблазн скрыть отчеты, просто убрав их из подсистем или ограничив доступ к самой подсистеме. Однако разберем ситуацию: доступ к объекту метаданных (отчету) — это одно, а доступ к данным (информации в отчете) — совсем другое. Даже если вы скроете пункт меню от пользователя, он сможет открыть отчет через «Все функции» или «Функции для технического специалиста» (если у него есть права на просмотр отчета как объекта). Следовательно, настройка подсистем не является инструментом разграничения доступа к данным.

Рекомендации по выбору решения

1. Для реальной безопасности: Однозначно используйте RLS. Это стандартный и самый эффективный путь. Если в вашей конфигурации есть Библиотека стандартных подсистем (БСП), используйте встроенные профили групп доступа — это упростит настройку RLS через пользовательский интерфейс.
2. Если RLS сильно замедляет систему: Проанализируйте сложность условий. Замедление происходит при использовании запутанных логических выражений. Упростите шаблоны ограничений, и производительность придет в норму.
3. Для защиты от ошибок пользователей: Если требования к безопасности невысокие, достаточно доработать отчеты программно. Однако помните, что при обновлении типовой конфигурации такие доработки могут конфликтовать с новыми релизами, поэтому лучше оформлять их через расширения.

Подводя итог: самый чистый архитектурный путь — это использование профилей групп доступа и настройка прав на чтение данных в ролях. Это позволит вам «забыть» о доработке каждого нового отчета, так как система будет фильтровать данные на уровне платформы.