Rls в 1с что это

Производительный режим RLS в 1С

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Оба режима RLS в 1С имеют свои преимущества и недостатки.

RLS в 1С

Для гибкой настройки прав пользователей в конфигурациях на базе БСП (подсистема УправлениеДоступом) реализован механизм настройки доступа на уровне записей (RLS). Этот механизм позволяет ограничивать доступ не только по видам объектов (для конкретных справочников, документов…), но и по данным в этих объектах (т.е., например, ограничить список документов только по одной организации или по конкретному менеджеру).

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в тексте далее.

Для дальнейших скриншотов, примеров кода, а также для решения задачи будем использовать демонстрационную конфигурацию «Библиотека стандартных подсистем», редакция 3.1 (3.1.5.132).

Ограничения RLS описываются в роли для конкретного объекта. Например, ограничение на чтение документа _ДемоСчетНаОплатуПокупателю в роли
_ДемоЧтениеДокументовПокупателей описывается следующим образом:

Как мы видим, для описания ограничений используются специальные шаблоны. В данном случае #ДляОбъекта и #ПоЗначениям. Шаблоны, которые могут быть использованы в роли необходимо описать на вкладке “Шаблоны ограничений”:

В свою очередь, эти шаблоны можно скопировать из поставляемой роли ИзменениеУчастниковГруппДоступа.

Рассмотрим текст ограничения доступа подробнее.

Как мы видим, выбор шаблона зависит от параметра &ОграничениеДоступаНаУровнеЗаписейУниверсально, который как раз и определяет режим, в котором должно использоваться RLS — стандартный или производительный. Значение этого параметра хранится в параметрах сеанса, а в самой базе выбрать режим можно двумя способами:

1. Зайти в раздел Администрирование — Настройки пользователей и прав — Группы доступа — Вариант работы — Производительный

2. В окне “Все функции” изменить значение константы “Ограничивать доступ на уровне записей универсально” на ИСТИНА, если нужен производительный режим и, соответственно на ЛОЖЬ, если стандартный.

Соответственно, если &ОграничениеДоступаНаУровнеЗаписейУниверсально = ЛОЖЬ, то будет использоваться стандартный метод и выполняться код

а если &ОграничениеДоступаНаУровнеЗаписейУниверсально = ИСТИНА, то будет использоваться производительный метод и выполняться код

Подробнее о синтаксисе и использовании шаблонов можно почитать в их описании.

При стандартном режиме ограничение прописывается прямо в роли (установлен отбор по разрешенным организации и партнеру). Эти отборы добавляются к итоговому запросу при обращении к СУБД. При наличии нескольких ролей с описанными ограничениями все условия собираются в один запрос, растет количество левых соединений, повышается риск неправильного использования индексов, выбора неоптимального плана выполнения запроса, что значительно его усложняет и замедляет выполнение. А так как при стандартном режиме работы ограничения рассчитываются “на лету” при каждом обращении к данным (формирование списков справочников и документов, их открытие и записи), то работа пользователя может значительно замедлиться из-за сложности сформированного запроса.

Эту проблему решает включение производительного режима. При нём все отборы и ограничения не добавляются в запрос, раздувая его, а предварительно рассчитываются в некоторые ключи доступа и в итоговый запрос попадают только они, что увеличивает производительность. О ключах и их расчете подробнее далее.

Как мы видим, в ограничении роли для производительного режима не описаны никакие условия, нет никакой информации о видах доступа, по которым необходимо ограничивать данные. Где же они указаны? Для этого в подсистеме УправлениеДоступом предусмотрена специальная экспортная процедура ПриЗаполненииОграниченияДоступа(), который описывается в модуле менеджера объекта, указанного в роли.

Так, для документа _ДемоСчетНаОплатуПокупателю эта процедура описана следующим образом:

Здесь мы видим, что ограничение описывается с помощью некоторых типов ограничения (РазрешитьЧтениеИзменение) и функций ограничений (ЗначениеРазрешено()). Это нужно понимать так: пользователю будет разрешено читать и изменять документ _ДемоСчетНаОплатуПокупателю, когда ему будут разрешены значения организации и партнера, указанные в этом документе.

Примечание. Подробно о типах, функциях, синтаксисе ограничений описано на сайте ИТС в разделе — Инструкции по разработке на 1С

— Библиотека стандартных подсистем 3.1.6. Документация

— Глава 3. Настройка и использование подсистем при разработке конфигурации

— Разработка ограничений прав доступа

Далее в статье рассмотрим кратко лишь некоторые.

Некоторые типы ограничений

Типы ограничения могут быть:

• РазрешитьЧтениеИзменение
• РазрешитьИзменениеЕслиРазрешеноЧтение
• РазрешитьИзменение

Основным способом описания ограничений необходимо считать функцию ЗначениеРазрешено(). Функция выполняет поиск проверяемого значения среди разрешенных значений в группах доступа, профили которых предоставляют соответствующие права на список.

• ЗначениеРазрешено(<Реквизит> [<проверяемые типы>] [, <уточнение сравнения 1> [, <уточнение сравнения 2>] …]), где проверяемые типы могут быть (значения непроверяемых типов запрещены, если не уточнены отдельно):

— ТОЛЬКО <Имя таблицы>;
— ТОЛЬКО (<Имя таблицы 1>, <Имя таблицы 2>, … );
— КРОМЕ <Имя таблицы>;
— КРОМЕ (<Имя таблицы 1>, <Имя таблицы 2>, … );

• Уточнение сравнения может быть:

— ПустаяСсылка КАК Ложь/Истина;
— Неопределено КАК Ложь/Истина;
— Null КАК Ложь/Истина;
— Отключено КАК Ложь/Истина (только для функции ЗначениеРазрешено);
— <Таблица> КАК Ложь/Истина (например, Справочник.Проекты КАК Истина).

Также существуют следующие функции:

• ЧтениеОбъектаРазрешено
• ЧтениеСпискаРазрешено
• ИзменениеОбъектаРазрешено
• ИзменениеСпискаРазрешено

Синтаксис этих функций аналогичен функции ЗначениеРазрешено().

Эти функции необходимо использовать, когда необходимо установить доступность (чтение/изменение) объекта в зависимости от доступности его реквизита. Например, документ _ДемоСчетНаОплатуПокупателю должен быть доступен, когда доступен его реквизит Организация. В таком случае ограничение будет описано как:

• ДляВсехСтрок(<Условие>)

Функция выполняет проверку в строках с помощью логического «И». Используется для одновременного выполнения условия во всех строках табличной части объекта.

• ДляОднойИзСтрок(<Условие>)

Функция выполняет проверку в строках с помощью логического «ИЛИ». Используется для выполнения условия хотя бы в одной строке табличной части объекта.

Примеры возможных ограничений

Организация и контрагент в шапке документа:

Организация в шапке документа, контрагент в табличной части, достаточно одного разрешенного контрагента:

Организация в шапке документа, контрагент в табличной части, достаточно одного разрешенного контрагента (если табличная часть пустая, тогда доступ по контрагенту разрешен):

Организация в шапке документа, контрагент в табличной части, и требуется, чтобы все контрагенты были разрешены (если табличная часть пустая, тогда доступ по контрагенту запрещен):

Организация и контрагент в табличной части, при этом достаточно, чтобы любая из пар организации с контрагентом была разрешена:

Организация и контрагент в табличной части, при этом требуется, чтобы все пары организации с контрагентом были разрешены:

Организация и контрагент в табличной части, при этом требуется, чтобы одна из организаций и один из контрагентов были разрешены:

Отправитель – измерение составного типа, при этом требуется проверять только ссылки Справочник.Склады:

Отличительная особенность производительного режима RLS в 1С

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

Для хранения этих предварительно рассчитанных данных (ключей) используются следующие таблицы:

• справочник КлючиДоступа
• регистр сведений КлючиДоступаКОбъектам
• регистр сведений КлючиДоступаПользователей

Справочник КлючиДоступа имеет структуру:

В реквизитах Значение1 — Значение5 хранятся комбинации конкретных значений доступа. В зависимости от ограничений каждого конкретного типа объектов конфигурации состав значений разный. Например, как упоминалось выше, для документа _ДемоСчетНаОплатуПокупателю определено ограничение по Организации и Партнеру. Соответственно, будут сформированы ключи с возможными комбинациями организации и партнера.

В реквизит Хэш реквизит рассчитывается специальный хеш функции. Он позволяет быстро понять, существует ли уже в системе ключ с такой комбинацией значений или нет.

Структура регистров следующая:

Причем Объект РС КлючиДоступаКОбъектам имеет тип ОпределяемыйТип.ВладелецЗначенийКлючейДоступа, которые содержит в себе ссылки на все объекты, которые могут быть ограничены с помощью RLS.

Регистр ключей доступа к объектам, а также сами ключи доступа обновляются регламентно. Регистр ключей доступа пользователей в измерении Пользователь содержит справочник ключей пользователей, к которым применяется ограничение, а также справочник ключей доступа к объектам.

Таким образом при проверке ограничений доступа вне зависимости от количества настроенных для конкретного проверяемого объекта видов доступа запрос всегда будет дополняться одним соединением с регистром «Ключи доступа к объектам» по проверяемому объекту и с регистром «Ключи доступа пользователей» по текущему пользователю:

Обновление ключей объектов и ключей доступа к ним выполняются регламентным заданием. А также оно может быть запущено из обработки “Обновление доступа на уровне записей”:

Эта обработка позволяет запускать процесс обновления ключей вручную, а также настраивать и контролировать процесс выполнения.

Запуск обработки выполняется по кнопке

Можно настроить обновление ключей по определенным объектам. Эта настройка выполняется по кнопке Ещё — Ручное управление… На этой форме можно выбрать конкретные справочники, документы или регистры, по которым необходимо обновить ключи, отметить их флажками, после этого запланировать обновление и запустить обработку:

Также есть возможность выводить более подробную информацию о ходе выполнения обработки

Для удобного написания и контроля текстов ограничений в комплекте поставки есть специальная обработка УправлениеДоступом:

Она позволяется в пользовательском режиме, без редактирования конфигурации формировать и проверять тексты ограничения доступа для объектов. Для этого необходимо во вкладке “Разработка ограничений доступа” необходимо выбрать список, ограничение на который нужно отредактировать:

После этого на форму загрузится текст ограничений из процедуры ПриЗаполненииОграниченияДоступа, а также шаблон ограничения в роли, а также кнопки для проверки текста вставки его в код:

При наличии ошибки в тексте ограничения и нажатии на кнопку “Проверить” появляется вкладка “(ошибки)”, в которой описаны ошибка как самого текста, так и всего внедрения механизма ограничений по записям для объекта:

Несколько конкретных примеров внедрения

Допустим, нам необходимо создать новый документ и подключить его к механизму ограничений RLS. Для этого необходимо выполнить следующие операции:

— создать новый документ ТестовыйДокументСОграничениями

— добавить объект в определяемые типы ВладелецЗначенийКлючейДоступа и ВладелецЗначенийКлючейДоступаДокумент.

Примечание. В определяемый тип ВладелецЗначенийКлючейДоступаДокумент добавляются документы. Справочники нужно добавить в ВладелецЗначенийКлючейДоступаОбъект, регистры сведений — в ВладелецЗначенийКлючейДоступаНаборЗаписей, регистры расчета — в ВладелецЗначенийКлючейДоступаНаборЗаписейРегистраРасчета.

— в процедуру ПриЗаполненииСписковСОграничениемДоступа общего модуля УправлениеДоступомПереопределяемый вставить текст

— на форме документа в обработчики ПриЧтенииНаСервере и ПослеЗаписиНаСервере добавить следующий код:

— создать новые роли для чтения и добавления/изменения нового документа: ЧтениеТестовыхДокументовСОграничениями и ДобавлениеИзменениеТестовыхДокументовСОграничениями. Для них определить соответствующие права (чтение, добавление, изменение), скопировать шаблон ограничений ДляОбъекта() из роли ИзменениеУчастниковГруппДоступа и прописать код ограничения доступа для необходимых прав:

Примечание. В данном конкретном случае принимаем, что производительный режим RLS используется, поэтому ограничение для обычного режима не прописываем и в соответствующей ветке прописываем просто ИСТИНА.

• Нужно для этого документа реализовать ограничение, чтобы были доступны только те документы, в которых доступны организация и подразделение. Необходимо выполнить следующие действия:

— в модуле менеджера документа в процедуре ПриЗаполненииОграниченияДоступа прописать текст ограничения:

— в пользовательском режиме создать профили доступа с созданными ранее ролями, группы доступа и прописать в них ограничения по организациям и подразделениям и назначить их пользователям:

— создать документы и запустить задание обновления ключей доступа.

В результате получим ограниченный список документов для тестового менеджера:

под полными правами

под ограниченными правами

• Нужно реализовать ограничение, чтобы были доступны только те документы, в которых доступны организация и было доступно хотя бы одно место хранения из ТЧ Запасы.

— в модуле менеджера документа в процедуре ПриЗаполненииОграниченияДоступа прописать текст ограничения:

— добавить вид ограничения в профиль доступа, прописать в группе доступа ограничения по местам хранения, обновить ключи:

В результате под пользователем с ограниченными правами увидим только те документы, у которых доступна организация и в ТЧ Запасы хотя бы в одной строке указан Розничный склад:

• Рассмотрим пример, когда необходимо реализовать ограничение по какому-то новому реквизиту, тип которого не описан в доступных видах доступа. Реализуем такую задачу. Для этого нужно выполнить следующее:

— создать новый справочник ТестовыйРегион. Выполнить для него все те же операции, что и для самого документа ТестовыйДокументСОграничениями (роли можно создать новые или прописать в какие-то существующие, например для чтения/изменения документа. В данном примере это не принципиально. В ПриЗаполненииОграниченияДоступа прописать ограничение на само себя: ЗначениеРазрешено(Ссылка)).

— добавить ссылку и объект ТестовыйРегион в определяемые типы соотстветственно ЗначениеДоступа и ЗначениеДоступаОбъект

— в процедуру ПриЗаполненииВидовДоступа общего модуля УправлениеДоступомПереопределяемый вставить текст:

— запустить обработку ОбновлениеВспомогательныхДанных (из Инструментов разработчика) и обновить всё.

— добавить новый вид доступа в профиль доступа и определить конкретные ограничения в группе доступа:

— добавить реквизит в документ, вывести на форму, заполнить (скриншот от пользователя с полными правами):

— изменить текст ограничения в процедуре ПриЗаполненииОграниченияДоступа документа ТестовыйДокументСОграничениями, чтобы он учитывал новый реквизит:

— обновить ключи доступа.

В результате на пользователя с ограниченными правами распространяются ограничения по организациям (ООО Тестовая организация и Новые технологии ООО) и регионам (Центральный и Южный) и он получит такой список документов:

RLS в 1С — ограничения доступа к данным на уровне записей

Система прав доступа в 1С помимо назначения ролей реализуется также через механизм ограничения доступа к данным на уровне записей и полей (RLS — Record Level Security). В то время как роль дает общее право на использование объекта конфигурации 1С, RLS позволяет ограничить доступ к части данных: документам лишь по конкретному контрагенту или реквизитам, содержащим финансовую информацию.

Ограничения задаются для действий Чтение, Добавление, Изменение, Удаление в режиме Конфигуратора и представляют собой условие в виде текста на языке запросов. При этом в режиме работы 1С Предприятие никаких дополнительных действий производить не требуется.

Установка дополнительных условий позволяет скрывать данные не только в самом объекте: скрытые данные не будут отображаться в формах, отчетах и их невозможно будет получить никаким запросом.

2. Подводные камни в использовании RLS 1С

В то же время, если условие ограничения доступа написано некорректно, пользователь может увидеть надпись «Объект не найден», что по незнанию может быть воспринято как 1С «битая ссылка».

Стоит также отметить, что применение механизма RLS 1С снижает производительность системы, так как условие ограничения добавляется к каждому запросу данные ИБ.

При разработке условия 1С ограничения доступа могут быть использованы 1С параметры сеанса, в качестве параметров запроса. Также допустимо использование инструкций препроцессора #Если <ЛогическоеУсловие>#Тогда<…> #КонецЕсли.

В случае если пользователю доступно несколько ролей с настроенными ограничениями доступа к данным, они суммируются по логическому условию «ИЛИ». В связи с этим рекомендуется для настройки доступа к ограничиваемым объектам использовать одну роль с установленными ограничениями доступа.

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

Ограничение прав на уровне записи 1С RLS

Восьмая версия платформы «1С:Предприятие» (сегодня 8.3) несла в себе множество изменений по отношению к «семерке», среди которых особенно выделялся механизм ограничения прав доступа на уровне записей. Несмотря на то, что можно, теоретически, обойтись и без него, используя исключительно роли, RLS позволяет добиться более тонкой настройки доступа. Но для правильной эксплуатации этого механизма, нужно четко понимать его суть и иметь достаточный опыт в разработке в 1С.

Что такое RLS?

Суть этого функционала заключается в возможности разработчика предотвратить доступ определенного пользователя или группы пользователей к таблицам или полям таблиц базы данных. Обычно ограничения используются, чтобы не дать возможность пользователям 1С увидеть и отредактировать конфиденциальную, секретную информацию, например, ограничить сотрудников компании, входящей в группу, просмотром документов только по своей организации. Также механизм ограничений прав доступа на уровне записи можно использовать, чтобы убрать лишнюю информацию из интерфейса.

Чтобы получить возможность писать запросы для ограничений по RLS, необходимо создать роль или взять уже имеющуюся. Настройка RLS в 1С 8.3 может применяться для следующих действий пользователя:

• Добавление;
• Чтение;
• Удаление;
• Изменение.

Кроме широчайших возможностей настройки доступа, RLS несут в себе и недостатки:

1. Требования к квалификации разработчика, так как писать запрос придется на встроенном языке с учетом правил синтаксиса;
2. Отсутствие возможности быстрой отладки условия;
3. Ограниченные возможности по описанию логики: слишком сложные условия придется все-таки писать в модулях документов и справочников;
4. В клиент-серверном варианте баз возможно неявный рост таблиц, включенных в запрос. Причем отследить этот процесс очень сложно;
5. Требования к ресурсам. Ограничения по RLS потребляют немало мощности клиентской машины и сервера;
6. Малочисленная документация в свободном доступе.

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

Создаем ограничение RLS

Для того чтобы добавить ограничение по RLS, необходимо найти нужную роль и открыть ее двойным щелчком.

Рис.1 Добавить ограничение по RLS

Открывшееся окно содержит 2 вкладки: «Права» и «Шаблоны ограничений». Чтобы наложить определенные ограничения на конкретное действие, необходимо выделить его и в правой нижней части нажать на зеленый плюс. Появиться строчка, в которой мы сможем задать ограничения 1С RLS на встроенном в 1С языке.

Рис.2 Наложить определенные ограничения на конкретное действие

Если вы знаете синтаксис 1С (как свои пять пальцев), то можете писать прямо в поле «Ограничение доступа». Разработчики 1С предусмотрели возможность открывать конструктор запроса, который поможет и подскажет, на что можно сделать ограничение. Чтобы его открыть, нужно нажать на кнопку с тремя точками (Выбрать) или F4 и появиться окно с кнопкой «Конструктор запроса…».

Рис.3 Конструктор запроса

В появившемся окне вы сможете настроить ограничения не только по данному справочнику, но и по другим объектам системы. Для этого необходимо добавить их на вкладке «Таблицы и поля». Прописываем ограничения на поля справочника «Номенклатура» и нажимаем на «ОК». Внимательно относитесь к названию переменных: параметры RLS задаются при старте сессии пользователя и должны содержаться в объекте метаданных.

Рис.4 Прописываем ограничения на поля справочника

В описанном примере мы добавили ограничение RLS, чтобы пользователи могли добавлять только номенклатуру определенного вида и с выбранной единицей измерения.

На вкладке «Шаблоны ограничений» задаются запросы, которые необходимы при копировании одинаковых настроек RLS в 1С 8.3. После того как вы добавили свой шаблон, по его имени можете обращаться в настройках прав доступа.

Также есть возможность одновременно добавлять ограничения на несколько ролей. Для этого в дереве конфигурации необходимо нажать правой кнопкой мыши на раздел «Роли» и выбрать пункт «Все роли».

Рис.5 Ограничения на несколько ролей

В качестве заключения хотелось бы отметить, что данная статья направлена на консультантов-разработчиков 1С и может помочь в первую очередь тем, кто уже имел опыт разработки на «1С:Предприятие». Несмотря на кажущуюся простоту, знание семантики и понимание структуры бизнес-процессов собственного предприятия или организации заказчика для правильной раздачи прав – требуют определенного уровня знаний и опыта.

От экспертов «1С‑Рарус»: Введение в управление доступом в больших системах 1С. Оптимизация RLS

Почему управление доступом в 1С это важно и не просто?

Размер имеет значение

Начиная с 2010 года фирма «1С» объявила о формировании новой стратегии по завоеванию рынка автоматизации крупных предприятий. Целью компании и сети ее франчайзи стала не только работа с небольшими фирмами, но и полноценная комплексная автоматизация крупных компаний и холдингов на тысячи рабочих мест. Автоматизация подобного масштаба диктует строгие требования к самой технологической платформе «1С:Предприятие», к выпускаемым на ней решениям и конфигурациям.

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

Для большинства крупных проектов на десятки, сотни и тысячи рабочих мест стали характерными общие проблемы производительности при работе с большим объемом данных.

Можно выделить две основные проблемы:

1. Деградация производительности с ростом объема данных.
2. Деградация производительности с ростом количества пользователей, закономерного увеличения числа функциональных ролей и усложнения при этом «матрицы прав».

Что такое крупный проект?

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

• Конфигурация на базе БСП + УТ 11 + CRM + самописные блоки.
• Объем базы данных 700 Гб.
• 2100 пользователей всего.
• 800–1000 активных пользователей.
• 1130 ролей доступа к объектам метаданных.
• 310 профилей (из них 40 — функциональные должности).
• 1157 групп доступа.

В ходе реализации проекта со стороны Заказчика были четко сформулированы требования по разграничению прав доступа ко всем объектам конфигурации в зависимости от функциональных обязанностей пользователей, а также разграничение прав внутри документов по определенным «Видам доступа» — ключевым аналитикам данных. В нашем случае использовались следующие виды доступа:

• филиалы компании,
• дирекции,
• организации,
• подразделения,
• склады.

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

Организация прав доступа к данным

Что в решении этой задачи для нас и для клиента чрезвычайно важно:

• Разделить пользователей так, чтобы они могли просматривать и изменять только предназначенные для них данные.
• Чтобы система при этом работала быстро и не замедлялась с ростом количества данных.
• Чтобы администратор мог, как на ладони, видеть всю картину по системе ограничений.

В условиях большого разнообразия данных, пользователей, сильно разнящихся по уровням доступа, и быстро растущей базы — эти задачи становятся сложными.

Настройка системы прав доступа с использованием ограничения по «Видам доступа»

Рассмотрим примеры настройки прав доступа на реальном проекте. Для начала детально изучим составные части системы прав доступа. Основные из них:

• роли,
• профили групп доступа,
• группы доступа,
• виды доступа,
• RLS шаблоны.

Права доступа настраиваются с помощью ролей, в каждой из которых описывается конкретный набор объектов метаданных, права на которые выдает сама роль. При этом внутри роли можно отдельно настроить права на чтение, изменение, добавление, проведение и удаление определенного объекта метаданных.

Роли могут выдавать пользователю права на просмотр определенных подсистем или специфическую функциональность (например «открытие внешних обработок и отчетов», доступ к режиму «все функции» и т. п.). Также существуют роли проверяемые программно.

Профили групп доступа

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

Группы доступа

Группа доступа является экземпляром профиля групп доступа. Т.е. набором прав конкретного «менеджера по продажам», «кладовщика», «бухгалтера» на предприятии со своим специфичным набором ограничений.

Пример: менеджер по продажам в Москве, имеющий права видеть данные только по Москве, по конкретной организации и конкретным указанным складам. Группа доступа имеет одну прямую ссылку на используемый профиль доступа. Аналитики, по которым разделяются группы доступа разных пользователей называются Видами доступа. Каждый проект может иметь свой уникальный набор видов доступа, диктуемый структурой организации предприятия и спецификой построения бизнеса.

Создание ролей и профилей групп доступа

При внедрении конкретного проекта всегда возникает вопрос о правилах построения системы прав доступа. Фирма «1С» при использовании Библиотеки Стандартных Подсистем дает свои рекомендации организации ролей. Выдержка с сайта its.1c.ru:

Библиотека Стандартных Подсистем не навязывает ту или иную методику разработки ролей в конфигурации. В общем виде при разработке системы ролей могут использоваться два подхода, которые различаются степенью детализации (укрупненности) ролей:

1. При первом подходе проектируются прикладные роли, предоставляющие доступ ко всему множеству объектов метаданных, которые требуются для работы определенной категории пользователей системы. Например, «Бухгалтер», «Кассир» и т. д. Такие роли самостоятельно назначают пользователям (группам пользователей) и, как правило, расширяют дополнительными правами, например: «Действия главного бухгалтера», «Печать непроведенных документов», «Запуск тонкого клиента» и т. п.

2. Во втором случае проектируются роли-функции, предоставляющие «атомарный» доступ к определенному подмножеству объектов метаданных, с которым различные пользователи могут работать как с одной функцией системы. Такие роли не назначаются пользователям поодиночке, а объединяются в профили групп доступа и назначаются пользователям (группам пользователей) в совокупности. При этом профили групп доступа выступают аналогами прикладных ролей, например: «Бухгалтер», «Кассир» и т. д.

(its.1c.ru/db/bsp23doc
#content:417:1:issogl2_
стандартные_роли_
и_дополнительные_права — требуется авторизация)

В нашем случае мы использовали второй способ и создавали набор атомарных ролей под каждый объект метаданных.

Выдача прав пользователям

Для организации системного подхода при выдаче прав доступа на проекте мы реализовали несколько доработок.

Статус группы доступа

Для большей управляемости мы ввели статусы групп. Для административных групп доступа требуем указание причины выдачи, даты и пользователя, согласовавшего выдачу такой группы доступа.

Временные группы доступа можно выдавать только с указанием причины и срока до которого они действуют. Такие группы используются до момента полного разбора проблем с правами конкретного пользователя. На постоянной основе такие группы доступа не используются.

Удаляемые и Неразобранные группы доступа являются также временными и используются только на этапе построения комплексной системы прав доступа.

Опросник прав

При выдаче прав пользователей мы используемы специальные опросник — документ, содержащий описание профилей и возможные ограничения по видам доступа. Руководитель подразделения заполняет для каждого своего сотрудника список профилей, которые ему необходимо выдать перед началом работы с программой.

Мониторинг состояния системы прав доступа

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

• добавление группы доступа пользователю;
• исключение пользователя из группы доступа;
• изменение параметров группы доступа.

Как сделать так, чтобы ограничения прав работали и при этом все не тормозило?

1С RLS (Row-Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.

Напомним, как работает ограничение прав на уровне записей: на уровне конкретной роли и права доступа к данным (чтение, изменение, добавление) есть возможность задать вызов шаблонного запроса RLS с определенным набором Видов доступа. Возможно использовать шаблонные запросы БСП, а можно написать любой свой произвольный запрос.

Типовой шаблон запроса RLS содержит несколько десятков тысяч строк.

Оптимизация типового шаблона RLS (получение групп доступа)

Попробуем посмотреть типовой шаблон RLS, возможно, там есть что оптимизировать?

Одной из самых часто выполняемых частей запроса RLS — проверка права конкретного пользователя на текущую конкретную таблицу (объект метаданных). При этом каждый раз сначала перебираются (определяются) группы доступа, дающие права на запрашиваемый объект метаданных, а следом выполняется запрос по определению групп доступа, доступных текущему пользователю.

Подобные запросы выполняются огромное количество раз, при этом сами группы доступа пользователя меняются крайне редко за время сеанса. Нет смысла в каждом вызове запроса RLS заново искать доступные группы доступа пользователя — их можно закешировать в параметр сеанса при старте.

Основным сценарием разбора проблемы был анализ плана запроса через extended events. Сразу под подозрение попала последняя ветка запроса, у которой был обнаружен достаточно высокий COST и возникло интуитивное сомнение в необходимости постоянного получения текущих групп доступа пользователя при каждом выполнении запроса RLS. Список групп доступа пользователей достаточно статичен, меняется крайне редко, а вот постоянное его получение в каждом запросе могло приводить к замедлению скорости выполнения запроса. Проверяем!

В параметр сеанса были инициализированы все актуальные группы доступа пользователей и в шаблонном запросе RLS выполнена замена поиска групп доступа на обращение к параметру сеанса.

Заменили на параметр сеанса, что дало ускорение примерно на 20% на самых тяжелых таблицах.

Пользовательский отбор по ключевому измерению

Продолжая разбираться с оптимизацией RLS запросов наткнулись на интересную ситуацию: в нашей базе есть специальная аналитика — справочник «Филиалы», по которому мы разделяем все документы в системе и, соответственно, настроили ограничения RLS. Обнаружили проблему: при открытии списка документов «Заказы клиентов» по филиалу, у которого не было введено ни одного документа, динамический список открывался десятки секунд. При этом у пользователей других филиалов (по которым есть документы) открытие того же списка происходило практически мгновенно. Как так? На момент эксперимента в базе было более 500 000 документов «Заказ клиентов».

Разбираемся в ситуации: динамический список пытается получить первые 50/1000 строк данных, удовлетворяющих заданному условию. При этом также выполняется RLS запрос с целью скрыть недоступные пользователю данные.

Чем больше «нужных» данных в текущей таблице тем быстрее SQL найдет первые 20/1000 подходящих строк и вернет их динамическому списку. Если «нужных» данных в базе нет — придется все строки текущей таблицы соединять с RLS запросом и проверить на «пригодность».

Возникла идея «помочь» динамическому списку и планировщику запросов SQL — сразу фильтровать данные на уровне динамического списка через пользовательские отборы.

Шаг 1

В настройках динамического списка ставим отбор по филиалу (офису).

Шаг 2

В формах ключевых документов прописываем специальную процедуру, которая устанавливает для текущего пользователя системы его филиал в отбор динамического списка. Филиал берем из параметра сеанса.

В итоге при открытии формы списка у пользователя автоматически установлен отбор по филиалу:

Посмотрим план запроса — какие изменения произошли при выполнении запроса?

На таблицу «Заказа клиента» сразу накладывается отбор по филиалу и вместо 500 000 записей остается 6000. Только после этого срабатывает RLS запрос и по каждой из 6000 строк проверяется соответствие ограничениям доступа.

Было: выборка из 527 138 строк таблицы Заказа клиента.

Стало: 6267 строк.

Перенастройка ролей, «выравнивание» запросов RLS

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

Мы продолжали исследовать комбинации прав пользователей, пытаясь найти закономерность и отловить в какой именно комбинации прав проявляется серьезная деградация производительности. Было замечено, что если пользователю выдавать разные профили с ролям на документ, на который уже дают права другие роли других профилей — сразу идет снижение производительности.

Включаем extended events, сравниваем планы запросов в ситуациях когда у пользователя 1 роль на объект и когда 2. Замечаем увеличение количества веток запроса с результирующим объединением.

Смотрим что же за RLS внутри ролей и как они настроены. Оказывается что RLS в ролях имеет разные шаблоны RLS и разные параметры вызовов шаблонов RLS. При чем даже если шаблоны RLS одинаковы, но вызывается он в ролях по‑разному — появляются дополнительные запросы.

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

Выполняем простую, но утомительно долгую работу — обходим ВСЕ роли, перепроверяем шаблоны RLS и порядок их вызова. Стараемся во всех ролях сделать единый шаблон и одинаковый оптимальный в нашей ситуации порядок вызова шаблонов RLS.

Что же нам пишет фирма «1С» на сайте в разделе Прав доступа по БСП:

Какой результат в цифрах мы получили:

Ускорение более чем в 8 раз!

Хотелось бы также отметить что порядок вызова видов доступа имеет достаточно важное значение и позволяет ускорить выполнение запроса RLS.

Три точки роста производительности RLS на крупных проектах

1. Для работы с системой ограничения прав доступа на крупном проекте необходимо иметь понимание функционирования 1С на уровне эксперта по технологическим вопросам. Без этого вам придется действовать «вслепую».
2. Нужно воспринимать задачу по организации доступа к данным как отдельный этап и целенаправленно планировать работы по нему.
3. Нужно аккуратно администрировать процесс подключения пользователей к системе в части определения для них профилей, видов и групп доступа. Не создавать без надобности новых точек этого пространства ограничений. В противном случае, как бы вы не старались, рано или поздно система придет в состояние если не хаоса, то сильно запутавшейся елочной гирлянды и вам придется прикладывать серьезные усилия, чтобы все огонечки ровно загорелись на вашем проекте.

Ранее мы уже писали о производительности нового RLS в 1С БСП 3 — приглашаем вас прочитать эту статью.