RLS – гибкая и тонкая настройка ограничений доступа к данным. Ограничение доступа к данным 1с ограничения доступа к данным

Объект конфигурации «роль» дает набор прав на операции (действия) над объектами конфигурации.

Роль «Полные права».

Это всего лишь роль (не предопределенная), в которой установлены флажки на все виды прав на все объекты конфигурации.

Отличие ее от остальных ролей – наличие права «Администрирование».

В случае создания хотя бы одного пользователя, система начинает проверять наличие права «Администрирование» — оно должно быть минимум у одного пользователя.

Ограничение доступа на уровне записей

Row Level Security (RLS) – ограничение на уровне записей.

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

роли,
параметры сеанса,
функциональные опции,
привилегированные общие модули,
ключевое слово РАЗРЕШЕННЫЕ в языке запросов.

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

Техническая реализация ограничений доступа в 1С

1С формирует запрос к СУБД. Кластер серверов добавляет к запросу секцию ГДЕ, в которой содержится текст условия на ограничение доступа по RLS, затем этот запрос отправляется в СУБД, извлеченные данные возвращаются на клиент 1С.

Такой механизм будет работать при любом запросе из клиента:

в отчетах,
в динамических списках и в обычных формах списков
в произвольных запросах.

Подобная реализация механизма сильно влияет на производительность.

Пути обхода ограничений доступа.

В больших ресурсоемких операциях (обработки перепроведения документов, например) часть кода можно выносить в привилегированные модули.

А) Привилегированный модуль — это общий модуль с флагом «Привилегированный» в свойствах.

Его особенность заключается в том, что код в нем исполняется без какого-либо контроля прав доступа, в том числе и RLS.

Б) Также привилегированный режим можно включить для модулей объектов документов . Это делается в свойствах документа, флаг

Привилегированный режим при проведении
Привилегированный режим при отмене проведения

В) Метод УстановитьПривилегированныйРежим()

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

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

Действовать он будет до строки отключения этого режима или до конца процедуры / функции

(Истина );

// любой код тут будет исполнен без контроля прав и RLS

УстановитьПривилегированныйРежим (Ложь ); // либо конец процедуры / функции

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

Если в процедуре или функции вызовов метода УстановитьПривилегированныйРежим (Ложь ) сделано больше, чем вызовов метода УстановитьПривилегированныйРежим (Истина ), то будет вызвано исключение

Функция ПривилегированныйРежим () возвращает Истина , если привилегированный режим еще включен, и Ложь , если он полностью выключен. При этом не анализируется количество установок привилегированного режима в конкретной функции.

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

Также существует возможность стартовать привилегированный сеанс. Это сеанс, в котором привилегированный режим установлен с самого начала работы системы. При этом во время работы метод ПривилегированныйРежим () будет всегда возвращать Истина , а возможность отключить привилегированный режим не поддерживается. Стартовать привилегированный сеанс может только пользователь, которому доступны административные права (право Администрирование). Запуск сеанса можно выполнить с помощью ключа командной строки запуска клиентского приложения UsePrivilegedMode или параметра строки соединения с информационной базой prmod .

Закономерно возникает вопрос: Зачем тогда вообще настраивать ограничения доступа, если его можно так легко обойти?

Безопасный режим.

Да, можно написать внешнюю обработку с привилегированным режимом исполнения и выгрузить / испортить данные. Для предотвращения этого в системе есть метод глобального контекста

УстановитьБезопасныйРежим ().

Безопасный режим кроме прочего игнорирует привилегированный режим.

Его нужно устанавливать перед программным вызовом внешних обработок или экспортных процедур и функций из их модулей.

При выполнении запрещенных операций во время выполнения генерирует исключение.

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

Настройка ограничения доступа

RLS можно настроить только для прав:

чтение (select)
добавление (insert)
изменение (update)
удаление (delete)

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

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

Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан).

Для всех остальных прав такой возможности нет.

Добавим новое ограничение для права «чтение» справочника «Номенклатура». Откроется список полей, для которых можно настроить добавляемое ограничение.

Это означает, что при попытке получить доступ к отмеченным флажками полям, ограничение сработает, а при попытке получить доступ к неотмеченным полям ограничение не сработает.

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

*Особенность: для прав добавление, изменение, удаление:

Ограничение может быть настроено только для всех полей.

Ограничение может быть только одно.

Для права «Чтение» можно настроить несколько условий, они будут объединяться логическим оператором «И».

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

в регистрах накопления ограничения доступа могут содержать только измерения основного объекта ограничения;
в регистрах бухгалтерии в ограничениях можно использовать только балансовые измерения основного объекта ограничения

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

Механизм наложения ограничений доступа.

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

Формируется список прав (чтение, добавление, изменение, удаление), список таблиц базы данных и список полей, используемых этим запросом.
Из всех ролей текущего пользователя выбираются ограничения доступа к данным для всех прав, таблиц и полей, задействованных в запросе. При этом если какая-нибудь роль не содержит ограничений доступа к данным какой-нибудь таблицы или поля, то это значит, что в данной таблице доступны значения требуемых полей из любой записи. Иначе говоря, отсутствие ограничения доступа к данным означает наличие ограничения ГДЕ Истина .
Получаются текущие значения всех параметров сеанса и функциональных опций , участвующих в выбранных ограничениях.

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

Ограничения, полученные из одной роли, объединяются операцией И .

Ограничения, полученные из разных ролей, объединяются операцией ИЛИ .

Построенные условия добавляются к SQL-запросам, с которыми «1С: Предприятие» обращается к СУБД. При обращении к данным со стороны условий ограничения доступа проверка прав не выполняется (ни к объектам метаданных, ни к объектам базы данных). Причем механизм добавления условий зависит от выбранного способа действия ограничений «все» или «разрешенные».

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

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

Способ «Все».

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

Наложение ограничений доступа способом «все» схематически представлено на рисунке:

Способ «Разрешенные».

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

Ограничения доступа к данным накладываются на объекты базы данных в момент обращения «1С:Предприятия» к базе данных.

В клиент-серверном варианте «1С:Предприятия» наложение ограничений выполняется на сервере «1С:Предприятия».

Однако эта опция (РАЗРЕШЕННЫЕ) не сработает в случае, если мы в запросе обратимся к таблице, для которой не настроены ограничения доступа, но в которой есть ссылки на строки таблицы с настроенными ограничениями. В этом случае результат запроса выдаст «<Объект не найден>…...» вместо значения ссылочного поля.

Если вы разрабатываете отчет или обработку с использованием запросов типовой или самописной конфигурации, всегда ставьте флаг «Разрешенные» , чтобы отчет работал под любым пользователем с любым набором прав.

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

Важно, что если в запросе не указано ключевое слово РАЗРЕШЕННЫЕ, то все отборы, заданные в этом запросе, не должны противоречить ни одному из ограничений на чтение объектов базы данных, используемых в запросе. При этом если в запросе используются виртуальные таблицы, то соответствующие отборы должны быть наложены и на сами виртуальные таблицы.

Практика 1. Конструктор запросов в настройках RLS.

Составим текст секции «ГДЕ» в запросе к справочнику. Можно воспользоваться конструктором запросов.
Конструктор имеет урезанный вид.

Закладка «Таблицы»

Основная таблица будет таблицей объекта, для которого настраивается ограничение.

Можно также выбирать и другие таблицы и настраивать между ними различные связи на закладке «Связи».

Закладка «Условия»

Здесь настраиваются собственно условия ограничения доступа

Добавим условия на реквизит «Цена» справочника номенклатура для права на «чтение» ко всем полям таблицы.

«Номенклатура ГДЕ Номенклатура.Цена > 500»

Проверим, как сработает это простое правило. Таблица справочника содержит такие элементы:

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

Пропали также и группы. Изменим текст ограничения

«Номенклатура ГДЕ Номенклатура.Цена > 500

ИЛИ Номенклатура.ЭтоГруппа»

Ну вот теперь то, что нужно.

Если в настройке списка убрать отображение поля «код», будут выведены все элементы справочника, т.е. ограничение не сработало. Если поставить отображение поля «Код», ограничение будет работать.

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

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

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

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

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

Ограничения при настройке доступа (RLS).

Нет секции Итоги;
Нельзя обращаться к виртуальным таблицам регистров;
В явном виде нельзя использовать параметры;
Во вложенных запросах могут использоваться любые>/span> средства языка запросов, кроме :
- оператора В ИЕРАРХИИ;
- предложения ИТОГИ;
- результаты вложенных запросов не должны содержать табличные части>/span>;
- виртуальных таблиц , в частности ОстаткиИОбороты

Практика 2. Номенклатура с актуальной ценой.

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

Решение:

Добавляем новое правило ограничения доступа для справочника «Номенклатура» на право «чтение».
Выбираем «прочие поля».
В конструкторе добавляем вложенный запрос. В нем выбираем таблицу регистра сведений «Цены номенклатуры».
Вкладки «порядок» нет – это особенность конструктора запросов для построения запроса ограничения доступа.
На вкладке «Дополнительно» ставим «первые 999999999», вкладка «порядок» появилась.
Настраиваем упорядочивание по полю «Период» по убыванию.
Затем настраиваем связь основной таблицы с вложенным запросом по ссылке.

Шаблоны ограничений доступа .

Практика 3. Ограничение на «контрагенты» по значению в константе.

Настроим ограничение доступа для справочника Контрагенты по значению, которое хранится в Константе.

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

Решение

Для справочника «Контрагенты» для права «чтение» настроим ограничение, добавив в секцию «Условия» вложенный запрос к константе. Не забыть ЭтоГруппа.

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

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

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

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

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

Можно вынести в шаблон любой кусок текста ограничения доступа. Вызов шаблона осуществляется через символ «#». Например, #ШаблонКонтрагент.

Через # в 1С пишутся инструкции препроцессору. В контексте исполнения настроек ограничений доступа платформа заменяет текст вызова шаблона на текст шаблона.

Вынесем в шаблон «ШаблонКонтрагент» текст после слова ГДЕ, кроме текста про ЭтоГруппа.

Параметры в шаблонах ограничений доступа.

Продолжим решение задачи 2.

Проблема заключается теперь в том, что основная таблица в справочнике называется «контрагент», в документе «Приходная накладная». Проверяемое поле в справочнике называется «ссылка», в документе – «Контрагент».

Изменим в тексте шаблона название основной таблицы на «#ТекущаяТаблица»

«#ТекущаяТаблица» — это предопределенный параметр.

И через точку укажем номер входного параметра – «.#Параметр(1)

«#Параметр» — это тоже предопределенное значение. Может содержать произвольное количество входных параметров. Обращение к ним происходит по порядковому номеру.

В тексте ограничения доступа для справочника укажем следующее:

Для документа следующее:

«РеализацияТоваров ГДЕ #ШаблонКонтрагент(«Контрагент»)»

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

Основная таблица — Номенклатура

Текст шаблона такой:

#ТекущаяТаблица ГДЕ #ТекущаяТаблица.#Параметр(1) = #Параметр(2)

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

После символа «#» могут следовать:

Одно из ключевых слов:
- Параметр, после которого в скобках указывается номер параметра в шаблоне;
- ТекущаяТаблица – обозначает вставку в текст полного имени таблицы, для которой строится ограничение;
- ИмяТекущейТаблицы – обозначает вставку в текст полного имени таблицы (как строковое значение, в кавычках), к которой применяется инструкция, на текущем варианте встроенного языка;
- ИмяТекущегоПраваДоступа – содержит имя права, для которого выполняется текущее ограничение: ЧТЕНИЕ/READ, ДОБАВЛЕНИЕ/INSERT, ИЗМЕНЕНИЕ/UPDATE, УДАЛЕНИЕ/DELETE;
имя параметра шаблона – означает вставку в текст ограничения соответствующего параметра шаблона;
символ «#» – обозначает вставку в текст одного символа «#» .

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

Шаблон ограничения доступа, который указывается в формате #ИмяШаблона(«Значение параметра шаблона 1», «Значение параметра шаблона 2»,...) . Каждый параметр шаблона заключается в двойные кавычки. При необходимости указания в тексте параметра символа двойной кавычки следует использовать две двойные кавычки.
Функция СтрСодержит(ГдеИщем, ЧтоИщем) . Функция предназначена для поиска вхождения строки ЧтоИщем в строке ГдеИщем. Возвращает Истина в случае, если вхождение обнаружено и Ложь – в противном случае.
Оператор + для конкатенации строк.

Для удобства редактирования текста шаблона на закладке Шаблоны ограничений в форме роли нужно нажать кнопку Установить текст шаблона. В открывшемся диалоге ввести текст шаблона и нажать кнопку ОК.

Их нельзя установить методом УстановитьПараметр() или чем-то подобным.

В качестве параметров в данном случае выступают:

Параметры сеанса
Функциональные опции

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

Практика 4. Доступ к «своим» контрагентам

Необходимо настроить ограничение доступа текущего пользователя к «своим» контрагентам.

Есть справочник «Пользователи», справочник «Контрагенты», документы с реквизитом «Контрагент».

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

Связь тоже нужно настроить.

Возможные варианты:

Установления связей пользователь + контрагент

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

Возможные решения задачи:

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

Решение.

Создадим новый параметр сеанса «ТекущийПользователь» и пропишем его заполнение в модуле сеанса.

Создадим регистр сведений «Соответствие менеджеров и контрагентов»

Создадим новую роль и в ней новое ограничение доступа для документа «ПриходнаяНакладная».

В тексте запроса соединим основную таблицу с регистром сведений по Контрагент = Контрагент и Менеджер = &ТекущийПользователь. Вид соединения Внутреннее.

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

Проверяем – ограничения работают

*Особенность : Если изменить список контрагентов пользователя в регистре ограничения доступа будут действовать сразу без перезапуска сеанса пользователя.

Практика 5. Дата запрета изменений.

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

Создадим регистр сведений «ДатыЗапретаИзменений» с измерением Пользователь, ресурс ДатаЗапрета.

Построим логику решения таким образом:

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

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

Документы
Периодические регистры сведений

Создадим новую роль «ОраниченияПоДатеЗапретаИзменений».

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

Настройку указываем для всех полей.

Текст ограничения такой:

ПриходнаяНакладная ИЗ Документ.ПриходнаяНакладная КАК ПриходнаяНакладная

ДатыЗапретаИзменений.ДатаЗапрета КАК ДатаЗапрета
ИЗ

ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
МАКСИМУМ(ДатыЗапретаИзменений.Пользователь) КАК Пользователь
ИЗ
РегистрСведений.ДатыЗапретаИзменений КАК ДатыЗапретаИзменений
ГДЕ
(ДатыЗапретаИзменений.Пользователь = &ТекущийПользователь
ИЛИ ДатыЗапретаИзменений.Пользователь = ЗНАЧЕНИЕ(Справочник.пользователи.ПустаяСсылка))) КАК ВЗ_Пользователь
ПО ДатыЗапретаИзменений.Пользователь = ВЗ_Пользователь.Пользователь) КАК ВложенныйЗапрос
ПО ПриходнаяНакладная.Дата > ВложенныйЗапрос.ДатаЗапрета

Проверяем – ограничение работает.

Использование инструкций препроцессору

#Если Условие1 #Тогда

Фрагмент запроса 1

#ИначеЕсли Условие2 #Тогда

Фрагмент запроса 2

#Иначе

Фрагмент запроса 3

#КонецЕсли

В условиях можно использовать логические операции (и. или, не и т.д) и обращение к параметрам сеанса.

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

Минус заключается в том, что конструктор запроса с таким текстом работать не будет.

*Особенность :

В отличие от инструкций препроцессору встроенного языка в текстах ограничения доступа перед оператором Тогда нужно ставить решетку — #Тогда

Практика 6. Переключатель «Использовать RLS»

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

Для этого добавим Константу и параметр сеанса с именем «ИспользоватьRLS».

Пропишем в Модуле сеанса установку значения параметра сеанса из значения константы.

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

«#Если &ИспользоватьRLS #Тогда ….. #КонецЕсли»

Проверяем – все работает.

Однако, теперь после включения флага «использовать РЛС» изменения сразу в силу не вступят. Почему?

Потому что параметр сеанса устанавливается при запуске сеанса.

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

Конец первой части.

В этой статье я расскажу, как работает механизм настройки «ограничение доступа на уровне записей» в 1С:УПП 1,3. Информация для статьи была подобрана на май 2015 года. С тех пор УПП кардинально не обновляется, т.к флагманом 1С выбрала 1С:ERP. Все же УПП исправно трудится на многих предприятиях, поэтому я выкладываю результаты своих исследований по RLS в УПП в этой статье. Кому-то точно пригодится.

Все сухо, сжато и без воды. Как я люблю))).

Настройки прав доступа.

Схема взаимодействия объектов.

В УПП 1.3 управление доступом осуществляется подсистемой «Управление доступом» из БСП версии 1.2.4.1.

Метаданные, используемые в системе управления доступом в УПП:

Справочник «Профили полномочий пользователей»
Регистр сведений «Значения дополнительных прав пользователей»
План видов характеристик «Права пользователей»
Справочник «Пользователи»
Системный справочник «Пользователи ИБ»
Справочник «Группы пользователей»
Регистр сведений «Настройки пользователей»
План видов характеристик «Настройки пользователей»
Перечисление «Виды объектов доступа»
Регистр сведений «Назначение видов ограничения доступа»
Перечисление «Области данных объектов доступа»
Регистр сведений «Настройки прав доступа пользователей»
Параметр сеанса «Использовать ограничение по <ВидДоступа>».

Включение ограничений доступа на уровне записей.

Ограничение доступа на уровне записей (RLS) включается в интерфейсе
«Администрирование пользователей» -> «Доступ на уровне записей» -> «Параметры».

Доступ на уровне записей определен через виды объектов доступа. Список видов объектов доступа (в скобках указаны соответствующие справочники):

«Контрагенты» («Контрагенты»)
«Организации» («Организации»)
«Физические лица» («Физические лица»)
«Проекты» («Проекты»)
«Склады («Склады (места хранения)»)
«Кандидаты» («Кандидаты»)
«Заметки» («Типы записей заметок»)
«Подразделения» («Подразделения»)
«Подразделения организаций» («Подразделения организации»)
«Номенклатура (изменение)» («Номенклатура»)
«Спецификации» («Спецификации»)
«Цены номенклатуры» («Типы цен номенклатуры»)
«Внешние обработки» («Внешние обработки»)

*Перечень возможных видов доступа фиксирован и содержится в перечислении «Виды объектов доступа».

Справочник «Профили полномочий пользователей».

Настройка доступа к объектам информационной базы начинается с настройки профиля полномочий пользователей.

Профиль объединяет

совокупность ролей – права доступа к объектам
дополнительных прав пользователей – права к функциональным возможностям программы.

Результат настройки профиля – это запись в регистр сведений «Значения дополнительных прав пользователей».
Этот регистр в настройке РЛС не используется.

Дополнительные права могут быть записаны для профиля или пользователя. Причем если дополнительные права настроены для профиля и профиль связан с пользователем, то индивидуально для пользователя нельзя до-настроить дополнительные права.
*Перечень прав перечислен в плане видов характеристик «Права пользователей»

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

Связь справочника «Пользователи» и «Пользователи информационной базы» реализована через реквизит «ИдентификаторПользователяИБ» справочника «Пользователи», в котором хранится GUID пользователя ИБ.

Состав ролей пользователя также недоступен для редактирования, если пользователю присвоен определенный профиль.

Для пользователя существует возможность указать «Настройки пользователя». Это различные сервисные настройки типового автоматического поведения системы в определенных ситуациях.

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

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

Справочник «Группы пользователей».

Используется для объединения пользователей в группы и в числе прочего для настройки ограничений доступа на уровне записей.

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

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

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

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

ВАЖНО! Пользователи, которые не включены в какую-либо группу, не смогут работать с теми объектами, доступ к которым определяется на уровне записей. Это относится ко всем объектам – независимо от того, используются ли соответствующие виды объектов доступа или нет.

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

ВАЖНО! Включение пользователя в большое количество групп может приводить к падению быстродействия. Поэтому не стоит включать пользователя в большое количество групп.

После записи изменений группы пользователей будет заполнен Регистр сведений «Назначение видов ограничения доступа». В этом регистре хранятся записи о соответствии группе пользователей определенного вида доступа.

*Регистр используется в шаблонах ограничения доступа

Форма «Настройка доступа».

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

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

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

Сравнение видов доступа и возможных настроек:

Вид доступа	Настройки вида доступа
	Чтение	Запись	Вид наследования прав доступа	Видимость в списке	Просмотр доп информации	Редактирование доп информации	Просмотр данных	Редакти рование данных	Цены компа нии		Цены контр аген тов
	Чтение	Запись	Вид наследования прав доступа	Видимость в списке	Просмотр доп информации	Редактирование доп информации	Просмотр данных	Редакти рование данных	Чтение	Запись	Чтение	Запись
Контрагенты
Организации
Физические лица
Проекты
Склады
Кандидаты
Заметки
Подразделения
Подразделения организаций
Номенклатура
Спецификации
Цены номенклатуры
Внешние обработки

Права доступа.

«Чтение » — пользователь будет видеть элемент справочника в списке и сможет открыть его на просмотр, также сможет выбрать его из списка при заполнении реквизитов других объектов.

«Запись » — пользователь сможет изменять:

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

Исключение: доступ к элементам некоторых справочников – видов объектов доступа – не зависит от права «Запись». Это справочники Организации, Подразделения, Подразделения организаций, Склады, Проекты. Они относятся к объектам НСИ, поэтому менять их может только пользователь с ролью «Настройка НСИ...».

Для вида объекта доступа «Номенклатура (изменение) » право доступа на «запись » определено только на уровне групп справочника «Номенклатура », нет возможности задать право «запись » для отдельного элемента справочника.

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

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

Области данных.

Для следующих видов объектов доступа определены области данных:

Контрагенты
Физические лица
Цены номенклатуры

Для вида объекта доступа «Контрагенты»

Контрагенты (список) — определяет видимость контрагентов в списке справочника «Контрагенты». Зависит от значения флажка в колонке «Видимость в списке».
Контрагенты (доп. информация) — определяет возможность «чтения»/«записи» элемента справочника «Контрагенты» и связанной с ним доп. информации (договоры, контактные лица и т.п.). Зависит от значения флажка в соответствующих колонках «Просмотр доп. информации»/«Редактировании доп. информации».
Контрагенты (данные) — определяет возможность «чтения»/«записи» данных (справочники, документы, регистры), связанных со справочником «Контрагенты». Зависит от значения флажка в колонке «Просмотр данных»/«Редактирование данных».

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

Физические лица (список) — определяет видимость физического лица в списке справочника «Физические лица». Зависит от значения флажка в колонке «Видимость в списке».
Физические лица (данные) — определяет возможность «чтения»/«записи» данных (справочники, документы, регистры), связанных со справочником «Физические лица». Зависит от значения флажка в колонке «Просмотр данных»/«Редактирование данных».

Для вида объекта доступа «Цены номенклатуры» предусмотрены следующие области данных:

Цены компании — определяет возможность «чтения»/«записи» цен номенклатуры компании.
Цены контрагентов — определяет возможность «чтения»/«записи» цен номенклатуры контрагентов.

*Области данных – это закрытый список элементов, содержится в перечислении «Области данных объектов доступа»

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

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

«Контрагенты» («Группы доступа контрагентов»)
«Физические лица» («Группы доступа физических лиц»)
«Кандидаты» («Группы кандидатов»)
«Спецификации номенклатуры» («Назначения использования спецификаций»)

Группа доступа указывается для каждого элемента справочника (в специальном реквизите).

Настройки доступа из «группы доступа…» осуществляются в дополнительной форме настройки прав доступа, которая вызывается одной из двух команд:

«Доступ к текущему элементы»,
«Доступ к справочнику в целом»

в форме списка справочников «Групп доступа...»

Пример: Документ «Приходный ордер на товары» ограничен по видам объектов доступа «Контрагенты», «Организации», «Склады».

Если для вида доступа «Контрагенты» предоставить доступ к пустому значению, то пользователь увидит документы, в которых реквизит «Контрагент» не заполнен.

Доступ к элементу справочника или группе.

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

Согласно этому, в форме «Настройка прав доступа» в колонке «Вид наследования прав доступа иерархических справочников» устанавливаются следующие значения:

Только для текущего права – для элемента справочника, права действуют на указанный элемент
Распространить на подчиненных – для группы справочника, права действуют на все подчиненные элементы

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

*Регистр используется в шаблонах ограничения доступа.

Использование шаблонов.

Шаблоны в УПП 1.3 написаны для каждого вида доступа отдельно и для возможных комбинаций видов доступа, как правило, для каждой группы пользователей.

Например , в демо-версии УПП настроена группа пользователей «Закупки». Для этой группы включено использование видов доступа «Организации», «Контрагенты», «Склады». Соответственно в системе создан ряд шаблонов ограничения доступа:

«Организация»
«Организация_Запись»
«Контрагенты»
«Контрагенты_Запись»
«Склады»
«Склады_Запись»
«КонтрагентОрганизация»
«КонтрагентОрганизация_Запись»
«ОрганизацияСклад»
«ОрганизацияСклад_Запись»
«КонтрагентОрганизацияСклад_Запись»
«КонтрагентСклад»
«КонтрагентСклад_Запись»

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

В общем случае схема построения шаблона одинакова для всех видов доступа и выглядит так:

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

По результату соединения определяется, разрешен доступ или нет.

Конец второй части.

Механизм RLS в 1С (ограничения доступа на уровне записей) позволяет разработчику устанавливать свои отборы и условия непосредственно на таблицы БД. Такие ограничения могут накладываться на чтение, добавление, изменение и удаление.

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

Несмотря на такой весомый недостаток, механизм RLS достаточно удобен и гибок. С его помощью можно настроить систему так, чтобы ни один пользователь не увидел ничего «лишнего». Ограничивать доступ своих сотрудников, особенно если их много, очень продуктивно. Дело заключается даже не столько в недоверии, сколько в защите от случайных ошибок и человеческого фактора. Чем меньше данных доступно, тем легче с ними работать и не «Запутаться».

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

Настройка ограничения доступа на уровне записей

Настройка и разработка РЛС производится в конфигураторе 1С. Для этого первым делом создайте роль в ветви метаданных.

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

Далее перейдите на вкладку «Права» той роли, для которой хотите установить ограничение. Для удобства вы можете воспользоваться конструктором запроса, который имеет всего две вкладки «Таблицы и поля» и «Условия».

Как вы можете увидеть на изображении ниже, мы добавили только одно ограничение с текстом:

ГДЕ ГруппаТоваров = &ГруппаТоваров

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

В программе 1С имеется встроенная система прав доступа, которая находится в Конфигуратор — Общие — Роли.

Чем характеризуется данная система и в чем ее основное предназначение? Она позволяет описывать наборы прав, которые соответствуют должностям пользователей либо видам их деятельности. Данная система прав доступа имеет статический характер, что означает, как выставил администратор права доступа к 1С, так и есть. В дополнение к статической действует вторая система прав доступа — динамическая (RLS). В этой системе права доступа высчитываются динамических способом, в зависимости от заданных параметров,в процессе работы.

Роли в 1С

К наиболее распространенным настройкам безопасности в разных программах является так называемый набор разрешений на чтение/запись для различных групп пользователей и в дальнейшем: включение либо исключение конкретного пользователя из групп. Такая система, например, используется в операционной системе Windows AD (Active Directory). Система безопасности, применяемая в программном обеспечении 1С, получила название - роли. Что это такое? Роли в 1С представляет собой объект, который расположен в конфигурации в ветви: Общие — Роли. Эти роли 1С представляют собой группы, для которых и назначаются права. В дальнейшем каждый пользователь может включаться и исключаться из данной группы.

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

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

Отметим, что все права доступа можно разделить на две основные группы — это «просто» право и такое точно право с добавлением характеристики «интерактивное». Что здесь имеется в виду? А дело в следующем.

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

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

RLS в 1С

Вы можете, включить доступ к справочнику (или документу) либо отключить его. Нельзя при этом «включить немножко». Для этой цели и существует определенное расширение системы ролей 1С, которое получило название - RLS. Это динамическая система по правам доступа, которая вносит частичные ограничения в доступ. К примеру, вниманию пользователя становятся доступны только документы определенной организации и склада, остальные он не видит.

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

Этот запрос будет выполняться динамически (при осуществлении попытки организовать чтение), для всех записей справочника. Это работает так: те записи, для которых запрос безопасности присвоил — Истина, пользователь увидит, а другие - нет. Права 1С с установленными ограничениями, подсвечены серым цветом.

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

Когда пользователь работает в режиме 1С Предприятие, при подключении к работе RLS, может появится сообщение об ошибке вида: «Недостаточно прав» (на чтение справочника ХХХ, например). Это говорит о том, что системой RLS заблокировано чтение некоторых записей. Чтобы это сообщение больше не появлялось, нужно в текст запроса ввести слово РАЗРЕШЕННЫЕ.

Часто возникает необходимость в частичном ограничении доступа к данным. Например, когда пользователь должен видеть документы только своей организации. В таких случаях в 1С используется механизм ограничения доступа на уровне записей (так называемый, RLS – Record Level Securiy).

Для примера предположим, что перед нами стоит следующая задача. На предприятии ведется многофирменный учет и каждый контрагент и пользователь базы данных относится к определенной организации. Необходимо обеспечить доступ к справочнику “Контрагенты” таким образом, чтобы каждый пользователь мог просматривать, редактировать и добавлять контрагентов только своей организации.

Для решения задачи будем использовать платформу “1С:Предприятие 8.2″. Создадим новую конфигурацию в свойствах которой в качестве основного режима запуска будет выбран вариант “Управляемое приложение”.

Далее создадим справочник “Организации” и ещё два справочника – “Контрагенты” и “Пользователи” с реквизитом “Организация”. Кроме справочников нам понадобятся два параметра сеанса – “Организация” и “Пользователь” (соответствующих типов). Значения этих параметров устанавливаются при запуске сеанса работы с конфигурацией и хранятся до его завершения. Именно значения этих параметров мы и будем использовать при добавлении условий ограничения доступа на уровне записей.

Установка параметров сеанса выполняется в специальном модуле – “Модуль сеанса”

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

Код 1C v 8.х Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
ПолныеПрава.УстановитьПараметрыСеанса();
КонецПроцедуры

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

Код 1C v 8.х Функция ОпределитьТекущегоПользователя()
ТекПользователь = Справочники.Пользователи.НайтиПоНаименованию(ИмяПользователя(),Истина);
Возврат ТекПользователь;
КонецФункции

Процедура УстановитьПараметрыСеанса() Экспорт
ТекущийПользователь = ОпределитьТекущегоПользователя();
ТекущаяОрганизация = Справочники.Организации.ПустаяСсылка();
Если ЗначениеЗаполнено(ТекущийПользователь) Тогда
ТекущаяОрганизация = ТекущийПользователь.Организация;
КонецЕсли;
ПараметрыСеанса.Пользователь = ТекущийПользователь;
ПараметрыСеанса.Организация = ТекущаяОрганизация;
КонецПроцедуры

Функция ПараметрСеансаУстановлен(ИмяПараметра) Экспорт
Возврат ЗначениеЗаполнено(ПараметрыСеанса[ИмяПараметра]);
КонецФункции

Функция РольДоступнаПользователю(ИмяРоли) Экспорт
Возврат РольДоступна(ИмяРоли);
КонецФункции

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

Код 1C v 8.х Процедура ПередНачаломРаботыСистемы(Отказ)
// всех кроме администратора будем проверять на наличие в справочнике "Пользователи"
Если Не ПолныеПрава.РольДоступнаПользователю("ПолныеПрава") Тогда
Если НЕ ПолныеПрава.ПараметрСеансаУстановлен("Пользователь") Тогда
Предупреждение("Пользователь """ + ИмяПользователя() + """ не найден в справочнике!");
Отказ = Истина;
Возврат;
КонецЕсли;
КонецЕсли;
КонецПроцедуры

Теперь можем перейти непосредственно к описанию ограничений доступа. Для этого создадим роль “Пользователь” и перейдем на закладку “Шаблоны ограничений”, где добавим новый шаблон “КонтрагентыЧтениеИзменение” со следующим текстом шаблона: ГДЕ Организация =Организация #Параметр(1)

Текст шаблона ограничений является расширением языка запросов. В отличии от обычного запроса, текст ограничения должен в обязательном порядке содержать условие “ГДЕ”. В качестве значений параметров запроса (в нашем случае это “&Организация”) используются значения одноименных параметров сеанса. Конструкция вида #Параметр(1) означает, что на это место система подставит текст, переданный в качестве первого параметра в месте использования шаблона. С помощь приведенного шаблона будет выполняться проверка каждой записи таблицы (в нашем случае это будет справочник “Контрагены”). Для записей, значение реквизита “Организация” которых совпадает с заданным в соответствующем параметре сеанса, условие описанное в шаблоне будет выполняться. Таким образом эти записи будут доступны для чтения, изменения или добавления (в зависимости от того для какого из этих прав применяется шаблон). Продемонстрирую вышеизложенное на нашем примере.

Перейдем на закладку “Права” роли “Пользователь” и откроем список прав справочника “Контрагенты”. Будем использовать шаблон ограничений “КонтрагентыЧтениеИзменеие” для прав “Чтение”, “Изменение” и “Доблавление”.

Для права “Чтение” будем использовать шаблон с параметром “ИЛИ ЭтоГруппа”. При этом пользователям данной роли будет разрешено чтение не только элементов справочника “Контрагенты” своей организации, но и всех групп этого справочника.

#КонтрагентыЧтениеИзменение("ИЛИ ЭтоГруппа")

Поскольку при добавлении новых элементов справочника системой выполняется неявное чтение предопределенных реквизитов (это нужно, например, для нумерации), то необходимо обеспечить беспрепятственное чтение этих полей. Для этого добавим дополнительную строку с пустым текстом ограничения в таблицу ограничения доступа к данным и перечислим поля для которых действует данное правило – Ссылка, Версия данных, Родитель, Код.

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