Администраторам информационных систем часто приходится сталкиваться с необходимостью прямого доступа к данным конфигурации через консоль SQL Server Management Studio. Основным вопросом в таких ситуациях является локализация таблицы, где физически хранятся учетные записи пользователей платформы 1С:Предприятие. В отличие от файловых баз, где данные лежат в одном файле, клиент-серверный вариант требует понимания внутренней структуры системных таблиц.
Центральным объектом хранения является таблица _Users. Именно в ней регистрируются все созданные в конфигураторе пользователи, их полные имена, короткие имена и статусы блокировки. Однако просто найти запись недостаточно: для корректного управления доступом необходимо понимать связь этой таблицы с таблицами групп и параметров.
Прямое редактирование данных в этих таблицах через графический интерфейс или простые UPDATE запросы без понимания структуры ссылок может привести к полной неработоспособности базы данных. Платформа 1С использует специфическую систему ссылок на объекты метаданных, которая отличается от стандартных реляционных связей, привычных разработчикам SQL.
Структура системных таблиц пользователей
В любой базе данных 1С, работающей под управлением MS SQL Server или PostgreSQL, пользователи хранятся не в одной, а в группе взаимосвязанных таблиц. Основной массив данных о правах и идентификации сосредоточен в таблице _Users. Каждая строка этой таблицы представляет собой уникальный объект пользователя, имеющий свой внутренний идентификатор (ссылку).
Помимо основной таблицы, критически важным элементом является таблица _Params. В ней хранятся дополнительные свойства объектов, которые не вынесены в основные поля. Для пользователей здесь могут содержаться специфические настройки, которые не отображаются в стандартной форме списка пользователей конфигуратора, но влияют на работу системы.
Третьим ключевым элементом структуры является таблица _GrpMembers. Она реализует механизм многие-ко-многим, связывая пользователей с группами доступа. Без понимания работы этой таблицы невозможно корректно определить, какие именно права имеет конкретный пользователь, так как права часто наследуются именно через групповую принадлежность.
Технические детали ссылок 1С
Внутренний идентификатор пользователя в таблице _Users (поле _RRef) состоит из 16 байт. Первые 8 байт обычно содержат префикс типа объекта, а вторые 8 байт — уникальный номер записи. При написании запросов важно учитывать этот бинарный формат или использовать функции преобразования типов 1С.
Поиск конкретного пользователя через SQL-запрос
Для нахождения нужной учетной записи администратору необходимо выполнить селективный запрос к таблице _Users. Проблема заключается в том, что имя пользователя в базе данных хранится не в виде привычной строки, а в виде ссылки или требует соединения с таблицей текстовых представлений, в зависимости от версии платформы и типа СУБД.
В большинстве современных версий платформы имя пользователя хранится в поле Description или может быть получено через функцию преобразования ссылки. Однако самый надежный способ — это поиск по логину (краткому имени), который часто используется для аутентификации при входе в систему.
Рассмотрим пример запроса, который позволяет найти пользователя по его короткому имени. Этот скрипт поможет определить внутренний идентификатор (_RRef), который потребуется для дальнейших операций, таких как блокировка или удаление.
SELECT _RRef, _Marked, _Description
FROM _Users
WHERE _Description LIKE '%Иванов%'
-- Или поиск по логину, если он хранится в отдельном поле или параметре
Стоит отметить, что поле _Marked играет роль флага удаления. Если в этом поле стоит значение 1 (или true), то объект помечен на удаление, но физически еще может присутствовать в базе до проведения процедуры очистки. При анализе списка пользователей обязательно фильтруйте записи по этому полю, чтобы не работать с «мертвыми» душами.
Используйте функцию UPPER() или LOWER() в условии WHERE при поиске имени, так как в разных версиях SQL Server чувствительность к регистру (collation) может отличаться, и запрос 'ivanov' не найдет запись 'Ivanov'.
Таблица соответствия пользователей и групп доступа
Система прав доступа в 1С построена на групповой модели. Пользователи редко получают права напрямую, чаще они включаются в состав групп, которым уже назначены роли. Таблица _GrpMembers выступает в роли связующего звена в этой иерархии.
В этой таблице хранятся пары ссылок: идентификатор группы и идентификатор пользователя (или другой группы, так как группы могут быть вложенными). Понимание структуры этой таблицы необходимо для аудита безопасности. Если вы видите подозрительную активность, проверьте, в какие группы включен данный пользователь через этот реестр.
Структура записей в таблице członков групп выглядит следующим образом:
| Поле | Описание | Тип данных |
|---|---|---|
| _IDRRef | Уникальный идентификатор записи связи | Binary(16) |
| _ParentRRef | Ссылка на родительский объект (Группу) | Binary(16) |
| _MemberRRef | Ссылка на участника (Пользователя или Группу) | Binary(16) |
При анализе прав доступа часто возникает ситуация, когда пользователь включен в несколько групп. В таком случае его итоговые права являются суммой (объединением) всех прав, назначенных этим группам. Исключить права через SQL напрямую из этой таблицы нельзя, можно лишь удалить членство пользователя в группе.
Блокировка и разблокировка пользователей в SQL
Одной из самых частых задач при администрировании через SQL является экстренная блокировка пользователя. Это может потребоваться при увольнении сотрудника с доступом к критическим данным или при обнаружении скомпрометированной учетной записи. В таблице _Users за состояние блокировки отвечает специальное булево поле.
Обычно это поле имеет имя _Blocked или аналогичное, зависящее от версии платформы. Установка значения 1 (или true) в это поле приводит к тому, что при следующей попытке входа платформа 1С выдаст сообщение о том, что пользователь заблокирован.
⚠️ Внимание: Изменение поля блокировки в таблице _Users вступает в силу только после перезапуска кластера серверов 1С или повторной авторизации пользователя. Если сессия уже активна, блокировка через SQL не разорвет текущее соединение мгновенно.
Для разблокировки пользователя необходимо выполнить обратную операцию — установить значение поля блокировки в 0. Крайне важно перед выполнением таких операций сделать резервную копию базы данных или хотя бы выгрузить таблицу пользователей, так как ошибка в синтаксисе запроса может привести к повреждению ссылочной целостности.
Используйте следующий шаблон запроса для блокировки:
UPDATE _Users
SET _Blocked = 1
WHERE _RRef = 0x050000001027334A...
Удаление пользователей и очистка ссылок
Физическое удаление пользователя из базы данных через SQL — операция рискованная. Простое удаление строки из таблицы _Users может оставить «висячие» ссылки в журналах документов, в таблицах истории изменений или в таблице _GrpMembers.
Платформа 1С использует механизм «помеченных на удаление» объектов. Корректный алгоритм удаления через SQL должен состоять из двух этапов. Сначала объект помечается на удаление (установка флага _Marked), и только затем, после проверки отсутствия зависимостей, он может быть физически удален.
- 🔍 Проверьте, не является ли пользователь владельцем каких-либо документов или справочников.
- 🗑️ Удалите записи о членстве пользователя в группах из таблицы _GrpMembers.
- 🚫 Только после этого удаляйте запись из таблицы _Users.
Если пользователь уже был удален через интерфейс конфигуратора, но остался в базе, скорее всего, он просто помечен на удаление. Для полной очистки в этом случае можно использовать стандартную обработку удаления помеченных объектов, запущенную в монопольном режиме, либо выполнить каскадное удаление вручную, зная все связанные таблицы.
☑️ Чек-лист перед удалением пользователя
Особенности хранения паролей и аутентификации
Вопрос о том, где хранятся пароли пользователей 1С в SQL, часто возникает у администраторов, пытающихся восстановить доступ. Важно понимать, что платформа 1С не хранит пароли в открытом виде. В таблице _Users или связанных таблицах параметров хранится только хеш пароля.
Алгоритм хеширования зависит от версии платформы и настроек безопасности. В старых версиях использовался менее стойкий алгоритм, в новых — криптографически стойкие хеш-функции. Восстановить исходный пароль из хеша математически невозможно, можно лишь сбросить его.
⚠️ Внимание: Попытки подмены хеша пароля вручную через SQL-запрос без использования штатных средств 1С могут привести к тому, что пользователь вообще не сможет войти в систему, так как формат хеша включает в себя Salt (случайную добавку), который генерируется при смене пароля.
Для сброса пароля администратору проще всего воспользоваться правами суперадминистратора базы данных или правами полного доступа в конфигураторе, чтобы задать новый пароль через интерфейс. Прямая манипуляция с полем хранения пароля в таблице _Params требует глубоких знаний внутренней структуры метаданных конкретной конфигурации.
Пароли в 1С хранятся в захешированном виде и не подлежат восстановлению. Единственный способ вернуть доступ — сбросить пароль через учетную запись администратора или изменить настройки аутентификации на использование учетных записей ОС.
Анализ активности и журналов регистрации
Хотя основная информация о пользователях хранится в таблице _Users, данные об их активности разбросаны по другим системным таблицам. Для полноценного аудита необходимо обращаться к регистрам накопления, хранящим журналы регистрации, если они настроены на запись в базу данных, а не в файлы.
Таблицы журналов регистрации обычно имеют префикс _Log или хранятся в специальных таблицах, имя которых зависит от настроек отбора событий в журнале. Анализ этих таблиц позволяет ответить на вопросы: кто заходил в базу, когда и с какого IP-адреса.
Частая проблема при анализе — большой объем данных. Таблицы журналов могут разрастаться до гигабайтов. Для ускорения выборки обязательно используйте индексацию по дате и по ссылке на пользователя (_RRef из таблицы _Users).
Где искать IP-адреса?
IP-адреса подключений часто хранятся в системных представлениях самого SQL Server (например, sys.dm_exec_connections), а не в таблицах 1С. Сопоставление сессии 1С и сессии SQL Server производится по идентификатору процесса (SPID).
Можно ли добавить пользователя через INSERT в таблицу _Users?
Технически это возможно, но крайне не рекомендуется. Вам придется вручную сгенерировать уникальный 16-байтный идентификатор (_RRef), правильно заполнить все обязательные поля и, возможно, создать записи в служебных таблицах. Ошибка приведет к нестабильности базы. Используйте интерфейс конфигуратора или API 1С.
Почему после UPDATE в SQL изменения не видны в 1С?
Сервер 1С кэширует метаданные и списки пользователей. После прямого изменения таблиц в SQL необходимо перезапустить службу агента сервера 1С или выполнить команду обновления конфигурации базы данных, чтобы сбросить кеш на стороне сервера приложений.
Как найти пользователя по полному имени, если в базе только короткое?
В таблице _Users обычно есть поле для полного имени (описания). Если вы ищете по короткому имени (логину), убедитесь, что вы обращаетесь к правильному полю. В некоторых конфигурациях краткое имя может храниться в таблице параметров _Params как дополнительное свойство объекта.
Что делать, если таблица _Users заблокирована на изменение?
Таблица может быть заблокирована другими транзакциями или процессами 1С. Попробуйте выполнить запрос в режиме WITH (NOLOCK) для чтения. Для записи убедитесь, что в базе нет активных пользовательских сессий, или выполните операцию в монопольном режиме через консоль администрирования.