Аудит безопасности · 10 SM · 16 скачиваний
Аудит паролей СУБД 1С: достаётся ли пароль SQL из файла кластера 1CV8Clst.lst
Обработка за один прогон проверяет все базы кластера 1С и по каждой отвечает: достаётся ли пароль пользователя СУБД из файла кластера 1CV8Clst.lst, не слабый ли он и чем закрыть доступ. Если пароль от SQL Server потерян, тот же прогон возвращает его из файла вашего кластера.
Обработка только читает файл кластера: ничего не меняет, никуда не отправляет и к СУБД не подключается. Используйте на своей инфраструктуре и там, где у вас есть на это право.
На выходе таблица по базам кластера: сервер и тип СУБД, пользователь, извлекается пароль или защищён, отметка слабого пароля и план защиты на той же форме. Файлы кластера обработка находит сама в типовых каталогах srvinfo, к SQL Server не подключается и ничего не меняет. Нужна она администратору 1С и СУБД, который проверяет свою инфраструктуру, и тому, кто принял сервер без переданных паролей.
Платформа 1С хранит пароль пользователя СУБД в файле 1CV8Clst.lst обратимо зашифрованным: AES-128 с ключом, зашитым в саму платформу. Кто дотянулся до файла, тот дотянулся и до пароля, а значит и до данных базы напрямую в SQL Server.
Отсюда вопрос, на который мало кто знает ответ: может ли человек с правом чтения папки сервера 1С восстановить пароли СУБД всех баз кластера? Чаще всего да, и это не взлом, а штатное поведение платформы. Обработка показывает, так ли это у вас, и ничего никуда не отправляет.
Чем отличается от публичных разборов
Пароль СУБД, а не администратора кластера
Публичные разборы этой темы почти всегда про пароль администратора кластера. Здесь другой пароль: тот, под которым 1С ходит в SQL Server. Готового инструмента, который достаёт именно его, в открытом доступе нет.
Сразу по всем базам кластера, за один прогон
Обработка сама находит файлы кластера автопоиском по типовым расположениям srvinfo и сводит картину по всем базам. По каждой видно сервер СУБД, тип СУБД, пользователя и главное - извлекается пароль или защищён.
Помечает заведомо слабые пароли
Короткие и чисто числовые подсвечиваются отдельно: сразу видно, что менять в первую очередь, не разбирая список глазами.
Демо-пример внутри
Посмотреть, как выглядит отчёт, можно не подключаясь к боевому кластеру. Удобно, когда надо показать картину руководителю или подрядчику.
Два законных сценария, ради которых она написана
- 01
Аудит безопасности
Увидеть своими глазами, что пароли СУБД вашего кластера лежат в извлекаемом виде, и понять, кто фактически имеет к ним доступ: администратор домена, бэкап-оператор, подрядчик, служба резервного копирования, любой процесс с правами учётной записи сервера 1С.
- 02
Восстановление доступа
Команду сменили, дела не передали, пароль от SQL Server никто не оставил, старые не подходят, а доступ к своей же инфраструктуре вернуть надо. Обработка достаёт пароль из файла кластера, к которому у вас доступ есть.
- 03
Дальше - план защиты
Вердикт выводится прямо на форме вместе с тем, что с этим делать: обработка не только показывает дыру, но и говорит, чем её закрыть.
O'zingiz hal qila olmayapsizmi? Yozing, birga ko'ramiz
Reglament xizmatni shunday sozlaymizki, baza barqaror ishlaydi, bekaplar kafolatli tiklanadi, disklardagi joy esa kutilmaganda tugab qolmaydi.
- Narxi
- 450 000 ₸ danbir martalik sozlash; kuzatib borish - oyiga 150 000 ₸ dan; soliqlarsiz
Mavzu boyicha tahlillar
Перенос базы 1С с PostgreSQL 18 на 17: восстановление по сети клиентом старшей версии
pg_restore версии 17 архив версии 18 не читает, а обновлять приёмник нельзя или некогда. Рабочий путь: запустить pg_restore 18 на источнике и направить его по сети в сервер 17. Методика целиком: какие пути тупиковые и почему, настройка доступа на приёмнике, выгрузка и загрузка в четыре потока, SQL-сверка таблиц и индексов, почему база после переноса меньше и как считать окно работ по одной таблице. С замерами на двух базах 1С.
Сервер 1С грузит процессор: как найти причину и не обвинить не тот процесс
Порядок поиска причины, когда сервер 1С грузит процессор, а в диспетчере задач сверху rmngr или rphost. Проверки расставлены по цене: от накопленного времени ЦП и часового ряда по журналу регистрации до технологического журнала и поиска сервиса внутри менеджера кластера без перезапуска агента. С готовыми скриптами PowerShell и рабочим фильтром техжурнала.
Восстановление базы 1С из бэкапа: готовые скрипты для MS SQL и PostgreSQL
Свежая копия рабочей базы нужна регулярно - под тест, под отладку, под проверку обновления. А restore руками делать страшно: один неверный ввод, и копия легла поверх боевой базы. Готовые скрипты восстановления для MS SQL и PostgreSQL с предохранителями, которые падают до того, как что-то испорчено: имена файлов берутся из самого бэкапа через FILELISTONLY, цель сверяется с источником, служебные базы закрыты. Плюс перевод разового восстановления в ночное задание, после которого копия обновляется сама. Замер на живом сервере: база 17,8 ГБ поднимается за 140 секунд.
Анализ кода внешних обработок 1С: как проверить чужой .epf и не читать его целиком
В базе, которая живёт больше трёх лет, лежит два-три десятка внешних обработок, и код ни одной из них никто не открывал. Разбираем, что искать в чужом .epf руками, почему обычный поиск по тексту врёт в четырёх местах из четырёх, как из находок получается решение "чинить или можно жить" - и что показал прогон анализатора по нашим собственным семнадцати обработкам с площадки.
Ko'p so'raladigan savollar
Какой пароль она достаёт - администратора кластера или пользователя СУБД?
Пользователя СУБД: тот SQL-логин, под которым база подключается к серверу, из строки подключения в файле кластера 1CV8Clst.lst. Пароль администратора кластера это другое, его обработка не разбирает - именно поэтому она закрывает то, о чём в публичных разборах обычно ставят точку.
Одна учётка в трёх базах, а зашифрованный блок у всех разный. Это сбой?
Нет. Пароль шифруется со случайным довеском, поэтому одна и та же учётная запись в разных базах даёт разные строки в файле. Расшифруете все - пароль внутри один и тот же.
А пароль от Windows для этого нужен?
Нет, и в этом суть. Обработка читает файл кластера 1CV8Clst.lst, куда платформа сама кладёт пароль пользователя СУБД обратимо зашифрованным. Пароль от операционной системы тут не участвует вообще.
У нас 1С ходит в SQL под доменной учёткой, в строке подключения DBUID пустой. Что покажет обработка?
Тогда пароля в файле нет вообще: кластер подключается под учётной записью службы агента через интегрированную аутентификацию Windows, доставать нечего. По такой базе обработка покажет, что пароль не извлекается.
Зачем обработка, если пароль отдаёт и штатный ibcmd server config import?
Да, эта команда выгружает конфигурацию кластера вместе с паролем. Вывод от этого только крепче: вся защита пароля сводится к правам на каталог кластера, а не к шифрованию. Обработка сводит картину сразу по всем базам кластера и добавляет план защиты.
Что с этим делать и законно ли это вообще применять?
Единственная защита - права на файл: доступ к папке srvinfo только у учётной записи службы агента, для СУБД отдельная учётная запись с минимумом прав вместо sa, ротация при смене команды; план обработка выводит в отчёте. Инструмент для своей инфраструктуры, к чужим системам без разрешения владельца применять незаконно.
1C tizimingiz uchun bepul ekspress-audit
1-2 kun ichida bazangizni ko'rib chiqamiz, unumdorlik qayerda yo'qolayotganini topamiz va nima qilish kerakligini aytamiz. Majburiyatsiz.
Vazifani muhokama qilamiz
Eng tezi WhatsApp: vazifa haqida bir-ikki qator yozing, ish kuni davomida javob beramiz.