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