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