Разграничение прав доступа пользователей к коммерческой информации — одна из наиболее частых задач при внедрении и сопровождении систем «1С:Предприятие». В конфигурации «1С:Бухгалтерия предприятия 3.0» (БП 3.0) часто возникает необходимость ограничить менеджеров по продажам таким образом, чтобы они могли видеть и редактировать только «свои» документы (например, документы Реализация (акты, накладные, УПД)), в которых они указаны в качестве ответственных.
В рамках этой статьи мы подробно проанализируем ситуацию, разберем по шагам все возможные варианты решения этой задачи, оценим их плюсы и минусы, а также предложим наиболее оптимальный и безопасный архитектурный подход с использованием современных механизмов платформы 1С.
Для реализации ограничения доступа к документам в системе 1С традиционно существуют три основных подхода:
Рассмотрим подробнее каждый из этих вариантов, чтобы определить их применимость в «1С:Бухгалтерия предприятия 3.0».
Это самый надежный способ с точки зрения безопасности данных. Когда включен RLS, платформа 1С автоматически модифицирует любой запрос к базе данных, добавляя в него условия ограничения. Пользователь физически не сможет получить данные «чужих» документов — ни через динамический список, ни через отчеты, ни через программный код.
Однако применительно к «1С:Бухгалтерия 3.0» этот метод имеет критическое ограничение. В отличие от крупных ERP-решений (таких как «1С:ERP Управление предприятием» или «1С:Управление торговлей 11»), встроенный в БП 3.0 шаблон RLS по умолчанию умеет ограничивать доступ только в разрезе Организаций. В типовом функционале БП 3.0 просто нет готового разреза (профиля доступа) для работы с «Ответственными» или «Контрагентами».
Если мы решим пойти по пути стандартного RLS, нам придется либо снимать конфигурацию с поддержки и вручную дописывать шаблоны ограничений в ролях, либо использовать расширение конфигурации.
Разберем ситуацию с производительностью. Классический RLS накладывает дополнительную нагрузку на SQL-сервер. При каждом обращении к таблице документов платформа выполняет подзапросы для проверки прав. На базах с большим объемом документов и высокой интенсивностью работы пользователей это гарантированно приведет к существенному замедлению проведения документов и открытия списков.
В современных версиях Библиотеки стандартных подсистем (БСП) реализован производительный RLS (на основе ключей доступа), но его ручная интеграция под нестандартный разрез («Ответственный») в БП 3.0 — это крайне трудоемкая задача, требующая от программиста глубоких знаний механизмов БСП и работы с регистрами ключей доступа.
На форумах часто предлагают «простой» путь: наложить неотключаемый отбор по ответственному в форме списка документов и прописать проверку в обработчике формы документа. Выглядит это достаточно просто.
Выясним причину, почему этот способ считается небезопасным и ненадежным. Проанализируем уязвимости данного подхода:
Оборотно-сальдовая ведомость по счету 62, Анализ субконто, Универсальный отчет) и увидеть там все суммы сделок, контрагентов, а при двойном клике (через расшифровку) — беспрепятственно открыть и сам документ реализации.Чтобы сохранить конфигурацию на поддержке и обеспечить быструю автоматическую установку обновлений, мы рекомендуем реализовывать задачу исключительно через расширение конфигурации. Ниже мы разберем по шагам два возможных сценария реализации в расширении.
Этот вариант подходит для большинства компаний, где нет жестких требований информационной безопасности на уровне ИТ-аудита, но нужно организационно разграничить работу сотрудников, чтобы они «не путались» в чужих сделках.
Мы решаем задачу комплексно в рамках одного расширения:
РеализацияТоваровУслуг и программно устанавливаем фиксированный (недоступный для изменения пользователем) отбор по текущему пользователю.ПриСозданииНаСервере формы документа РеализацияТоваровУслуг и проверяем: если документ не новый и значение реквизита Ответственный не совпадает с текущим пользователем, мы вызываем исключение или устанавливаем параметр Отказ = Истина.Посмотрим на пример кода для установки отбора в динамическом списке через расширение. В модуле формы списка документов перехватываем метод ПриСозданииНаСервере:
&ВКанале("После")
Процедура Расш_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Получаем текущего пользователя системы
ТекущийПользователь = Пользователи.ТекущийПользователь();
// Проверим, нужно ли применять ограничение (например, у пользователя нет полных прав)
Если Не РолиДоступна("ПолныеПрава") Тогда
// Находим элемент отбора по реквизиту "Ответственный"
ПолеОтветственный = Новый ПолеКомпоновкиДанных("Ответственный");
// Проверяем, есть ли уже такой отбор в списке, чтобы не дублировать
ЭлементОтбора = Неопределено;
Для Каждого Элемент Из Список.Отбор.Элементы Цикл
Если Элемент.ЛевоеЗначение = ПолеОтветственный Тогда
ЭлементОтбора = Элемент;
Прервать;
КонецЕсли;
КонецЦикла;
// Если отбор не найден, создаем новый
Если ЭлементОтбора = Неопределено Тогда
ЭлементОтбора = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементОтбора.ЛевоеЗначение = ПолеОтветственный;
КонецЕсли;
// Настраиваем параметры отбора
ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
ЭлементОтбора.Использование = Истина;
ЭлементОтбора.ПравоеЗначение = ТекущийПользователь;
ЭлементОтбора.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;
КонецЕсли;
КонецПроцедуры
Разберем теперь, как заблокировать открытие самой формы документа, если пользователь пытается открыть чужую реализацию (например, перейдя по ссылке из другого документа). В модуле формы документа пишем обработчик:
&ВКанале("После")
Процедура Расш_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Ограничение действует только для пользователей без Полных прав
Если Не РолиДоступна("ПолныеПрава") Тогда
// Проверяем, что документ уже записан в базу (для новых документов проверка не требуется)
Если ЗначениеЗаполнено(Объект.Ссылка) Тогда
ТекущийПользователь = Пользователи.ТекущийПользователь();
// Если ответственный в документе отличается от текущего пользователя
Если Объект.Ответственный <> ТекущийПользователь Тогда
ВызватьИсключение "Недостаточно прав для просмотра и редактирования данного документа!";
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Если требования безопасности жесткие и нельзя допускать чтение данных через сторонние инструменты, необходимо настроить полноценный RLS. Современная платформа «1С:Предприятие 8.3» позволяет добавлять собственные роли и настраивать RLS непосредственно внутри расширения, не затрагивая основную конфигурацию.
Рассмотрим подробнее шаги реализации этого сценария:
Документ.РеализацияТоваровУслуг (без реквизитов, только сам объект для возможности управления правами).Расш_МенеджерСОграничениемПоОтветственному).РеализацияТоваровУслуг на вкладке Шаблоны ограничений или непосредственно в ограничениях доступа на уровне записей для прав Чтение и Изменение прописываем текст ограничения.Пример простого текста ограничения (RLS) для права Чтение:
ГДЕ Ответственный = &ПараметрСеанса.ТекущийПользователь
После этого нам останется лишь назначить созданную роль пользователям-менеджерам в режиме «1С:Предприятие» и забрать у них типовые роли, дающие неограниченный доступ к чтению реализаций.
Независимо от выбранного технического решения, безопасность коммерческих данных в «1С:Бухгалтерия 3.0» начинается с правильного распределения ролей. Менеджерам ни в коем случае нельзя давать права «Бухгалтер» или «Администратор».
В типовой БП 3.0 (начиная с версии 3.0.44) присутствует отличный предопределенный профиль групп доступа — «Менеджер по продажам». Назначьте этот профиль сотрудникам отдела продаж. Он изначально спроектирован так, что скрывает от пользователей все «лишние» разделы учета: банковские выписки, кассовые операции, расчет заработной платы, закрытие периода и регламентированную отчетность. Использование этого профиля в связке с легким расширением (ограничивающим работу с чужими документами по ответственному) даст наиболее стабильный, быстрый и безопасный результат.
Подведем итоги нашего анализа: