Роли и права пользователей 1С: что лежит в конфигурации, что в базе, а что на сервере

Роли пользователя в 1С 8.3 хранятся в двух местах сразу. Сама роль (набор прав на справочники, документы, отчёты) — это объект конфигурации, ветка Общие → Роли в Конфигураторе. А то, какие роли выданы конкретному человеку, записано в служебной таблице V8USERS внутри информационной базы. Кластер серверов 1С ролей не хранит вообще.

Частое заблуждение — искать права «на сервере» или в настройках SQL. Пользователи 1С не являются пользователями SQL Server или PostgreSQL. СУБД видит одну учётную запись, под которой подключается сервер 1С, а всё разграничение доступа делает платформа. Ниже — по уровням, с отличиями файлового и клиент-серверного варианта.

Три слоя доступа: роль, назначение роли, данные БСП

Права в 1С 8.3 складываются из трёх слоёв. Путаница начинается, когда их смешивают.

Первые два слоя есть в любой конфигурации. Третий появляется в типовых решениях на Библиотеке стандартных подсистем: БП 3.0, ЗУП 3.1, УТ 11, КА, ERP.

💡 Если коротко: «что разрешает роль» — в конфигурации, «кому роль выдана» — в базе данных, «почему выдана именно эта роль» — в справочниках БСП.

Что ещё хранится рядом с пользователем

• 👤 имя и полное имя пользователя ИБ;
• 🔑 хеш пароля и флаг «Аутентификация 1С:Предприятия»;
• 🖥 привязка к пользователю Windows (аутентификация ОС);
• 🌐 язык, основной интерфейс, режим запуска;
• 📋 список ролей.

Персональные настройки форм, отчётов и рабочего стола хранятся отдельно — в служебных таблицах хранилищ настроек (например, _CommonSettings, _FrmDtSettings, _SystemSettings). Поэтому удаление пользователя ИБ не всегда чистит его настройки.

Роли пользователя в файловой базе 1С

В файловом варианте вся информационная база — это один файл 1Cv8.1CD в каталоге базы. Внутри него лежат все таблицы: данные, конфигурация, пользователи.

Где что находится:

1. Описания ролей — в таблице Config (конфигурация базы данных) и ConfigSave (основная конфигурация, ещё не применённая к базе).
2. Пользователи и их роли — в таблице V8USERS.
3. Данные справочников БСП («Профили групп доступа», «Группы доступа», «Пользователи») — в таблицах вида _Reference….

Отдельного файла со списком пользователей рядом с базой нет. Скопировали 1Cv8.1CD — скопировали и пользователей, и их роли, и пароли.

Доступ на уровне операционной системы

У файловой базы есть ещё один слой прав, не относящийся к 1С. Каждый пользователь, который открывает базу, должен иметь права NTFS на чтение и запись в каталог базы. Нет прав на запись — 1С выдаст ошибку открытия файла, хотя роли в базе настроены верно.

Этот слой роли не заменяет. Права на папку дают доступ к файлу целиком, а что человек увидит внутри — решают роли.

Права пользователей в клиент-серверной базе на SQL

В клиент-серверном варианте те же таблицы лежат в базе данных SQL Server или PostgreSQL. Имена служебных таблиц совпадают с файловым вариантом:

Поле с ролями в V8USERS хранится в двоичном сериализованном виде. Прочитать его запросом SQL «по-человечески» не получится, и менять эту таблицу напрямую в СУБД нельзя — так легко потерять вход в базу всем пользователям сразу.

Чем права 1С отличаются от прав в СУБД

• 🗄 Сервер 1С подключается к СУБД под одной учётной записью (например, sa или отдельный логин с ролью db_owner на базу).
• 🙅 Пользователи 1С в SQL Server не создаются, их нет в списке логинов.
• 🔒 Если дать бухгалтеру доступ к базе в SQL Management Studio, он обойдёт все роли 1С и прочитает любые данные. Поэтому прямой доступ к СУБД держат только у администраторов.

Отсюда практическое правило: настраивать права в SQL для каждого сотрудника бессмысленно. Это не ограничит его в 1С и создаст дыру в безопасности.

Кластер серверов 1С и управление доступом

Кластер — это сервер приложений: агент (порт 1540), менеджер кластера (1541) и рабочие процессы. Он хранит реестр кластера в каталоге srvinfo (файл 1CV8Clst.lst в папке кластера): список информационных баз, параметры подключения к СУБД, рабочие серверы, профили безопасности.

Ролей пользователей ИБ в кластере нет. При входе в базу рабочий процесс читает V8USERS из СУБД и проверяет пароль и роли сам.

У кластера свои администраторы, и это отдельный механизм:

Когда в консоли администрирования открываете свойства базы, консоль просит логин и пароль пользователя этой базы. Проверяет их рабочий процесс по V8USERS. Если у пользователя нет административной роли, параметры базы не откроются.

💡 Профили безопасности кластера ограничивают не пользователей, а код: доступ к файловой системе, COM, внешним компонентам. С ролями их не путайте.

Где роли хранятся в типовых конфигурациях на БСП

В БП 3.0, ЗУП 3.1, УТ 11 роли напрямую в Конфигураторе почти не назначают. Цепочка такая:

1. Профиль группы доступа содержит список ролей (табличная часть ссылается на справочник идентификаторов объектов метаданных).
2. Группа доступа связывает профиль с участниками и задаёт ограничения, например по организациям.
3. При записи группы или пользователя программа вычисляет итоговый набор ролей и записывает его пользователю ИБ в V8USERS.

Найти это в интерфейсе: Администрирование → Настройки пользователей и прав. Там ссылки на «Пользователи», «Группы доступа» и «Профили групп доступа».

Почему правка в Конфигураторе «откатывается»

Это главный приём, который стоит знать. Справочник «Пользователи» БСП хранит идентификатор пользователя ИБ и при обновлении или записи синхронизирует роли с группами доступа. Добавили роль через Администрирование → Пользователи в Конфигураторе — она проживёт до ближайшего обновления прав или перезаписи пользователя.

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

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

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

Вывести роли всех пользователей:

Для Каждого ПользовательИБ Из ПользователиИнформационнойБазы.ПолучитьПользователей() Цикл
    Список = Новый Массив;
    Для Каждого Роль Из ПользовательИБ.Роли Цикл
        Список.Добавить(Роль.Имя);
    КонецЦикла;
    Сообщить(ПользовательИБ.Имя + ": " + СтрСоединить(Список, ", "));
КонецЦикла;

Проверить права текущего сеанса:

Если РольДоступна("ПолныеПрава") Тогда
    Сообщить("У вас полные права");
КонецЕсли;

МожноЧитать = ПравоДоступа("Чтение", Метаданные.Справочники.Номенклатура);

Выдать роль пользователю по имени:

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("Иванова");
Если ПользовательИБ <> Неопределено Тогда
    ПользовательИБ.Роли.Добавить(Метаданные.Роли.ПолныеПрава);
    ПользовательИБ.Записать();
КонецЕсли;

Имена ролей в коде — это имена объектов метаданных (ПолныеПрава, АдминистраторСистемы), а не синонимы, которые видны в списке. Точные имена смотрите в ветке Общие → Роли.

Перенос ролей и пользователей в другую базу

Здесь чаще всего ошибаются при копировании баз. Разные форматы выгрузки переносят разное:

Отсюда два следствия:

• 📦 Загрузили .cf в чистую базу — список пользователей будет пустым, и в базу пустят без пароля любого, у кого есть ярлык.
• 🔁 Загрузили .dt от другой организации — вместе с данными приехали чужие пользователи и пароли. Пройдитесь по списку и удалите лишних.

Выгрузка в XML удобна, чтобы сравнить права двух версий конфигурации через систему контроля версий: файл Rights.xml читается как обычный текст.

Частые проблемы с правами доступа

Удалять роль из конфигурации, пока она назначена пользователям, можно, но назначение просто пропадёт.

Потеряли пароль единственного администратора — восстанавливайте базу из резервной копии или обращайтесь к специалисту, который обслуживает базу. Ручные правки V8USERS в рабочей СУБД без копии — прямой путь к недоступной базе.

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