← На главную

При администрировании информационных баз 1С нередко возникает вопрос: почему в современных конфигурациях настоятельно рекомендуется создавать учетные записи исключительно в режиме 1С:Предприятие через справочник Пользователи, а не через список пользователей в Конфигураторе? Разберем подробно технические причины, архитектурные особенности платформы и подсистем, а также риски, к которым приводит некорректное заведение учетных записей.

Архитектурное разделение: Пользователь ИБ и Справочник «Пользователи»

Для понимания логики работы системы проанализируем, из каких компонентов состоит учетная запись пользователя в 1С:

1. Пользователь информационной базы (объект платформы): системный объект, отвечающий за аутентификацию (логин, пароль, аутентификация операционной системы, OpenID), список непосредственно назначенных ролей и язык интерфейса.
2. Элемент справочника Пользователи (прикладной объект): элемент данных, в котором хранятся реквизиты сотрудника (физическое лицо, подразделение, контактная информация, индивидуальные настройки, права доступа, группы доступа).

Связь между системным пользователем платформы и элементом справочника осуществляется по уникальному идентификатору УникальныйИдентификатор (UUID). Когда создание происходит через пользовательский режим, типовые механизмы Библиотеки стандартных подсистем (БСП) одновременно инициализируют оба объекта, сохраняя строгую связку по UUID.

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

Управление правами доступа и механизмы RLS

Рассмотрим, как устроена система разграничения прав в конфигурациях на базе БСП (например, 1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей, 1С:Бухгалтерия предприятия). В современных конфигурациях прямое назначение ролей пользователю информационной базы не применяется.

Разберем цепочку назначения прав:

1. Администратор включает пользователя в одну или несколько Групп доступа (например, «Бухгалтеры», «Менеджеры по продажам»).
2. Группы доступа ссылаются на Профили групп доступа, которые содержат утвержденный набор ролей и ограничения на уровне записей (RLS — Record Level Security).
3. Служебные механизмы подсистемы управления доступом БСП рассчитывают результирующий набор прав, автоматически назначают роли объекту платформы и заполняют служебные регистры сведений (таблицы ключей доступа).

Если администратор вручную назначит роли в Конфигураторе в обход групп доступа, возникнут следующие проблемы:

1. Сброс прав при фоновом обновлении: регламентные задания БСП по контролю прав доступа выявят несоответствие между назначенными группами доступа и системными ролями, после чего перезапишут список ролей, удалив все ручные правки из Конфигуратора.
2. Неработоспособность RLS: без включения пользователя в группы доступа не формируются ключи доступа RLS в служебных регистрах. В результате пользователь либо не увидит нужные документы и справочники, либо получит ошибку нарушения прав доступа при попытке чтения данных.

Жизненный цикл учетной записи и ссылочная целостность

Проанализируем сценарий увольнения или блокировки сотрудника. В документах информационной базы реквизиты Автор, Ответственный, Создал ссылаются на справочник Пользователи, а не на системного пользователя Конфигуратора.

Когда работа ведется по стандарту через режим 1С:Предприятие:

1. В карточке пользователя снимается признак Доступ к информационной базе разрешен или устанавливается флаг Недействителен.
2. Система блокирует возможность входа сотрудника в базу, но элемент справочника Пользователи сохраняется.
3. Все исторические документы, отчеты, журналы регистрации и задачи сохраняют валидные ссылки на реального сотрудника.

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

Работа в разделенных базах (SaaS / 1С:Фреш)

При использовании режима разделения данных (мультиарендность, работа в облачном сервисе «1С:Фреш»):

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

Расширенная аутентификация и сервисные настройки

В современных конфигурациях функционал учетной записи включает множество сервисных параметров:

1. Интеграция с внешними провайдерами аутентификации (OpenID, OpenID Connect).
2. Настройка двухфакторной аутентификации (2FA).
3. Привязка адресов электронной почты для отправки системных уведомлений и восстановления паролей.
4. Привязка к конкретному физическому лицу для зарплатных и кадровых контуров учета.

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

Итог и регламент работы

Подведем итог: в любых конфигурациях, использующих Библиотеку стандартных подсистем (а также в более ранних комплексных решениях вроде УПП при типовом ведении учета), единственно корректным способом создания и изменения учетных записей является режим 1С:Предприятие (раздел Администрирование → Настройки пользователей и прав → Пользователи).

Использование Конфигуратора для создания пользователей допускается исключительно в самописных конфигурациях «с нуля», в которых полностью отсутствуют механизмы БСП, профили доступа и справочник пользователей.