Как ограничить доступ к документам в 1С, чтобы каждый пользователь видел только свои записи, а директор — все?

← На главную

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

В этой статье мы подробно разберем, почему популярные «простые» способы решения этой задачи не работают, что такое механизм RLS (Record Level Security), как правильно настроить ограничение прав в конфигураторе и в режиме «1С:Предприятие» с использованием Библиотеки стандартных подсистем (БСП), а также как избежать критических проблем с производительностью системы.

Почему скрытие колонок и отборы на формах — это иллюзия безопасности?

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

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

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

Именно поэтому единственным надежным способом защиты конфиденциальной информации является ограничение доступа на уровне СУБД. В платформе «1С:Предприятие» за это отвечает механизм RLS (Record Level Security).

Что такое RLS и как работает принцип сложения прав?

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

При настройке прав доступа в 1С крайне важно понимать фундаментальное правило платформы: права пользователя складываются по разрешению. Это означает следующее:

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

Исходя из этого принципа, наша задача («менеджеры видят только свое, директор — все») решается созданием правильной структуры ролей:

Создаем или настраиваем роль «Менеджер». Для этой роли у нужного документа (например, Документ.ЗаявкаНаТур) настраиваем RLS-ограничение, которое разрешает чтение только тех записей, где ответственным является текущий пользователь.
Создаем или используем роль «Директор» (или «Полные права»), в которой для этого же документа право чтения предоставлено без каких-либо ограничений RLS.
Менеджерам назначаем только роль «Менеджер». Директору назначаем роль «Директор» (или обе роли сразу). В итоге менеджеры будут ограничены правилом RLS, а директор увидит все документы скопом и сможет использовать обычные интерактивные отборы для удобства работы.

Настройка RLS в Конфигураторе вручную

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

Для начала нам необходимо определить, по какому признаку мы будем идентифицировать текущего пользователя. Напрямую сравнивать поле документа со значением текущего пользователя в SQL-запросе RLS нельзя, так как функции платформы ограничены. Для этого используются Параметры сеанса.

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


Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    
    // Код инициализации текущего пользователя
    Если ТребуемыеПараметры.Найти("ТекущийПользователь") <> Неопределено Тогда
        ПараметрыСеанса.ТекущийПользователь = НайтиТекущегоПользователяВБазе();
    КонецЕсли;
    
КонецПроцедуры

Теперь перейдем к настройке роли. Разберем по шагам этот процесс:

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

ГДЕ Ответственный = &ТекущийПользователь

Этот простой запрос указывает платформе, что при чтении таблицы документов СУБД должна отфильтровать записи по значению нашего параметра сеанса.

Современный подход: Ограничение доступа средствами БСП

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

Рассмотрим подробнее, как решить нашу задачу с помощью встроенной подсистемы «Управление доступом» в БСП:

Запускаем базу данных в режиме «1С:Предприятие» под правами администратора.
Переходим в раздел Администрирование -> Настройки пользователей и прав -> Группы доступа.
Создаем новый Профиль групп доступа (например, «Менеджер по продажам туров»).
На вкладке «Разрешенные действия (роли)» отмечаем галочками те роли, которые необходимы менеджеру для работы.
Переходим на вкладку «Ограничения доступа». Здесь мы увидим доступные виды ограничений. Нам нужно выбрать вид доступа «Пользователи».
Устанавливаем для вида доступа «Пользователи» значение «Все запрещены, исключения назначаются в группах доступа».
Записываем профиль и на его основании создаем Группу доступа (например, «Группа менеджеров»).
В созданной группе доступа на вкладке «Участники» добавляем наших менеджеров, а на вкладке «Ограничения доступа» для вида доступа «Пользователи» указываем значение «Свои данные» (или выбираем конкретного пользователя индивидуально для каждого участника).

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

Производительность RLS: Стандартный и Производительный режимы

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

Начиная с версии БСП 3.0, разработчикам доступны два режима работы подсистемы управления доступом:

1. Стандартный режим (динамический расчет)

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

2. Производительный режим (универсальный, с предварительным расчетом)

Это современный стандарт разработки в среде «1С:Предприятие». Логика его работы кардинально отличается:

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

Преимущество: Производительность работы интерфейса, отчетов и динамических списков возрастает в десятки и сотни раз. Нагрузка на СУБД минимизируется.

Недостаток: Требуется дополнительное дисковое пространство на сервере под хранение регистров ключей доступа. При первом включении этого режима системе может потребоваться время (от нескольких минут до нескольких часов в зависимости от объема базы данных) на первоначальный расчет прав.

Важнейшее правило разработки: Использование ключевого слова РАЗРЕШЕННЫЕ

Проанализируем типичную ошибку программистов при внедрении RLS. Если в системе активированы ограничения на уровне записей, при написании любого программного запроса к базе данных (в отчетах, обработках, модулях проведения документов) мы обязаны использовать ключевое слово РАЗРЕШЕННЫЕ.

Посмотрим на пример неправильного запроса:


// Этот код вызовет критическую ошибку у обычного менеджера!
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Ссылка,
    |	Номер,
    |	СуммаДокумента
    |ИЗ
    |	Документ.ЗаявкаНаТур";
ТаблицаДанных = Запрос.Выполнить().Выгрузить();

Если этот код выполнит менеджер, у которого включен RLS, система прервет работу и выдаст ошибку: «У пользователя недостаточно прав на исполнение операции над базой данных». Дело в том, что по умолчанию платформа пытается выбрать все записи из таблицы СУБД, на что у пользователя нет прав.

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


// Правильный запрос с использованием ключевого слова РАЗРЕШЕННЫЕ
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ РАЗРЕШЕННЫЕ
    |	Ссылка,
    |	Номер,
    |	СуммаДокумента
    |ИЗ
    |	Документ.ЗаявкаНаТур";
ТаблицаДанных = Запрос.Выполнить().Выгрузить();

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

Выводы

Мы рассмотрели особенности настройки ограничений доступа в «1С:Предприятии 8.3». Защита конфиденциальной информации — это задача, требующая комплексного подхода. Попытки обойтись визуальным скрытием полей на формах не защитят базу от утечки данных. Использование штатного механизма RLS (особенно в его современном производительном режиме через БСП) позволяет построить надежную, гибкую и быстродействующую систему разграничения прав доступа, гарантирующую безопасность коммерческих данных компании.