Многие разработчики 1С сталкиваются с парадоксальной ситуацией: для пользователя или системной учетной записи создается специальная ограниченная роль, в которой установлено право только на Чтение определенного справочника (например, справочника ГруппыДоступа). Однако, при обращении к базе через REST-интерфейс, HTTP-сервисы или при выполнении внешних обработок, пользователь внезапно получает возможность не только получать данные объекта, но и успешно его редактировать и записывать. Проанализируем эту ситуацию и разберем по шагам скрытые механизмы платформы 1С:Предприятие 8 и Библиотеки стандартных подсистем (БСП), которые приводят к такому поведению.
Первое, что мы рассмотрим — это фундаментальное отличие в проверке прав платформой при работе пользователя в интерфейсе и при программном доступе.
При программном обращении к объектам конфигурации (будь то стандартный REST API, OData интерфейс, ваши собственные HTTP-сервисы или код внешней обработки) платформа 1С проверяет исключительно базовые, так называемые «неинтерактивные» права: Чтение, Изменение, Добавление, Удаление.
Интерактивные права, такие как Интерактивное изменение, Редактирование или Интерактивное добавление, в программном контексте полностью игнорируются. Если у пользователя где-то в недрах профилей доступа закралось базовое право на Изменение, он сможет беспрепятственно модифицировать объект, выполнив, например, такой примитивный код:
Выборка = Справочники.ГруппыДоступа.Выбрать();
Пока Выборка.Следующий() Цикл
Объект = Выборка.Ссылка.ПолучитьОбъект();
// Модификация реквизитов
Объект.Записать();
КонецЦикла;
При этом, если такой пользователь зайдет в клиентское приложение 1С, форма элемента справочника может открыться строго на просмотр, так как интерактивных прав у него нет. Это создает ложное ощущение безопасности настроенных ролей.
Посмотрим на общую архитектуру назначения прав. В платформе 1С действует жесткое правило: «что не запрещено — разрешено». Если пользователю назначено несколько ролей (или они собираются из профилей групп доступа, как это реализовано в БСП для конфигураций уровня Комплексной автоматизации 2.4 или ERP), платформа применяет все права со всех ролей кумулятивно.
Если в вашей новой ограниченной роли стоит только Чтение, это само по себе не запрещает изменение объекта. Это лишь означает, что данная конкретная роль не дает права на изменение. Если у пользователя есть вторая роль (например, базовая или административная), в которой есть право Изменение на этот справочник, платформа их сложит. В результате право на редактирование будет получено.
Разберем ситуацию, когда пользователю, помимо ограниченной роли, назначают корневые роли, такие как Администрирование (часто требуется для работы с пользователями информационной базы). В конфигураторе у типовой роли Администрирование может не стоять галочек на конкретных прикладных объектах (справочниках, документах). Включены только несколько галок в корне конфигурации: Администрирование, Администрирование данных и т.д.
Казалось бы, корневая роль не должна влиять на права конкретного справочника. Однако здесь вступает в игру логика работы конфигураций на базе БСП. Справочники Пользователи и ГруппыДоступа — это системно значимые объекты, тесно связанные со списком пользователей самой информационной базы.
В БСП реализовано множество переопределенных алгоритмов в подписках на события и модулях объектов (например, в обработчиках ПередЗаписью или ПриЗаписи). Когда программный код БСП видит у текущего сеанса наличие корневой роли Администрирование или АдминистрированиеДанных, он может автоматически включать привилегированный режим работы с помощью метода УстановитьПривилегированныйРежим(Истина). В привилегированном режиме проверка прав отключается, позволяя коду беспрепятственно сохранить связанные элементы системных справочников, даже если у пользователя нет явного права Изменение в матрице ролей.
Выясним еще одну частую причину, вводящую разработчиков в заблуждение при настройке ролей. В платформе 1С существует жесткая иерархическая зависимость галочек в матрице прав конфигуратора. Физически невозможно дать право на Изменение, Добавление или Удаление, если не установлено базовое право Чтение.
Как возникает иллюзия? Предположим, в роли случайно (или при копировании) были установлены права на изменение. Разработчик, пытаясь ограничить роль, вручную снимает галочку Чтение. Конфигуратор в этот момент автоматически и без каких-либо предупреждений снимает все зависимые галки (включая Изменение). Разработчик видит, что при тестировании возможность записи пропала, или система выдает ошибку, и делает ошибочный вывод: «именно снятие галочки 'Чтение' закрыло право на редактирование». На самом деле редактированием управляло право Изменение, которое исчезло в фоновом режиме вместе с чтением.
Чтобы надежно защитить справочники от несанкционированного изменения через программные интерфейсы, рекомендуем выполнить следующие шаги:
Изменение.ПередЗаписью и проверьте стек вызовов. Вы обязательно найдете место, где вызывается УстановитьПривилегированныйРежим().ПриСозданииНаСервере можно программно устанавливать атрибут формы ТолькоПросмотр = Истина. Это решит проблему в интерфейсе, но не защитит REST.Изменение с условием, которое всегда возвращает Ложь (например, ГДЕ ЛОЖЬ) для этой конкретной ограниченной роли. RLS будет отрабатывать на уровне платформы при любом программном обращении.Заполнение данных для ограничения доступа в подсистеме БСП, чтобы новые настройки ролей и профилей корректно применились.Подводя итог: право Чтение никогда само по себе не позволяет изменять объект. Если объект модифицируется — ищите скрытое базовое право Изменение в других ролях, программное включение привилегированного режима в БСП или влияние корневых административных прав.