Где 1С хранит пароли в базе SQL и что с этим делать администратору

Вопрос «где в SQL-базе 1С лежат пароли» возникает у администраторов в двух ситуациях: когда нужно аудиторски проверить хранение учётных данных и когда утерян пароль единственного администратора и хочется «вытащить» его напрямую из базы. Важно сразу понять ключевой факт: платформа 1С:Предприятие не хранит пароли в открытом виде ни в файловой, ни в клиент-серверной базе. В таблицах SQL Server или PostgreSQL хранятся только криптографические хеши, и восстановить из них исходный пароль штатными средствами невозможно.

Информация о пользователях информационной базы — имена, хеши паролей, настройки аутентификации — хранится в служебной таблице Params в сериализованном бинарном формате. Это не таблица с понятными колонками «логин — пароль», а единое хранилище параметров, которое платформа читает и пишет целиком через собственные механизмы. Поэтому прямая работа с этими данными через SQL-запросы ограничена и в ряде случаев опасна для целостности базы.

Ниже разобрано, как именно устроено хранение, что реально можно увидеть в SQL Management Studio, какие легальные способы сброса пароля существуют и где проходит граница между допустимым администрированием и повреждением данных.

Как 1С хранит данные о пользователях в SQL-базе

В клиент-серверном варианте работы (MS SQL Server, PostgreSQL, Oracle, IBM DB2) платформа создаёт набор служебных таблиц. Среди них есть таблица Params — универсальное хранилище параметров информационной базы. Именно туда платформа сериализует список пользователей: для каждого сохраняется имя, полное имя, хеш пароля, признаки аутентификации (парольная, аутентификация ОС), роли и прочие настройки.

Данные внутри Params лежат в полях типа image/varbinary в собственном бинарном формате платформы. Открыв таблицу в SQL Server Management Studio, вы увидите строки с именами параметров (например, блок, отвечающий за пользователей, часто содержит идентификатор со словом users) и нечитаемое бинарное содержимое. Никакой колонки «Password» с понятным значением там нет.

Отдельно стоит различать пароли пользователей информационной базы и пароли доступа к самой СУБД. Учётная запись, под которой сервер 1С подключается к SQL Server (например, sqladmin или доменная учётка), хранится в настройках сервера 1С и в конфигурации самой СУБД — к таблице Params она отношения не имеет.

Почему пароль нельзя «вытащить» запросом

Даже если вы получите полный доступ к базе на уровне СУБД и выгрузите содержимое Params, восстановить пароль из хеша напрямую не получится. Хеширование — односторонняя операция: платформа проверяет пароль, вычисляя хеш от введённого значения и сравнивая его с хранимым, а не расшифровывая сохранённое.

Теоретически хеш можно подобрать перебором, если пароль слабый (короткий, словарный). На практике это означает не «чтение пароля из базы», а взлом — со всеми юридическими последствиями, если база чужая. Для собственной базы перебор бессмыслен: проще и быстрее сбросить пароль, чем подбирать его.

Поэтому корректная постановка задачи администратора — не «как узнать пароль», а «как восстановить доступ». Механизмов для этого несколько, и все они сводятся к замене или удалению хеша, а не к его чтению.

Что реально видно в SQL Server Management Studio

Если задача — аудит, а не восстановление доступа, посмотреть структуру хранения можно безопасно, в режиме чтения. Подключитесь к SQL Server, найдите базу информационной базы и раскройте список таблиц.

1. Откройте SQL Server Management Studio и подключитесь к экземпляру сервера.
2. Найдите базу данных нужной информационной базы 1С.
3. В разделе «Таблицы» найдите dbo.Params.
4. Выполните запрос SELECT * FROM dbo.Params — вы увидите строки с именами параметров и бинарные значения.
5. Строка, связанная с пользователями, содержит сериализованный список; читаемых логинов и тем более паролей в нём при простом просмотре не будет.

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

SELECT [FileName], DATALENGTH([BinaryData]) AS DataSize FROM dbo.Params

Легальные способы сброса пароля администратора

Если пароль единственного администратора утерян, действуйте штатными методами. Первый и самый простой: если в базе есть другой пользователь с правами администратора, он меняет пароль через конфигуратор («Администрирование» → «Пользователи») или в режиме предприятия через стандартную обработку управления пользователями.

Второй способ — снятие списка пользователей через изменение признака в таблице Params на копии базы: известен приём, когда значение соответствующего параметра очищается, после чего база открывается без запроса пароля и администратор создаёт пользователей заново. Этот метод относится к неподдерживаемым: формат хранения может меняться между версиями платформы, и ошибка в бинарных данных приведёт к неработоспособности базы. Применять его допустимо только на копии и только когда других вариантов нет.

Третий вариант — если используется аутентификация операционной системы, доступ может быть восстановлен через доменную учётную запись, указанную у пользователя, без манипуляций с хешами. Также при наличии свежей выгрузки .dt иногда проще развернуть её и задать пароли заново.

1. 1
   Сделайте полный бэкап базы средствами СУБД и выгрузку .dt, если вход ещё возможен хотя бы под одним пользователем
2. 2
   Проверьте, есть ли второй пользователь с правами администратора — если да, сбросьте пароль через него
3. 3
   Проверьте, настроена ли аутентификация ОС у административных учётных записей
4. 4
   Если штатных путей нет — разверните копию базы и экспериментируйте только на ней
5. 5
   После восстановления доступа задайте новый пароль и зафиксируйте его в корпоративном хранилище секретов

Пароли к SQL Server и другие секреты рядом с 1С

Кроме паролей пользователей базы, в инфраструктуре 1С есть ещё несколько типов секретов, и их часто путают. Пароль учётной записи СУБД, под которой сервер 1С обращается к базе, задаётся при создании информационной базы и хранится в настройках кластера серверов 1С, а не в SQL-таблицах базы. Сменить его можно в свойствах информационной базы в консоли кластера.

Пароль центрального администратора кластера (если установлен) хранится в реестре кластера серверов 1С — в файлах каталога srvinfo на сервере. Пароли хранилища конфигурации — во внутреннем хранилище самого хранилища. Пароли, заданные в коде конфигурации (например, для обменов, почты, веб-сервисов), могут храниться в базе в константах или защищённом хранилище — в типовых конфигурациях часто используется подсистема, сохраняющая такие данные в зашифрованном виде.

Типичные ошибки и ограничения

Самая распространённая ошибка — попытка найти в базе таблицу с колонкой «Password» и прочитать значения. Такой таблицы не существует, и время, потраченное на перебор таблиц, бесполезно. Вторая ошибка — правка Params на рабочей базе без копии: повреждение сериализованных данных приводит к тому, что база перестаёт открываться, и восстановление возможно только из бэкапа.

Третья ошибка — хранение паролей в открытом виде в коде конфигурации или в константах строкового типа. Такие пароли действительно можно прочитать из SQL-таблиц запросом, что является уязвимостью. Если аудит показал, что пароли обменов или почты лежат в базе открытым текстом, их нужно перевести на штатные защищённые механизмы хранения и сменить.

Ограничение, о котором стоит помнить: формат сериализации в Params — внутренний формат платформы, он не документирован и может измениться при обновлении платформы. Любые инструкции по ручной правке, найденные для одной версии, на другой могут не сработать или повредить данные.

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