Ограничение прав доступа на уровне записей (RLS) в 1С
Начиная с релиза 8.0 в платформу 1С:Предприятие встроен механизм ограничения прав доступа на уровне записей (Record-level Security – RLS). Этот инструмент позволяет очень гибко настроить доступ к данным для конечного пользователя. Ещё гибче, чем расстановка «галочек» в соответствующих действиях пользователей. Собственно, он является расширением этого механизма.
Смысл следующий: права на каждое действие накладываются в соответствии с неким «запросом» (чем по сути и является) к БД. В результате, многие пользователи даже «не будут догадываться» о существовании дополнительных записей в таблицах БД.
Несколько замечаний и трюков:
1. В качестве параметров в запросе RLS выступает объект конфигурации Параметры сеанса.
2. Если необходимо дать доступ на метаданные таблицы, не давая доступ к записям самой таблицы, то можно использовать такой запрос:
ГДЕ ЛОЖЬ
3. Как уже было сказано выше, каждый запрос прав доступа является соединением к «обычным» запросам к БД. Отсюда следует, что RLS в неумелых руках способен значительно замедлить выборку данных, особенно это относится к высоконагруженным объектам.
4. По этой же причине в RLS нет инструкции
В ИЕРАРХИИ
5. В запросах нельзя использовать временные таблицы. Придется обойтись вложенными. Здесь важно не забывать о низкой производительности вложенных запросов (см. выше). Чуть по-проще обстоит дело с объединениями. Во «внешнем» запросе нельзя использовать объединения, однако они доступны во вложенных.
6. Обработка «Консоль отчетов» последних версий позволяет выполнить любой запрос от имени какого-либо пользователя, что может сэкономить немного времени при отладке RLS.
7. В результате настройки прав доступа, у пользователей могу перестать работать «обычные» запросы. В таких случаях стоит попробовать использовать инструкцию
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Тогда в запрос попадут только те записи, к которым у пользователя есть доступ. Но здесь стоит быть осторожным и спросить себя лишний раз: «А почему так вышло?».
8. Недостаточно ограничивать доступ только для действия «Чтение», т.к. пользователь (намеренно или случайно) может создать новый/изменить существующий элемент, который не подойдет под условие.
По сути, этот запрос каждый раз добавляется при запросе к таблице #ТекущаяТаблица . Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.
[…] уже рассматривали механизм разделения доступа на уровне записей (Record Level Security — RLS) в […]