Как установить права пользователей в 1С

Права пользователей в 1С определяют, кто может просматривать, создавать, изменять и удалять данные в информационной базе. Корректная настройка прав — это не только защита коммерческой информации, но и профилактика случайных ошибок: бухгалтер не удалит документы склада, а менеджер не увидит зарплатную ведомость. В типовых конфигурациях (1С:Бухгалтерия, 1С:Управление торговлей, 1С:ЗУП, 1С:ERP) механизм прав построен на ролях и профилях групп доступа.

Подход к настройке зависит от режима работы базы. В файловом варианте права настраиваются напрямую в конфигураторе или в режиме «Предприятие», в клиент-серверном — дополнительно учитываются права на уровне СУБД. В современных конфигурациях на платформе 8.3 основным инструментом является подсистема «Управление доступом» из библиотеки стандартных подсистем (БСП), где администратор работает с профилями и группами доступа, не открывая конфигуратор.

Перед началом работы убедитесь, что у вас есть учётная запись с полными правами (роль «Полные права» или «Администратор системы»), и сделайте резервную копию базы. Некорректное изменение ролей способно заблокировать работу всех пользователей, включая администратора.

Как устроена система прав в 1С

Минимальной единицей прав является роль — набор разрешений на объекты конфигурации: справочники, документы, регистры, отчёты. Роль определяет, можно ли читать, добавлять, изменять, удалять объекты, а также использовать интерактивные команды. Роли задаются разработчиком в конфигураторе и поставляются в составе типового решения.

Пользователю напрямую роли назначаются в конфигураторе или в списке пользователей информационной базы. Однако в типовых конфигурациях с БСП поверх ролей работает более удобный слой: профили групп доступа. Профиль объединяет несколько ролей в осмысленный набор — например, «Менеджер по продажам», «Кассир», «Главный бухгалтер». Пользователь включается в группу доступа, а группа связана с профилем.

Дополнительно существует механизм RLS (Record Level Security) — ограничение доступа на уровне записей. Он позволяет показывать пользователю не все данные, а только относящиеся к его организации, складу или контрагентам. RLS настраивается через шаблоны ограничений в ролях и параметры сеанса.

Создание пользователя и назначение ролей в конфигураторе

Базовый способ, доступный в любой конфигурации, — работа через конфигуратор. Откройте базу в конфигураторе, перейдите в меню «Администрирование» → «Пользователи» и нажмите «Добавить». На закладке «Основные» укажите имя (логин), полное имя, при необходимости задайте пароль и выберите язык интерфейса.

На закладке «Прочие» отметьте флажками роли, которые должен получить пользователь. Здесь же назначаются основной интерфейс и режим запуска. Сохраните пользователя — после перезапуска сеанса новые права вступят в силу.

Способ через конфигуратор подходит для небольших баз и простых конфигураций. Его ограничения: нельзя задать ограничения на уровне записей в удобной форме, нет наследования прав через группы, а любое изменение требует доступа к конфигуратору, который есть не у каждого администратора.

Настройка прав через профили групп доступа в режиме «Предприятие»

В типовых конфигурациях на платформе 8.3 основная работа ведётся в режиме «Предприятие». Откройте раздел «Администрирование» → «Настройки прав и пользователей» (в некоторых конфигурациях — «Настройка пользователей и прав») и убедитесь, что включён флажок «Группы доступа» или «Ограничивать доступ на уровне записей».

Порядок настройки через профили выглядит так. Сначала создайте или скопируйте профиль: в подразделе «Профили групп доступа» выберите типовой профиль, близкий к нужной должности, и скопируйте его, чтобы не менять поставляемые настройки. Внутри профиля отметьте разрешённые роли и, при необходимости, дополнительные права — например, разрешение на изменение печатных форм или работу с внешними обработками.

Затем создайте группу доступа, свяжите её с профилем и включите в неё пользователей. Один пользователь может входить в несколько групп — его итоговые права будут суммой разрешений всех групп. Это удобно, когда сотрудник совмещает функции, например кассира и оператора склада.

1. 1
   Откройте «Администрирование» → «Настройки прав и пользователей» и включите механизм групп доступа
2. 2
   Скопируйте типовой профиль, близкий к должности сотрудника, и дайте копии понятное имя
3. 3
   Отметьте в профиле необходимые роли и дополнительные права, уберите лишние
4. 4
   Создайте группу доступа, привяжите её к профилю и добавьте пользователей
5. 5
   Войдите в базу под учётной записью пользователя и проверьте доступность нужных функций и недоступность запрещённых

Ограничение доступа на уровне записей (RLS)

Когда в одной базе работают несколько организаций или подразделений, ролей недостаточно: роль разрешает чтение документов целиком, но не отбирает конкретные записи. Для этого служит RLS. В типовых конфигурациях ограничение включается в настройках прав, а значения доступа задаются в карточке группы доступа или пользователя: разрешённые организации, склады, кассы, контрагенты.

Например, чтобы менеджер видел документы только своей организации, создайте группу доступа с профилем «Менеджер», в поле «Организации» укажите конкретное юрлицо и добавьте пользователя. Все запросы к данным будут автоматически дополняться условием отбора.

Учтите, что RLS замедляет выполнение запросов: к каждому обращению добавляется проверка условий. На больших базах с сотнями пользователей избыточные ограничения способны заметно снизить производительность. Включайте ограничения только там, где это действительно требуется, и не дублируйте их на уровне нескольких групп.

Частая причина жалоб «пользователь не видит документы» — включённый RLS без заполненных значений доступа. Если в группе доступа указан вид ограничения (например, организации), но список разрешённых значений пуст, система трактует это как «ничего не разрешено». Либо заполните список, либо установите вариант «Все разрешены».

Настройка прав в файловой и клиент-серверной базе

Механизм ролей и профилей одинаков для обоих режимов, но есть отличия в инфраструктурном слое. В файловой базе список пользователей хранится в самой базе, аутентификация выполняется средствами платформы или операционной системы. Администратору достаточно прав на файл базы и доступа в конфигуратор.

В клиент-серверном варианте добавляется уровень СУБД: пользователь кластера 1С и пользователь базы данных — разные сущности. Учётная запись создаётся в консоли кластера или через конфигуратор, но права на таблицы SQL Server или PostgreSQL выдаёт администратор СУБД. Разграничение прав внутри прикладного решения по-прежнему настраивается ролями и профилями — напрямую в SQL менять ничего не нужно.

Для доменных сетей удобна аутентификация операционной системы: пользователь входит в 1С без ввода пароля под своей доменной учётной записью. Она включается в свойствах пользователя флажком «Аутентификация операционной системы» с указанием доменного имени в формате \\ДОМЕН\Пользователь.

Проверка и аудит назначенных прав

После настройки обязательно проверьте результат от имени пользователя. Войдите в базу под его учётной записью и пройдите типовые сценарии: открытие рабочих документов, попытка создания запрещённого объекта, доступ к отчётам. Сообщение «Нарушение прав доступа» при попытке открыть закрытый раздел — признак корректно работающего ограничения.

Для массового контроля в типовых конфигурациях есть отчёт «Права доступа» или «Анализ прав доступа» (раздел администрирования). Он показывает, какие роли и профили действуют для каждого пользователя и через какие группы доступа они получены. Это позволяет быстро найти избыточные права — например, сотрудника, которому случайно выдали профиль администратора.

Контрольные точки

Как проверить результат

Вход пользователя в базу

Норма

Вход выполняется, открывается начальная страница с нужными разделами

Тревожный признак

Ошибка «Нарушение прав доступа» сразу при входе или пустой интерфейс без разделов

Доступ к разрешённым документам

Норма

Документы открываются, проводятся, печатаются

Тревожный признак

Документы видны, но не проводятся — не хватает роли на изменение

Доступ к запрещённым разделам

Норма

Разделы скрыты или выдают ошибку доступа

Тревожный признак

Пользователь открывает чужие данные — права избыточны

Отчёт по правам доступа

Норма

У пользователя только профили его должности

Тревожный признак

В списке есть лишние группы или профиль «Администратор»

Типичные ошибки и риски при настройке прав

Самая опасная ошибка — блокировка единственного администратора. Если изменить роли единственной учётной записи с полными правами и ошибиться, восстановить доступ штатными средствами будет невозможно. Перед изменениями создайте второго администратора и резервную копию базы.

Вторая распространённая проблема — редактирование типовых профилей вместо создания копий. При обновлении конфигурации поставщик может перезаписать типовые профили, и ваши настройки пропадут. Всегда копируйте профиль и работайте с копией.

Часто задаваемые вопросы

Можно ли настроить права без доступа к конфигуратору?

Да, в типовых конфигурациях на базе БСП вся настройка выполняется в режиме «Предприятие» через профили групп доступа в разделе «Администрирование». Конфигуратор нужен только для создания новых ролей или изменения встроенных.

Пользователь входит в базу, но не видит ни одного документа. В чём причина?

Чаще всего включено ограничение на уровне записей, а список разрешённых значений (организаций, складов) пуст. Проверьте настройки группы доступа и заполните список значений либо отключите ограничение по этому виду объектов.

Как быстро выдать одинаковые права группе сотрудников?

Создайте один профиль с нужными ролями и одну группу доступа, затем добавьте в неё всех сотрудников. Изменение профиля автоматически применится ко всем участникам группы без индивидуальной настройки каждого.

Что делать, если заблокирована единственная учётная запись администратора?

Штатного способа сброса пароля администратора без доступа к базе нет. Варианты: восстановление из резервной копии, вход под другой записью с полными правами (если создавалась) или обращение к специалисту по 1С. Поэтому резервный администратор и копии обязательны.

Суммируются ли права, если пользователь входит в несколько групп доступа?

Да, итоговые разрешения складываются: если хотя бы одна группа разрешает действие, оно будет доступно. Ограничения RLS при этом также комбинируются, поэтому избыточное членство в группах расширяет доступ сильнее, чем ожидается.

Влияет ли настройка прав на производительность базы?

Сами роли влияют незначительно, но ограничения на уровне записей добавляют условия к каждому запросу. На крупных базах с большим числом пользователей чрезмерные RLS-ограничения могут замедлить работу, поэтому включайте их только там, где это обосновано требованиями безопасности.