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