Вопрос о физическом и логическом расположении данных об учетных записях часто возникает у администраторов при миграции баз, восстановлении прав доступа или глубокой отладке системы. Понимание того, где хранятся пользователи 1С, критически важно для обеспечения информационной безопасности и корректной работы кластера серверов. Архитектура хранения кардинально отличается в зависимости от режима работы базы данных: файловый вариант или клиент-серверный с использованием СУБД.
В файловом варианте данные об учетных записях лежат непосредственно в каталоге информационной базы, что упрощает перенос, но усложняет разграничение прав на уровне СУБД. В клиент-серверном варианте информация дублируется: часть метаданных resides в файлах конфигурации, а сами пользователи и их права фиксируются в системных таблицах Microsoft SQL Server или PostgreSQL. Разберем детально структуру этих хранилищ.
Архитектура хранения в файловом варианте базы
Если ваша информационная база работает в файловом режиме, все данные, включая список пользователей, находятся в одной папке на диске. Ключевым файлом здесь является 1Cv8.1CD, который представляет собой основное хранилище данных. Однако сами определения пользователей, их пароли и настройки прав доступа хранятся в отдельном служебном файле 1Cv8.1CL (или 1Cv8c.1CL для локального списка в старых версиях). Этот файл имеет бинарный формат и не предназначен для ручного редактирования текстовыми редакторами.
При попытке открыть этот файл через блокнот вы увидите лишь набор нечитаемых символов, так как данные зашифрованы и структурированы внутренним форматом платформы 1С:Предприятие 8. Любое прямое вмешательство в структуру файла .1CL с высокой вероятностью приведет к повреждению базы данных и невозможности её запуска. Администрирование в этом режиме должно проводиться исключительно через интерфейс конфигуратора или администратора базы данных.
Важно отметить, что в файловом режиме список пользователей является локальным для конкретной базы. Это означает, что создав пользователя в одной файловой базе, вы не увидите его в другой, даже если они лежат в соседних папках. Для управления правами необходимо заходить в режим Конфигуратор и использовать меню Администрирование → Пользователи. Здесь же происходит синхронизация прав с ролями, описанными в метаданных.
⚠️ Внимание: Никогда не удаляйте и не перемещайте файл
1Cv8.1CLвручную через проводник Windows при работающей базе. Это мгновенно сбросит все настройки прав доступа и может заблокировать вход администратору, требуя восстановления из резервной копии.
Перед любыми манипуляциями с файлами базы данных обязательно создайте полную копию папки с базой на другой физический диск или в облачное хранилище.
Структура данных в клиент-серверном варианте (SQL)
В режиме работы с сервером баз данных (SQL) ситуация становится сложнее и интереснее. Здесь данные о пользователях хранятся непосредственно в таблицах СУБД. Платформа 1С:Предприятие создает специализированные системные таблицы, которые не видны обычному пользователю через интерфейс программы, но доступны администратору базы данных через инструменты вроде SQL Server Management Studio или pgAdmin.
Основная таблица, где физически располагаются записи о пользователях, обычно имеет имя _Users (префикс может меняться в зависимости от версии платформы и настроек, но часто это именно _Users или _UsersR). В этой таблице хранятся уникальные идентификаторы (UUID), имена пользователей, описания и хеши паролей. Пароли никогда не хранятся в открытом виде, что является стандартом безопасности для современных систем.
Связь между пользователями и их правами реализуется через систему ролей. В SQL это отражается в виде связанных таблиц, где каждому пользователю присваивается набор идентификаторов ролей. Если вы планируете писать сложные SQL-запросы для аудита безопасности, вам потребуется знать структуру этих системных таблиц. Прямое изменение данных в таблице _Users через SQL-запрос UPDATE строго запрещено платформой и может привести к рассинхронизации метаданных.
Технические детали таблиц SQL
В современных версиях 1С (8.3.20+) структура системных таблиц может быть усложнена использованием таблиц временных данных и специфических индексов для ускорения проверки прав доступа при старте сеанса.
Для просмотра списка пользователей на уровне SQL можно использовать следующий запрос (пример для MS SQL):
SELECT Description, Name FROM _Users ORDER BY Description;Этот запрос вернет список описаний и имен, но не покажет пароли или детальные настройки прав, так как они разнесены по другим системным объектам. Администраторам следует помнить, что платформа 1С кэширует права доступа, поэтому изменения, внесенные напрямую в SQL, могут не примениться до перезапуска сервиса кластера или сброса кэша.
Регламентные задания и фоновые обработки
Отдельного внимания заслуживают пользователи, созданные специально для выполнения регламентных заданий. Часто администраторы задаются вопросом, где хранятся учетные данные для фоновых обработок, таких как выгрузка данных в торговые системы или отправка почты. Эти пользователи также фиксируются в общем списке, но имеют специальные флаги и настройки.
В интерфейсе Администрирование такие пользователи могут быть помечены как "Технические". Их пароли часто имеют политику сложности, отличную от обычных пользователей, и могут не требовать смены по истечении срока. При настройке регламентных заданий в разделе НСИ и администрирование система обращается именно к этой записи в таблице пользователей для авторизации процесса.
- 👤 Интерактивный пользователь: имеет право на вход через толстый или тонкий клиент, видит интерфейс программы.
- ⚙️ Технический пользователь: используется только для фоновых задач, вход через интерфейс для него обычно закрыт правами.
- 🔐 Администратор системы: обладает полными правами на изменение структуры базы и управление другими пользователями.
- 📉 Только чтение: пользователь с ограниченными правами, часто используемый для аналитики или внешних отчетов.
Синхронизация с Active Directory и внешними источниками
В крупных организациях ручное создание пользователей в каждой базе 1С становится неэффективным. Здесь на сцену выходит интеграция с Active Directory (AD). В этом сценарии физические записи о пользователях в таблице _Users могут создаваться автоматически при первом входе сотрудника или синхронизироваться по расписанию.
При использовании аутентификации через ОС или AD, платформа 1С не хранит пароль пользователя в своей базе данных. Вместо этого в записи пользователя хранится ссылка на SID (Security Identifier) доменного пользователя. При попытке входа 1С делегирует проверку подлинности контроллеру домена Windows. Это значительно повышает безопасность, так как пароли не дублируются в разных системах.
Однако, даже при использовании AD, в базе 1С должна существовать запись-заглушка, связывающая доменного пользователя с конкретными ролями внутри конфигурации. Без этой записи, даже успешно прошедший аутентификацию в Windows сотрудник, не сможет получить доступ к данным, так как система не будет знать, какие права ему предоставить. Настройка этой связи происходит через механизм сопоставления пользователей.
⚠️ Внимание: При смене имени пользователя в Active Directory связь с учетной записью в 1С может разорваться, если сопоставление было выполнено по имени (Name), а не по уникальному идентификатору (SID). Всегда используйте SID для надежной привязки.
Таблица соответствия режимов и хранилищ
Для наглядного понимания различий в хранении данных приведем сводную таблицу. Она поможет быстро определить, где искать информацию в зависимости от вашей архитектуры.
| Параметр | Файловый режим | Клиент-сервер (SQL) | Аутентификация OS/AD |
|---|---|---|---|
| Физическое расположение | Файл 1Cv8.1CL |
Таблица _Users в СУБД |
Контроллер домена Windows |
| Хранение пароля | Хеш в файле базы | Хеш в таблице SQL | Не хранится в 1С |
| Инструмент правки | Конфигуратор 1С | Конфигуратор / SQL (ограниченно) | AD Users and Computers |
| Риск повреждения | Высокий при ручном вмешательстве | Средний (есть транзакции) | Низкий (внешняя система) |
Как видно из таблицы, переход на клиент-серверный вариант дает больше инструментов для администрирования на уровне СУБД, но требует более глубоких знаний структуры баз данных. Файловый вариант проще в переносе, но уязвим при сбоях файловой системы.
Выбор способа хранения пользователей диктуется архитектурой базы: файлы для малых групп, SQL и AD для предприятий со штатом от 10 человек.
Частые ошибки и восстановление доступа
Одной из самых распространенных проблем является потеря доступа пользователя из-за блокировки или забывания пароля. В файловом варианте восстановление часто требует наличия другого пользователя с полными правами. Если же заблокирован единственный администратор, ситуация становится критической. В таких случаях иногда прибегают к использованию специальных внешних обработок для сброса пароля, которые работают с файлом 1Cv8.1CL на низком уровне.
В SQL варианте восстановление проще: администратор базы данных может выполнить скрипт для сброса флага блокировки или установки нового пароля (хотя платформа может потребовать его смены при первом входе). Однако, важно помнить о политик безопасности вашей организации. Прямое вмешательство в базу данных должно быть задокументировано.
Также частой ошибкой является дублирование пользователей. При интеграции с несколькими системами или неаккуратном импорте из Excel в базе могут появиться записи с одинаковыми именами, но разными UUID. Это приводит к путанице в журналах регистрации и аудита действий пользователей. Регулярная чистка справочника пользователей от неактивных записей — обязательная процедура технического обслуживания.
☑️ Аудит пользователей 1С
FAQ: Часто задаваемые вопросы
Можно ли узнать пароль пользователя, посмотрев таблицу в SQL?
Нет, это невозможно. Платформа 1С использует криптографическое хеширование паролей. В базе данных хранится только хеш, который нельзя обратно преобразовать в исходный пароль. Вы можете только сбросить пароль на новый.
Где хранится история входов пользователей в 1С?
История входов (сеансов) хранится в журнале регистрации. В файловом варианте это файлы в подпапке log, в SQL варианте — специальные системные таблицы журнала (обычно префикс _Log), которые можно анализировать через отчеты или SQL-запросы.
Как перенести пользователей из одной базы 1С в другую?
Простого копирования файлов недостаточно, особенно для SQL баз. Рекомендуется использовать обработку "Выгрузка/Загрузка пользователей" или использовать механизм обмена данными (Корпоративная почта, XML), если конфигурация поддерживает синхронизацию справочников.
Почему пользователь есть в списке, но не может войти?
Возможно, у пользователя не установлено право на запуск приложения (флаг "Активный" снят), либо его аутентификация в Windows не сопоставлена с учетной записью в 1С. Также причиной может быть блокировка на уровне лицензионного сервера.