Настройка RLS в 1С — ограничение доступа на уровне записей
Ранее мы рассматривали настройку ролей пользователей в системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).
Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.
1С RLS (Record Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.
Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).
Преимущества ограничения прав на уровне записей в 1С
Основное преимущество — наличие механизма вообще, механизм достаточно сложный и интересный. Позволяет очень тонко разграничить права пользователей — пользователи могут даже не догадываться о существовании в системе других данных.
Недостатки 1С 8 RLS
Среди недостатков можно отметить заметное падение производительности системы. Это вызвано тем, что платформа при построении запроса в базе данных осложняет любой запрос разработчика дополнительными условиями.
Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.
Настройка ограничения прав на уровне записей 1С RLS
Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:
##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли
По сути, этот запрос каждый раз добавляется при запросе к таблице «#ТекущаяТаблица». Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.
Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — «Параметры сеансов«. Как правило, они задаются при старте сессии пользователя.
Конструктор ограничения доступа к данным
Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:
Другие статьи по 1С:
Пример настройки RLS:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Часто возникает необходимость в частичном ограничении доступа к данным. Например, когда пользователь должен видеть документы только своей организации. В таких случаях в 1С используется механизм ограничения доступа на уровне записей (так называемый, RLS – Record Level Securiy).
Для примера предположим, что перед нами стоит следующая задача. На предприятии ведется многофирменный учет и каждый контрагент и пользователь базы данных относится к определенной организации. Необходимо обеспечить доступ к справочнику “Контрагенты” таким образом, чтобы каждый пользователь мог просматривать, редактировать и добавлять контрагентов только своей организации.
Для решения задачи будем использовать платформу “1С:Предприятие 8.2″. Создадим новую конфигурацию в свойствах которой в качестве основного режима запуска будет выбран вариант “Управляемое приложение”.
Далее создадим справочник “Организации” и ещё два справочника – “Контрагенты” и “Пользователи” с реквизитом “Организация”. Кроме справочников нам понадобятся два параметра сеанса – “Организация” и “Пользователь” (соответствующих типов). Значения этих параметров устанавливаются при запуске сеанса работы с конфигурацией и хранятся до его завершения. Именно значения этих параметров мы и будем использовать при добавлении условий ограничения доступа на уровне записей.
Установка параметров сеанса выполняется в специальном модуле – “Модуль сеанса”
В этом модуле опишем предопределенную процедуру “УстановкаПараметровСеанса” в которой вызовем функцию заранее подготовленного общего модуля “ПолныеПрава”. Это необходимо в силу особенностей работы базы данных в режиме управляемого приложения, когда часть программного кода может выполняться только на стороне сервера (подробно на объяснении этих принципов в данной статье я останавливаться не буду).
В свойствах модуля “ПолныеПрава” необходимо отметить флажки “Сервер”, “Вызов сервера” и “Привилегированный” (последнее означает, что процедуры и функций данного модуля будут выполнятся без контроля прав доступа). Текст модуля будет выглядеть так:
В модуле управляемого приложения будем проверять наличие пользователя конфигурации в справочнике “Пользователи” (для простоты будем искать его по наименованию) и завершать работу системы если он не найден. Это необходимо для того, чтобы обеспечить заполнение параметров сеанса.
Теперь можем перейти непосредственно к описанию ограничений доступа. Для этого создадим роль “Пользователь” и перейдем на закладку “Шаблоны ограничений”, где добавим новый шаблон “КонтрагентыЧтениеИзменение” со следующим текстом шаблона: ГДЕ Организация =Организация #Параметр(1)
Текст шаблона ограничений является расширением языка запросов. В отличии от обычного запроса, текст ограничения должен в обязательном порядке содержать условие “ГДЕ”. В качестве значений параметров запроса (в нашем случае это “&Организация”) используются значения одноименных параметров сеанса. Конструкция вида #Параметр(1) означает, что на это место система подставит текст, переданный в качестве первого параметра в месте использования шаблона. С помощь приведенного шаблона будет выполняться проверка каждой записи таблицы (в нашем случае это будет справочник “Контрагены”). Для записей, значение реквизита “Организация” которых совпадает с заданным в соответствующем параметре сеанса, условие описанное в шаблоне будет выполняться. Таким образом эти записи будут доступны для чтения, изменения или добавления (в зависимости от того для какого из этих прав применяется шаблон). Продемонстрирую вышеизложенное на нашем примере.
Перейдем на закладку “Права” роли “Пользователь” и откроем список прав справочника “Контрагенты”. Будем использовать шаблон ограничений “КонтрагентыЧтениеИзменеие” для прав “Чтение”, “Изменение” и “Доблавление”.
Для права “Чтение” будем использовать шаблон с параметром “ИЛИ ЭтоГруппа”. При этом пользователям данной роли будет разрешено чтение не только элементов справочника “Контрагенты” своей организации, но и всех групп этого справочника.
#КонтрагентыЧтениеИзменение(«ИЛИ ЭтоГруппа»)
Поскольку при добавлении новых элементов справочника системой выполняется неявное чтение предопределенных реквизитов (это нужно, например, для нумерации), то необходимо обеспечить беспрепятственное чтение этих полей. Для этого добавим дополнительную строку с пустым текстом ограничения в таблицу ограничения доступа к данным и перечислим поля для которых действует данное правило – Ссылка, Версия данных, Родитель, Код.
Таким образом, поставленная задача ограничения доступа на уровне записей решена. Пользователи с действующими ограничениями получат доступ на просмотр и редактирование данных только своей организации.
Доступ на уровне записей в типовых конфигурациях. Настройка доступа пользователей с разделением по подразделениям/складам – практический пример
С задачей «как сделать так, чтобы кладовщик Иванов видел документы только своего склада?» сталкивался, наверное, каждый администратор/разработчик. «Продвинутые» специалисты знают, что в конфигурациях на основе БСП доступен механизм разделения доступа на уровне записей, он же RLS и автоматически посоветуют заказчику самостоятельно настроить доступ с использованием данного функционала и не отвлекать специалистов по пустякам.
С одной стороны, это хорошо, что данная возможность предоставляется типовыми средствами, а с другой – этой возможностью еще нужно уметь воспользоваться, что, поверьте, не так и очевидно.
Итак, пусть в типовой УТ требуется ограничить доступ нескольких кладовщиков/менеджеров/продавцов только к своим складам/подразделениям. Другими словами, предоставить стандартный для выполняемых данными работниками обязанностей перечень ролей, при этом ограничить эти возможности только одним складом/подразделением, то есть:
Начать следует с включения функциональных опций в разделе НСИ и Администрирование – Настройка пользователей и прав. Далее будем работать только с этой командой, поэтому сообщать ниже ее расположение не буду.
Для активации функционала ограничения доступа следует включить функциональную опцию Ограничивать доступ на уровне записей. Можно дополнительно настроить вариант работы: стандартный и производительный. Если кратко, то рекомендовано использовать вариант производительный, а в случае, когда начнут возникать проблемы, переключить на стандартный.
Для большего удобства назначения наборов прав пользователей (особенно при их серьезном количестве) рекомендую включить опцию Группы пользователей – о ней речь пойдет далее.
Теперь нужно настроить группы доступа для каждого склада/подразделения.
В типовой конфигурации изначально имеется несколько наборов групп доступа и удобно воспользоваться ими для создания отдельных групп доступа для каждого склада/подразделения.
Например, на основании групп доступа: Кладовщик, Менеджер по продажам, Менеджер по закупкам следует создать такие же по доступным ролям группы, но с ограничением по каждому из складов: Кладовщик (Магазин 1), Кладовщик (Магазин 2)…
Это удобно сделать копированием типовых групп доступа с последующей доработкой каждой.
Если планируется создание нескольких групп, объединенных в рамках каждого склада(магазина), удобно заранее создать группы в справочнике для каждого из разделителей, и новые группы доступа сосредотачивать по группам. Хотя соглашусь, что понятие Группы групп доступа находится за рамками логики.
Группы доступа в дальнейшем будут назначаться конечным пользователям (их группам) и предоставлять права в рамках ролей, определенных в соответствующем профиле групп доступа.
Если вводить группы копированием советующих, то новой группе назначается профиль копируемой. Если же создается новая группа, то следует подобрать подходящий профиль из набора предопределенных.
Когда функциональная опция Ограничивать доступ на уровне записей включена, в форме справочника Группы доступа появляется закладка Ограничение доступа.
В верхней таблице приведены варианты видов доступа и значение доступа (вариант ограничения). В данную таблицу нельзя добавлять строки, можно лишь изменять значение доступа на один из двух вариантов: Все разрешены(по умолчанию) и все запрещены.
Вариант «все запрещены» предоставляет доступ только к указанным в нижней таблице значениям соответствующих данных – например, элементов справочника склады.
«Все разрешены» разрешает доступ ко всем советующим значениям доступа, за исключением указанных в нижней таблице.
В нашей задаче требуется предоставить доступ только к одному складу/подразделению, поэтому воспользуемся первым вариантом и добавим единственный нужный склад/подразделение для каждой группы.
Таким образом необходимо подготовить набор групп доступа для каждого из магазинов.
Настала очередь назначения пользователям созданных групп доступа.
Сделать это можно как минимум тремя способами:
Рассмотрим 3-й способ.
Порядок включения в группы доступа для групп и для отдельных пользователей аналогичен:
Однако очевидным достоинством данного способа является отсутствие необходимости определения групп доступа для каждого пользователя группы.
При создании нового пользователя в рамках группы, этому пользователю по умолчанию назначаются группы доступа, определенные для пользовательской группы.
При переносе из группы в группу (например, при переводе работника на другой склад) группы доступа по умолчанию определяются по новой группе.
После настройки групп доступа и включения в них пользовательских групп рекомендуется проверить работу ограничений, для этого создать тестового пользователя и переносить его в разные группы доступа.
Запустив сеанс тестового пользователя следует убедиться, что, например, в справочнике Склады/Магазины имеется только один «свой» склад.
Например, на рисунке выше в списке ограничений есть ограничение по складам, но отсутствует ограничение по подразделениям.
Однако есть способ добавления вида ограничения в группе доступа, если такое ограничение не предусмотрено. Для этого необходимо изменить профиль групп доступа. При этом нужно понимать, что профили, имеющиеся в справочнике изначально, являются предопределенными и их изменение невозможно. Для дополнения ограничений следует создать новый профиль путем копирования советующего предопределенного. При этом в новый профиль копируются доступные роли и ограничения.
Например, скопировав профиль работник склада, создать новый Работник склада с ограничениями.
При редактировании нового (непредопределенного) профиля на закладке Ограничения в верхней таблице доступна кнопка Добавить, позволяющая задать новое ограничение, например по подразделениям.
В отличие от группы доступа в качестве значения доступа предлагается выбор из четырех вариантов:
Для первых двух вариантов заполнение нижней таблицы не предусмотрено. Для нашей задачи целесообразно выбрать 1-й вариант. 2-й тоже подходит, только в группе доступа при назначении ограничения по складу потребуется изменить значение по умолчанию.
Теперь подготовленные профили с ограничениями можно назначать группам доступа, при этом назначая конкретны склады/подразделения для каждой группы.
Следует отметить, что в отдельных типовых конфигурациях, например 1С: Бухгалтерия предприятия 3.0, в списках ограничений доступа могут присутствовать виды, недоступные для использования, так как их функционал не реализован.
Эффективная работа ограничений доступа к данным на уровне записей
В статье дается условное разделение ограничений прав доступа на уровне записей на простые и сложные; показано, как эти ограничения влияют на запрос к СУБД; даются рекомендации по написанию эффективных ограничений на уровне записей.
1. Режимы наложения ограничений
Существует 2 режима наложения ограничений на уровне записей. Первый, со словом РАЗРЕШЕННЫЕ в запросе, используется для исключения записей из результата выборки, которые пользователю запрещены (например, вывод списка документов). Второй, без слова РАЗРЕШЕННЫЕ, не включает фильтр для отсеивания запрещенных записей, но определяет поведение механизма работы с базой данных таким образом, чтобы при попытке доступа к запрещенным данным произошло исключение.
2. Различие между простым и сложным ограничением
Ограничения доступа на уровне записей задаются запросом, определяющим, какие записи пользователю доступны. В этом запросе всегда определена главная таблица, которая соответствует защищаемой таблице. Если таблица не указана (запрос может начинаться с «ГДЕ»), то это равносильно включению только одной таблицы в раздел ИЗ.
Ограничения доступа на уровне, задаваемые для объектов метаданных, можно разделить на 2 вида: простые и сложные. К простым относятся ограничения, которые имеют только одну таблицу в разделе ИЗ (и эта таблица – защищаемая). В этом случае ограничение доступа задается лишь с помощью реквизитов этой таблицы, без использования соединений с другими таблицами. Неявные соединения (обращение через точку к реквизиту ссылочного типа), добавляемые в запрос автоматически, переводят ограничение в категорию сложных. К сложному классу ограничений относятся запросы с более чем одной таблицей в разделе ИЗ.
Иногда ограничение, которое выглядит простым, на самом деле исполняется как сложное ограничение. Это случается, когда ограничение задано для регистра остатков или регистра бухгалтерии, поскольку в этом случае механизм работы с базой данных защищает не только таблицу движений этих регистров, но и таблицу остатков. Таким образом, запрос к таблице остатков получает ограничения, заданные для регистра. И чтобы эти ограничения включить в запрос к СУБД (чтобы иметь доступ к реквизитам регистра), механизм работы с базой данных добавляет таблицу движений в условие ограничений доступа.
3. Принципы трансляции ограничения доступа на уровне записей в запрос к СУБД
Рассмотрим самый простой случай, когда запрос выбирает данные из одной таблицы.
В случае, если запрос содержит слово РАЗРЕШЕННЫЕ, простое ограничение будет добавлено в раздел ГДЕ исходного запроса. Запрос к СУБД получит дополнительные инструкции по отбору только тех записей, которые разрешено видеть пользователю, и от СУБД придут только те данные, которые пользователю разрешены.
Настройка доступа на уровне записей справочников.
Данная настройка в конфигурацию была включена не так давно, я лично считаю, что настройка весьма полезная.
Данная настройка необходима тем, кому необходимо разграничить доступ к справочнику в разрезе элементов этого справочника. Например, менеджеру необходимо видеть только покупателей, а также отчеты и журналы документов, только по контрагентам, к которым ему разрешен доступ, а бухгалтеру необходимо иметь полный доступ ко всем элементам справочника, к примеру «Контрагенты».
Предлагаю рассмотреть пример на примере конфигурации УПП.
Обычно вышеописанные списки групп обсуждаются с руководством и только после вводятся в программу.
Теперь необходимо описать собственно те настройки, которые нужно выполнить в 1С.
Откроется форма обработки «Параметры доступа на уровне записей» см. Рис. 2.
На данной форме необходимо собственно включить ограничение, за что отвечает флаг «Ограничить доступ на уровне записей по видам объектов» и выбрать те справочники, по которым ограничение будет действовать. В данной статье рассматривается только справочник «Контрагенты».
Группы контрагентов вводятся в справочнике «Группы пользователей» см. Рис. 3.
Откроется форма элемента справочника «Группы пользователей» см. Рис. 4.
В левой части окна указывается объект доступа (у нас это «контрагенты»), справа указываются пользователи, которые входят в группу, в данном примере это «Администраторы».
Для каждой группы пользователей определенной вами необходимо выполнить данную настройку, не должно остаться ни одного пользователя, который не входит в группу.
Для нашего примера это: Покупатели, Поставщики, Прочие. См. Рис. 6.
Группа доступа для контрагента назначается на закладке «прочие». Обычно я использую вспомогательную стандартную обработку для назначения данных групп. «Групповая обработка справочников и документов», она позволяет массово установить нужную группу для этого реквизита.
Красным цветом выделено отношение групп пользователей к группам доступа контрагентов. Для групп «Менеджеры закупа» и «Менеджеры продаж» настраиваются отношения точно также, только объекты доступа указываются те к которым они должны иметь доступ, например, только «Поставщики» или только «Покупатели». Флаги, к примеру «Видимость в списке» это права «Объекта доступа». Из названия я думаю, что понятна и функциональность этих прав.
После выше указанных манипуляций у Вас должен появиться разграниченный доступ к справочнику «Контрагенты».
По аналогии настраиваются и остальные справочники.
Важно:
Разграниченный доступ не распространяется на роль «ПолныеПрава»;
В наборе ролей пользователя должна присутствовать роль «Пользователь»;
Если у Вас собственные роли, то необходимо в вашу роль вставить шаблоны и ограничения как в роли «Пользователь» по отношению к справочнику «Контрагенты» (см. код в роли Пользователь кликнув на справочнике контрагенты).