Администрирование · 11 мин
Как ограничить доступ в 1С: практическое руководство
Пошаговая инструкция по ограничению доступа в 1С: роли, профили групп доступа, RLS, права на объекты и типичные ошибки при настройке безопасности.
Ограничение доступа в 1С — это не разовое действие, а система из нескольких уровней: аутентификация пользователя, назначение ролей или профилей групп доступа, ограничения на уровне записей (RLS) и настройка интерфейса. Правильно выстроенная модель позволяет сотруднику видеть и изменять только те данные, которые нужны ему для работы, и защищает базу от случайных и намеренных ошибок.
Подход к настройке зависит от конфигурации. В типовых решениях на базе Библиотеки стандартных подсистем (Управление торговлей, ERP, ЗУП, Бухгалтерия предприятия 3.0) основной инструмент — профили групп доступа. В простых или самописных конфигурациях приходится работать напрямую с ролями в конфигураторе. Ниже разобраны оба сценария, а также механизм RLS, который часто становится источником проблем с производительностью при неправильном применении.
Перед любыми изменениями прав сделайте резервную копию информационной базы. Ошибка в настройке ролей может заблокировать работу пользователей или, наоборот, открыть доступ к зарплате и финансовым данным тем, кому он не положен. Проверяйте результат под тестовой учётной записью, а не под своей административной.
Как устроена модель прав в 1С
В платформе 1С:Предприятие права назначаются не пользователю напрямую, а через промежуточные сущности. Базовый элемент — роль: набор прав на объекты метаданных (справочники, документы, регистры, отчёты). Роль определяет, можно ли читать, добавлять, изменять, удалять объект, а также использовать интерактивные команды вроде проведения документа.
В типовых конфигурациях поверх ролей надстроены профили групп доступа. Профиль — это «должностная» обёртка: например, «Менеджер по продажам», «Кассир», «Главный бухгалтер». Администратор включает пользователя в группу доступа с нужным профилем, и система автоматически выдаёт соответствующий набор ролей. Это удобнее, чем назначать десятки ролей вручную, и снижает риск ошибки.
Третий уровень — RLS, ограничение на уровне записей. Роль даёт право читать справочник «Контрагенты» целиком, а RLS сужает выборку: менеджер видит только своих клиентов, кассир — только кассовые документы своей организации. RLS настраивается через шаблоны ограничений в ролях или через значения групп доступа в типовых конфигурациях.
Настройка доступа через профили групп доступа
В типовых конфигурациях (Бухгалтерия 3.0, ЗУП, УТ, ERP) откройте раздел «Администрирование» → «Настройки прав и пользователей». Убедитесь, что включён флажок «Группы доступа» — без него механизм профилей не работает, и пользователи получают права только через роли по умолчанию.
Дальше логика такая: вы создаёте (или используете поставляемый) профиль, например «Менеджер по закупкам», затем создаёте группу доступа с этим профилем и включаете в неё конкретных пользователей. Один пользователь может входить в несколько групп — права суммируются. Это важно: механизм в 1С аддитивный, «запрещающей» группы создать нельзя, можно только не давать лишнего.
- 1Включите «Группы доступа» в разделе «Администрирование → Настройки прав и пользователей»
- 2Откройте справочник «Профили групп доступа» и выберите поставляемый профиль или создайте свой на основе существующего
- 3Проверьте состав ролей профиля и при необходимости снимите лишние (например, «Изменение макетов печатных форм»)
- 4Создайте группу доступа, укажите в ней профиль и добавьте пользователей
- 5Задайте разрешённые значения доступа: организации, склады, подразделения
- 6Войдите в базу под тестовым пользователем и проверьте доступные документы и отчёты
Самостоятельно редактировать состав ролей типового профиля стоит осторожно: при обновлении конфигурации поставляемые профили могут быть перезаполнены. Надёжнее скопировать профиль, дать ему понятное имя (например, «Менеджер по продажам — без закрытия месяца») и донастроить копию.
Ограничение прав через роли в конфигураторе
Если конфигурация нетиповая или требуется тонкая настройка, работа ведётся в конфигураторе: «Администрирование» → «Пользователи», затем вкладка «Прочее» или «Роли» у конкретного пользователя. Здесь можно вручную отметить роли, которые ему доступны. Состав самих ролей редактируется в дереве конфигурации: ветка «Общие» → «Роли».
В свойствах роли для каждого объекта метаданных задаются права: чтение, добавление, изменение, удаление, проведение, интерактивное удаление и другие. Обратите внимание на пару прав «Удаление» и «Интерактивное удаление»: первое разрешает удаление программно, второе — пользователю из интерфейса. Частая ошибка — снять только интерактивное удаление и считать объект защищённым, хотя право на удаление осталось.
После изменения ролей обновите конфигурацию базы данных (F7) и попросите пользователей перезайти. Права кэшируются в сеансе, поэтому «вроде всё настроил, а доступ не изменился» — типичная ситуация, решаемая перезапуском сеанса.
Ограничение видимости данных через RLS
RLS нужен, когда роли слишком грубы: право на чтение документов есть у всех менеджеров, но каждый должен видеть только свои. В типовых конфигурациях это настраивается без конфигуратора: в группе доступа на вкладке «Ограничение доступа» задаются разрешённые значения — организации, склады, кассы, подразделения, контрагенты (если включён соответствующий вид доступа).
Сначала включите нужные виды доступа в «Настройках прав и пользователей» (например, «Группы партнёров» или «Склады»), затем в группе доступа укажите конкретные значения. Если у пользователя в группе не задано ни одного значения по виду доступа, поведение зависит от настройки «Все разрешены» / «Все запрещены» — проверьте её явно, иначе пользователь либо увидит всё, либо не увидит ничего.
В нетиповых конфигурациях шаблоны RLS пишутся вручную в свойствах роли, на языке ограничения доступа к данным (похож на язык запросов). Ошибка в шаблоне приводит либо к пустым спискам у пользователей, либо к падению запросов с сообщением о нарушении прав доступа. Тестируйте шаблоны под учётной записью с минимальными правами.
Дополнительные меры: пароли, интерфейс, внешний доступ
Ограничение прав бессмысленно без контроля входа. В настройках пользователя задайте требования к паролю: минимальная длина, сложность, срок действия. В типовых конфигурациях это делается в «Настройках входа пользователей». Для Windows-аутентификации политика паролей наследуется из домена.
Скрытие команд интерфейса — не защита, а лишь косметика. Если убрать кнопку из меню, но оставить право на объект, пользователь откроет его через «Все функции», поиск или внешнюю обработку. Поэтому сначала настраиваются права, и только потом ради удобства чистится интерфейс.
Если база опубликована на веб-сервере или доступна через тонкий клиент извне, дополнительно ограничьте доступ на уровне сети: VPN, фильтрация по IP, отдельная публикация только для нужных пользователей. Права внутри 1С — последний рубеж, а не единственный.
Проверка результата и аудит прав
Единственный надёжный способ проверить настройку — войти под учётной записью пользователя с целевым набором прав. Создайте тестового пользователя, включите его в те же группы доступа и пройдитесь по сценариям: открытие списков документов, проведение, попытка удаления, запуск регламентных отчётов, доступ к зарплатным документам.
Для массового контроля используйте отчёт «Права доступа» (в типовых конфигурациях — «Администрирование» → «Обслуживание» или поиск по разделам). Он показывает, какие роли и через какие профили получил конкретный пользователь. Периодически выгружайте список пользователей с полными правами — их должно быть минимальное количество.
Как проверить результат
Доступны только нужные разделы и документы
Видны чужие организации, зарплата или настройки
Сообщение о нарушении прав доступа
Документ удаляется или помечается на удаление
Время формирования сопоставимо с прежним
Отчёты формируются в разы дольше
Роли соответствуют должности, полных прав нет
Лишние роли, непонятные источники прав
Что важно запомнить
Настраивайте доступ через профили групп доступа в типовых конфигурациях и через роли в нетиповых. Используйте RLS только там, где нужна фильтрация записей, и проверяйте производительность. Права в 1С суммируются — давайте минимум необходимого. Перед изменениями делайте копию базы, а результат проверяйте под тестовой учётной записью, а не под администратором.
Частые вопросы
Как запретить пользователю удалять документы, но оставить изменение?
В роли для нужного типа документов снимите права «Удаление» и «Интерактивное удаление», оставив «Изменение». В типовых конфигурациях проще использовать профиль без права удаления или включить запрет изменения данных по дате запрета для старых периодов. Проверьте результат под тестовой учётной записью: при попытке удаления должно появляться сообщение о нарушении прав.
Почему пользователь всё равно видит данные, хотя я ограничил доступ?
Наиболее частые причины: сеанс не перезапущен после изменения прав; пользователь входит в другую группу доступа, которая даёт эти права (права суммируются); ограничение настроено только в интерфейсе, а не в ролях; в группе доступа по виду доступа стоит «Все разрешены». Проверьте состав прав через отчёт «Права доступа».
Чем профиль групп доступа отличается от роли?
Роль — технический набор прав на объекты конфигурации, задаётся в конфигураторе. Профиль групп доступа — пользовательская надстройка в типовых конфигурациях: он объединяет роли и настройки RLS в понятную «должность», которую администратор назначает через интерфейс предприятия без входа в конфигуратор.
Можно ли ограничить доступ к отдельным отчётам?
Да. Отчёты — такие же объекты метаданных, и права на них задаются в ролях (право «Использование» и «Просмотр»). В типовых конфигурациях дополнительно работают варианты отчётов с настройкой видимости по пользователям, но это скрытие, а не защита: при наличии права на отчёт пользователь сможет создать свой вариант.
Что делать, если после настройки RLS база стала тормозить?
Сначала выясните, какие запросы замедлились, — включите технологический журнал или замер производительности. Обычно помогает сокращение числа видов доступа, отказ от RLS по большим регистрам, проверка индексов по полям, используемым в шаблонах ограничений. Если оптимизировать не удаётся, рассмотрите разделение доступа на уровне отдельных баз или копий вместо RLS.
Как быстро заблокировать доступ уволенному сотруднику?
Откройте карточку пользователя в списке пользователей и снимите флажок «Вход в программу разрешён» (или установите «Недействителен»). Это надёжнее, чем удаление пользователя: история документов и ссылки на автора сохранятся. В клиент-серверном варианте дополнительно завершите активные сеансы через консоль администрирования.