При администрировании серверных баз 1С:Предприятия многие специалисты сталкиваются с архитектурной особенностью платформы: в системном каталоге кластера серверов srvinfo находится файл 1CV8Clst.lst. В данном файле хранятся параметры информационных баз, включая учетные данные для подключения службы сервера 1С к СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2). Рассмотрим, почему эти данные уязвимы и какой комплекс мер необходим для нейтрализации сопутствующих рисков информационной безопасности.
Проанализируем механизм аутентификации платформы на уровне сервера баз данных. В отличие от пароля администратора кластера 1С, который хранится в виде необратимого хеша (SHA-1) и проверяется локально самой службой, учетные данные к СУБД платформа обязана передавать внешнему драйверу в открытом виде при каждом открытии пула соединений рабочих процессов rphost.
В силу этого архитектурного ограничения платформа 1С использует для пароля СУБД симметричное обратимое шифрование с фиксированными ключами. При получении доступа к файлу 1CV8Clst.lst (через открытые сетевые ресурсы, резервные копии без шифрования или при избыточных правах в операционной системе) злоумышленник может мгновенно восстановить пароль пользователя базы данных. Прямой доступ к СУБД в обход сервера 1С позволяет обойти все встроенные механизмы защиты: роли пользователей, ограничения на уровне записей (RLS) и журнал регистрации.
Кроме того, платформа не поддерживает сквозную аутентификацию (Windows Authentication / Kerberos) для связи службы 1С с СУБД и не имеет встроенных механизмов интеграции с внешними хранилищами секретов (HashiCorp Vault и аналоги). Поэтому защита инфраструктуры полностью возлагается на грамотную настройку окружения.
Разберем по шагам практические действия, которые необходимо выполнить системному администратору для полной нейтрализации угрозы несанкционированного доступа.
Ограничение прав на уровне файловой системы ОС (каталог srvinfo)
Каталог служебных данных кластера должен быть изолирован с помощью списков контроля доступа (NTFS ACL в Windows или POSIX-прав в Linux). Доступ на чтение и запись должен быть предоставлен исключительно системной учетной записи, от имени которой запущена служба сервера 1С (например, usr1cv8), и группе локальных администраторов сервера. Любые доменные пользователи, разработчики и непривилегированные службы должны быть полностью лишены прав доступа к каталогу srvinfo.
Обязательное назначение администраторов кластера
Если в кластере 1С не настроен хотя бы один администратор, любой клиент, имеющий сетевой доступ к портам кластера (по умолчанию 1540, 1541), может через утилиту администрирования или программный COM/RAS-интерфейс создать произвольную информационную базу или изменить параметры существующих баз. Назначение администратора кластера блокирует несанкционированные изменения конфигурации и структуры информационных баз.
Сетевая изоляция портов СУБД (White-listing IP)
Порты СУБД (по умолчанию 1433 для MS SQL, 5432 для PostgreSQL) должны быть закрыты межсетевым экраном от всей корпоративной сети, терминальных серверов и рабочих станций пользователей. Пакеты к порту базы данных должны приниматься только с IP-адресов серверов, на которых запущены рабочие процессы кластера 1С. В случае с PostgreSQL дополнительно настраивается файл pg_hba.conf с явным указанием доверенных адресов нод кластера 1С. При таком подходе даже факт утечки пароля из файла конфигурации не позволит злоумышленнику открыть соединение с СУБД извне.
Принцип наименьших привилегий (Least Privilege) для учетной записи СУБД
Категорически запрещено использовать учетную запись с глобальными правами (такую как sa в MS SQL Server или postgres в PostgreSQL) для подключения информационных баз 1С. Для каждой информационной базы создается индивидуальный пользователь СУБД. Права пользователя ограничиваются рамками конкретной базы данных (роль db_owner в MS SQL или владелец схемы/базы в PostgreSQL) без назначения серверных ролей уровня sysadmin или superuser.
В среде MS SQL Server необходимо отключить расширенные системные процедуры (включая xp_cmdshell), отключить вызовы OLE Automation и заблокировать выполнение небезопасных сборок CLR, чтобы исключить выполнение стороннего кода через инъекции при наличии прав на внешние обработки в 1С.
Аудит нетипичных подключений к базе данных
На стороне СУБД настраивается логирование входящих сессий с фиксацией параметров подключающегося приложения (Application Name). Любые успешные или отклоненные попытки авторизации, инициированные не процессами rphost, а утилитами администрирования (SSMS, DBeaver, pgAdmin, sqlcmd, psql), должны фиксироваться системой мониторинга и вызывать автоматические оповещения для группы безопасности.
Защита резервных копий конфигурации кластера
Каталог srvinfo не должен включаться в общие незашифрованные планы резервного копирования, доступные широкому кругу сотрудников. Если создается резервная копия файлов конфигурации кластера, архив должен шифроваться стойкими криптографическими средствами с хранением ключей в изолированном контуре.
Выполнение описанных шагов позволяет построить эшелонированную оборону: даже при компрометации служебных файлов кластера злоумышленник не сможет установить сетевой контакт с сервером баз данных или повысить привилегии в инфраструктуре предприятия.