Rls в 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 — приглашаем вас прочитать эту статью.

Ограничение доступа к данным

Механизм ограничений доступа к данным (также известный как RLS, Row Level Security) позволяет управлять правами доступа не только на уровне объектов метаданных, но и на уровне объектов базы данных «1С:Предприятия». Для ограничения доступа к данным могут быть использованы следующие объекты «1С:Предприятия»:
● роли,
● параметры сеанса,
● функциональные опции,
● привилегированные общие модули,
● ключевое слово РАЗРЕШЕННЫЕ в языке запросов.
Совместное использование перечисленных объектов позволяет обеспечить максимальную гибкость при необходимости разграничения прав доступа к данным между пользователями, выполняющими различные функции.
Ограничения доступа к данным могут накладываться на следующие операции с данными (права доступа): чтение (право Чтение ), добавление (право Добавление ), изменение (право Изменение) и удаление (право Удаление ). Текущий пользователь будет иметь возможность выполнить требуемую операцию в следующих случаях:
● Для операций чтения и удаления объект, находящийся в базе данных, должен соответствовать ограничению доступа к данным.
● Для операции добавления ограничению доступа к данным должен соответствовать объект, который планируется записать в базу данных.
● Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан).
При наложении ограничений доступа к данным следует помнить, что для операций изменения, добавления и удаления можно задать только одно условие, а для операции чтения можно задать более одного ограничения доступа к данным. Это означает, что для чтения разных полей объекта могут быть заданы разные условия, причем при задании условия можно указать как имя конкретного поля, так и специальное поле Прочие поля. В первом случае условие будет накладываться только в том случае, если в выборке (которой выполняется чтение данных) будет присутствовать поле, для которого задано ограничение, а во втором – ограничение будет накладываться для всех полей объекта, кроме полей, для которых ограничения заданы явным образом.
При задании ограничения на конкретное поле, это поле будет читано в том случае, если ограничение выполняется, а при задании ограничения на Прочие поля, данные объекта будут прочитаны только в том случае, если ограничение выполняется для всех полей объекта, попавших в запрос чтения данных.
Для объектов базы данных следующих видов могут быть наложены различные ограничения на разные виды изменений (добавление, модификацию, удаление):
● Планы обмена,
● Справочники,
● Документы,
● Планы видов характеристик,
● Планы счетов,
● Планы видов расчета,
● Бизнес-процессы,
● Задачи.
Для следующих видов объектов базы данных возможно наложение ограничений на чтение не только всего объекта целиком, но и отдельных его полей:
● Планы обмена,
● Справочники,
● Документы,
● Журналы документов,
● Планы видов характеристик,
● Планы счетов,
● Планы видов расчета,
● Регистры сведений,
● Бизнес-процессы,
● Задачи.
ВНИМАНИЕ! При обращении к полям объектов базы данных посредством свойств прикладных объектов из встроенного языка «1С:Предприятия» выполняется чтение всего объекта целиком, а не только значения используемого поля. Исключением является получение представления, когда будут прочитаны только значения полей, участвующих в формировании представления.
Ограничения доступа содержатся в ролях, они могут быть указаны для большинства объектов метаданных и записываются на специальном языке, являющимся подмножеством языка запросов.

Язык ограничения доступа к данным

Ограничения доступа к данным описываются на специальном языке, являющимся подмножеством языка запросов (подробное описание языка запросов . Язык ограничения доступа к данным имеет следующие изменения относительно языка запросов:
● В запросе ограничения доступа к данным всегда присутствует одна таблица в качестве источника данных – это таблица объекта, на который накладывается ограничение (основной объект ограничения).
● Сокращено описание запроса. Язык ограничения доступа к данным использует только секции ИЗ и ГДЕ языка запросов. Так, описание языка запросов выглядит следующим образом:
ВЫБРАТЬ [ РАЗРЕШЕННЫЕ ] [ РАЗЛИЧНЫЕ ] [ ПЕРВЫЕ <Количество> ]
< Список полей выборки >
[ ИЗ <Список источников> ]
[ ГДЕ <Условие отбора> ]
[ СГРУППИРОВАТЬ ПО <Поля группировки> ]
[ ИМЕЮЩИЕ <Условие отбора> ]
[ ДЛЯ ИЗМЕНЕНИЯ [ <Список таблиц верхнего уровня> ]]
В то время как описание языка запросов ограничения доступа к данным выглядит следующим образом:
[ Псевдоним таблицы основного объекта ограничения ]
[ ИЗ <Список источников> ]
[ ГДЕ <Условие отбора> ]

Во вложенных запросах, используемых в языке ограничения доступа к данным, ограничен набор допустимых возможностей ;
● В качестве элементов условий можно указывать параметры сеанса и функциональные опции ;
● В любом месте запроса ограничения доступа к данным допустимо использование шаблонов, упрощающих написание ограничений.
Главной частью ограничения является условие, которое вычисляется для каждой записи таблицы базы данных, на которую накладывается ограничение доступа к данным. Запись считается доступной в том случае, если в результате работы условия для одной записи таблицы основного объекта ограничения получена не пустая таблица (т.е. таблица, в которой 1 или более записей). Если в результате работы условия получается пустая таблица – запись, для которой условие исполнилось таким образом, считается недоступной. Причем изменение записи таблицы основного объекта ограничения
считается допустимым, если запись не противоречит ограничению, указанному для права, как до выполнения операции изменения, так и после выполнения этой операции.

Поля таблиц

В ограничениях доступа к данным можно использовать:
● Поля таблиц объекта, для которого описывается ограничение доступа к данным.
Например, если ограничение накладывается на чтение элементов справочника Контрагенты, то в ограничении могут использоваться поля справочника Контрагенты и его табличных частей. В частности, наиболее простые ограничения на чтение элементов справочника Контрагенты могут выглядеть так:

ГДЕ Наименование = “Кирпичный завод”
Или так:

ГДЕ Продукция.Наименование = “Кирпич красный”
Где Продукция – это табличная часть справочника Контрагенты.
● Поля таблиц объектов, доступных по ссылкам в основном объекте ограничения.
Например, если реквизит ОсновнойМенеджер справочника Контрагенты имеет тип ссылки на справочник Пользователи, то ограничение доступа может иметь, например, следующий вид:

ГДЕ ОсновнойМенеджер.Код = “Иванов”
Или:

ГДЕ ОсновнойМенеджер.ФизическоеЛицо.Наименование = “Петровский”
● Поля таблиц объектов, связанных с основным объектом ограничения некоторыми условиями и выражения над ними.
Например, на чтение элементов справочника Контрагенты может быть наложено следующее ограничение:

Контрагенты
ИЗ
Справочник.Контрагенты КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Пользователи КАК Пользователи
ПО Контрагенты.ОсновнойМенеджер.Наименование = Пользователи.Наименование
ГДЕ Пользователи.ФизическоеЛицо.Наименование = “Петровский”
В этом ограничении используются поля элементов справочника Пользователи, связанных с данным элементом справочника Контрагенты по значению полей Наименование.

Вложенные запросы

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

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

ГДЕ
ПаспортныеДанныеФизЛиц.ФизЛицо В
( ВЫБРАТЬ РАЗЛИЧНЫЕ
Работники.ФизЛицо КАК ФизЛицо
ИЗ
РегистрСведений.Работники КАК Работники )
Если во вложенном запросе необходимо получить данные из табличной части, то в разделе ИЗ вложенного запроса необходимо обращаться непосредственно к табличной части. Например, вместо:

ВЫБРАТЬ Ссылка КАК Ссылка ,
Продукция.Наименование КАК НаименованиеПродукции
ИЗ Справочник.Контрагенты
в качестве запроса, вложенного в ограничение, следует использовать:

ВЫБРАТЬ Ссылка КАК Ссылка,
Наименование КАК НаименованиеПродукции
ИЗ Справочник.Контрагенты.Продукция

Параметры сеанса

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

ГДЕ Владелец.ДоступКУчетнойЗаписи.Пользователь = &ТекущийПользователь
И Владелец.ДоступКУчетнойЗаписи.Администрирование = ИСТИНА

ТекущийПользователь – это параметр сеанса

Функциональные опции

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

ГДЕ &УчетПоСкладам = ИСТИНА

Где УчетПоСкладам – это функциональная опция

Особенности использования

В ограничениях на объекты базы данных следующих типов могут быть использованы не все поля основного объекта данных ограничения:
● в регистрах накопления ограничения доступа могут содержать только измерения основного объекта ограничения;
● в регистрах бухгалтерии в ограничениях можно использовать только балансовые измерения основного объекта ограничения.
ПРИМЕЧАНИЕ. Если в условиях ограничения доступа к данным оборотного регистра накопления используются измерения, не входящие в итоги, то
при обращении к виртуальной таблице оборотов не используются хранимые итоги и запрос выполняется полностью по таблице движений.

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

Ограничения доступа проверяются при любом выполнении соответствующих операций над объектами базы данных (из диалогов, из встроенного языка, посредством запросов) и могут действовать одним из двух способов:
● Все . Способ «все» подразумевает, что некоторая операция над данными (из диалогов, из встроенного языка или посредством запросов) должна быть выполнена над всеми подразумеваемыми данной операцией объектами базы данных. Если при выполнении такой операции должны быть прочитаны или изменены объекты базы данных, для которых не выполняются соответствующие ограничения доступа, то операция завершается
аварийно из-за нарушения прав доступа.
● Разрешенные . Способ «разрешенные» подразумевает, что при выполнении операции над данными должны быть прочитаны только те объекты базы данных, которые удовлетворяют соответствующим ограничениям доступа. Объекты базы данных, не удовлетворяющие ограничениям доступа, при выполнении такой операции считаются отсутствующими и на результат операции не влияют.
Ограничения доступа к данным накладываются на объекты базы данных в момент обращения «1С:Предприятия» к базе данных. В клиент-серверном варианте «1С:Предприятия» наложение ограничений выполняется на сервере «1С:Предприятия».
Способ действия ограничений, выбираемый для выполнения каждой операции над данными, определяется назначением этой операции и степенью ответственности ее результатов. В частности, способ «разрешенные» используется при отображении динамических списков и некоторых других интерактивных действиях. Способ «все» используется при выполнении любых операций с прикладными объектами из встроенного языка «1С:Предприятия», в том числе при любых изменениях объектов базы данных. Поэтому, например, могут возникнуть затруднения при построении отбора для метода Выбрать( ) менеджеров справочников, документов и других с последующим обходом результата в том случае, если на соответствующий объект установлено достаточно сложное ограничение, поскольку не всякое условие в ограничении прав доступа может быть адекватно представлено в виде отбора для метода Выбрать() .
В запросах способом действия ограничений доступа к данным можно управлять. Для этого в языке запросов предусмотрено ключевое слово РАЗРЕШЕННЫЕ . Если в запросе не указано РАЗРЕШЕННЫЕ , то ограничения действуют способом « все» . Если слово РАЗРЕШЕННЫЕ указано, то выбирается способ «разрешенные ».
Важно, что если в запросе не указано ключевое слово РАЗРЕШЕННЫЕ, то все отборы, заданные в этом запросе, не должны противоречить ни одному из ограничений на чтение объектов базы данных, используемых в запросе. При этом если в запросе используются виртуальные таблицы, то соответствующие отборы должны быть наложены и на сами виртуальные таблицы.
Пример:

ВЫБРАТЬ
КонтактнаяИнформацияСрезПервых.Представление
ИЗ РегистрСведений.КонтактнаяИнформация.СрезПоследних(, Тип = &Тип)
КАК КонтактнаяИнформацияСрезПервых
ГДЕ
КонтактнаяИнформацияСрезПервых.Тип = &Тип
При использовании объектной техники не поддерживается получение доступа к данным в режиме РАЗРЕШЕННЫЕ. Предполагается, что объектная техника используется для наиболее ответственных операций над данными, в том числе для их изменения. Для получения при помощи объектной техники всех данных, независимо от установленных ограничений, можно выполнять необходимые действия в привилегированном модуле или от имени пользователя с полными правами. Средств получения только разрешенных данных в объектной технике не предусмотрено.

Механизм наложения ограничений

Любая операция над данными, хранимыми в базе данных, в «1С:Предприятии» в конечном счете приводит к обращению к базе данных с некоторым
запросом на чтение или изменение данных. В процессе исполнения запросов к базе данных внутренние механизмы «1С:Предприятия» выполняют наложение ограничений доступа. При этом:
● Формируется список прав (чтение, добавление, изменение, удаление), список таблиц базы данных и список полей, используемых этим запросом.
● Из всех ролей текущего пользователя выбираются ограничения доступа к данным для всех прав, таблиц и полей, задействованных в запросе. При этом если какая-нибудь роль не содержит ограничений доступа к данным какой-нибудь таблицы или поля, то это значит, что в данной таблице доступны значения требуемых полей из любой записи. Иначе говоря, отсутствие ограничения доступа к данным означает наличие ограничения
ГДЕ Истина.
● Получаются текущие значения всех параметров сеанса и функциональных опций, участвующих в выбранных ограничениях.
Для получения значения параметра сеанса от текущего пользователя не требуется наличие права на получение этого значения. Однако если значение некоторого параметра сеанса не было установлено, то произойдет ошибка и запрос к базе данных выполнен не будет.
На получение функциональных опций оказывает влияние свойство функциональной опции Привилегированный режим при получении .
Если это свойство сброшено, то текущий пользователь должен обладать правами на чтение объекта, в котором хранится функциональная опция.
● Ограничения, полученные из одной роли, объединяются операцией И .
● Ограничения, полученные из разных ролей, объединяются операцией ИЛИ.
● Построенные условия добавляются к SQL-запросам, с которыми «1С:Предприятие» обращается к СУБД. При обращении к данным со стороны условий ограничения доступа проверка прав не выполняется (ни к объектам метаданных, ни к объектам базы данных). Причем механизм добавления условий зависит от выбранного способа действия ограничений «все» или «разрешенные» .
Способ «все»
При наложении ограничений способом «все» к SQL-запросам добавляются условия и поля так, чтобы «1С:Предприятие» могло получить информацию о том, были ли в процессе исполнения запроса к базе данных использованы данные, запрещенные для данного пользователя или нет. Если запрещенные данные были использованы, то инициируется аварийное завершение запроса. Наложение ограничений доступа способом «все» схематически представлено на рис. 1:

Рис. 1. Способ «все»

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

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

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

Если для общего модуля установлен флажок Привилегированный, то исполнение процедур и функций этого модуля приобретает важную специфику:
● В клиент-серверном варианте «1С:Предприятия» привилегированным может быть только тот модуль, который исполняется на сервере.
● Исполнение процедур и функций привилегированного модуля и всего, что из них вызвано, выполняется при выключенной системе ограничения
прав, как к объектам метаданных, так и к данным. Таким образом, из привилегированного модуля может быть выполнена любая операция над
любыми объектами даже в том случае, если текущий пользователь не имеет соответствующих прав.
Привилегированные модули предназначены для начальной установки значений параметров сеанса, используемых в ограничениях доступа к данным.
Еще общие модули могут быть использованы для некоторых целостных действий над данными со стороны пользователя с ограниченными правами.
Например, если в функции пользователя входит ввод и проведение документов, но пользователь не должен иметь доступа к данным, на которые влияет проведение документа, то выполнение операции проведения может быть вынесено в привилегированный модуль. Это позволит пользователю проводить документы без предоставления ему прав на другую информацию (регистры, например).
Привилегированный режим
Имеется возможность программной установки привилегированного режима при работе с данными. Программная установка привилегированного режима
может потребоваться в случае массированных операций с данными информационной базы, и при этом нет смысла проверять права доступа к данным.
Описание привилегированного режима см. здесь.

Использование препроцессора

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

#ЕСЛИ <Выражение> #ТОГДА
#ИНАЧЕЕСЛИ <Выражение> #ТОГДА
#ИНАЧЕ
#КОНЕЦЕСЛИ
<Выражение> – произвольное логическое выражение на встроенном языке, результат которого имеет тип Булево. Выражение может содержать:
● операции сравнения <, >, <=, >= , =, <> ;
● логические операции И, ИЛИ, НЕ ;
● параметры сеанса – используется синтаксис &Параметр , где Параметр – имя параметра сеанса.
Если результатом выражения инструкции #ЕСЛИ или #ИНАЧЕЕСЛИ является значение Истина, то в результирующий текст инструкции ограничения доступа помещается текст, расположенный после ключевого слова #ТОГДА . Если же результатом выражения является значение Ложь, то текст, расположенный после ключевого слова #ТОГДА , не помещается в текст инструкции ограничения доступа. Текст, расположенный после инструкции #ИНАЧЕ, будет помещен в результирующий текст ограничения доступа, если ни одно из ранних условий не было выполнено.
ПРИМЕЧАНИЕ . Если текст ограничения доступа к данным содержит инструкции препроцессора, то такое ограничение не проходит проверку синтаксиса при редактировании и не может быть изменено при помощи конструктора.
Пример:

#ЕСЛИ &ТекущийПользователь <> “Климова” #ТОГДА
<текст ограничения доступа>
#КОНЕЦЕСЛИ
Здесь ТекущийПользователь – параметр сеанса типа СправочникСсылка.Пользователи.
Такая конструкция означает, что условие для установки ограничения доступа будет проверяться для всех пользователей из справочника, кроме пользователя Климовой.

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

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

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

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

● Оператор + для конкатенации строк.
Для удобства редактирования текста шаблона на закладке Шаблоны ограничений в форме роли нужно нажать кнопку Установить текст шаблона. В открывшемся диалоге ввести текст шаблона и нажать кнопку ОК.
Система «1С:Предприятие» выполняет проверку синтаксиса текстов шаблонов, проверку синтаксиса использования шаблонов и макроподстановку текстов шаблонов ограничения доступа роли в текст запроса.
Макроподстановка шаблона заключается:
● в замене вхождений параметров в тексте шаблона на значения параметров из выражения использования шаблона в тексте ограничения;
● в замене выражения использования шаблона в тексте запроса на получившийся текст шаблона.
При вызове конструктора запроса для условия, содержащего шаблоны ограничения доступа, выдается предупреждение о замене всех шаблонов.
Далее приведены примеры шаблонов ограничений:

Общие рекомендации по ограничению прав

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

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

● для справочников при проверке родителя, владельца и уникальности кода;
● для документов, бизнес-процессов и задач при проверке уникальности номера;
● для планов обмена отключена при проверке уникальности кода;
● для планов счетов и планов видов характеристик при проверке родителя и уникальности кода.

При создании запроса ограничения к данным следует помнить о некоторых ограничениях и особенностях:

● Если для объектной таблицы заданы ограничения доступа к данным и в запросе к данным используется объединение с такой таблицей, то в условии соединения (секция запроса ПО) не допускается использование табличной части объекта с заданным ограничением доступа.
● Если в запросе указана таблица, у которой в запросе не используется ни одного поля, то на эту таблицу накладываются все ограничения доступа к данным. Например, запрос ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ Справочник.Контрагенты будет исполнен с учетом всех ограничений доступа, заданными для справочника Тест. Ограничения накладываются «по ИЛИ». Это значит, что будут доступны все записи, доступные хотя бы по одному условию. Если для каких-то полей не задано условий, то запрос будет выполнен для всех записей таблицы.
Если в запросе используется таблица верхнего уровня, то ограничения, заданные для колонок вложенных таблиц, не накладываются.
Если в запросе используется вложенная таблица, то накладываются ограничения как для вложенной таблицы, так и для таблицы верхнего уровня.
Например, запрос ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ Справочник.Контрагенты.Договора будет исполнен с учетом всех ограничений для справочника Контрагенты, а также с учетом ограничений, относящихся к табличной части Договора.

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

Конструктор ограничения доступа к данным

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

Рис. 3. Закладка «Таблицы и поля» конструктора ограничений

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

Рис. 4. Закладка «Связи» конструктора ограничений

На закладке Связи формируются условия, которые накладываются на связи между полями таблиц. Для ввода нового условия нужно нажать кнопку Добавить и в колонке Таблица1 выбрать одну из таблиц. В колонке Таблица2 выбрать таблицу, поля которой связаны с полями первой. Ниже списка условий расположены элементы управления, с помощью которых формируется условие связи таблиц.
Если выбран простой тип условия, то в Поле1 и Поле2 выбираются связанные поля указанных таблиц и задается условие сравнения. Если выбраны поля, сравнение которых не производится, то в строке списка условий в колонке Условие связи выводится текст: Неверно заполненное условие.
На закладке Условия , если требуется, нужно указать условия, по которым будет выполняться отбор исходных данных.

Рис. 5. Закладка «Условия» конструктора ограничений

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

Групповое редактирование ограничений прав доступа и шаблонов

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

Рис. 6 Все ограничения прав доступа и шаблоны

На закладке Ограничения доступа можно просматривать все введенные ограничения доступа в общем списке (по всем ролям, объектам, правам,комбинациям полей).
Существует возможность добавлять ограничение доступа сразу для нескольких ролей, объектов, прав и комбинаций ролей.
Можно фильтровать список по различным критериям.

Рис. 7. Отбор ограничений доступа

Режим группового редактирования позволяет удалять выделенные в списке ограничения.
Существует возможность редактировать выделенные ограничения. При этом можно заменять состав полей и/или ограничение доступа.
Режим группового редактирования позволяет также копировать выделенные ограничения в другие роли.

На закладке Шаблоны ограничений можно видеть все шаблоны ограничения доступа, присутствующие в прикладном решении, при этом из собственно текста шаблона в таблице отображаются только первые 10 строк, которые завершаются символом “…”, если текст шаблона более 10 строк. В окне редактирования шаблона будет отображаться полный текст шаблона.

Рис 8. Все шаблоны ограничения доступа

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

Рис. 9. Отбор шаблонов ограничения доступа

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

Rls в 1с что это

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

1. О том, каким образом платформа обрабатывает RLS; ;

Роли, права доступа

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

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

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

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

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

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

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С:Предприятия».

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

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

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

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

Ограничение прав доступа на уровне записей (RLS) в 1С

Начиная с релиза 8.0 в платформу 1С:Предприятие встроен механизм ограничения прав доступа на уровне записей (Record-level Security – RLS). Этот инструмент позволяет очень гибко настроить доступ к данным для конечного пользователя. Ещё гибче, чем расстановка «галочек» в соответствующих действиях пользователей. Собственно, он является расширением этого механизма.

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

Несколько замечаний и трюков:

1. В качестве параметров в запросе RLS выступает объект конфигурации Параметры сеанса.

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