При подготовке информационной базы для внешних аудиторов или при разграничении прав между сотрудниками в программе «1С:Зарплата и управление персоналом» (редакция 2.5) администраторы часто сталкиваются с типовой проблемой. Настроив группы пользователей и ограничив доступ к конкретным организациям, мы обнаруживаем, что пользователь под своей учетной записью всё равно видит абсолютно все данные. Если же мы пытаемся исправить эту ситуацию и забираем у пользователя административные роли, система просто отказывается запускаться, выдавая критическую ошибку «Нарушение прав доступа».
В этой статье мы подробно разберем, почему возникает этот конфликт, как правильно настроить механизм ограничения доступа на уровне записей (RLS) в ЗУП 2.5, избавиться от ошибок при старте системы, а также рассмотрим альтернативные и более безопасные методы передачи базы данных аудиторам.
Проанализируем базовый принцип работы платформы «1С:Предприятие». Механизм RLS (Record Level Security — ограничение доступа на уровне записей) предназначен для того, чтобы накладывать дополнительные условия фильтрации на SQL-запросы к базе данных «на лету». Однако у этого механизма есть важнейшее исключение.
Если у пользователя в списке ролей активна роль ПолныеПрава, система полностью игнорирует любые настройки RLS. Эта роль разработана как суперпользовательская (административная). Для нее проверка прав доступа на уровне записей не выполняется в принципе. Поэтому, если вы добавили пользователя в группу с ограничением доступа по организациям, но забыли снять флажок ПолныеПрава в Конфигураторе, он продолжит видеть все организации, документы и справочники без ограничений.
Решение: Первым делом откройте Конфигуратор, перейдите в меню «Администрирование» — «Пользователи», откройте карточку нужного пользователя и на вкладке «Прочие» снимите флажок с роли ПолныеПрава. Оставьте только прикладные роли, например, Пользователь, КадровикРегламентированныхДанных и РасчетчикРегламентированныхДанных.
Как только мы забираем у учетной записи полные права, при входе в программу от имени аудитора или ограниченного пользователя мгновенно возникает ошибка доступа, и сеанс аварийно завершается. Выясним, почему это происходит и как это исправить.
Во-первых, любому пользователю в конфигурациях на обычных формах (к которым относится и ЗУП 2.5) в обязательном порядке должна быть назначена служебная роль Пользователь. Без этой роли сеанс работы в принципе не может быть инициализирован, так как она содержит базовые права чтения на общие константы, системные справочники, классификаторы и параметры сеанса.
Во-вторых, виновником падения при старте часто выступает встроенный рабочий стол программы — обработка ПанельФункций. По умолчанию система настроена так, чтобы при открытии программы автоматически запускать эту обработку. При старте панель функций пытается собрать сводную информацию по ключевым показателям, обращаясь к различным регистрам и документам, доступ к которым у нашего ограниченного пользователя может быть закрыт настройками RLS. Происходит конфликт прав, и платформа аварийно завершает работу.
Разберем два эффективных способа решения этой проблемы.
Если аудитору или ограниченному пользователю для работы не требуется интерактивный рабочий стол (панель функций), проще всего отключить его автозапуск при старте системы. Сделаем это по шагам:
ПолныеПрава).После этого попробуйте запустить базу под учетной записью аудитора. Вход должен пройти успешно, программа откроется со стандартным главным меню без вызова стартового рабочего стола.
Если панель функций пользователю жизненно необходима, нам придется скорректировать права доступа в Конфигураторе. Этот способ требует монопольного доступа к базе данных для сохранения изменений конфигурации:
ПанельФункций.Теперь программа не будет падать с ошибкой, так как у пользователя появятся легитимные права на запуск интерфейсного объекта.
Если вы выполнили описанные шаги, но система всё равно выдает «Нарушение прав доступа» при старте или при проведении документов, не нужно гадать, на какой именно объект не хватает прав. Платформа фиксирует абсолютно все отказы. Выясним точную причину с помощью Журнала регистрации:
В колонке «Данные» или «Представление объекта» система четко укажет имя метаданных (например, конкретный регистр сведений РегистрСведений.ПлановыеНачисленияРаботниковОрганизаций или константу), к которому программа пыталась обратиться, но получила отказ. Зная имя этого объекта, вы сможете легко добавить на него права чтения в Конфигураторе для роли вашего пользователя.
Даже если вы успешно ограничили доступ по организациям, в ЗУП 2.5 вас подстерегает еще один серьезный подводный камень. Структура метаданных программы такова, что кадровые и расчетные документы содержат ссылки на справочник ФизическиеЛица.
Если вы ограничили видимость документов по организации, но оставили справочник физлиц полностью открытым, пользователь все равно сможет косвенно увидеть персональные данные сотрудников других организаций через отчеты или общие списки. И наоборот: если вы включили жесткое ограничение по физлицам, но не распределили сотрудников по группам доступа, ваш аудитор может открыть документ по разрешенной организации, но табличная часть документа окажется абсолютно пустой, так как у него нет прав на чтение конкретных записей физлиц.
Чтобы избежать этой проблемы, выполните следующие действия:
Помните, что включение RLS в ЗУП 2.5 на больших базах данных неизбежно приводит к заметному снижению производительности. Сложные SQL-запросы с наложенными условиями RLS могут выполняться в несколько раз медленнее, особенно при формировании тяжелых отчетов вроде расчетных ведомостей.
Поскольку настройка RLS в ЗУП 2.5 является трудоемким процессом, который нагружает систему, а аудиторам зачастую требуется предоставить базу «еще вчера», рассмотрим другие варианты решения задачи.
Идея создать распределенную информационную базу (РИБ) с фильтрацией по организации — это отличный и самый цивилизованный путь. В этом случае аудиторы получают отдельный файл базы данных, в котором физически отсутствуют лишние организации. Если у вас не получается сделать выгрузку из-за ошибок реструктуризации при переходе между релизами или версиями платформ, структуру базы данных необходимо вылечить.
Выполним процедуру восстановления структуры таблиц:
После успешного завершения тестирования все рассогласования в структуре SQL-таблиц будут устранены. Вы сможете без ошибок настроить план обмена по организациям и создать чистую периферийную базу для передачи аудиторам.
Если лечить рабочую базу некогда, а предоставить данные аудиторам нужно срочно, можно пойти по пути физического удаления «чужих» организаций из копии базы. Это гарантирует, что аудиторы никаким образом (даже случайно получив полные права) не смогут увидеть закрытые коммерческие данные других юрлиц.
Рассмотрим по шагам этот алгоритм:
Организация Не Равно [РазрешеннаяДляАудитаОрганизация].Для окончательной очистки базы от «хвостов» и уменьшения размера файла базы данных запустите Конфигуратор и выполните процедуру «Тестирование и исправление» с включенной опцией реструктуризации таблиц и очистки битых ссылок. В результате вы получите чистую, легкую и абсолютно безопасную копию базы данных, содержащую сведения только по одной организации.