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