При работе в многофирменных базах данных «1С:Предприятие 8» (например, в «1С:Бухгалтерия предприятия 3.0») часто возникает специфическая задача администрирования прав доступа. Представим ситуацию: менеджеру необходимо дать доступ к документам определенной организации (например, «Ромашка»), но сделать это нужно строго для одного типа документов — к примеру, Реализация товаров и услуг. Во всех остальных объектах системы (платежные поручения, поступления, отчеты) пользователь не должен видеть данные этой организации.
В этой статье мы подробно разберем, как решить эту задачу в современных конфигурациях на управляемых формах, проанализируем сильные и слабые стороны каждого подхода, а также приведем конкретные примеры программного кода для реализации ограничений.
В современных типовых конфигурациях 1С, базирующихся на Библиотеке стандартных подсистем (БСП), механизм ограничения доступа на уровне записей (RLS) активируется в пользовательском режиме в разделе настроек прав. Однако стандартный RLS работает глобально на уровне профилей групп доступа.
Если мы настроим стандартную группу доступа с ограничением по организации «Ромашка», система автоматически применит это ограничение ко всем справочникам и документам базы данных, где разработчиками предусмотрено ограничение по этому виду доступа. Стандартными средствами БСП в режиме «1С:Предприятие» невозможно сказать системе: «Для реализации права ограничиваем, а для платежек — разрешаем все». Для этого нам придется прибегнуть к кастомизации системы.
Существует два принципиально разных пути решения этой задачи:
Рассмотрим каждый из этих вариантов подробнее.
Если требования к конфиденциальности данных высоки и утечка информации по другим организациям недопустима, мы обязаны использовать ограничение на уровне записей (RLS). По современным стандартам разработки, чтобы не снимать конфигурацию с поддержки, всю доработку мы будем выполнять в специальном расширении конфигурации.
Разберем по шагам, как спроектировать такое ограничение:
РеализацияТоваровУслуг.Инт_ОграничениеРеализацииПоОрганизации.РеализацияТоваровУслуг для прав Чтение и Изменение добавим шаблон ограничения.Если мы используем БСП, то можем применить стандартный производительный шаблон ограничения доступа. Пример текста запроса RLS для ограничения по реквизиту Организация может выглядеть следующим образом:
#ПоЗначениям("Документ.РеализацияТоваровУслуг", "Чтение", "",
"Организации", "Организация",
"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "")
В этом случае система свяжет права пользователя на документ с его персональными настройками разрешенных организаций в группах доступа. Для остальных же документов пользователю назначаются стандартные роли без ограничений. Таким образом, ограничение по организации «Ромашка» будет действовать исключительно на документ реализации.
Важный нюанс производительности: В современных версиях БСП 3.x используется производительный (универсальный) режим RLS. Система предварительно рассчитывает права доступа и записывает их в специальный регистр сведений КлючиДоступаКОбъектам. Если мы создаем кастомные RLS-правила, нам необходимо интегрировать их в общую подсистему БСП, переопределив процедуры в общем модуле УправлениеДоступомПереопределяемый. Иначе система может либо игнорировать правила, либо перевести работу с документом в устаревший «медленный» режим RLS, что негативно скажется на производительности СУБД при росте базы данных.
Когда жестких требований к безопасности нет, а задача носит скорее эргономический характер (чтобы менеджер случайно не выбрал чужую организацию и не запутался в списках), мы можем ограничиться доработкой интерфейса. Это значительно дешевле в разработке и проще в поддержке.
Для реализации этого метода мы также используем расширение конфигурации. Нам потребуется решить две задачи: ограничить отображение документов в динамическом списке (форма списка) и запретить открытие чужих документов напрямую.
Выясним, как это реализовать программно. Перехватим событие формы списка ПриСозданииНаСервере с помощью аннотации &После:
&НаСервере
Процедура Инт_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверяем, нужно ли применять ограничение для текущего пользователя
Если НЕ РольДоступна("ПолныеПрава") Тогда
// Накладываем жесткий отбор на динамический список документов "Список"
ЭлементОтбора = Список.КомпоновкаДанных.Настройки.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Организация");
ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
// Находим ссылку на разрешенную организацию "Ромашка"
ОрганизацияРомашка = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7701234567");
ЭлементОтбора.ПравоеЗначение = ОрганизацияРомашка;
ЭлементОтбора.Использование = Истина;
// Делаем отбор недоступным для изменения пользователем в интерфейсе
ЭлементОтбора.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;
КонецЕсли;
КонецПроцедуры
Этот код гарантирует, что при открытии журнала продаж пользователь увидит документы только по организации «Ромашка». Однако этого недостаточно. Если пользователь попытается открыть документ по прямой ссылке или через историю, мы должны заблокировать чтение данных на форме самого документа. Для этого перехватим событие формы документа ПриЧтенииНаСервере:
&НаСервере
Процедура Инт_ПриЧтенииНаСервереПосле(ТекущийОбъект)
Если НЕ РольДоступна("ПолныеПрава") Тогда
ОрганизацияРомашка = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7701234567");
// Если открывается документ по другой организации - вызываем исключение
Если ТекущийОбъект.Организация <> ОрганизацияРомашка Тогда
ВызватьИсключение "Недостаточно прав для просмотра документов по организации " + СокрЛП(ТекущийОбъект.Организация);
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Проанализируем ситуацию с точки зрения уязвимостей интерфейсного метода. Ограничение «на форме» работает только до тех пор, пока пользователь находится в рамках этой формы. Если у пользователя остаются стандартные роли на чтение документов без физического RLS на уровне СУБД, он сможет обойти ограничения формы следующими способами:
Ctrl + Shift + F) может проиндексировать и показать в результатах поиска представления документов закрытой организации.Таким образом, интерфейсный метод подходит только для дружественного разграничения работы («чтобы менеджеры не путались»), но категорически не подходит для защиты коммерческой тайны и предотвращения умышленного шпионажа со стороны сотрудников.
Выбор конкретного решения всегда зависит от бюджета проекта, требований к безопасности данных и квалификации разработчика:
Если перед нами стоит задача строгого соблюдения конфиденциальности в крупной компании, мы рекомендуем потратить время и спроектировать полноценную роль с RLS в расширении конфигурации. При этом важно следовать стандартам БСП 3.x, чтобы не потерять в скорости проведения документов и формирования отчетов.
Если же цель — упростить интерфейс для сотрудников одной небольшой компании, сократить затраты на разработку и обновление базы, то оптимальным решением станет создание небольшого расширения с программным отбором в динамическом списке и проверкой при открытии формы документа.