Права пользователя в 1С 8.3: профили, группы доступа и запреты

Чтобы ограничить доступ пользователю в 1С 8.3, откройте Администрирование → Настройки пользователей и прав, создайте копию подходящего профиля групп доступа, уберите из неё лишние роли и включите пользователя в группу доступа с этим профилем. Так права настраиваются в БП 3.0, ЗУП 3.1, УТ 11 и других конфигурациях на Библиотеке стандартных подсистем (БСП).

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

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

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

В типовых конфигурациях над ролями построены ещё два уровня:

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

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

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

Как создать профиль и роли доступа под должность

Поставляемые профили (Бухгалтер, Главный бухгалтер, Кадровик, Менеджер по продажам и другие, набор зависит от конфигурации) изменять нельзя: их перезапишет обновление. Работают с копией.

Шаг 1. Копия профиля

1. Откройте Администрирование → Настройки пользователей и прав → Профили групп доступа.
2. Выделите профиль, ближайший к нужной должности, и скопируйте его кнопкой копирования в командной панели списка (или клавишей F9).
3. Дайте копии понятное имя, например «Бухгалтер по банку — без удаления».

Шаг 2. Состав ролей

На вкладке с разрешёнными действиями (ролями) снимите флажки с того, что должности не нужно. В БП 3.0 роли разбиты парами: «Чтение …» и «Добавление и изменение …» для одной группы объектов. Это и есть главный способ запретить редактирование:

• оставьте роль «Чтение» — пользователь видит документы и отчёты;
• снимите «Добавление и изменение» — кнопки «Создать», «Записать», «Провести» становятся недоступны.

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

Шаг 3. Свои роли в Конфигураторе

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

1. Сделайте резервную копию базы : Администрирование → Выгрузить информационную базу в Конфигураторе.
2. Создайте расширение конфигурации и добавьте в него роль. Править роли самой типовой конфигурации не стоит: это снимет её с полной поддержки и усложнит обновления.
3. В роли отметьте нужные права на объекты и обновите конфигурацию базы данных.
4. В пользовательском режиме роль из расширения появится в списке ролей профиля.

Группы доступа: как назначить права конкретному пользователю

Профиль сам по себе ничего не даёт — права появляются, когда пользователя добавляют в группу доступа.

1. Откройте Администрирование → Настройки пользователей и прав → Группы доступа.
2. Создайте группу и выберите в ней профиль, созданный на прошлом шаге.
3. На вкладке участников добавьте пользователей или группы пользователей.
4. Если в профиле есть виды ограничений (организации, склады, подразделения), заполните конкретные значения прямо в группе.
5. Запишите группу.

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

Настройки входа

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

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

Роли решают, к каким объектам есть доступ. RLS (Record Level Security) решает, к каким записям внутри объекта: бухгалтер видит документы только своей организации, кладовщик — только своего склада, расчётчик — только своего подразделения.

Как включить

1. В Администрирование → Настройки пользователей и прав установите флажок «Ограничивать доступ на уровне записей».
2. В профиле групп доступа на вкладке ограничений выберите вид доступа (например, «Организации») и режим: «Все разрешены» с перечнем запрещённых или «Все запрещены» с перечнем разрешённых.
3. В группе доступа укажите конкретные значения — нужные организации, склады, подразделения.

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

Что учесть при работе RLS:

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

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

Как запретить запуск внешних обработок и расширений

Внешняя обработка (.epf) или отчёт (.erf) выполняет код с правами пользователя, который её открыл. Если у бухгалтера есть право изменять документы, внешняя обработка сможет изменить их массово. Поэтому открытие файлов «через Файл → Открыть» нужно закрыть почти всем.

Что сделать в типовой конфигурации

• 🚫 Не включайте в профили роль «Интерактивное открытие внешних отчётов и обработок». Без неё пользователь не откроет .epf из файла.
• 📁 Нужные обработки подключайте через Администрирование → Печатные формы, отчёты и обработки → Дополнительные отчёты и обработки. Администратор загружает файл один раз и указывает, кому она доступна.
• 🧱 Расширения конфигурации подключает только администратор: в пользовательском режиме это делается в разделе Администрирование → Печатные формы, отчёты и обработки → Расширения, обычным пользователям этот раздел недоступен.

Защита от опасных действий

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

Профили безопасности кластера

В клиент-серверном варианте администратор кластера может создать профиль безопасности в консоли администрирования серверов и назначить его базе. Профиль ограничивает, что код может делать на сервере: доступ к файловой системе, запуск внешних программ, COM-объекты, интернет-ресурсы. Это защищает сервер даже тогда, когда пользователь сумел запустить недоверенный код.

Даты запрета изменения: защита закрытого периода

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

Настройка в БП 3.0 находится в разделе Администрирование → Проведение документов по ссылке «Даты запрета изменения» (в других конфигурациях — в общих настройках раздела администрирования). Варианты:

• 📅 одна дата для всех пользователей;
• 👤 разные даты по пользователям: главному бухгалтеру период открыт, остальным закрыт;
• 🏢 разные даты по организациям.

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

Аудит: кто и что сделал в базе

Ограничения без контроля работают наполовину. Главный инструмент контроля — журнал регистрации.

Настройка журнала

1. В Конфигураторе откройте Администрирование → Настройка журнала регистрации.
2. Выберите уровень «Регистрировать все события» — тогда в журнал попадут и изменения данных, а не только ошибки.
3. Задайте разбиение файлов журнала по периодам, чтобы его можно было архивировать.

Просмотр журнала

В пользовательском режиме журнал открывается через Администрирование → Обслуживание → Журнал регистрации. Отбором можно оставить:

• 👤 одного пользователя;
• 🗂 события изменения и удаления данных;
• 📄 конкретный документ или справочник;
• ⏱ интервал времени.

Для отдельного документа то же самое быстрее: в его форме найдите в меню «Ещё» переход к журналу регистрации — откроются события только по этому объекту.

Что ещё помогает в аудите:

• 👥 список активных пользователей (Администрирование → Обслуживание) — кто сейчас работает в базе и с какого компьютера;
• 🔐 отчёт по правам доступа из карточки пользователя — периодически сверяйте его с должностью;
• 📌 у документов с историей изменений (в конфигурациях, где она включена) можно посмотреть, какое поле и кто поменял.

Частые ошибки при настройке прав

• ❌ Правка поставляемого профиля. Изменения либо невозможны, либо пропадут при обновлении. Всегда копия.
• ❌ Роли через Конфигуратор в типовой базе. Программа приводит роли пользователей в соответствие с группами доступа, ручные назначения исчезнут.
• ❌ «Запрещающая» группа. Права складываются, поэтому вторая группа с меньшими правами ничего не отнимет.
• ❌ Один пользователь на несколько человек. В журнале регистрации невозможно понять, кто именно удалил документ.
• ❌ Полные права «на время». Роль «Полные права» у бухгалтера после разового действия обычно остаётся навсегда. Ставьте отдельную группу и убирайте человека из неё сразу.
• ❌ RLS сразу в рабочей базе. Проверяйте в копии под учётной записью реального сотрудника.