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