Администрирование системы 1С:Предприятие требует от специалиста глубокого понимания архитектуры хранения данных. Часто возникает необходимость узнать, где физически и логически располагается информация о конкретных сотрудниках, их учетных записях и правах доступа. Ответ на вопрос не так однозначен, как может показаться на первый взгляд, поскольку платформа разделяет понятия "пользователь информационной базы" и "сотрудник организации".
В стандартной конфигурации данные разбросаны по нескольким сущностям. С одной стороны, есть служебные таблицы, отвечающие за авторизацию и вход в систему. С другой — бизнес-объекты, описывающие кадровый состав компании. Понимание этой разницы критически важно при написании сложных запросов, проведении миграций или отладке проблем с безопасностью.
Некорректная работа с этими данными может привести к тому, что сотрудники потеряют доступ к рабочим местам или, наоборот, получат избыточные полномочия. Поэтому перед тем как вмешиваться в структуру хранения, необходимо четко представлять, за что отвечает каждый объект метаданных. В этой статье мы детально разберем физическую структуру таблиц и логическую связь между ними.
Разделение понятий: Пользователь ИБ и Сотрудник
Первое, что должен усвоить администратор, — это фундаментальное различие между объектом Пользователь и объектом ФизическоеЛицо или Сотрудник. В системе 1С эти сущности живут в разных измерениях. Пользователь — это учетная запись, необходимая для входа в программу. Она содержит логин, пароль (хеш), настройки интерфейса и привязку к профилям групп доступа.
Сотрудник же является частью бизнес-логики. Это человек, с которым заключен трудовой договор, которому начисляется заработная плата и который фигурирует в кадровых приказах. Один и тот же сотрудник может иметь несколько учетных записей (например, для работы в разных базах), а одна учетная запись теоретически может использоваться разными людьми (хотя это нарушение правил безопасности).
Связь между этими двумя мирами осуществляется через специальные реквизиты или регистры сведений. В типовых конфигурациях, таких как 1С:Бухгалтерия или 1С:ЗУП, эта связь часто реализуется через справочник "Пользователи", который является надстройкой над системными правами. Именно здесь происходит "сшивка" технической учетной записи и конкретного человека из штатного расписания.
⚠️ Внимание: Прямое редактирование системных таблиц пользователей через внешние SQL-клиенты (например, SSMS или pgAdmin) без использования встроенных механизмов 1С может привести к нарушению целостности хешей паролей и блокировке входа в базу.
Почему нельзя менять пароли напрямую в SQL?
Прямое изменение поля пароля в таблице пользователей невозможно, так как 1С использует специфические алгоритмы хеширования и соления. Ввод сырого значения приведет к тому, что система не сможет верифицировать пароль при входе.
Физическая структура хранения в базе данных
Если рассмотреть вопрос с точки зрения СУБД (MS SQL, PostgreSQL или файловый вариант), то информация о пользователях хранится в специфических служебных таблицах. Платформа 1С использует префиксы и специальные имена для служебных объектов. Основной массив данных об учетных записях находится в таблице _Users (или _IBUsers в зависимости от версии платформы и типа базы).
В этой таблице хранятся уникальные идентификаторы (UUID), имена пользователей в базе, а также бинарные данные, отвечающие за аутентификацию. Однако эта таблица не содержит фамилий, должностей или подразделений. Она служит исключительно шлюзом для пропуска внутрь системы. Для получения расширенной информации необходимо обращаться к таблицам справочников.
Данные о физических лицах и сотрудниках хранятся в таблицах, соответствующих справочникам _Reference14 (условный номер может меняться) или именованным таблицам, если включено использование имен в именах таблиц. Ключевым элементом связи здесь выступает поле Ссылка, которое является уникальным ключом во всей системе 1С.
Используйте консоль запросов внутри конфигуратора, чтобы увидеть точные имена физических таблиц, соответствующих вашим объектам метаданных. Это упростит написание прямых SQL-запросов при необходимости.
Ниже приведена таблица, иллюстрирующая соответствие объектов метаданных и примерных имен таблиц в реляционной СУБД:
| Объект в конфигураторе | Тип данных | Примерное имя таблицы (SQL) | Основное назначение |
|---|---|---|---|
| Пользователь (Системный) | Служебный объект | _Users / _IBUsers | Авторизация, вход в систему |
| ФизическиеЛица | Справочник | _ReferenceXX | Персонифицированные данные (ФИО, ИНН) |
| Сотрудники | Справочник | _ReferenceYY | Кадровый учет, должности, приемы |
| Пользователи (Бизнес) | Справочник | _ReferenceZZ | Связь учетной записи и сотрудника |
Справочник "Пользователи" в типовых конфигурациях
В большинстве современных решений на базе платформы 1С существует отдельный справочник с названием "Пользователи". Это не системный объект платформы, а объект конфигурации, созданный разработчиками для удобства администрирования. Именно здесь хранится основная видимая информация для администратора.
В этом справочнике можно найти такие важные реквизиты, как "Основное место работы", "Ответственный менеджер" или "Подразделение". Запись в этом справочнике ссылается на системного пользователя ИБ. Это позволяет гибко управлять правами: вы можете отключить доступ человеку, просто сняв галочку в этом справочнике, не удаляя при этом его историю как сотрудника в кадровом учете.
Важно отметить, что в некоторых конфигурациях, например в упрощенных версиях или старых релизах, такого промежуточного звена может не быть. Тогда связь налаживается напрямую между системным пользователем и справочником "ФизическиеЛица". В таком случае администратору приходится быть более внимательным при удалении записей, чтобы не потерять исторические данные по начислениям.
Табличные части и дополнительная информация
Информация о пользователе не ограничивается лишь его именем и паролем. Часто требуется знать, в каких дополнительных сервисах он зарегистрирован, какие у него настройки персонализации или история изменений прав. Эти данные часто хранятся в табличных частях справочников или в отдельных регистрах сведений.
Например, для хранения настроек интерфейса (цветовая схема, состав панелей инструментов) могут использоваться специализированные таблицы, привязанные к идентификатору пользователя. Также в табличных частях справочника "Группы доступа" хранится информация о том, какие именно роли назначены конкретному человеку.
При анализе базы данных стоит обратить внимание на регистры сведений, такие как "СоставГруппДоступа" или "НастройкиПользователей". Они хранят измерения и ресурсы, которые в разрезе времени показывают эволюцию прав доступа. Это особенно полезно при расследовании инцидентов безопасности, когда нужно понять, кто и когда имел доступ к определенному документу.
⚠️ Внимание: Структура табличных частей может отличаться в зависимости от версии конфигурации и наличия установленных обновлений. Всегда сверяйтесь с объектной моделью вашей конкретной базы перед написанием запросов.
☑️ Аудит прав пользователя
Поиск данных через консоль запросов и СКД
Для получения сводной информации о том, где и как хранятся данные, наиболее эффективным инструментом является консоль запросов в режиме предприятия или конфигуратора. Используя язык запросов 1С, можно объединить данные из системных таблиц и бизнес-справочников в единую выборку.
Типичный запрос должен соединять таблицу Справочник.Пользователи с таблицей Справочник.ФизическиеЛица по полю ссылки. При этом важно использовать оператор ЕСТЬ NULL для обработки ситуаций, когда у пользователя не заполнено основное физическое лицо (например, для технических учетных записей типа "Администратор" или "Интернет-пользователь").
ВЫБРАТЬ
Пользователи.Ссылка КАК СсылкаНаПользователя,
Пользователи.Наименование КАК ИмяВБазе,
ФизическиеЛица.Фамилия,
ФизическиеЛица.Имя
ИЗ
Справочник.Пользователи КАК Пользователи
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ФизическиеЛица КАК ФизическиеЛица
ПО Пользователи.ФизическоеЛицо = ФизическиеЛица.Ссылка
Такой подход позволяет получить полную картину без необходимости лазить внутрь системных таблиц напрямую. Система сама транслирует этот запрос в оптимальный SQL-код, учитывая особенности конкретной СУБД. Это гарантирует корректность работы даже при смене платформы с файловой на клиент-серверную.
Использование языка запросов 1С предпочтительнее прямых SQL-запросов, так как оно обеспечивает независимость от типа СУБД и корректную работу с уникальными идентификаторами (UUID).
Особенности хранения в файловом и клиент-серверном варианте
Архитектура хранения данных существенно влияет на то, как именно физически располагаются файлы с информацией. В файловом варианте базы данных (формат *.1CD) все данные, включая пользователей, упакованы в один бинарный файл. Доступ к отдельным таблицам возможен только через механизмы платформы 1С.
В клиент-серверном варианте данные распределяются по таблицам СУБД. Здесь администратор имеет возможность использовать мощные инструменты анализа базы данных, строить индексы для ускорения выборки пользователей и проводить сложный анализ логов. Однако именно здесь риск повреждения данных при некорректном вмешательстве максимален.
Стоит помнить, что в распределенных информационных базах (РИБ) информация о пользователях может реплицироваться между узлами. В таком случае мастер-узел хранит полные данные, а узлы-получатели — только необходимую часть. Нарушение правил репликации может привести к рассинхронизации прав доступа на разных узлах сети.
⚠️ Внимание: Интерфейсы и точные названия таблиц могут изменяться разработчиками конфигурации в новых версиях. Всегда проверяйте актуальную документацию к вашему релизу 1С перед выполнением административных процедур.
Часто задаваемые вопросы (FAQ)
Можно ли восстановить удаленного пользователя в 1С?
Восстановление удаленного пользователя возможно только из резервной копии базы данных (бэкапа). В самой 1С нет корзины для системных пользователей. Если запись удалена из справочника "Пользователи", но физическое лицо осталось, можно создать новую учетную запись и привязать её к существующему сотруднику, однако история его действий в системе будет утеряна.
Где хранятся пароли пользователей в открытом виде?
Нигде. 1С:Предприятие никогда не хранит пароли в открытом виде. В базе данных сохраняются только криптографические хеши. Даже администратор базы данных не может узнать пароль пользователя, он может только сбросить его, задав новый.
Как найти всех пользователей, у которых не заполнено физическое лицо?
Для этого необходимо сформировать отчет или запрос по справочнику "Пользователи" с отбором по условию "ФизическоеЛицо Пусто". Это частая ситуация для сервисных учетных записей, используемых для обмена данными или работы фоновых заданий.
Влияет ли удаление сотрудника из кадрового учета на возможность входа в 1С?
Нет, не влияет напрямую. Вход в систему контролируется справочником "Пользователи" и системными правами. Если вы уволите сотрудника в кадровом модуле, но не отключите его учетную запись в настройках пользователей, он технически сможет продолжать заходить в базу, если у него есть действующий пароль.