XV

Конференция 1С-Рарус для корпоративных клиентов

14 – 18 октября 2022 года

Сочи, Красная поляна

Сочи, Красная поляна, Radisson Rosa Khutor 5*

При участии руководителей подразделений фирмы «1С»
и профессора МШУ Сколково Андрея Шишакова

Подробнее
Спикеры конференции
1c-crm-red
От экспертов «1С‑Рарус»: Введение в управление доступом в больших системах 1С. Оптимизация RLS
31 мая 2021

От экспертов «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 — проверка права конкретного пользователя на текущую конкретную таблицу (объект метаданных). При этом каждый раз сначала перебираются (определяются) группы доступа, дающие права на запрашиваемый объект метаданных, а следом выполняется запрос по определению групп доступа, доступных текущему пользователю.

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

Оптимизация типового шаблона RLS

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

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

Оптимизация типового шаблона RLS

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

Оптимизация типового шаблона RLS

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

Продолжая разбираться с оптимизацией 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

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

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

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

Ответ фирмы «1С»

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

Перенастройка ролей. Результат в цифрах

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

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

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

Подведём итоги:

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

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

Авторы статьи

Федченко Алексей
Федченко Алексей
Есть вопросы по статье? Задайте их нам!
info-big
Рассылка «Новости компании»: узнавайте о новых продуктах, услугах и спецпредложениях
Отправляя эту форму, Вы соглашаетесь с Политикой конфиденциальности и даете согласие на обработку персональных данных компанией «1С-Рарус»

Остались вопросы?
Нужна консультация?
Свяжитесь с нами!