RLS (Row-Level Security) — это механизм ограничения доступа к данным непосредственно на уровне записей в платформе 1С:Предприятие 8.3. В отличие от стандартного разграничения прав, которое работает с объектами целиком (справочниками, документами, регистрами), рлс в 1с позволяет контролировать видимость каждой конкретной строки в таблице базы данных.
Практическая ценность механизма очевидна: бухгалтер одной организации не видит документы другой, менеджер по продажам работает только со своими клиентами, кладовщик склада №3 не имеет доступа к остаткам склада №1. Управление доступом на таком детальном уровне делает систему по-настоящему безопасной и избавляет пользователей от информационного шума — они работают исключительно с релевантными данными, не отвлекаясь на чужие записи.

Среди очевидных преимуществ rls — возможность тонкой настройки доступа без создания отдельных информационных баз для каждого подразделения или юридического лица. Это экономит ресурсы и упрощает администрирование. Одновременно повышается информационная безопасность: конфиденциальные данные о зарплатах, ценах или контрагентах остаются скрытыми от тех, кому они не предназначены.
Однако у механизма есть и обратная сторона. Во-первых, грамотная настройка rls требует высокой квалификации разработчика — понимания синтаксиса языка запросов 1С, логики работы ролей и профилей. Во-вторых, отладка сложных условий превращается в нетривиальную задачу: ошибки в ограничениях проявляются не сразу и не всегда очевидны. В-третьих, и это критически важно, включение rls в 1с заметно увеличивает нагрузку на сервер. Каждый запрос к данным проходит дополнительную фильтрацию, что при большом объёме таблиц и сложных условиях может снизить скорость работы системы в несколько раз. Отчёты тоже попадают под действие ограничений, что иногда вызывает путаницу у пользователей с разными правами — одни видят одни цифры, другие — иные.

Чтобы правильно использовать механизм rls, нужно понимать, как устроена вся цепочка разграничения прав в платформе. Ключевые элементы выстраиваются в следующую иерархию:
- Роль — набор разрешений на объекты метаданных с условиями ограничения доступа.
- Профиль группы доступа — объединяет одну или несколько ролей в логически связанный набор.
- Группа доступа — связывает профиль с конкретными пользователями и значениями видов доступа.
- Пользователь — конечное звено, получающее итоговый набор прав.
Когда пользователь открывает список документов, система формирует запрос к базе данных и автоматически добавляет в него условия из всех ролей, назначенных через группы доступа. Именно так данные фильтруются ещё до того, как попадают на экран.

Подход к настройке rls различается в зависимости от конфигурации 1с. В УТ 11 характерный пример — журнал «Реестр торговых документов». По умолчанию этот объект доступен лишь пользователям с полными правами. Чтобы предоставить к нему ограниченный доступ, требуется создать новую роль в расширении конфигурации и прописать в ней условия выборки.
В 1С Бухгалтерия 3.0 и БП КОРП 3.0 типичная задача — ограничение по организациям: бухгалтер видит документы только своего юридического лица. Механизм rls здесь реализован через стандартную модель БСП (Библиотека стандартных подсистем), которая предоставляет готовые виды доступа и шаблоны ограничений.
БИТ.Финанс имеет собственную специфику. В этой конфигурации 1с ограничение доступа настраивается по ЦФО, статьям оборотов и проектам. Причём поведение системы кардинально отличается в зависимости от того, используется ли модель БСП или нет — об этом подробнее в разделе практических рекомендаций.

Первый шаг — активация самой возможности ограничивать доступ на уровне записей. Откройте раздел «Администрирование» → «Настройка пользователей и прав» и установите флаг «Ограничивать доступ на уровне записей».
Прежде чем включать эту опцию в рабочей базе, обязательно проверьте её на тестовой копии. Активация механизма немедленно увеличивает количество обращений к базе данных, и в нагруженных системах это ощущается сразу. Также убедитесь, что у всех пользователей корректно настроены роли — иначе после включения rls часть сотрудников просто не увидит нужных им документов.

Открывайте Конфигуратор и переходите к расширению конфигурации — именно там следует создавать новые роли, чтобы не нарушать целостность типовой конфигурации 1с и сохранить возможность обновления.
Создайте новую роль, например «Менеджер_ОграниченныйДоступ». В дереве объектов найдите нужный объект — скажем, журнал документов «Реестр торговых документов» — и проставьте разрешения: Чтение и Просмотр. Права на добавление, изменение и удаление назначайте только при реальной необходимости — принцип минимальных привилегий здесь работает особенно хорошо.

Использование шаблонов ограничений
Вкладка «Шаблоны ограничений» в свойствах роли — ключевое место для описания логики rls. Шаблон — это заготовка условия на языке запросов 1С, которая впоследствии подставляется в ограничения конкретных объектов.
Наиболее распространённые стандартные шаблоны — #ДляОбъекта и #ПоЗначениям. Первый применяется для ограничения по самому объекту, второй — для фильтрации по значениям реквизитов.
Пример кода ограничения для права «Чтение» с учётом режима работы rls:
```
ВЫБРАТЬ Ссылка ИЗ Справочник.Контрагенты КАК Объект
ГДЕ
  &ОграничениеДоступаНаУровнеЗаписейУниверсально
  ИЛИ Объект.Ссылка В
    (ВЫБРАТЬ ТЗ.Объект ИЗ РегистрСведений.НаборыЗначенийДоступа КАК ТЗ
     ГДЕ ТЗ.ВидДоступа = ЗНАЧЕНИЕ(ПланВидовХарактеристик.ВидыДоступа.Организации))
```
Параметр &ОграничениеДоступаНаУровнеЗаписейУниверсально — логический флаг, определяющий режим работы. В производительном режиме система использует предварительно рассчитанные наборы значений доступа, что существенно быстрее. В стандартном режиме условие проверяется непосредственно при каждом запросе — медленнее, но не требует регламентных заданий.
Шаблон #ПоЗначениям задаётся парами «вид доступа — проверяемый реквизит объекта». Например: `Организации, Организация` означает, что система будет сверять реквизит «Организация» документа со списком разрешённых значений вида доступа «Организации» для текущего пользователя.

Пример создания ограничения с помощью конструктора запроса
Для тех, кто не уверен в синтаксисе 1С, в редакторе ограничений доступен конструктор запроса — вызывается кнопкой или клавишей F4. Через вкладки «Таблицы и поля» выбираете нужный объект, например справочник «Номенклатура», добавляете условия отбора.
Важно понимать: параметры rls не передаются пользователем вручную — они устанавливаются автоматически при старте сессии на основе групп доступа. Конструктор помогает корректно выстроить структуру запроса, но финальную логику всё равно нужно проверять вручную.

Добавление роли в профиль группы доступа
Созданную роль необходимо включить в профиль группы доступа. Откройте раздел «Администрирование» → «Пользователи и права» → «Профили групп доступа», найдите нужный профиль или создайте новый, добавьте туда роль.
После этого перейдите в группы доступа, выберите нужную группу и убедитесь, что она связана с правильным профилем. Когда пользователь, входящий в эту группу, откроет систему, в его интерфейсе появится команда для доступа к журналу документов — и он увидит только те записи, которые соответствуют его правам доступа.

Настройка ограничений в группах доступа (на примере 1С:ERP, БП 3.0)
В карточке группы доступа находится вкладка с видами доступа, где задаются конкретные значения фильтрации. Рассмотрим пример для профиля «Маркетологи» в 1С Бухгалтерия 3.0.
1. Откройте «НСИ и администрирование» → «Пользователи» → «Группы доступа».
2. Создайте группу «Маркетологи_Регион_Восток» и привяжите к профилю «Маркетологи».
3. На вкладке видов доступа для вида «Партнёры» выберите режим «Разрешённые значения» и добавьте конкретных контрагентов или партнёров, с которыми работает этот отдел.
4. Аналогично настройте доступ к видам цен — например, разрешите только «Розничную цену» и «Цену для региона Восток», исключив оптовые прайсы.
В карточке каждого партнёра или контрагента система автоматически учитывает принадлежность к группе доступа. При входе пользователя rls формирует фильтр и показывает только разрешённые записи — остальные физически недоступны, а не просто скрыты в интерфейсе.

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

БИТ.Финанс предлагает два принципиально разных сценария работы механизма rls. Если конфигурация использует модель БСП, права назначаются через привычные группы доступа, а ограничения по ЦФО, статьям оборотов и проектам настраиваются стандартным образом. Однако здесь есть подводный камень: при проверке табличных документов система может выдавать ошибку «Объект не найден». Причина — не рассчитаны ключи доступа. Решение: настройте и запустите регламентное задание «Создание ключей доступа ЦФО/Статья оборотов». После его выполнения ошибка исчезает.
Если же БИТ.Финанс работает без модели БСП, механизм ограничений строится на группах пользователей, а не на группах доступа в понимании БСП. Права назначаются напрямую через роли без промежуточного слоя профилей. Это упрощает архитектуру, но лишает гибкости: добавить исключение для конкретного пользователя сложнее, и при росте числа сотрудников администрирование становится трудоёмким.

Один из самых распространённых просчётов при настройке rls — одновременное назначение пользователю профиля с ограничениями и роли с полными правами. Роль «Полные права» отключает все ограничения доступа на уровне записей, и тщательно настроенный механизм rls просто перестаёт работать. Администратор и финансовый директор вполне могут иметь полные права — но тогда rls для них бессмысленен.
Выстраивайте роли по двум принципам:
- Прикладные роли — соответствуют конкретным функциям: «Работа с заказами покупателей», «Просмотр складских остатков».
- Роли-функции — задают ограничения доступа: «Только своя организация», «Только свой склад».
Объединяя их в профили групп доступа, вы получаете гибкую и понятную систему без конфликтов прав. Таблица совместимостей профилей поможет заранее выявить противоречия — например, когда один профиль разрешает видеть все организации, а другой ограничивает до одной.

Нагрузка на систему при включённом rls растёт пропорционально сложности условий ограничений и объёму данных в таблицах. Каждый запрос получает дополнительное условие WHERE, а при стандартном режиме работы это условие вычисляется заново при каждом обращении.
Отчёты становятся особым источником вопросов: пользователь с доступом только к трём организациям видит суммы только по ним, тогда как его коллега с полными правами — консолидированную картину. Расхождение цифр в одном и том же отчёте нередко вызывает недоумение и требует объяснений от администратора. Это не баг — это корректная работа механизма ограничения доступа на уровне записей.

Ошибки в ограничениях rls проявляются по-разному: пользователь не видит нужные записи, видит лишние, или система выдаёт ошибку при открытии формы. Ниже — основные инструменты диагностики.
Типичные симптомы и причины:


Пошаговая диагностика:
1. Проверьте роли пользователя. В Конфигураторе откройте пользователя и убедитесь, что ему назначены нужные роли через группы доступа. Роль «Полные права» отключает все ограничения — её присутствие означает, что rls для данного пользователя не работает.
2. Используйте консоль запросов от имени пользователя. Выполните тестовый запрос к проблемному объекту, предварительно сменив контекст на нужного пользователя. Это покажет, какие записи реально доступны с учётом ограничений.
3. Проверьте наборы значений доступа. Откройте регистр сведений «НаборыЗначенийДоступа» и убедитесь, что для пользователя сформированы строки с нужными видами доступа. Если записей нет — запустите регламентное задание «Обновление вспомогательных данных» или его аналог в вашей конфигурации.
4. Анализируйте журнал регистрации. Фильтруйте события по типу «Отказ в доступе» для конкретного пользователя. Журнал фиксирует объект, к которому был запрос, и причину отказа — это значительно сужает область поиска.
5. Проверьте текст ограничения в роли. Откройте роль в Конфигураторе, найдите объект и проверьте условие на вкладке ограничений. Используйте конструктор запроса (F4) для синтаксической проверки — ошибки в тексте запроса могут приводить к неожиданному поведению.

Несколько правил, которые упростят жизнь при масштабировании системы:
- Стройте группы доступа по структуре предприятия: отдел, филиал, юридическое лицо — а не по именам конкретных людей.
- Давайте профилям понятные имена: «Бухгалтер_ОднаОрганизация» лучше, чем «Профиль17».
- Всегда тестируйте изменения на тестовом пользователе перед применением в рабочей базе.
- В крупных информационных базах учитывайте задержку применения настроек — после изменения групп доступа пользователю нужно перезайти в систему, а в некоторых случаях ждать пересчёта наборов значений доступа.
- Фиксируйте все изменения в документации, чтобы при возникновении коллизий прав можно было быстро восстановить историю настроек.