← На главную

Многие системные администраторы сталкиваются с ситуацией, когда стабильно работающая связка из 1С:Розница и СУБД PostgreSQL 13 внезапно перестает пускать пользователей в базу данных. Внешне это выглядит как ошибка аутентификации: платформа сообщает, что пароль пользователя базы данных не подходит. Давайте вместе разберем эту ситуацию по шагам, проанализируем причины инцидента и рассмотрим подробные инструкции по восстановлению работоспособности системы.

Анализ ситуации: почему 1С теряет доступ к PostgreSQL?

Прежде чем приступать к сбросу паролей, выясним причину, по которой СУБД внезапно перестала принимать учетные данные от сервера 1С (иногда это связано с нехваткой места). Рассмотрим несколько основных векторов проблемы.

1. Взлом базы данных и атака программ-вымогателей (Ransomware). Это самая критическая и частая причина «внезапной» смены пароля. Если порт 5432 (по умолчанию для PostgreSQL) открыт в интернет без должной защиты, ботнеты могут подобрать простой пароль суперпользователя postgres, особенно если в системе есть пользователи без пароля. Злоумышленники меняют пароль, удаляют исходную базу 1С и создают новую с названием, содержащим требование выкупа (например, README_TO_RECOVER). Из-за этого при попытке зайти 1С не может авторизоваться, и единственным выходом в такой ситуации остается архивирование и восстановление баз.
2. Блокировка учетной записи. Если в сети настроены строгие политики безопасности или работают агрессивные скрипты мониторинга со старыми учетными данными, они могут заблокировать пользователя СУБД из-за множества неудачных попыток входа. Зависший фоновый процесс 1С также мог стать причиной временной блокировки.
3. Несоответствие методов шифрования паролей. Начиная с 10-й версии и особенно в PostgreSQL 13, методом шифрования по умолчанию может выступать scram-sha-256 вместо привычного md5. Если настройки шифрования на сервере 1С и в СУБД разошлись (например, после обновления), авторизация будет падать с ошибкой.
4. Использование "ванильной" версии СУБД. Стандартные сборки PostgreSQL могут некорректно работать со специфическими блокировками платформы 1С. Для стабильной работы всегда следует использовать специально адаптированные сборки (патчи 1С).

Решение 1: Синхронизация паролей в pgAdmin и консоли серверов 1С

Часто администраторы меняют пароль суперпользователя через утилиту pgAdmin, но забывают, что платформа 1С об этом не знает. Проанализируем, как правильно обновить эти данные.

Если вы просто поменяли пароль в СУБД, вам необходимо зайти в оснастку Администрирование серверов 1С Предприятия. Разберем по шагам:

1. Откройте консоль администратора кластера 1С.
2. Перейдите в ветку Информационные базы и откройте свойства вашей базы данных.
3. В поле Пароль пользователя БД введите новый пароль, который вы задали в PostgreSQL.
4. Сохраните изменения.

Важный нюанс (ошибка создания пустой базы): При редактировании свойств подключения нужно быть предельно осторожным. Если вы случайно измените поле База данных (имя базы в самом PostgreSQL) и оставите установленным флажок Создать базу данных в случае ее отсутствия, сервер 1С подключится к СУБД, не найдет там базы с новым именем с опечаткой и просто создаст новую, абсолютно пустую базу ("чистую платформу без конфы"). Чтобы вернуть старую базу, проверьте точное написание её имени в pgAdmin, верните его в консоль 1С и снимите галочку автоматического создания.

Решение 2: Полный сброс пароля пользователя postgres (если доступ утерян)

Если пароль сменили не вы, а злоумышленники, и доступ через pgAdmin невозможен, нам понадобится механизм восстановления доступа на уровне конфигурационных файлов кластера СУБД. Выполним следующие действия.

1. Перейдите в каталог данных вашего кластера PostgreSQL (обычно это папка data, путь к которой можно посмотреть в службах Windows или логах PGDATA\pg_log\).
2. Найдите и откройте любым текстовым редактором файл pg_hba.conf.
3. Найдите строку конфигурации, которая отвечает за локальные подключения. Она выглядит примерно так: host all all 127.0.0.1/32 md5 или scram-sha-256.
4. Временно измените метод аутентификации в самом конце этой строки на trust. Это скажет серверу доверять всем локальным подключениям без запроса пароля.
5. Перезапустите службу PostgreSQL (через services.msc в Windows или systemctl restart postgresql в Linux).
6. Теперь запустите консольную утилиту psql -U postgres (или зайдите в pgAdmin). Сервер пустит вас без пароля.
7. Выполните следующий SQL-запрос для принудительной установки нового пароля:

ALTER USER postgres WITH PASSWORD 'Ваш_Новый_Надежный_Пароль';

После того как команда успешно выполнится, ОБЯЗАТЕЛЬНО вернитесь в файл pg_hba.conf. Замените trust обратно на md5 или scram-sha-256 (в зависимости от ваших исходных настроек). Снова перезапустите службу СУБД. Теперь ваша база снова защищена.

Решение 3: Создание отдельного пользователя для работы 1С

С точки зрения безопасности использовать учетную запись суперпользователя postgres для подключения информационных баз 1С — это плохая практика. Посмотрим на альтернативный и более безопасный вариант.

Если у вас есть доступ к СУБД, мы рекомендуем создать нового пользователя БД специально для конкретной базы 1С:

1. Зайдите в pgAdmin.
2. Создайте новую роль (Login/Group Roles).
3. Назначьте ей права на создание баз данных (Create databases), если планируете создавать базы из консоли 1С, либо сделайте эту роль владельцем (Owner) уже существующей базы данных вашей "Розницы".
4. Задайте этой роли сложный пароль.
5. Перейдите в консоль Администрирование серверов 1С Предприятия и в свойствах информационной базы укажите логин и пароль этого нового пользователя вместо postgres.

Такой подход защитит кластер баз данных от полной компрометации в случае перехвата учетных данных конкретной базы 1С.