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

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

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

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

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

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

Отдельный уровень — ограничение доступа на уровне записей (RLS, Record Level Security). Оно ограничивает не список объектов, а конкретные строки данных: например, менеджер видит только документы своей организации или своего склада. RLS настраивается в типовых конфигурациях через «Ограничение доступа на уровне записей» в настройках пользователей и прав.

Подготовка: что проверить перед настройкой

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

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

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

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

После создания пользователя назначьте ему доступ через группы. Перейдите в «Группы доступа», откройте подходящую группу (например, «Менеджеры по продажам») и добавьте пользователя на закладке «Участники». Права применятся автоматически — перезапуск базы не требуется, но пользователю нужно перезайти в сеанс, если он уже работал.

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

Настройка профилей групп доступа

Типовые профили покрывают большинство должностей, но часто требуют доработки. Не изменяйте поставляемые профили напрямую — при обновлении конфигурации изменения могут быть затёрты или привести к конфликтам. Правильный путь: скопируйте типовой профиль, дайте ему понятное имя (например, «Менеджер по продажам — без закрытия месяца») и настройте состав ролей.

В карточке профиля на закладке «Роли» отметьте нужные роли. Ищите роли по названию объекта или действия: например, для доступа к реализациям нужны роли чтения и изменения документа «Реализация товаров и услуг», а также роли чтения связанных справочников — контрагентов, номенклатуры, договоров. Частая ситуация: документ открывается, но поля пустые или недоступны — это признак отсутствия прав на связанные объекты.

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

Назначение ролей через конфигуратор

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

Будьте осторожны с ролями «Полные права» и «Администратор системы»: они дают неограниченный доступ ко всем данным и настройкам. Выдавайте их только администраторам базы. Роль «Администратор системы» при этом не даёт права на просмотр данных — только на административные операции, поэтому администратору обычно нужны обе роли.

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

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

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

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

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

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

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

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

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

Вход под учётной записью пользователя

Норма

Открываются нужные разделы, документы создаются и проводятся без ошибок прав

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

Ошибки «Нарушение прав доступа» или пустые поля в документах

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

Норма

Чужие организации и склады не отображаются в списках и отчётах

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

Пользователь видит данные других подразделений или организаций

Отчёт «Права доступа» по пользователю

Норма

Состав ролей соответствует профилю его группы доступа

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

Присутствуют лишние роли, назначенные в обход профиля

Частые вопросы

Пользователь не видит документы, хотя профиль назначен. Что проверить?

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

Можно ли дать пользователю права «только чтение» на всю базу?

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

Чем отличаются права в файловой и клиент-серверной базе?

Механизм ролей и профилей одинаковый. Различия в инфраструктуре: в клиент-серверном варианте дополнительно действуют права на уровне СУБД и кластера серверов 1С, а список пользователей применяется сразу после сохранения. В файловой базе некоторые административные операции требуют монопольного доступа.

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

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

Что делать, если после обновления конфигурации права «слетели»?

Проверьте, не изменялись ли типовые профили напрямую — обновление могло вернуть их состав к поставляемому. Сравните текущие профили с копией базы до обновления и восстановите состав ролей. На будущее все доработки прав ведите только в собственных скопированных профилях.

Нужно ли настраивать RLS в небольшой компании?

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