Ограничение доступа на уровне записей, или RLS (Record Level Security), является фундаментальным механизмом защиты данных в конфигурациях 1С:Предприятие. В отличие от прав на запуск или интерфейсов, RLS позволяет гибко управлять тем, какие конкретно строки в документах и справочниках видит пользователь. Это критически важно для многопользовательских систем, где менеджеры должны видеть только свои заказы, а бухгалтеры — документы своего участка.
Настройка этого механизма требует понимания архитектуры прав доступа и умения писать код на встроенном языке платформы. Неправильная реализация может привести к тому, что пользователи либо не увидят нужные данные, либо, что хуже, получат доступ к конфиденциальной информации конкурентов или смежных отделов. В этой статье мы разберем процесс от создания ролей до отладки готового решения.
Механизм работает на стороне сервера 1С, фильтруя выборки данных еще до их передачи клиенту. Это обеспечивает не только безопасность, но и производительность, так как в оперативную память клиента не загружаются лишние объекты. Однако сложность заключается в том, что ограничения должны быть прозрачными для пользователя и не ломать стандартную логику работы программы.
Подготовка инфраструктуры прав доступа
Первым шагом является создание новой роли в конфигураторе. Именно к этой роли будут привязаны ограничения. Не стоит пытаться внедрять RLS в существующие базовые роли, такие как «Полные права» или «Администратор», так как это может привести к непредсказуемым конфликтам при обновлении конфигурации. Создайте отдельную роль, например, МенеджерПоПродажам.
В свойствах роли необходимо установить галочку Ограничение доступа на уровне записей. Без включения этого флага все последующие настройки профилей групп доступа будут игнорироваться платформой. После этого роль должна быть добавлена в профиль группы доступа, который назначается конкретному пользователю в режиме предприятия через консоль администрирования.
Важно понимать разницу между правами на чтение и самим ограничением. Пользователь может иметь право читать справочник «Номенклатура», но RLS скроет из него все товары, кроме тех, что относятся к его категории. Это двухуровневая система защиты: сначала проверяется право на объект метаданных, затем применяется фильтр записей.
Всегда создавайте тестового пользователя с новой ролью перед внедрением RLS в рабочую базу. Это позволит проверить ограничения без риска заблокировать доступ основным сотрудникам.
⚠️ Внимание: Если вы добавляете роль с включенным RLS пользователю, у которого уже есть полные права через другую роль, ограничения могут не сработать. Платформа 1С объединяет права по принципу «ИЛИ»: если хоть одна роль разрешает доступ ко всем записям, ограничение снимается.
Создание и настройка профиля ограничения доступа
После создания роли необходимо определить, к каким именно данным будет применяться фильтр. Для этого в конфигураторе создается профиль ограничения доступа. В этом объекте указывается имя профиля, привязка к ранее созданной роли и список таблиц (объектов метаданных), которые подлежат фильтрации.
В поле «Таблицы» добавляются необходимые справочники, документы или регистры сведений. Например, если мы ограничиваем доступ менеджеров только к своим контрагентам, в список нужно добавить справочник Контрагенты. Можно также ограничить доступ к регистрам накопления, чтобы пользователь видел остатки только по своим складам.
Ключевым элементом здесь является поле Условие. Именно здесь прописывается логика фильтрации на языке запросов 1С. Условие должно возвращать Истину для тех записей, которые пользователю разрешено видеть. Синтаксически это выражение подставляется в секцию ГДЕ основного запроса к таблице.
Написание условий ограничения (Скрипты RLS)
Самая сложная часть настройки — это написание корректного условия. Обычно оно строится на основе сравнения владельца записи с текущим пользователем. Для получения имени текущего пользователя в условии используется предопределенное поле Ссылка или специальные функции, но чаще всего сравнивают ссылку на пользователя в регистре или самом объекте.
Рассмотрим типовой пример. Допустим, в документе «ЗаказКлиента» есть реквизит «Менеджер», который хранит ссылку на справочник «Пользователи». Чтобы менеджер видел только свои заказы, условие в профиле RLS для таблицы Документ.ЗаказКлиента будет выглядеть следующим образом:
Документ.ЗаказКлиента.Менеджер = &ТекущийПользовательЗдесь &ТекущийПользователь — это специальный параметр, который платформа 1С автоматически подставляет при выполнении запроса. Он содержит ссылку на объект пользователя, под которым выполнен вход в систему. Если в документе нет прямого реквизита менеджера, приходится использовать более сложные конструкции с регистрами сведений или дополнительными таблицами.
Часто возникает необходимость ограничить доступ по организации. В этом случае условие может проверять вхождение организации в список разрешенных для данного пользователя. Для этого используется оператор В или существование записи в вспомогательном регистре:
СУЩЕСТВУЕТ (ВЫБРАТЬ 1 ИЗ РегистрСведений.РазрешенныеОрганизации КАК РЗО
ГДЕ РЗО.Пользователь = &ТекущийПользователь
И РЗО.Организация = Документ.РеализацияТоваровУслуг.Организация)
Почему нельзя использовать обычные переменные в условии RLS?
Потому что условие RLS выполняется на сервере в контексте генерации SQL-запроса. Обычные переменные клиентского приложения там недоступны. Использовать можно только параметры запроса, такие как &ТекущийПользователь, или поля самой таблицы.
Таблица типовых сценариев ограничения доступа
Ниже приведена сводная таблица, которая поможет быстро сориентироваться в выборе объекта метаданных и логики условия для распространенных задач бизнеса.
| Объект доступа | Цель ограничения | Пример условия (фрагмент) |
|---|---|---|
| Справочник.Контрагенты | Только свои клиенты | Справочник.Контрагенты.Ответственный = &ТекущийПользователь |
| Документ.ЗаказПокупателя | Только заказы своего отдела | Документ.ЗаказПокупателя.Подразделение В (ВЫБРАТЬ...) |
| РегистрНакопления.ТоварыНаСкладах | Остатки только своих складов | Регистр.Склад В (ВЫБРАТЬ П.Склад ИЗ РегистрСведений.СкладыПользователя...) |
| Справочник.СтатьиДвиженияДенег | Скрытие финансовых статей | Справочник.СтатьиДвиженияДенег.ЭтоСекретнаяСтатья = ЛОЖЬ |
Использование подзапросов в условии, как показано в третьей строке таблицы, является наиболее гибким, но и самым ресурсоемким способом. Если таблица содержит миллионы записей, наличие сложного подзапроса в условии RLS может существенно замедлить формирование отчетов и списков документов.
Для оптимизации рекомендуется создавать индексированные регистры сведений, которые хранят явные связи «Пользователь — Разрешенный объект». Проверка существования записи в таком регистре работает быстрее, чем динамический расчет списка разрешенных элементов «на лету».
Отладка и тестирование настроек RLS
После написания кода необходимо обновить конфигурацию базы данных и протестировать результат. Самый надежный способ проверки — запуск 1С в режиме предприятия под тестовым пользователем. Попробуйте открыть списки документов и справочников: вы должны видеть только те записи, которые удовлетворяют условию.
Если пользователь видит лишние записи или, наоборот, не видит положенные ему, используйте консоль запросов или встроенный отладчик. В конфигураторе можно выполнить запрос с тем же условием, подставив конкретного пользователя вручную, чтобы убедиться в логике работы фильтра.
- 🔍 Проверьте, что у пользователя действительно назначена роль с включенным ограничением.
- 🔍 Убедитесь, что в условии нет ошибок синтаксиса и имена полей совпадают с метаданными.
- 🔍 Проверьте, не перекрывают ли другие роли пользователя ваши ограничения (принцип суммирования прав).
Главная причина неработающего RLS — наличие у пользователя другой роли с полными правами. Права в 1С суммируются, и разрешение от одной роли отменяет запрет от другой.
Обратите внимание на производительность. Если при открытии большого списка документов система «зависает» на несколько секунд, скорее всего, условие RLS слишком сложное и не использует индексы базы данных. В таких случаях стоит обратиться к анализу плана выполнения запроса через технологический журнал.
⚠️ Внимание: При изменении структуры метаданных (добавлении новых реквизитов, изменении имен таблиц) условия RLS могут перестать работать или вызвать ошибки при обновлении базы. Всегда проверяйте скрипты ограничений после серьезной доработки конфигурации.
Распространенные ошибки и способы их устранения
Одной из самых частых проблем является ситуация, когда RLS работает в конфигураторе при проверке запроса, но не работает в режиме предприятия. Это часто связано с кэшированием прав доступа. После изменения настроек ролей и профилей ограничений рекомендуется перезапустить клиент 1С или выполнить команду сброса кэша прав.
Другая распространенная ошибка — попытка ограничить доступ к виртуальным таблицам регистров накопления без учета их периодичности. Условие должно корректно обрабатывать срезы на начало и конец периода. Если фильтр отсекает нужные движения, отчеты по оборотам будут показывать неверные данные.
Также стоит помнить о служебных задачах. Фоновые задания, обмен данными и регламентные отчеты часто запускаются от имени специального системного пользователя. Если для него настроены жесткие ограничения RLS, эти процессы могут завершаться ошибкой, так как не смогут прочитать необходимые для работы данные.
- ⚙️ Используйте роль «Полные права» для системных пользователей сервисов и фоновых заданий.
- ⚙️ При отладке используйте параметр
УстановитьPrivilegeMode(Ложь)во временных процедурах, если нужно обойти RLS программно. - ⚙️ Проверяйте права не только на чтение, но и на изменение, если планируете ограничивать редактирование конкретных записей.
☑️ Диагностика проблем с RLS
FAQ: Часто задаваемые вопросы по RLS
Можно ли настроить RLS так, чтобы пользователь видел документы, но не мог их открывать?
Нет, механизм RLS фильтрует именно наличие записей в выборке. Если запись отфильтрована, пользователь не увидит её в списке и, следовательно, не сможет открыть. Для запрета открытия при наличии в списке нужно использовать права на выполнение действий (например, запретить проведение или изменение), а не ограничение на уровне записей.
Влияет ли RLS на скорость работы базы данных?
Да, влияет. Каждое условие RLS добавляет дополнительный блок WHERE или JOIN к SQL-запросам, генерируемым платформой. Если условия сложные и не оптимизированы (например, содержат функции над полями или сложные подзапросы без индексов), это может значительно замедлить формирование списков и отчетов.
Как временно отключить RLS для администратора?
Самый простой способ — не назначать администратору роль, в которой включено ограничение доступа. Если администратор должен иметь роль с RLS для тестирования, но при этом нужен полный доступ, создайте для него отдельный профиль группы доступа с ролью «Полные права», которая имеет приоритет.
Работает ли RLS в файловом варианте базы 1С?
Да, механизм ограничения доступа на уровне записей работает одинаково как в файловом, так и в клиент-серверном варианте базы данных. Логика применения прав идентична, разница лишь в производительности выполнения сложных запросов с условиями фильтрации.
Можно ли использовать RLS для скрытия реквизитов внутри документа?
Нет, RLS скрывает или показывает всю строку (документ, элемент справочника) целиком. Скрыть отдельный реквизит (например, поле «Цена») внутри видимого документа с помощью RLS нельзя. Для этого используются права на просмотр конкретных реквизитов в настройках роли.