Пароль СУБД из 1CV8Clst.lst достать можно: разбор и защита кластера 1С

Иван Недомолков · Chop etilgan: 6 августа 2026 г.

Если поискать “расшифровать пароль СУБД 1С” или “1CV8Clst.lst пароль”, выдача почти хором отвечает: достать нельзя, зашифровано, ключ неизвестен. Ответ неверный - точнее, он верен для пароля администратора кластера и неверен для пароля пользователя СУБД, а это разные вещи. Пароль, под которым 1С ходит в SQL Server, хранится обратимо, извлекается из файла на диске и даёт прямой вход в базу данных мимо всех прав и ролей внутри 1С.

Это не уязвимость, которую “поправят в релизе”, и не результат взлома: ключ шифрования публичен и одинаков для всех установок платформы. Это следствие того, как устроен сервер 1С. Ниже - где именно лежит пароль, почему он обязан храниться обратимо, кто фактически до него дотягивается, чем оборачивается частая настройка “подключаемся под sa, чтобы просто работало”, и, главное, как закрыть дыру. Материал написан с одной рамкой: аудит собственной инфраструктуры и восстановление своего же доступа, а не доступ к чужим системам. Короче и с обсуждением в комментариях эта же история разобрана в нашей статье на Инфостарте.

Рамка и дисклеймер. Проверять свою инфраструктуру и восстанавливать доступ к собственным системам - законно и нормально. Применять описанное к чужим системам без письменного разрешения владельца - нет. Мы сознательно не публикуем ни ключ шифрования, ни готовый код расшифровки: механизм описан на уровне “что происходит и почему”, а извлечение для аудита своей базы делает обработка, которая ничего не пишет и никуда не отправляет. Имена баз, серверов и пароли в примерах - вымышленные; сценарий обобщён из практики обслуживания унаследованных кластеров.

Где 1С хранит пароль подключения к СУБД

Для каждой информационной базы кластер держит параметры подключения к СУБД в файле 1CV8Clst.lst. Типичный путь на сервере 1С:

…\srvinfo\reg_1541\1CV8Clst.lst

reg_1541 - папка рабочего процесса для порта кластера по умолчанию (1541); у вас может быть другой номер. Файл - обычный текст, открывается блокнотом. Строка одной базы выглядит примерно так (данные вымышленные):

{7732df89-…,"Base01","Base01","MSSQLServer","Server1C","DB01","1cuser",
 "<пароль пользователя СУБД: base64, AES-128>",
 "DB=DB01;DBMS=MSSQLServer;DBSrvr=Server1C;DBUID=1cuser;…"}

Разберём по полям, потому что здесь и кроется вся суть:

MSSQLServer - тип СУБД (может быть PostgreSQL, Oracle, IBMDB2);
Server1C - адрес сервера СУБД;
DB01 - имя базы данных на сервере;
1cuser - логин пользователя СУБД открытым текстом, его даже расшифровывать не нужно;
длинная строка в base64 - зашифрованный пароль этого пользователя;
строка подключения, где всё то же продублировано параметрами, включая DBUID - логин.

То есть логин к вашему SQL Server лежит в файле голым текстом. Осталось разобраться с паролем - и вот тут начинается миф про “нельзя”.

Заодно в этом же файле хранится список всех баз кластера, адреса всех серверов СУБД и - отдельным блоком - зашифрованный пароль администратора кластера 1С. Именно про него написаны почти все форумные разборы “пароль 1С не расшифровать”. Он нас сейчас не интересует: администратор кластера управляет самим кластером 1С, а прямой вход в SQL Server даёт другой пароль - пользователя СУБД. О нём и речь.

Почему “расшифровать нельзя” - это про другой пароль

Разберём миф по частям, потому что путаница здесь стоит людям ложного чувства безопасности.

Пароль пользователя СУБД зашифрован алгоритмом AES-128-CBC с фиксированным ключом и вектором инициализации, зашитыми в саму платформу 1С. Ключевое слово - “фиксированным”: ключ не генерируется под вашу установку, не зависит от пароля администратора и не хранится где-то отдельно. Он один и тот же для всех инсталляций платформы соответствующего поколения и давно разобран в открытых источниках. Поэтому расшифровка - это не подбор и не “взлом”: имея файл и общеизвестный ключ, восстановить пароль детерминированно.

Почему тогда так уверенно пишут “нельзя”? Две причины:

Путают два пароля. Про пароль администратора кластера действительно долго считалось, что он практически неизвлекаем в общем случае, и это утверждение по инерции переносят на пароль пользователя СУБД - хотя это разные поля, зашифрованные по-разному.
Само шифрование выглядит как защита. Base64 и “AES-128” в строке подключения создают впечатление сейфа. На деле это не сейф от того, кто добрался до файла, а способ платформы не держать пароль совсем уж голым текстом рядом с логином. От легитимного доступа к файлу оно не защищает вообще.

Вывод, который важно принять до того, как думать о защите: шифрование пароля СУБД в 1CV8Clst.lst не является механизмом безопасности против человека, у которого есть доступ к файлу. Оно эквивалентно хранению пароля открытым текстом для любого, кто может прочитать srvinfo.

Почему пароль вообще хранится обратимо, а не хешем

Резонный вопрос: пароли пользователей 1С платформа хранит хешем - почему с паролем СУБД иначе? Ответ - в архитектуре, и он объясняет, почему “в следующем релизе исправят” здесь не сработает.

Рабочий процесс сервера 1С (rphost) поднимается автоматически, без человека за клавиатурой, и должен сам подключиться к SQL Server - под тем логином и паролем, что заданы для базы. Аутентификация на стороне СУБД требует именно пароль, а не его хеш: хешем нельзя пройти проверку в MS SQL Server или PostgreSQL. Значит, платформе нужно хранить пароль так, чтобы уметь его восстановить и предъявить серверу СУБД. Отсюда обратимое шифрование, а не одностороннее хеширование.

Это фундаментальное свойство любой службы, которая ходит в чужую систему по паролю без участия человека: где-то на диске лежит то, что можно превратить обратно в пароль. Меняется только степень защиты хранилища, но не сам факт обратимости. Поэтому единственная точка, которую вы реально контролируете, - не “сделать пароль нерасшифровываемым” (это невозможно), а ограничить круг тех, кто может прочитать файл.

Кто на самом деле имеет доступ к паролям всех ваших баз

Теперь неприятное. Раз пароль извлекается из файла, то любой, у кого есть чтение папки srvinfo, получает пароли СУБД всех баз кластера сразу. Прикинем, у кого этот доступ есть на типовом сервере 1С:

администратор домена - почти всегда, по факту членства в группе локальных администраторов сервера;
система резервного копирования и бэкап-оператор - папка srvinfo часто попадает в бэкап целиком, а значит, пароли лежат в каждой резервной копии;
любой процесс под учётной записью службы сервера 1С - то есть скомпрометированный сервер 1С отдаёт и пароли СУБД;
подрядчик, которого пускали “посмотреть” - доступ выдали разово, а унёс он его навсегда;
файловая синхронизация или сетевая шара, если сервер по недосмотру в неё попал.

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

Худший, но самый частый случай: подключение под sa

Всё описанное выше - про доступ к данным одной базы. Но есть деталь, которая превращает “утекла одна база” в “утёк весь сервер”, и встречается она сплошь и рядом.

Обработка-аудитор достаёт тот логин, под которым 1С ходит в СУБД. Если этот логин - sa (системный администратор MS SQL Server), то прочитавший файл получает не пароль к одной базе, а пароль sa - полный контроль над всем экземпляром SQL Server:

все базы на инстансе, а не только базы 1С - бухгалтерия, склад, чужие приложения на том же сервере;
изменение любых данных без следов на уровне 1С;
выполнение команд операционной системы через SQL. Речь про xp_cmdshell: по умолчанию он выключен, но sa включает его одной командой - и дальше выполняет команды ОС с правами учётной записи службы SQL Server. От “прочитал файл” до “выполняю команды на сервере” - несколько строк.

Один текстовый файл на диске - и весь сервер баз данных, а нередко и операционная система под ним, в чужих руках. Причём sa под 1С ставят не по злому умыслу, а по инерции: “поставили временно, чтобы заработало, - потом не трогали”. Временное стало постоянным, и о нём никто не вспоминает, пока не случится инцидент.

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

Как узнать, под каким логином ходит именно ваш кластер

Не нужно ничего расшифровывать, чтобы это выяснить: логин лежит открытым текстом. В строке подключения из 1CV8Clst.lst смотрите поле DBUID (в примере выше - 1cuser). Варианты:

DBUID=sa - красный флаг, первый кандидат на замену;
DBUID= доменная учётка с широкими правами - почти так же плохо;
DBUID= отдельная учётка с доступом к одной базе - так и должно быть.

Если открывать файл руками по всем базам кластера не хочется (а на кластере из десятков баз это муторно и легко ошибиться), ровно эту инвентаризацию и делает обработка “Аудит доступности паролей СУБД”: за один прогон по всем базам показывает, где пароль извлекается, помечает заведомо слабые и выводит план защиты. К СУБД она не подключается, ничего не пишет и никуда не отправляет - только читает файл кластера на стороне сервера 1С. Сами пароли по умолчанию не показывает: виден лишь факт “извлекается / защищён”, а открытым текстом пароль появляется только по явному подтверждению - для сценария восстановления собственного доступа.

Как закрыть дыру: защита в глубину

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

1. Ограничить NTFS-права на srvinfo

Это закрывает основную массу сценариев утечки и делается за минуты. Сначала посмотрите, у кого сейчас есть доступ:

icacls "C:\Program Files\1cv8\srvinfo"

В выдаче не должно быть ни Everyone, ни BUILTIN\Users, ни широких доменных групп. Оставить чтение и запись нужно только:

учётной записи, под которой запущена служба “Агент сервера 1С” (часто USR1CV8 или отдельная сервисная учётка);
администраторам сервера.

Всё лишнее убрать, а наследование прав от родительской папки на srvinfo - отключить, преобразовав унаследованные разрешения в явные, иначе широкие группы вернутся при следующем изменении прав на родителе. Логика простая: нет доступа к файлу - нет и пароля.

2. Проверить, куда утекает папка

Права на боевом сервере - половина дела, если тот же srvinfo уезжает наружу копией. Проверьте:

бэкапы. Если папка srvinfo попадает в резервную копию сервера целиком, то пароли СУБД лежат в каждом бэкапе - а бэкапы часто хранятся с более широким доступом, чем боевой сервер. Зашифрованный пароль в открытом бэкапе - это открытый пароль.
файловые синхронизации и облачные агенты, если они настроены на диск с srvinfo;
сетевые шары. Сервер не должен светить каталог 1С в общий доступ даже “только на чтение для своих”.

3. Отдельная учётная запись СУБД с минимумом прав

Стратегическая мера, которая обесценивает саму утечку. Для каждой базы 1С - своя учётная запись SQL Server с правами только на эту базу (db_owner на конкретной базе достаточно для работы платформы), а не sa и не доменный администратор. Тогда даже извлечённый из файла пароль открывает ровно одну базу, а не весь инстанс и не операционную систему. Это единственная мера, которая работает, даже если файл всё-таки утёк.

Если сейчас везде sa - менять логин подключения нужно аккуратно: создать ограниченную учётку на стороне SQL Server, выдать ей права на базу, затем сменить параметры подключения базы в консоли кластера 1С и перезапустить рабочие процессы. Это штатная операция администрирования, но на боевом кластере её планируют на окно, а не делают на ходу.

4. Ротация при смене людей

Организационная мера, про которую забывают. Уволили администратора, отпустили подрядчика, сменилась обслуживающая компания - смените пароли СУБД и пароль администратора кластера. Тот, кто хоть раз имел доступ к srvinfo, унёс копию всех паролей с собой, и никакие права, выставленные задним числом, этого не отменяют. Ротация - единственное, что закрывает уже случившийся доступ.

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

Это законно? Проверять свою инфраструктуру и восстанавливать доступ к своим системам - да. Применять к чужим системам без разрешения владельца - нет. Весь материал - про аудит и восстановление собственного доступа.

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

У меня PostgreSQL, а не MS SQL Server - меня это касается? Да. Платформа хранит пароль пользователя СУБД так же обратимо, в файле просто указан другой тип СУБД. Специфика с sa и xp_cmdshell - это про MS SQL, но сам факт извлекаемости пароля от типа СУБД не зависит. Для PostgreSQL аналог гигиены - не подключаться под суперпользователем и ограничивать роль правами на нужную базу.

Антивирус или EDR это поймает? Ловить нечего. Чтение файла с диска процессом, у которого есть легитимный доступ, - не атака и не эксплойт, сигнатуре не за что зацепиться. Поэтому защита не в мониторинге, а в правах доступа к файлу.

Мы на облачном/арендованном сервере 1С - что меняется? Добавляется ещё один субъект с доступом к srvinfo - хостинг-провайдер и его администраторы. Это не повод для паники, но повод понимать: пароли ваших СУБД доступны тем, кто обслуживает железо. Отдельная ограниченная учётка на базу здесь особенно уместна.

Можно ли вынести пароль в переменную окружения или внешнее хранилище? Штатными средствами платформы - нет: параметры подключения хранятся в 1CV8Clst.lst, и это поведение не настраивается. Управляемая точка - только права на файл и минимизация прав самой учётной записи СУБД.

Коротко

В 1CV8Clst.lst (папка srvinfo сервера 1С) лежат логины СУБД открытым текстом и пароли - обратимо зашифрованными общеизвестным ключом платформы.
“Расшифровать нельзя” - миф, перенесённый с пароля администратора кластера на пароль пользователя СУБД. Второй извлекается детерминированно.
Обратимость - не баг, а следствие того, что сервер 1С сам ходит в СУБД по паролю. “В релизе исправят” - не про этот случай.
Кто читает srvinfo (админ домена, бэкап, подрядчик, синхронизация), тот достаёт пароли всех баз кластера в обход прав 1С.
Если подключение под sa - утекает весь SQL Server и потенциально ОС. Если под ограниченной учёткой - только одна база.
Защита: NTFS-права на srvinfo, контроль утечки папки в бэкапы и шары, отдельная учётка СУБД на каждую базу, ротация паролей при смене людей.

Проверить свой кластер за один прогон, не открывая файлы руками, помогает обработка “Аудит доступности паролей СУБД”: она показывает по всем базам, где пароль вынимается, и сразу выдаёт план защиты. А если хочется, чтобы права на srvinfo, учётки СУБД и регламент ротации привёл в порядок кто-то, кто это уже делал, - это часть нашей работы по обслуживанию баз 1С. Остальные наши обработки про права и безопасность, от матрицы прав для нейросети до анонимизатора базы, собраны на одной странице.

INFOSTART TECH EVENT 2026: конференция для 1с-специалистов. если собираетесь, регистрируйтесь по нашей ссылке. Регистрация →