Добавление и настройка ролей в 1С 8.3: права, профили, аудит

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

Разница между этими двумя путями — ключевая, и именно на ней чаще всего спотыкаются. Если база типовая (Бухгалтерия 3.0, ЗУП 3.1, УТ 11), собственные роли почти всегда лишние: там работают профили групп доступа, а роли только наполняют эти профили. Если же конфигурация самописная или сильно доработанная, роли вы настраиваете и раздаёте руками. Ниже — оба сценария, настройка прав до уровня записей (RLS), способ добавить роль без снятия типовой с поддержки и проверка результата.

Роль, профиль и группа доступа — что где лежит

Три понятия, которые путают, но настраиваются в разных местах:

• 🧩 Роль — объект метаданных. Живёт в конфигураторе, это набор разрешений на объекты. Пользователь роль «не видит» — он видит её последствия.
• 👥 Профиль групп доступа — объект режима 1С:Предприятие (из библиотеки стандартных подсистем, БСП). Это именованный набор ролей: «Бухгалтер», «Кадровик», «Только просмотр».
• 🔑 Группа доступа — связка «профиль + список пользователей + значения доступа». Через неё профиль попадает конкретным людям.

Определитесь с этим до того, как открыли конфигуратор:

Вход в конфигуратор и подготовка базы

Запустите базу в режиме Конфигуратор (выбор режима — в окне запуска 1С). Нужен пользователь с правом администрирования, иначе дерево конфигурации откроется только на просмотр.

Перед работой — два обязательных пункта:

1. 💾 Выгрузите резервную копию: Администрирование → Выгрузить информационную базу (файл .dt). Любое изменение метаданных необратимо после обновления, а копию восстановить проще, чем откатывать права вручную.
2. 🔎 Проверьте режим поддержки: Конфигурация → Поддержка → Настройка поддержки. Если напротив конфигурации стоит замок с «запрещено изменение», добавлять роли в саму конфигурацию нельзя — только через расширение (см. раздел ниже).

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

Откройте дерево конфигурации (Конфигурация → Открыть конфигурацию). Нужная ветка — Общие → Роли. Там уже лежат роли, пришедшие с конфигурацией: трогать их в типовой базе нельзя.

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

Порядок действий:

1. Встаньте на ветку Роли, правой кнопкой → Добавить. Появится пустая роль и откроется её редактор.
2. В палитре свойств задайте имя латиницей без пробелов (например, МенеджерПоПродажам) и синоним — то, что увидит администратор на русском («Менеджер по продажам»).
3. Редактор роли разделён на две вкладки: Права (дерево объектов с разрешениями) и Шаблоны ограничений (тексты для RLS). По умолчанию вы на вкладке «Права».
4. Слева — дерево метаданных, справа — список прав для выделенного объекта. Все галочки изначально сняты: новая роль не разрешает ничего.

Над деревом есть три флажка, которые экономят время, но и подводят новичков:

• ☑️ Устанавливать права для новых объектов — если включить, роль будет автоматически получать права на объекты, добавленные в конфигурацию позже. Для узкой роли лучше выключить, чтобы права не «расползались».
• ☑️ Устанавливать права для реквизитов и табличных частей по умолчанию — права дочерних элементов наследуются от объекта. Удобно для старта.
• ☑️ Независимые права подчинённых объектов — наоборот, снимает наследование; включайте, только если планируете раздавать права по отдельным реквизитам.

Настройка прав на объекты и ролей верхнего уровня

Права в 1С делятся на две группы, и обе нужны для работающей роли.

Права на прикладные объекты (справочники, документы, регистры, отчёты, обработки). Для каждого объекта — свой набор:

Логика такая: Чтение, Добавление, Изменение, Удаление — это доступ к данным на уровне платформы. Просмотр, Редактирование, Интерактивное... — доступ через интерфейс. Если дать Изменение, но не дать Чтение, роль работать не будет: нельзя изменить то, что не прочитано.

Права верхнего уровня (корень конфигурации) — встаньте на самый верх дерева, на имя конфигурации. Здесь системные разрешения:

• 🖥 Запуск толстого клиента, Запуск тонкого клиента, Запуск веб-клиента — без хотя бы одного пользователь вообще не войдёт в базу.
• 🛠 Администрирование — полный доступ к управлению пользователями и настройкам. Давайте только администраторам.
• 🔒 Монопольный режим, Активные пользователи, Журнал регистрации — административные права на мониторинг.
• 🗂 Вывод — разрешение печати и сохранения; без него пользователь не выгрузит данные (иногда это и нужно).

Минимальный рабочий набор для обычного сотрудника: один из Запуск... клиента, плюс права на те объекты, с которыми он реально работает. Остальное не включайте.

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

Когда нужно, чтобы менеджер видел только свои заказы, а не все, одних галочек мало — включается RLS (ограничение доступа на уровне записей). Технически это текст условия, который платформа подставляет в каждый запрос к объекту.

В роли: выделите право (например, Чтение документа) — внизу редактора появится поле Ограничение доступа к данным. Туда пишется условие на языке запросов. Тексты, которые повторяются, выносят на вкладку Шаблоны ограничений и подставляют по имени.

После того как права расставлены, сохраните роль (Файл → Сохранить) и обновите конфигурацию базы данных: Конфигурация → Обновить конфигурацию базы данных (F7). Пока не обновите — роль существует только в конфигураторе и пользователям недоступна.

Назначение роли через пользователей и профили

Дальше два пути — в зависимости от типа базы.

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

Путь Б — через профили групп доступа (типовые базы на БСП). Здесь в конфигуратор заходить не надо, всё в режиме 1С:Предприятие под администратором:

1. Откройте Администрирование → Настройки пользователей и прав → Профили групп доступа (в УТ и ERP раздел может называться НСИ и администрирование).
2. Чтобы изменить набор ролей — не правьте поставляемый профиль, а скопируйте его кнопкой Создать на основании и правьте копию. На вкладке Разрешённые действия (роли) отмечаются роли.
3. Вернитесь в Пользователи, откройте сотрудника → Права доступа → добавьте группу доступа с нужным профилем. При необходимости здесь же задаются Значения доступа — это и есть RLS по-человечески (например, список складов или организаций).

Проверьте, что пользователь получил вход: у него должна остаться хотя бы одна роль с правом запуска клиента, иначе после сохранения он увидит «У пользователя недостаточно прав».

Роль в расширении — без снятия типовой с поддержки

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

1. В конфигураторе: Конфигурация → Расширения конфигурации. Создайте расширение (или откройте существующее), назначьте префикс имён.
2. В дереве расширения на ветке Роли → Добавить. Роль создаётся только внутри расширения, типовая конфигурация не трогается.
3. Расставьте права так же, как в основной роли. Объекты основной конфигурации в расширении доступны для назначения прав.
4. Сохраните, обновите конфигурацию базы данных.
5. В режиме 1С:Предприятие включите новую роль в копию профиля групп доступа.

Расширение не снимает конфигурацию с поддержки и переживает типовые обновления — это стандартный и безопасный способ добавить роль в Бухгалтерию, ЗУП или УТ. Если же вы добавляете роль прямо в типовую конфигурацию , она уходит «на доработку», и каждое обновление станет ручным сравнением-объединением.

Проверка прав и аудит безопасности

Роль добавлена — теперь убедитесь, что она работает ровно как задумано, и ничего лишнего не открывает.

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

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

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

Минимальный регламент безопасности, который стоит держать:

• 🔐 отдельная учётная запись каждому сотруднику, без общих «кассиров» и «менеджеров»;
• 🧾 периодический просмотр журнала регистрации на отказы в доступе — они подсказывают, где прав не хватает или где кто-то лезет не туда;
• 🧹 ревизия ролей раз в несколько месяцев: уволенных отключать (не удалять — иначе потеряется история в журнале), набор ролей сверять с должностью;
• 🗄 разграничение доступа к персональным данным сотрудников и контрагентов — это прямое требование закона о персональных данных (организационные меры и ограничение круга лиц).

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

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