Как роли разграничивают работу пользователей в 1С 8.3

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

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

Как роли защищают данные в 1С

Защита данных в 1С держится на трёх уровнях. Роли — только один из них, но центральный.

• 🔑 Аутентификация — кто входит. Пароль 1С или вход через учётную запись Windows (аутентификация ОС).
• 🛡️ Роли — что пользователь может делать с объектом: читать, добавлять, изменять, удалять, проводить.
• 📂 Ограничения на уровне записей (RLS) — какие именно записи ему видны. Например, документы только своей организации или только своего склада.

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

Что даёт разграничение прав на практике

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

Какие бывают права и роли в 1С

В Конфигураторе каждая роль — отдельный объект ветки Общие → Роли. Откройте роль двойным щелчком: слева дерево объектов конфигурации, справа — список прав на выбранный объект.

Права на уровне объектов

Интерактивные права зависят от основных. Нельзя дать «Просмотр» без «Чтения»: без чтения смотреть просто нечего.

Права на уровне всей конфигурации

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

• 👑 Администрирование — управление пользователями, журналом регистрации, параметрами базы;
• 🔒 Монопольный режим — вход в базу без других пользователей;
• 👥 Активные пользователи — просмотр списка сеансов;
• 📜 Журнал регистрации — просмотр журнала;
• 💻 Тонкий клиент, Веб-клиент, Толстый клиент, Внешнее соединение — каким способом можно подключаться;
• 📎 Интерактивное открытие внешних обработок и отчётов — запуск файлов .epf и .erf с диска.

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

Типичные роли в конфигурациях на БСП

Типовые конфигурации построены на Библиотеке стандартных подсистем (БСП). В них роли мелкие, «атомарные», и названия у многих совпадают:

• Полные права — доступ ко всем данным без ограничений;
• Администратор системы — служебные права администрирования; даётся вместе с «Полными правами»;
• Базовые права БСП — минимум для входа в программу;
• Запуск тонкого клиента , Запуск веб-клиента — разрешение способа подключения;
• Интерактивное открытие внешних отчётов и обработок;
• десятки ролей вида «Добавление и изменение …», «Чтение …» по конкретным разделам учёта.

По отдельности такие роли бесполезны. Работают они только в наборе — и этот набор задаёт профиль группы доступа.

Настройка профилей и групп доступа в БП, ЗУП и УТ

В типовых конфигурациях цепочка такая: роли → профиль группы доступа → группа доступа → пользователь. Пользователь получает роли только через группы, в которые входит.

Шаг 1. Подберите или создайте профиль

1. Откройте Профили групп доступа. В списке есть поставляемые профили: «Администратор», «Бухгалтер», «Главный бухгалтер» и другие — набор зависит от конфигурации.
2. Если поставляемый профиль подходит целиком — используйте его как есть.
3. Если нужны отличия — выделите профиль и скопируйте его. Состав ролей поставляемого профиля менять нельзя, а копию — можно.
4. В копии на вкладке ролей снимите или поставьте нужные флажки. Удобно включить отбор «Только выбранные», чтобы видеть итоговый набор.
5. Дайте профилю понятное имя: «Бухгалтер без зарплаты», «Кассир филиала».

💡 Копирование лучше создания с нуля. В поставляемом профиле уже есть служебные роли, без которых пользователь получит ошибку при входе или при открытии формы.

Шаг 2. Создайте группу доступа

1. Откройте Группы доступа и создайте группу.
2. Укажите профиль.
3. Добавьте участников — пользователей или группы пользователей.
4. Если включены ограничения на уровне записей, заполните вкладку ограничений: например, вид доступа «Организации» со значением «ООО Ромашка».

Один профиль можно использовать во многих группах. Например, профиль «Бухгалтер» → группа «Бухгалтеры Ромашки» и группа «Бухгалтеры Лютика» с разными организациями.

Шаг 3. Включите ограничение по записям, если нужно

По умолчанию ограничения на уровне записей выключены. Флажок «Ограничивать доступ на уровне записей» находится в тех же настройках пользователей и прав.

Шаг 4. Проверьте карточку пользователя

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

Роли в типовой и в самописной конфигурации

Главное различие — кто управляет набором ролей у пользователя.

Почему в типовой базе не трогают роли в Конфигураторе

Если поставить пользователю роль вручную в Конфигураторе, БСП при пересчёте прав приведёт набор ролей обратно к составу групп доступа. Ручная правка пропадёт, а ошибку будут искать долго.

Изменять сами типовые роли тоже не стоит: конфигурация снимается с поддержки или копит конфликты при каждом обновлении.

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

Как строят роли в самописной базе

• одна роль на одну функцию («Работа с кассой», «Просмотр отчётов продаж»), а не одна роль на сотрудника;
• отдельная роль администратора с правом «Администрирование» — только для 1–2 человек;
• флажок «Устанавливать права для новых объектов» в свойствах ролей пользователей держите выключенным: иначе каждый новый справочник автоматически станет доступен всем;
• в Конфигураторе на ветке Роли есть таблица всех ролей: в ней удобно смотреть, у каких ролей есть право на конкретный объект.

Типичные ошибки при выдаче прав

Эти ошибки встречаются в базах любого размера. Каждая открывает больше, чем планировалось.

• ❌ «Полные права» всем, чтобы не мешали ошибки доступа. Вопрос закрыт, но защиты больше нет: любой может удалить объекты, поменять настройки, закрыть или открыть период .
• ❌ Общая учётная запись на отдел. В журнале регистрации видно только «Бухгалтерия», а не того, кто удалил документ.
• ❌ Нет второго администратора. Единственный пользователь с полными правами уволился или забыл пароль — базу нечем администрировать.
• ❌ Пустой список пользователей «для удобства». Если в базе нет ни одного пользователя, вход выполняется без пароля и с полными правами.
• ❌ Права на внешние обработки у всех. Любой файл .epf из интернета запускается с правами пользователя.
• ❌ Уволенный сотрудник не отключён. Снимите «Вход в программу разрешён» в день увольнения, а не удаляйте пользователя: ссылки на него в документах сохранятся.
• ❌ Права выданы под одну задачу и забыты. Через год никто не помнит, зачем кассиру роль на зарплатные документы.

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

Отчёт о правах в карточке пользователя

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

Проверка из-под самого пользователя

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

1. Создайте тестового пользователя.
2. Включите его в те же группы доступа.
3. Войдите под ним и пройдите его типовой день: откройте документы, проведите один, постройте отчёт.
4. Всё, что выдало Нарушение прав доступа!, — повод добавить роль. Всё, что открылось, но не должно было, — повод её убрать.

Журнал регистрации

Администрирование → Обслуживание → Журнал регистрации (в УТ 11 раздел называется НСИ и администрирование). Поставьте отбор по пользователю и периоду. Видно, кто входил, какие объекты менял и удалял.

Для аудита это главный источник. Работает он только при персональных учётных записях — см. ошибку про общий логин выше.

Регулярный аудит

Права «расползаются» со временем. Проверку стоит делать раз в квартал и после каждой смены штата.

Если пользователю не хватает прав

Пользователь видит Нарушение прав доступа! или пустой список там, где у коллеги всё есть. Порядок поиска:

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

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